Re: [RFC V2] b43: A patch for control of the radio LED using rfkill

[Michael Buesch <mb@bu3sch.de>]

On Thursday 18 September 2008 16:48:36 Henrique de Moraes Holschuh wrote:
> On Thu, 18 Sep 2008, Ivo van Doorn wrote:
> > On Thursday 18 September 2008, Henrique de Moraes Holschuh wrote:
> > > On Thu, 18 Sep 2008, Larry Finger wrote:
> > > > The changes below, along with Henriques patch "[PATCH] rfkill: update
> > > > LEDs for all state changes", and the reversion of commit bc19d6e make
> > > > the wireless LED toggle correctly.
> > > > 
> > > > This version passes UNBLOCKED to rfkill when the hardware switch enables the radio.
> > > 
> > > As I said in an email I just sent (unfortunately, after you already sent
> > > this patch), whatever goes to rfkill_force_state must be the CURRENT state
> > > of the hardware.
> > > 
> > > So, depending on what happens to b43 hardware when the hardware switch
> > > enables it (i.e. does it enable for real, ignoring the software rfkill input
> > > lines?), this patch might or might not be correct.
> > 
> > As far as I can see the v2 patch is correct, it sends the BLOCK event when the
> > rfkill key was pressed to block the radio and the UNBLOCK event when the rfkill
> > key was pressed to unblock the radio.
> 
> If rfkill_force_state() is being used, you MUST send to it the *real* radio
> state.  Not the cached radio state, not "desired" radio state, not "user
> requested" radio state.  It has to be the *real* radio state.
> 
> If a device driver is not doing so, it is incorrect and either it must send
> the real radio state, or it should be doing something else than calling
> rfkill_force_state().

So well. You tell me this way, and Ivo tells me the other way around to not
announce SW_BLOCKED state ever. ;)
What's actually right?

-- 
Greetings Michael.