Re: [PATCH 2/2] leds: Support OpenFirmware led bindings

On Mon, Jul 28, 2008 at 11:26:28AM -0700, Trent Piepho wrote:

On Mon, 28 Jul 2008, Anton Vorontsov wrote:

quoted

On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
[...]

quoted

quoted

quoted

quoted

+- function :  (optional) This parameter, if present, is a string
+  defining the function of the LED.  It can be used to put the LED
+  under software control, e.g. Linux LED triggers like "heartbeat",
+  "ide-disk", and "timer".  Or it could be used to attach a hardware
+  signal to the LED, e.g. a SoC that can configured to put a SATA
+  activity signal on a GPIO line.

This makes me nervous.  It exposes Linux internal implementation details
into the device tree data.  If you want to have a property that
describes the LED usage, then the possible values and meanings should be
documented here.

Should it be a linux specific property then?  I could list all the current
linux triggers, but enumerating every possible function someone might want
to assign to an LED seems hopeless.

I'd rather see the device tree provide 'hints' toward the expected usage
and if a platform needs something specific, then the platform specific
code should setup the trigger.

Maybe we can encode leds into devices themselves, via phandles?

How will this work for anything besides ide activity?  For example, flashing,
heartbeat, default on, overheat, fan failed, kernel panic, etc.

It certainly doesn't work for everything; but where it does work it
makes a lot of sense because the property position provides a lot of
context.

quoted

And then the OF GPIO LEDs driver could do something like:

char *ide_disk_trigger_compatibles[] = {
	"fsl,sata",
	"ide-generic",
	...
};

Everytime someone added a new ide driver, this table would have to be updated.

Yes, the implementation needs thought.

g.