If there is a problem with the firmware load (eg, firmware not present in
/lib/firmware/brcm), then the driver would dump its stack instead of bailing
out gracefully. Root cause was an uninitialized variable (wl->pub) being
dereferenced in the rfkill portion of a cleanup routine (wl_remove). Fix was
to move the rfkill calls into the correct spot in wl_remove().
Signed-off-by: Roland Vossen <rvossen@xxxxxxxxxxxx>
Reviewed-by: Arend van Spriel <arend@xxxxxxxxxxxx>
---
drivers/staging/brcm80211/brcmsmac/wl_mac80211.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/brcm80211/brcmsmac/wl_mac80211.c b/drivers/staging/brcm80211/brcmsmac/wl_mac80211.c
index 3f6365d..a52cbf7 100644
--- a/drivers/staging/brcm80211/brcmsmac/wl_mac80211.c
+++ b/drivers/staging/brcm80211/brcmsmac/wl_mac80211.c
@@ -1206,15 +1206,13 @@ static void wl_remove(struct pci_dev *pdev)
return;
}
- /* make sure rfkill is not using driver */
- wiphy_rfkill_set_hw_state(wl->pub->ieee_hw->wiphy, false);
- wiphy_rfkill_stop_polling(wl->pub->ieee_hw->wiphy);
-
if (!wlc_chipmatch(pdev->vendor, pdev->device)) {
WL_ERROR("wl: wl_remove: wlc_chipmatch failed\n");
return;
}
if (wl->wlc) {
+ wiphy_rfkill_set_hw_state(wl->pub->ieee_hw->wiphy, false);
+ wiphy_rfkill_stop_polling(wl->pub->ieee_hw->wiphy);
ieee80211_unregister_hw(hw);
WL_LOCK(wl);
wl_down(wl);
--
1.7.1
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
