On 10-02-17 21:56, Pavel Machek wrote:
Hi!
+ led.default_brightness = LED_OFF;
+ of_property_read_u32(child, "brightness",
+ &led.default_brightness);
At first you would have to submit a patch for
Documentation/devicetree/bindings/leds/common.txt that would add
brightness property. The question is whether it is really needed?
You can set brightness from userspace via sysfs API.
By the way, I have a question to DT maintainers: is DT a proper
place for defining this type of configuration that can be set via
userspace scripts? Shouldn't DT describe only hardware properties and
constraints resulting from board configuration?
Well, if the hardware has label "half - power, full - transmitting" on
a LED, we might want kernel to turn it to half power on bootup.
If you have a "disk activity LED" on a PC, it is driven by
hardware. On arm notebook, it would be nice if "disk activity LED"
worked, too. Preferably even when running fsck in init=/bin/bash
mode. We already provide that, AFAICT, so having ability to set
constant brightness sounds sane to me.
There is also some delay between kernel and user space where the leds
are too bright or simply off... (which is quite ugly for a simple "power
on" led)
One thing that I have seen is that several led triggers do not play
along with the brightness. For example, the "heartbeat" trigger always
sets the brightness to LED_FULL. Which negates the set brightness on
each blink... So would it not be an idea to add a "led_set_on_off(led,
state)" function which retains "brightness" and additionally takes an
"invert" parameter into account. This might also simplify code in other
led triggers.
Jelle
--
------------------------------------------------------------------------
You/Com Audiocommunicatie b.v.
Motorenweg 5k
2623CR Delft
The Netherlands
tel. : (+31)15 262 59 55
fax. : (+31)15 257 15 95
mail : jmkok@xxxxxxxxx
http : http://www.youcom.nl
------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
