linux-kernel - Re: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 17 Sep 2008 16:22:55 +0200
From:	Michael Buesch <mb@...sch.de>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Larry Finger <Larry.Finger@...inger.net>,
	Carlos Corbacho <carlos@...angeworlds.co.uk>,
	Adel Gadllah <adel.gadllah@...il.com>,
	wireless <linux-wireless@...r.kernel.org>,
	bcm43xx-dev@...ts.berlios.de, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/