Re: Regression in 2.6.27-rcX caused by commitbc19d6e0b74ef03a3baf035412c95192b54dfc6f

[Henrique de Moraes Holschuh]

On Wed, 17 Sep 2008, Michael Buesch wrote:
> On Wednesday 17 September 2008 01:32:40 Matthew Garrett wrote:
> > On Tue, Sep 16, 2008 at 02:30:35PM -0500, Larry Finger wrote:
> > 
> > > I didn't say it was not possible. What I said is that _ONLY_ the
> > > operator's finger could change the state, just like in your laptop.
> > > Thus it makes absolutely no difference what state RFKILL thinks it is
> > > in.
> > 
> > Of course it makes a difference. The reason why two states are provided 
> > is to allow userspace to distinguish whether it can unblock the device 
> > or not. It's clear that b43's rfkill code is astonishingly broken (and 
> > that's not a criticism of anyone involved - the documentation's 
> > confusing and there weren't any good examples of how it should be 
> > implemented).
> > 
> > The real question is how the LED state is supposed to be being toggled, 
> > and what that's got to do with rfkill. I /think/ that the current state 
> > of events is:
> 
> Read the rfkill code. It toggles a LED trigger if the state changes from
> UNBLOCKED to BLOCKED. b43 uses that trigger to run the radio LED.
> 
> > 1) User toggles state
> > 2) b43 changes rfkill state (by using rfkill_force_state). The LED state 
> > should also be changed in the process.
> 
> No it shouldn't. LEDs are entirely handled by triggers. We must _never_ toggle
> the LED state from within b43 directly via hardcoded stuff.
> rfkill is responsible for handling the radio LEDs in the machine.

He means rfkill_force_state() should change the LED state in the process,
which it isn't doing.

It is an one-line patch, I am testing it now.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/