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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 28 Jul 2008 01:31:47 -0700 (PDT)
From:	Trent Piepho <>
To:	Grant Likely <>
	Anton Vorontsov <>,
	Richard Purdie <>,
	Stephen Rothwell <>,
	Kumar Gala <>,
Subject: Re: [PATCH 2/2] leds: Support OpenFirmware led bindings

On Sat, 26 Jul 2008, Grant Likely wrote:
> On Fri, Jul 25, 2008 at 02:01:45PM -0700, Trent Piepho wrote:
>> Add bindings to support LEDs defined as of_platform devices in addition to
>> the existing bindings for platform devices.
>> +- gpios :  Should specify the LED GPIO.
> Question: it is possible/desirable for a single LED to be assigned
> multiple GPIO pins?  Say, for a tri-color LED?  (I'm fishing for
> opinions; I really don't know if it would be a good idea or not)

Good question.  The Linux LED layer has no concept of multi-color LEDs, so
it's more difficult that just adding support to the gpio led driver.  I have
a device with a tri-color red/green/orange LED and this posed some
difficulty.  It's defined as independent red and greed LEDs, which is mostly
fine, except I wanted it to flash orange.  I can make both the red LED and
green LED flash, but there is nothing to insure their flashing remains in

Other OF bindings allow multiple GPIOs to be listed in a gpios property, so
that's not a problem if someone wants to do that.  There would need to be a
way to define what the gpios mean.  I don't think it's worthwhile to come up
with a binding for that until there is a real user.

>> +- 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.

>> +		led.default_trigger =
>> +			of_get_property(child, "linux,default-trigger", NULL);
> This isn't in the documented binding.  I assume that you mean 'function'
> here?

Looks like I emailed the wrong patch file.  That should be changed to
"function" and there are a few cosmetic changes that are missing.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists