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

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

[Christoph Niedermaier]

Mark the label property as deprecated as it is mentioned
in the description.

Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
---
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: kernel@dh-electronics.com
Cc: linux-leds@vger.kernel.org
Cc: devicetree@vger.kernel.org
To: linux-kernel@vger.kernel.org
---
 Documentation/devicetree/bindings/leds/common.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
index f5c57a580078..c1ce846f7676 100644
--- a/Documentation/devicetree/bindings/leds/common.yaml
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -52,6 +52,7 @@ properties:
     $ref: /schemas/types.yaml#/definitions/uint32
 
   label:
+    deprecated: true
     description:
       The label for this LED. If omitted, the label is taken from the node name
       (excluding the unit address). It has to uniquely identify a device, i.e.
-- 
2.11.0

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

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

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.

Best regards,
								Pavel

> +++ b/Documentation/devicetree/bindings/leds/common.yaml
> @@ -52,6 +52,7 @@ properties:
>      $ref: /schemas/types.yaml#/definitions/uint32
>  
>    label:
> +    deprecated: true
>      description:
>        The label for this LED. If omitted, the label is taken from the node name
>        (excluding the unit address). It has to uniquely identify a device, i.e.

-- 
People of Russia, stop Putin before his war on Ukraine escalates.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Marek Vasut]

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".

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

[Christoph Niedermaier]

From: Marek Vasut [mailto:marex@denx.de]
Sent: Friday, November 25, 2022 10:27 PM
> On 11/22/22 13:23, Pavel Machek wrote:
>> Hi!
> 
> 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".

I'm a little confused because the direction seems to have changed here.
Do you want label and functions (etc.) to be able to be used equally
side by side, or should one of them be preferred?

I also do DTs and it would be good to know what to go for.
Could you please provide further explanation?


Regards
Christoph

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

[Rob Herring]

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'.

'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.


They serve 2 different purposes.

Rob

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

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

On Wed 2022-11-30 13:19:05, 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'.
> 
> '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.

Unfortunately, no.

We use label as a path in /sys/class/leds. And it looks like integer
"function" is not really adequate for describing what LED does. There
are too many LEDs and not enough integers, and it is common to have
same function ("activity") on multiple devices ("wifi", "mmc", "eth").

Best regards,
								Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Rob Herring]

On Wed, Nov 30, 2022 at 1:27 PM Pavel Machek <pavel@ucw.cz> wrote:
>
> On Wed 2022-11-30 13:19:05, 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'.
> >
> > '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.
>
> Unfortunately, no.

That's why I said 'shouldn't care', not 'doesn't care'.

'label' is also not just an LED property. It's used elsewhere, but
unfortunately the LED subsystem makes more use of it than it perhaps
should.

> We use label as a path in /sys/class/leds.

Yes, or node name if no label. That's still not really caring what the
value of label is. At least the kernel doesn't. A well behaved
userspace wouldn't either and doesn't for most classes.

> And it looks like integer
> "function" is not really adequate for describing what LED does. There
> are too many LEDs and not enough integers, and it is common to have
> same function ("activity") on multiple devices ("wifi", "mmc", "eth").

Whatever the problems are, 'label' is not the solution.

There is a way to associate leds with devices. 'trigger-source' IIRC.

Rob

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

[Marek Vasut]

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' ?

$ 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.

We newly have 'function', 'function-enumerator' and 'color' DT 
properties for LEDs, which seem to be standardized forms of describing 
what the LED is used for, which LED it is (if there are multiple), and 
color of that LED. This was previously described in the 'label' 
property, usually in free form of e.g. "beaglebone:green:usr2" .

> They serve 2 different purposes.

[...]

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

[Marek Vasut]

On 11/30/22 20:26, Pavel Machek wrote:
> On Wed 2022-11-30 13:19:05, 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'.
>>
>> '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.
> 
> Unfortunately, no.
> 
> We use label as a path in /sys/class/leds. And it looks like integer
> "function" is not really adequate for describing what LED does. There
> are too many LEDs and not enough integers, and it is common to have
> same function ("activity") on multiple devices ("wifi", "mmc", "eth").

The Documentation/devicetree/bindings/leds/common.yaml schema indicates 
that function is a string, not an integer:

"
  32   function:
  33     description:
  34       LED function. Use one of the LED_FUNCTION_* prefixed definitions
  35       from the header include/dt-bindings/leds/common.h. If there is no
  36       matching LED_FUNCTION available, add a new one.
  37     $ref: /schemas/types.yaml#/definitions/string
"

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

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]

Hi!

