Re: [patch 3/5] wistron_btns: add led support

From: Éric Piel
Date: Thu Apr 26 2007 - 17:26:35 EST

[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@xxxxxxxxxxxxxxxxxxxx <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
From: Eric Piel <eric.piel@xxxxxxxxxxxxxxxx>

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,
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at