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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
