Message-ID: <42f5b747-63c2-4ffc-94ba-10ecb2e5efa9@gmail.com>
Date: Wed, 20 Aug 2025 22:43:02 +0200
From: Jacek Anaszewski <jacek.anaszewski@...il.com>
To: Diederik de Haas <didi.debian@...ow.org>,
 Krzysztof Kozlowski <krzk@...nel.org>
Cc: Lee Jones <lee@...nel.org>, Pavel Machek <pavel@...nel.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, linux-leds@...r.kernel.org,
 devicetree@...r.kernel.org, linux-rockchip@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: leds: Clearly mark label property as
 deprecated

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@...ow.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

Powered by blists - more mailing lists