Subject: Re: best way to handle LEDs
From: Richard Purdie <rpurdie@rpsys.net>
To: Pavel Machek <pavel@suse.cz>
Cc: vojtech@suse.cz, lenz@cs.wisc.edu,
       kernel list <linux-kernel@vger.kernel.org>,
       Russell King <rmk@arm.linux.org.uk>
In-Reply-To: <20051102135614.GL30194@elf.ucw.cz>
References: <20051101234459.GA443@elf.ucw.cz>
	 <1130891953.8489.83.camel@localhost.localdomain>
	 <20051102135614.GL30194@elf.ucw.cz>
Content-Type: text/plain
Date: Wed, 02 Nov 2005 14:38:41 +0000
Message-Id: <1130942322.8523.15.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1583
Lines: 43

On Wed, 2005-11-02 at 14:56 +0100, Pavel Machek wrote:
> > 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).

Then the arguments start about which function should be hardcoded to
which leds and why can't userspace access these triggers?

I'd prefer a totally flexible system and it doesn't really add much
complexity once you have a trigger framework which we're going to need
to handle mutiple led trigger sources sanely anyway.

Richard

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