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

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

[Diederik de Haas]

The text description already mentioned the label property was
deprecated, but using the 'deprecated' property makes is clearer and
more explicit.

Signed-off-by: Diederik de Haas <didi.debian@cknow.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 3e8319e44339..45ce9e13c7ff 100644
--- a/Documentation/devicetree/bindings/leds/common.yaml
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -58,6 +58,7 @@ properties:
       no other LED class device can be assigned the same label. This property is
       deprecated - use 'function' and 'color' properties instead.
       function-enumerator has no effect when this property is present.
+    deprecated: true
 
   default-state:
     description:
-- 
2.50.1

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

[Krzysztof Kozlowski]

On 15/08/2025 12:47, Diederik de Haas wrote:
> The text description already mentioned the label property was
> deprecated, but using the 'deprecated' property makes is clearer and
> more explicit.
> 
> Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
> ---
>  Documentation/devicetree/bindings/leds/common.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Please first read previous discussions:
https://lore.kernel.org/all/20240509110545.49889-1-linux@fw-web.de/

https://lore.kernel.org/all/20221122111124.6828-1-cniedermaier@dh-electronics.com/

Best regards,
Krzysztof

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

[Diederik de Haas]

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

On Fri Aug 15, 2025 at 1:00 PM CEST, Krzysztof Kozlowski wrote:
> On 15/08/2025 12:47, Diederik de Haas wrote:
>> The text description already mentioned the label property was
>> deprecated, but using the 'deprecated' property makes is clearer and
>> more explicit.
>> 
>> Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
>> ---
>>  Documentation/devicetree/bindings/leds/common.yaml | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>
> Please first read previous discussions:

[I reversed the order of the links so the oldest is first]

> https://lore.kernel.org/all/20221122111124.6828-1-cniedermaier@dh-electronics.com/

Rob: "They ['function' and 'label'] serve 2 different purposes."

> https://lore.kernel.org/all/20240509110545.49889-1-linux@fw-web.de/

Krzysztof: "I don't think there was conclusion to make it deprecated on
last attempt"

