CHROMIUM: mwifiex: free buffers and poison lists after wiphy teardown
In mwifiex_adapter_cleanup(), we still have wireless dev(s) and wiphy
exposed to user space, and commands might still be in flight. We've
started to cancel them and halt our internal threads, but we can't
start free-ing memory and poisoning lists (e.g.,
mwifiex_free_lock_list()) until after we've waited for all requests to
exit. That only happens once we've removed our interfaces
(mwifiex_del_virtual_intf()) and unregistered the wiphy
(wiphy_unregister()).
Let's move this tear-down into mwifiex_unregister(), a safe spot.
This resolves bugs seen when we try to exercise the card_reset()
functionality, which removes and reinitializes the entire adapter. Bugs
can be easily triggered synthetically by, for example, initiating a scan
then trying to reset the device:
iw mlan0 scan &
sleep 0.5
echo 1 > /sys/kernel/debug/mwifiex/mlan0/reset
Editorial note: I'm working on similar fixes for upstream (and, e.g.,
chromeos-4.4), but the driver has diverged quite a bit. AFAICT, the same
bug still applies there though.
BUG=b:62836830
TEST=`iw mlan0 scan & sleep 0.5; echo 1 > /sys/kernel/debug/mwifiex/mlan0/reset`
[wireless-3.8->wireless-3.4: conflicts on dev_dbg() vs. mwifiex_dbg()]
Change-Id: I568c127764b1bac1a3586ed085ebb12ec1e7667b
Signed-off-by: Brian Norris <briannorris@chromium.org>
(cherry picked from commit f0e245e28282a85dff50c864b962a85ed8d93ad9)
Reviewed-on: https://chromium-review.googlesource.com/588376
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
(cherry picked from commit c804e9dda3c89bf07f4f09ea9a6b94df79d6a4f1)
Reviewed-on: https://chromium-review.googlesource.com/765129
3 files changed
