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 20:23:21 Ivo van Doorn wrote:
> > On Thursday 18 September 2008, Michael Buesch wrote:
> > > On Thursday 18 September 2008 20:10:35 Ivo van Doorn wrote:
> > > > 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.
> > > 
> > > I'm kind of confused. You say one thing and revert it right in the next sentence.
> > 
> > Ehm now you are confusing me.
> > You state that software rfkill state is not the state as requested by mac80211.
> 
> 
> Nono. I will try to explain it once again. It's really easy.
> 
> Think of b43 having two independent registers for rfkill. (the actual hardware
> is different, but that doesn't matter. It's a driver internal implementation detail).
> One of these registers is readonly and it does indicate the physical rfkill button state.
> If that register indicates BLOCK, we can't do anything about it. The radio is blocked.

Which qualifies for a HW_BLOCK signal

> However, we can still write to the second register and turn the radio off through
> that, too. We can also write to the second register to turn the radio on, _but_ it won't
> physically turn on until the physical button is pressed and the first register changes
> to Unblocked.

Since the hardware doesn't toggle this field when a key is pressed, it is more the state
of the radio as configured by mac80211. And thus shouldn't generate RFKILL events.

> So you say that rfkill should only be notified about changes in the first read-only
> hardware intication bit? If that's the case, it would be possible to turn the radio off
> through mac80211 calls (using the read-write register), but still have rfkill think it's
> unblocked.

Right. Because how I see the rfkill layer is that it doesn't represent the RADIO state
but the RFKILL state (and uses that to control the RADIO state).

Ivo