Date: Wed, 2 Nov 2005 14:56:14 +0100
From: Pavel Machek <pavel@suse.cz>
To: Richard Purdie <rpurdie@rpsys.net>
Cc: vojtech@suse.cz, lenz@cs.wisc.edu,
       kernel list <linux-kernel@vger.kernel.org>,
       Russell King <rmk@arm.linux.org.uk>
Subject: Re: best way to handle LEDs
Message-ID: <20051102135614.GL30194@elf.ucw.cz>
References: <20051101234459.GA443@elf.ucw.cz> <1130891953.8489.83.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1130891953.8489.83.camel@localhost.localdomain>
User-Agent: Mutt/1.5.9i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1181
Lines: 37

Hi!

> Led triggers would be kernel sources of led on/off events. Some
> examples:
> 
> 2Hz Heartbeat - useful for debugging (and/or Generic Timer)
> CPU Load indicator
> Charging indicator
> HDD activity (useful for microdrive on handheld)
> Network activity
> no doubt many more
> 
> led triggers would be connected to leds via sysfs. Each trigger would
> probably have a number you could echo into an led's trigger attribute.
> Sensible default mappings could be had by assigning a default trigger to
> a device by name in the platform code that declares the led.

Perhaps I'd keep it simple and leave it at

* do hardcoded kernel action for this led

or

* do whatever userspace tells you.

That way you will not be able to remap charger LED onto hard disk
indicator, but we can support that on ibm-acpi too. (Where hw controls
LEDs like "sleep", but lets you control them. You can't remap,
though).
								Pavel
-- 
Thanks, Sharp!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/