RE: [PATCH] dt-bindings: leds: Mark label property as deprecated

[Christoph Niedermaier]

From: Jacek Anaszewski [mailto:jacek.anaszewski@xxxxxxxxx]
Sent: Monday, December 5, 2022 7:44 PM
> 
> Hi all,
>

Hi all,

> On 12/2/22 00:41, Marek Vasut wrote:
>> On 11/30/22 20:19, Rob Herring wrote:
>>> On Fri, Nov 25, 2022 at 10:26:30PM +0100, Marek Vasut wrote:
>>>> On 11/22/22 13:23, Pavel Machek wrote:
>>>>> Hi!
>>>>
>>>> Hi,
>>>>
>>>>>> Mark the label property as deprecated as it is mentioned
>>>>>> in the description.
>>>>>
>>>>> Lets do it the other way around. Functions (etc) don't really provide
>>>>> good enough description of LED, and label is still needed.
>>>>
>>>> Can you please provide a clear explanation which property or approach
>>>> is the
>>>> correct one for new DTs ?
>>>>
>>>> So far, the documentation states that "label" is deprecated, and users
>>>> should replace it with "function" and "color".
>>>
>>> 'function' is what activity/operation the LED is associated with. It is
>>> a fixed set of strings which s/w may use. It is a replacement for
>>> 'linux,default-trigger'.
>>
>> Isn't this 'function' more of a standardized replacement for 'label' ?
> 
> Yes it is. Introduction of function and color properties aimed at
> standardizing LED naming. Before there was only 'label' used for that,
> with DT node name as fallback if 'label' property was not provided.
> With introduction of 'function' and 'color' label was deprecated in
> the sense that if the former two are present, they are used for
> composing the LED name.
> 
> In LED documentation [0] people are encouraged to use definitions from
> include/dt-bindings/leds/common.h to keep LED naming uniform.
> It allows to avoid duplicates like "wlan" and "wifi".
> 
>> $ git grep LED_FUNCTION_ include/
>> ...
>> include/dt-bindings/leds/common.h:#define LED_FUNCTION_PLAYER5 "player-5"
>> include/dt-bindings/leds/common.h:#define LED_FUNCTION_ACTIVITY "activity"
>> include/dt-bindings/leds/common.h:#define LED_FUNCTION_ALARM "alarm"
>> include/dt-bindings/leds/common.h:#define LED_FUNCTION_BACKLIGHT
>> "backlight"
>> include/dt-bindings/leds/common.h:#define LED_FUNCTION_BLUETOOTH
>> "bluetooth"
>> include/dt-bindings/leds/common.h:#define LED_FUNCTION_BOOT "boot"
>> ...
>>
>> Seems to me that ^ is closer to a "standardized" form of 'label' .
>>
>> The LED subsystem does not infer any behavior of those LEDs based on
>> their 'function' property as far as I can tell, at least not in the way
>> 'linux,default-trigger' behaves.
>>
>>> 'label' is what is printed next to the LED for a human to read. 'label'
>>> can be anything and the OS shouldn't care what it is.
>>
>> This part I understand. What is not clear to me is, why is 'label' being
>> un-deprecated.
> 
> It shouldn't be. It seems to be Pavel's ad-hoc decision.

Is there a majority agreement that the "label" property remains deprecated?
If so, I would say we can mark the label as deprecated.

On the other hand, the new generated standardized sysfs name does not seem
to provide a full replacement for the "label" property.
What is still missing?
How can the current state be extended to find more acceptance?

[...]

Regards
Christoph