On Wed, 17 Sep 2008, Michael Buesch wrote: > On Wednesday 17 September 2008 01:32:40 Matthew Garrett wrote: > > On Tue, Sep 16, 2008 at 02:30:35PM -0500, Larry Finger wrote: > > > > > I didn't say it was not possible. What I said is that _ONLY_ the > > > operator's finger could change the state, just like in your laptop. > > > Thus it makes absolutely no difference what state RFKILL thinks it is > > > in. > > > > Of course it makes a difference. The reason why two states are provided > > is to allow userspace to distinguish whether it can unblock the device > > or not. It's clear that b43's rfkill code is astonishingly broken (and > > that's not a criticism of anyone involved - the documentation's > > confusing and there weren't any good examples of how it should be > > implemented). > > > > The real question is how the LED state is supposed to be being toggled, > > and what that's got to do with rfkill. I /think/ that the current state > > of events is: > > Read the rfkill code. It toggles a LED trigger if the state changes from > UNBLOCKED to BLOCKED. b43 uses that trigger to run the radio LED. > > > 1) User toggles state > > 2) b43 changes rfkill state (by using rfkill_force_state). The LED state > > should also be changed in the process. > > No it shouldn't. LEDs are entirely handled by triggers. We must _never_ toggle > the LED state from within b43 directly via hardcoded stuff. > rfkill is responsible for handling the radio LEDs in the machine. He means rfkill_force_state() should change the LED state in the process, which it isn't doing. It is an one-line patch, I am testing it now. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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
