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

[Larry Finger <Larry.Finger@lwfinger.net>]

Henrique de Moraes Holschuh wrote:
> 
> IMHO if tx power off is handled by the wireless device driver through the
> software rfkill line, it DOES MEAN the radio goes into rfkill SOFT_BLOCK.
> 
> As long as the rfkill class is kept syncronized with reality through the use
> of rfkill_force_state(), this WILL work just fine, because no input events
> that change any other devices are ever sent by the rfkill core.
> 
> Now, if any input event generation (by the wireless device driver, since
> rfkill core NEVER does it) is in the picture, it could be more complicated
> (or not... after all, an *INPUT DEVICE* switch would simply *always* match
> the *particular* hardware rfkill input line it is tied to, regardless of
> radio state -- the input device does not CARE at all about the software
> rfkill lines, other hardware rfkill lines, wireless tx power state, or phase
> of the moon).

OK, now I'm totally confused. I realize that English is probably not
your first language, but simple declarative sentences would be nice.

The situation with b43 is as follows:

(a) When the hardware switch is off, the radio is hardware blocked.

(b) When the hardware switch is on, the radio should follow whatever
mac80211 and userland wants.

What should b43 do to make this happen? Does V2 do it right?

Larry