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

[Ivo van Doorn <ivdoorn@gmail.com>]

On Thursday 18 September 2008, Michael Buesch wrote:
> 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.

Ah ok. In that case b43 should do:

send HW_BLOCK when the hardware rfkill state is set to block
send SOFT_BLOCK when the software rfkill state is set to block

But it shouldn't (and that change was the start of this discussion) send SOFT_BLOCK
when mac80211 disabled the radio.

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

Ok.

Ivo