I agree.
What I don't understand: Why wasn't the text updated to correct the
incorrect statement about deprecation (that's how I interpret it now)?
Or some other conclusion being made and that that will be reflected in
the text and/or a deprecated property.

Otherwise the confusion remains and then it's just a matter of time
before a 4th person comes along proposing the same patch.
And possibly even more harmful: people use it incorrectly.

There's also this line:
"function-enumerator has no effect when this property is present."

if that is true, and I would assume so as that's what the binding says,
then I messed up even bigger then I already think I did in commit
1631cbdb8089 ("arm64: dts: rockchip: Improve LED config for NanoPi R5S")
resulting in commit
912b1f2a796e ("arm64: dts: rockchip: Drop netdev led-triggers on NanoPi R5S")

... but I'd have expected that to be pointed out in the review.

I can understand that function-enumerator is used in an automatically
generated label when a label doesn't exist, but I'm inclined to think
the same "They serve 2 different purposes" applies here too.

Cheers,
  Diederik

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

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

[Krzysztof Kozlowski]

On Fri, Aug 15, 2025 at 02:06:49PM +0200, Diederik de Haas wrote:
> On Fri Aug 15, 2025 at 1:00 PM CEST, Krzysztof Kozlowski wrote:
> > On 15/08/2025 12:47, Diederik de Haas wrote:
> >> The text description already mentioned the label property was
> >> deprecated, but using the 'deprecated' property makes is clearer and
> >> more explicit.
> >> 
> >> Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
> >> ---
> >>  Documentation/devicetree/bindings/leds/common.yaml | 1 +
> >>  1 file changed, 1 insertion(+)
> >> 
> >
> > Please first read previous discussions:
> 
> [I reversed the order of the links so the oldest is first]
> 
> > https://lore.kernel.org/all/20221122111124.6828-1-cniedermaier@dh-electronics.com/
> 
> Rob: "They ['function' and 'label'] serve 2 different purposes."
> 
> > https://lore.kernel.org/all/20240509110545.49889-1-linux@fw-web.de/
> 
> Krzysztof: "I don't think there was conclusion to make it deprecated on
> last attempt"
> 
> I agree.
> What I don't understand: Why wasn't the text updated to correct the
> incorrect statement about deprecation (that's how I interpret it now)?
> Or some other conclusion being made and that that will be reflected in
> the text and/or a deprecated property.
> 
> Otherwise the confusion remains and then it's just a matter of time
> before a 4th person comes along proposing the same patch.
> And possibly even more harmful: people use it incorrectly.

Whatever change you want to do here, I expect to address one way or
another these previous discussions. If the code is confusing, refine the
description. But not in a way which ignored previous feedbacks.

Best regards,
Krzysztof

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

[Diederik de Haas]

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

On Wed Aug 20, 2025 at 10:14 AM CEST, Krzysztof Kozlowski wrote:
> On Fri, Aug 15, 2025 at 02:06:49PM +0200, Diederik de Haas wrote:
>> On Fri Aug 15, 2025 at 1:00 PM CEST, Krzysztof Kozlowski wrote:
>> > On 15/08/2025 12:47, Diederik de Haas wrote:
>> >> The text description already mentioned the label property was
>> >> deprecated, but using the 'deprecated' property makes is clearer and
>> >> more explicit.
>> >> 
>> >> Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
>> >> ---
>> >>  Documentation/devicetree/bindings/leds/common.yaml | 1 +
>> >>  1 file changed, 1 insertion(+)
>> >> 
>> >
>> > Please first read previous discussions:
>> 
>> [I reversed the order of the links so the oldest is first]
>> 
>> > https://lore.kernel.org/all/20221122111124.6828-1-cniedermaier@dh-electronics.com/
>> 
>> Rob: "They ['function' and 'label'] serve 2 different purposes."
>> 
>> > https://lore.kernel.org/all/20240509110545.49889-1-linux@fw-web.de/
>> 
>> Krzysztof: "I don't think there was conclusion to make it deprecated on
>> last attempt"
>> 
>> I agree.
>> What I don't understand: Why wasn't the text updated to correct the
>> incorrect statement about deprecation (that's how I interpret it now)?
>> Or some other conclusion being made and that that will be reflected in
>> the text and/or a deprecated property.
>> 
>> Otherwise the confusion remains and then it's just a matter of time
>> before a 4th person comes along proposing the same patch.
>> And possibly even more harmful: people use it incorrectly.
>
> Whatever change you want to do here, I expect to address one way or
> another these previous discussions. If the code is confusing, refine the
> description. But not in a way which ignored previous feedbacks.

I'm not going to make a change.

I thought I would be making (more) explicit what the binding says.
Apparently I read/interpreted it incorrectly. What I described above is
how I currently interpret the *confusion* text/discussion. Is that
correct? I have no idea. That I'm at least the 3rd person proposing this
change indicates I'm not the only one who is confused.

IMO it's up to a/the maintainer to make a decision and that should then
be reflected in the binding, which should fix any confusion.

I hadn't looked at the code yet, but *I*IUC the code should follow the
binding, not the other way around. That's how I have interpreted
(mostly your) comments related to various binding patches ever since I
started actively following upstream(ing) work. Which (again) may be an
incorrect interpretation.

Regards,
  Diederik

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

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

[Jacek Anaszewski]

On 8/20/25 12:37, Diederik de Haas wrote:
> On Wed Aug 20, 2025 at 10:14 AM CEST, Krzysztof Kozlowski wrote:
>> On Fri, Aug 15, 2025 at 02:06:49PM +0200, Diederik de Haas wrote:
>>> On Fri Aug 15, 2025 at 1:00 PM CEST, Krzysztof Kozlowski wrote:
>>>> On 15/08/2025 12:47, Diederik de Haas wrote:
>>>>> The text description already mentioned the label property was
>>>>> deprecated, but using the 'deprecated' property makes is clearer and
>>>>> more explicit.
>>>>>
>>>>> Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
>>>>> ---
>>>>>   Documentation/devicetree/bindings/leds/common.yaml | 1 +
>>>>>   1 file changed, 1 insertion(+)
>>>>>
>>>>
>>>> Please first read previous discussions:
>>>
>>> [I reversed the order of the links so the oldest is first]
>>>
>>>> https://lore.kernel.org/all/20221122111124.6828-1-cniedermaier@dh-electronics.com/
>>>
>>> Rob: "They ['function' and 'label'] serve 2 different purposes."
>>>
>>>> https://lore.kernel.org/all/20240509110545.49889-1-linux@fw-web.de/
>>>
>>> Krzysztof: "I don't think there was conclusion to make it deprecated on
>>> last attempt"
>>>
>>> I agree.
>>> What I don't understand: Why wasn't the text updated to correct the
>>> incorrect statement about deprecation (that's how I interpret it now)?
>>> Or some other conclusion being made and that that will be reflected in
>>> the text and/or a deprecated property.
>>>
>>> Otherwise the confusion remains and then it's just a matter of time
>>> before a 4th person comes along proposing the same patch.
>>> And possibly even more harmful: people use it incorrectly.
>>
>> Whatever change you want to do here, I expect to address one way or
>> another these previous discussions. If the code is confusing, refine the
>> description. But not in a way which ignored previous feedbacks.
> 
> I'm not going to make a change.
> 
> I thought I would be making (more) explicit what the binding says.
> Apparently I read/interpreted it incorrectly. What I described above is
> how I currently interpret the *confusion* text/discussion. Is that
> correct? I have no idea. That I'm at least the 3rd person proposing this
> change indicates I'm not the only one who is confused.
> 
> IMO it's up to a/the maintainer to make a decision and that should then
> be reflected in the binding, which should fix any confusion.
> 
> I hadn't looked at the code yet, but *I*IUC the code should follow the
> binding, not the other way around. That's how I have interpreted
> (mostly your) comments related to various binding patches ever since I
> started actively following upstream(ing) work. Which (again) may be an
> incorrect interpretation.

I think that what we are lacking to move forward is Pavel's response
to Marek's question [0] about elaboration on the subject.
Unless there was a response and I can't find it.

[0] 
https://lore.kernel.org/all/cb3c3a1e-ec10-1e7b-1b21-3cb250f92ecf@denx.de/#t
-- 
Best regards,
Jacek Anaszewski