Re: [PATCH] rfkill: always init poll delayed work

[Larry Finger <Larry.Finger@lwfinger.net>]

Johannes Berg wrote:
> 
> I do mean that, but I don't think you can access the 802.11 core's MMIO
> while it's down. I'm out of ideas expect taking the core up, checking,
> and down again periodically.

You were right. What I missed was that the stop callback was taking
the interface down to the uninitialized state, which caused the rfkill
poll routine to bail out without testing the switch state in the
hardware. A quick fix is for the poll routine to call
b43_wireless_core_init() whenever it detects the uninitialized state.
This call brings the interface back to the initialized state where the
 switch state can be tested. With this change, the radio now follows
the switch. The LED now stays on all the time - always something to fix.

What bothers me is that this seems like a lot of work when the same
effect could be achieved by simply turning the radio off/on when the
rfkill blocking state changes. Perhaps there should be the option of
using two new ieee80211_ops callbacks (radio_off/radio_on) that would
default to stop/start if not specified. By specifying these callbacks,
each driver could choose how intrusive the radio shutdown need be.

Larry