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>] [day] [month] [year] [list]
Date:	Thu, 26 Apr 2007 23:25:59 +0200
From:	Éric Piel <Eric.Piel@...mplin-utc.net>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	mitr@...ny.cz, Ivo van Doorn <ivdoorn@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 3/5] wistron_btns: add led support

[re-CC'ing lkml as it's back to the original topic]
26.04.2007 17:50, Dmitry Torokhov wrote/a écrit:
> On 4/26/07, akpm@...ux-foundation.org <akpm@...ux-foundation.org> wrote:
>> From: Eric Piel <eric.piel@...mplin-utc.net>
>>
>> Add support to wistron_btns for leds that comes with the multimedia keys.
>> Mail and wifi leds are supported, on laptops which have them.  
>> Depending on
>> the laptop, wifi subsystem may control just the led, or both the led and
>> the wifi card.  Wifi led interface is activated only for the former 
>> type of
>> laptops, as the latter type is already managed.  Leds are controled by 
>> the
>> interface in /sys/class/leds.
> 
> I am not sure if we want to allow controlling WIFI state via leds. I'd
> rather plug it into RFkill infrastructure once it is merged and have
> leds only reflect state of the corresponding switch.
> 
Sorry if I wasn't clear. This is basically what does the driver. At 
least, the led interface _do not_ control the WIFI state :-)

What I meant is that there are two kinds of laptops:
A - the one where wifi led _only_ is controlled by the wistron hardware. 
Wifi card is controlled completely independently (pcmcia).
B - the one where wifi card _and_ wifi led are controlled by the wistron 
hardware (they are completely bound).

So far, only B laptops were handled, à la RFkill: the button directly 
modifies the wifi state and wifi led with no userspace involvement. My 
patch adds wifi led interface only to A laptops, only the led is 
controlled. So wifi state is never modified by led interface.

I hope I cleared up what does this patch and that it's ok with you. If 
not, just let me know which behaviour you think would be more 
appropriate and I'll hack a new patch :-)

See you,
Eric
-
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