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. Correction to my earlier post. If the system is booted with the RF switch off, the LED is on, whereas it should be off. The original code works correctly. 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
