kernel/drivers/net/wireless/marvell, branch linux-4.16.y

mwifiex: resolve reset vs. remove()/shutdown() deadlocks

2018-01-16T16:00:17Z

Commit b014e96d1abb ("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: b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()") Cc: Cc: Xinming Hu Signed-off-by: Brian Norris Signed-off-by: Kalle Valo

Revert "mwifiex: cancel pcie/sdio work in remove/shutdown handler"

2018-01-16T16:00:16Z

This reverts commit b713bbf1471b56b572ce26bd02b81a85c2b007f4. The "fix" in question does not actually fix all related problems, and it also introduces new deadlock possibilities. Since commit b014e96d1abb ("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 Signed-off-by: Brian Norris Signed-off-by: Kalle Valo

mwifiex: cancel pcie/sdio work in remove/shutdown handler

2018-01-08T17:38:11Z

The last command used to shutdown firmware might be timeout, and trigger firmware dump in asynchronous pcie/sdio work. The remove/shutdown handler will continue free core data structure private/adapter, which might be dereferenced in pcie/sdio work, finally crash the kernel. Sync and Cancel pcie/sdio work, could be a fix for above cornel case. In this way, the last command timeout could be handled properly. Signed-off-by: Xinming Hu Signed-off-by: Kalle Valo

mwifiex: debugfs: trigger device dump for usb interface

2018-01-08T17:36:56Z

This patch extend device_dump debugfs function to make it works for usb interface. For command timeouts, USB firmware will automatically emit firmware dump events, so we don't implement device_dump(). For user-initiated dumps, we trigger it by issue firmware dump event command to firmware, as there is no command response, do not start 10s timer. Signed-off-by: Xinming Hu Signed-off-by: Cathy Luo Signed-off-by: Kalle Valo

mwifiex: device dump support for usb interface

2018-01-08T17:36:55Z

Firmware dump on usb interface is different with current sdio/pcie chipset, which is based on register operation. When firmware hang on usb interface, context dump will be upload to host using 0x73 firmware debug event. This patch store dump data from debug event and send to userspace using device coredump API. Signed-off-by: Xinming Hu Signed-off-by: Cathy Luo Signed-off-by: Kalle Valo

mwifiex: refactor device dump code to make it generic for usb interface

2018-01-08T17:36:55Z

This patch refactor current device dump code to make it generic for subsequent implementation on usb interface. Signed-off-by: Xinming Hu Signed-off-by: Cathy Luo Signed-off-by: Ganapathi Bhat Signed-off-by: Kalle Valo

mwifiex: cfg80211: do not change virtual interface during scan processing

2017-12-07T13:30:57Z

(1) Change virtual interface operation in cfg80211 process reset and reinitilize private data structure. (2) Scan result event processed in main process will dereference private data structure concurrently, ocassionly crash the kernel. The cornel case could be trigger by below steps: (1) wpa_cli mlan0 scan (2) ./hostapd mlan0.conf Cfg80211 asynchronous scan procedure is not all the time operated under rtnl lock, here we add the protect to serialize the cfg80211 scan and change_virtual interface operation. Signed-off-by: Limin Zhu Signed-off-by: Xinming Hu Signed-off-by: Kalle Valo

mwifiex: do not support change AP interface to station mode

2017-12-07T13:26:27Z

Firmware do not support change interface from micro-ap mode to station mode, forbid this operation Signed-off-by: Cathy Luo Signed-off-by: Xinming Hu Signed-off-by: Kalle Valo

mwl8k: Expand non-DFS 5G channels

2017-12-07T13:17:26Z

Add non-DFS 5G upper channels (149-165) besides existed 4 lower channels (36, 40, 44, 48). Signed-off-by: Weixiao Zhang Signed-off-by: Kalle Valo

Merge tag 'wireless-drivers-next-for-davem-2017-11-03' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next

2017-11-04T09:07:50Z

Kalle Valo says: ==================== wireless-drivers-next patches for 4.15 Mostly fixes this time, but also few new features. Major changes: wil6210 * remove ssid debugfs file rsi * add WOWLAN support for suspend, hibernate and shutdown states ath10k * add support for CCMP-256, GCMP and GCMP-256 ciphers on hardware where it's supported (QCA99x0 and QCA4019) ==================== Signed-off-by: David S. Miller