Matthew Garrett wrote: > I've reworked the rfkill code in b43. This ought to be more consistent > with the other drivers and it seems to work on the machines I've tested > it on here, but it'd be good to get some feedback. > > Firstly, I've replaced the polled input device. It's just some delayed > work now. It polls the hardware every second to determine whether the > radio has been hardware killed or not. If it has, it sets the rfkill > state to HARD_BLOCKED. If the radio is enabled and the previous state > was HARD_BLOCKED, it resets the state to UNBLOCKED. If the radio is > enabled and the previous state was SOFT_BLOCKED, it leaves the state as > is. > > I also removed some of the complexity from the rfkill toggle function, > since the rfkill core will handle the case of the user requesting a > change from HARD_BLOCKED without the driver needing to care. > > The final change is that I removed the code for changing the wireless > state in response to the txpower configuration in mac80211. Right now, I > can't see any way for this to work correctly - if the user disables the > radio via rfkill, mac80211 doesn't flag the radio as disabled. As a > result, the next time the configuration callback is called, b43 > reenables the radio again, even though the user has explicitly disabled > it. I don't think any of the other drivers handle this case, so I'm not > really sure what the best way to handle this in future is. The current > situation certainly seems broken. > > How does this look to people? All this discussion about hard vs soft rfkill makes my head hurt and I have stopped reading those posts. With this patch, my b43 device and its LED still work. 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
