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

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


-- 
Pengutronix e.K.                           | Jonas Rebmann               |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-9    |