On 10-02-17 21:56, Pavel Machek wrote:

Hi!

quoted

quoted

+        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-i3KCcyIX/XtmR6Xm/wNWPw@public.gmane.org
http : http://www.youcom.nl
------------------------------------------------------------------------

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html