Re: [PATCH v4] dt-bindings: leds: Add default-intensity property

From: Jonas Rebmann

Date: Thu Jul 16 2026 - 07:29:58 EST

Hello Stefan,

On 2026-07-16 11:07, Stefan Wahren wrote:

Am 16.07.26 um 09:31 schrieb Jonas Rebmann:

On 2026-07-15 18:55, Stefan Wahren wrote:

Am 14.07.26 um 09:35 schrieb Jonas Rebmann:

+ default-intensity:
+ description:
+ The initial intensity of the LED color component. As the
intensity of
+ each sub-LED is multiplied by the overall brightness, without
this
+ property on a sub-LED, it may effectively be initialized at a
brightness
+ of 0 regardless of its linux,default-trigger and
default-brightness
+ properties.

I have some reservations about the wording. It isn't wrong, but in my
view, it isn't entirely clear that the initial value depends on the
implementation.

Maybe something like this?

without this property on a sub-LED, the initial intensity value depends
on the implementation regardless of its linux,default-trigger and
default-brightness properties.

[...]

How about:

The initial intensity of the LED color component. As the intensity of
each sub-LED is multiplied by the overall brightness, without this
property on a sub-LED, it will be initialized at a brightness of 0
regardless of its linux,default-trigger and default-brightness
properties, for drivers with initial intensity values of 0.

IMO the mention of "0" suggests a driver behavior, which this generic DT
binding can never guarantee and it confuses more than it helps.
I think in absence of default-intensity the user should consider the
initial value as undefined. The value depend on the driver
implementation. So I think we should avoid mention any specific values
in this case.

The only implied driver behavior is that intensity is multiplied by
brightness, and that is well-defined across all multicolor-LED drivers
(leds-class-multicolor.rst).

The warning here is that "for drivers with initial intensity values of
0", default-brightness is dysfunctional when no default-intensity is
specified. This does imply that the behavior is driver specific, not the
contrary.

But the key message is that there are cases where without
default-intensity, a driver may just do a whole lot of nothing.

This is not only against my personal expectations, it is also against
the documentation in leds-class.rst:

The brightness file will set the brightness of the LED (taking a value
0-max_brightness). Most LEDs don't have hardware brightness support so
will just be turned on for non-zero brightness settings.

This I find to be much more of an issue than an LED blinking in an
arbitrary color when you haven't specified the color. Not only would
that to me be somewhat expected that I didn't ask for a specific color
and got any one, there is also no documentation I know of that says
otherwise; and the question seems completely hypothetical given that
to my knowdelge, no drivers exist which default to anything other than
(0,0,0) or (max,max,max).

No multicolor-LED driver should have ever initialized intensity to
(0,0,0). In that perfect (and/or non-backwards-compatible) world, "The
initial intensity of the LED color component." would have completely
sufficed as property description of default-intensity. But since we now
have LEDs that don't turn on when you turn them on, I felt the need to
include this long second sentence.

--- a/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
@@ -45,6 +45,9 @@ properties:
color: true
+ default-intensity:
+ default: 0
+