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

[Michael Buesch <mb@bu3sch.de>]

On Thursday 18 September 2008 19:48:27 Ivo van Doorn wrote:
> Well no actually, when the radio state (software rfkill state in your words)

No, "radio state" is _not_ "software rfkill state" in my words.
It's an independent state.
The actual physical radio state is a combined state of the two sw and hw state bits.
If either bit blocks the radio, it's physically blocked. We cannot toggle the hw bit
from software.

> it shouldn't be send to rfkill at all. rfkill should only be informed about the hardware
> rfkill state changes.

So that's fine. We just revert the patch that caused all the trouble and we will
gain _exactly_ that.

> > Do not change any software state from within the hardware state change handler.
> > This will blow up.
> 
> When you use userspace tools this won't happen since the hardware state change handler
> will send an uevent to userspace which might act upon that, and will eventually send an
> instruction back to the hardware, but that goes through a different thread.

It will semantically blow up. See the initial mail from Larry with the regression report.

-- 
Greetings Michael.