Re: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f

[Matthew Garrett]

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:

1) User toggles state
2) State toggle is used by b43 to generate KEY_WLAN (this is broken)
3) rfkill-input toggles the rfkill state, changing the LED state in the 
process

What *should* be happening is:

1) User toggles state
2) b43 changes rfkill state (by using rfkill_force_state). The LED state 
should also be changed in the process.

It looks like the commit in question gets part of the way to 
implementing the second of these situations, but will now change the 
rfkill state at the same time that rfkill-input tries to. I agree that 
it should be reverted for now, but because it's (a) broken (changing the 
state member directly is wrong) and (b) potentially open to strange 
states being generated by rfkill-input trying to change the state after 
it's already been changed. The general intent is correct.

-- 
Matthew Garrett | mjg59@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/