> > > > 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'.
> > >
> > > '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.
> >
> > Unfortunately, no.
> 
> That's why I said 'shouldn't care', not 'doesn't care'.
> 
> 'label' is also not just an LED property. It's used elsewhere, but
> unfortunately the LED subsystem makes more use of it than it perhaps
> should.
> 
> > We use label as a path in /sys/class/leds.
> 
> Yes, or node name if no label. That's still not really caring what the
> value of label is. At least the kernel doesn't. A well behaved
> userspace wouldn't either and doesn't for most classes.

A well behaved userspace needs that to tell what kind of LED it is. It
is important to tell keyboard backlight from HDD activity LED and from
fllash on back camera for example.

> > And it looks like integer
> > "function" is not really adequate for describing what LED does. There
> > are too many LEDs and not enough integers, and it is common to have
> > same function ("activity") on multiple devices ("wifi", "mmc", "eth").
> 
> Whatever the problems are, 'label' is not the solution.
> 
> There is a way to associate leds with devices. 'trigger-source'
> IIRC.

Neither is trigger-source a solution.

Can we have linux,sysfs-path or something?

								Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Jacek Anaszewski]

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.

> We newly have 'function', 'function-enumerator' and 'color' DT 
> properties for LEDs, which seem to be standardized forms of describing 
> what the LED is used for, which LED it is (if there are multiple), and 
> color of that LED. This was previously described in the 'label' 
> property, usually in free form of e.g. "beaglebone:green:usr2" .
> 
>> They serve 2 different purposes.
> 
> [...]

[0] Documentation/leds/leds-class.rst
-- 
Best regards,
Jacek Anaszewski

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

[Christoph Niedermaier]

From: Jacek Anaszewski [mailto:jacek.anaszewski@gmail.com]
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

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

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

Hi!

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

Having reasonable naming of the LEDs is pre-requisite for deprecating
label property.

And no, kernel community does not operate by "majority agreement"s.

Best regards,
								Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Marek Vasut]

On 12/22/22 14:50, Pavel Machek wrote:
> Hi!
> 
>>>> 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?
> 
> Having reasonable naming of the LEDs is pre-requisite for deprecating
> label property.

As far as I can tell, function and function-enumerator is the reasonable 
naming. Jacek seem to confirm that. I would say, label can be deprecated 
. What is the counter-argument for why it should NOT be deprecated ?

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

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]

On Thu 2022-12-22 15:01:44, Marek Vasut wrote:
> On 12/22/22 14:50, Pavel Machek wrote:
> > Hi!
> > 
> > > > > 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?
> > 
> > Having reasonable naming of the LEDs is pre-requisite for deprecating
> > label property.
> 
> As far as I can tell, function and function-enumerator is the reasonable
> naming. Jacek seem to confirm that. I would say, label can be deprecated .
> What is the counter-argument for why it should NOT be deprecated ?

When the label is no longer neccessary for naming leds, it can be
deprecated. AFAICT, that is currently not the case.

Best regards,
									Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Marek Vasut]

On 12/22/22 15:56, Pavel Machek wrote:
> On Thu 2022-12-22 15:01:44, Marek Vasut wrote:
>> On 12/22/22 14:50, Pavel Machek wrote:
>>> Hi!
>>>
>>>>>> 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?
>>>
>>> Having reasonable naming of the LEDs is pre-requisite for deprecating
>>> label property.
>>
>> As far as I can tell, function and function-enumerator is the reasonable
>> naming. Jacek seem to confirm that. I would say, label can be deprecated .
>> What is the counter-argument for why it should NOT be deprecated ?
> 
> When the label is no longer neccessary for naming leds, it can be
> deprecated. AFAICT, that is currently not the case.

I'm sorry, this is not a counter-argument, this is hand-waving .

Do you have anything to back your claim that the label is currently 
still needed, contrary to what the DT bindings document claims for 
years? "This property is deprecated - use 'function' and 'color' 
properties instead. function-enumerator has no effect when this property 
is present."

"
commit c5d18dd6b64e09dd6984bda9bdd55160af537a8c
Date:   Sun Jun 9 20:19:04 2019 +0200

     dt-bindings: leds: Add properties for LED name construction

     Introduce dedicated properties for conveying information about
     LED function and color. Mark old "label" property as deprecated.

     Additionally function-enumerator property is being provided
     for the cases when neither function nor color can be used
     for LED differentiation.
"

It seems the function and function-enumerator is very much the 
replacement for label, except standardized. If that's not the case, do 
elaborate. If there is a special case that is not covered by it, do 
point it out.