lkml.org 
[lkml]   [2008]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f
Date
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.

--
Greetings Michael.


\
 
 \ /
  Last update: 2008-09-17 16:25    [W:0.088 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site