From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Diederik de Haas <didi.debian@cknow.org>,
Krzysztof Kozlowski <krzk@kernel.org>
Cc: Lee Jones <lee@kernel.org>, Pavel Machek <pavel@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: leds: Clearly mark label property as deprecated
Date: Wed, 20 Aug 2025 22:43:02 +0200 [thread overview]
Message-ID: <42f5b747-63c2-4ffc-94ba-10ecb2e5efa9@gmail.com> (raw)
In-Reply-To: <DC76U4GVR0O2.1HXLEPCF8BG02@cknow.org>
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
WARNING: multiple messages have this Message-ID (diff)
From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Diederik de Haas <didi.debian@cknow.org>,
Krzysztof Kozlowski <krzk@kernel.org>
Cc: Lee Jones <lee@kernel.org>, Pavel Machek <pavel@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: leds: Clearly mark label property as deprecated
Date: Wed, 20 Aug 2025 22:43:02 +0200 [thread overview]
Message-ID: <42f5b747-63c2-4ffc-94ba-10ecb2e5efa9@gmail.com> (raw)
In-Reply-To: <DC76U4GVR0O2.1HXLEPCF8BG02@cknow.org>
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
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-08-20 20:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-15 10:47 [PATCH] dt-bindings: leds: Clearly mark label property as deprecated Diederik de Haas
2025-08-15 10:47 ` Diederik de Haas
2025-08-15 11:00 ` Krzysztof Kozlowski
2025-08-15 11:00 ` Krzysztof Kozlowski
2025-08-15 12:06 ` Diederik de Haas
2025-08-15 12:06 ` Diederik de Haas
2025-08-20 8:14 ` Krzysztof Kozlowski
2025-08-20 8:14 ` Krzysztof Kozlowski
2025-08-20 10:37 ` Diederik de Haas
2025-08-20 10:37 ` Diederik de Haas
2025-08-20 20:43 ` Jacek Anaszewski [this message]
2025-08-20 20:43 ` Jacek Anaszewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42f5b747-63c2-4ffc-94ba-10ecb2e5efa9@gmail.com \
--to=jacek.anaszewski@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=didi.debian@cknow.org \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=pavel@kernel.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.