1. 17 1月, 2018 3 次提交
    • K
      Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git · 70c8de0c
      Kalle Valo 提交于
      ath.git patches for 4.16. Major changes:
      
      ath9k
      
      * add MSI support (not enabled by default yet)
      70c8de0c
    • B
      mwifiex: resolve reset vs. remove()/shutdown() deadlocks · a64e7a79
      Brian Norris 提交于
      Commit b014e96d ("PCI: Protect pci_error_handlers->reset_notify()
      usage with device_lock()") resolves races between driver reset and
      removal, but it introduces some new deadlock problems. If we see a
      timeout while we've already started suspending, removing, or shutting
      down the driver, we might see:
      
      (a) a worker thread, running mwifiex_pcie_work() ->
          mwifiex_pcie_card_reset_work() -> pci_reset_function()
      (b) a removal thread, running mwifiex_pcie_remove() ->
          mwifiex_free_adapter() -> mwifiex_unregister() ->
          mwifiex_cleanup_pcie() -> cancel_work_sync(&card->work)
      
      Unfortunately, mwifiex_pcie_remove() already holds the device lock that
      pci_reset_function() is now requesting, and so we see a deadlock.
      
      It's necessary to cancel and synchronize our outstanding work before
      tearing down the driver, so we can't have this work wait indefinitely
      for the lock.
      
      It's reasonable to only "try" to reset here, since this will mostly
      happen for cases where it's already difficult to reset the firmware
      anyway (e.g., while we're suspending or powering off the system). And if
      reset *really* needs to happen, we can always try again later.
      
      Fixes: b014e96d ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()")
      Cc: <stable@vger.kernel.org>
      Cc: Xinming Hu <huxm@marvell.com>
      Signed-off-by: NBrian Norris <briannorris@chromium.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      a64e7a79
    • B
      Revert "mwifiex: cancel pcie/sdio work in remove/shutdown handler" · 7e34c0d2
      Brian Norris 提交于
      This reverts commit b713bbf1.
      
      The "fix" in question does not actually fix all related problems, and it
      also introduces new deadlock possibilities. Since commit b014e96d
      ("PCI: Protect pci_error_handlers->reset_notify() usage with
      device_lock()"), the race in question is actually resolved (PCIe reset
      cannot happen at the same time as remove()). Instead, this "fix" just
      introduces a deadlock where mwifiex_pcie_card_reset_work() is waiting on
      device_lock, which is held by PCIe device remove(), which is waiting
      on...mwifiex_pcie_card_reset_work().
      
      The proper thing to do is just to fix the deadlock. Patch for this will
      come separately.
      
      Cc: Signed-off-by: Xinming Hu <huxm@marvell.com>
      Signed-off-by: NBrian Norris <briannorris@chromium.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      7e34c0d2
  2. 16 1月, 2018 24 次提交
  3. 15 1月, 2018 12 次提交
  4. 13 1月, 2018 1 次提交