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:	Tue, 16 Sep 2008 12:08:48 -0500
From:	Larry Finger <Larry.Finger@...inger.net>
To:	Michael Buesch <mb@...sch.de>
CC:	bcm43xx-dev@...ts.berlios.de,
	John Linville <linville@...driver.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Adel Gadllah <adel.gadllah@...il.com>,
	wireless <linux-wireless@...r.kernel.org>
Subject: Re: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f

Michael Buesch wrote:
> On Tuesday 16 September 2008 16:18:34 Larry Finger wrote:
>> Since commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f entitled
>> "b43/b43legacy: add RFKILL_STATE_HARD_BLOCKED support", the radio LED
>> no longer responds to rfkill switch events.
>>
>> ATM, I do not have a fix, other than reversion of this commit.
> 
> It's kind of bogus that it pokes with the software rfkill state
> from within the hardware rfkill handler.
> 
> Please revert this patch. The commit log says nothing about
> why this is needed and I don't see a point in overriding the state
> in the rfkill-private data structure from within the driver.

I agree with Michael. From what I know, the only possible reason for
having this state would be if user space could somehow affect the
state of the hardware switch. As the user's finger is the only such
thing, then there is no use for the RFKILL_STATE_HARD_BLOCKED state,
particularly when it breaks LED operations.

Please revert the patch.

Larry
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