Re: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f

[Henrique de Moraes Holschuh <hmh@hmh.eng.br>]

On Wed, 17 Sep 2008, Matthew Garrett wrote:
> 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).

I sure hope you mean "the documentation WAS confusing"... because if it is
still confusing, I have not got any comments or ideas about how it could be
improved yet... (HINT!).

> 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

Actually 2 and 3 will fight each other, and weird things will happen.

> 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.

Correct.

However, rfkill_force_state() is NOT updating LED states (I just checked).
I will sleep on the issue, and send in a patch tomorrow.

This probably means a small patch to rfkill + Matthew's fixed patch to use
rfkill_force_state() in b43 will fix the regression in the right way.

I don't care either way which kind of fix goes to 2.6.27, though.

The proper fix for rfkill will be in two stages. A small fix now, and a
complete change on the LED handling to use the blocking notifier chain
instead later on (which will clean up rfkill code somewhat).

-- 
  "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