summaryrefslogtreecommitdiff
path: root/net/bluetooth/cmtp
diff options
context:
space:
mode:
authorJohannes Berg <johannes.berg@intel.com>2016-12-13 10:29:07 +0100
committerLuca Coelho <luciano.coelho@intel.com>2017-02-06 19:19:26 +0200
commit23aeea943b466083637dfd878b298e76416fcc29 (patch)
treee0f21ab30e573c3b664ab1d450a5dc527cbba8f4 /net/bluetooth/cmtp
parent5594d80e9bf46d607bfcb08df0353b009dd6e2e8 (diff)
iwlwifi: pcie: fix another RF-kill race
When resuming, it's possible for the following scenario to occur: * iwl_pci_resume() enables the RF-kill interrupt * iwl_pci_resume() reads the RF-kill state (e.g. to 'radio enabled') * RF_KILL interrupt triggers, and iwl_pcie_irq_handler() reads the state, now 'radio disabled', and acquires the &trans_pcie->mutex. * iwl_pcie_irq_handler() further calls iwl_trans_pcie_rf_kill() to indicate to the higher layers that the radio is now disabled (and stops the device while at it) * iwl_pcie_irq_handler() drops the mutex * iwl_pci_resume() continues, acquires the mutex and calls the higher layers to indicate that the radio is enabled. At this point, the device is stopped but the higher layers think it's available, and can call deeply into the driver to try to enable it. However, this will fail since the device is actually disabled. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Diffstat (limited to 'net/bluetooth/cmtp')
0 files changed, 0 insertions, 0 deletions