From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Jan Kiszka <jan.kiszka@siemens.com>, Nishanth Menon <nm@ti.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
Tero Kristo <kristo@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Bao Cheng Su <baocheng.su@siemens.com>,
Chao Zeng <chao.zeng@siemens.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Li Hua Qian <huaqian.li@siemens.com>
Subject: Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
Date: Tue, 19 Dec 2023 16:56:01 +0100 [thread overview]
Message-ID: <be4011c2-4628-45d7-a2c2-6d936ad2b636@linaro.org> (raw)
In-Reply-To: <cc6b7f99-3439-45a1-b4b4-0b5796dcbbbf@siemens.com>
On 19/12/2023 16:48, Jan Kiszka wrote:
> On 19.12.23 16:42, Krzysztof Kozlowski wrote:
>> On 19/12/2023 16:40, Jan Kiszka wrote:
>>> On 19.12.23 16:39, Krzysztof Kozlowski wrote:
>>>> On 19/12/2023 16:37, Jan Kiszka wrote:
>>>>>>>>
>>>>>>>> You have label for that... Somehow all these nodes are half-baked,
>>>>>>>> without all the expected properties and now you call node name as ABI.
>>>>>>>> The node name is not the ABI.
>>>>>>>
>>>>>>> Well, existing userspace uses those names, and adding the properties
>>>>>>> would break that interface. Now, does Linux do that?
>>>>>>
>>>>>> I don't think you understood the concept. There is no change for
>>>>>> userspace. Same interface, same names. No ABI break.
>>>>>
>>>>> I do understand the impact very well:
>>>>> open("/sys/class/leds/user-led1-red") has to work for all the variants,
>>>>> consistently and backward-compatible for userspace.
>>>>
>>>> And it will. The name is the same.
>>>
>>> Nope, it's not - I tried that already :)
>>>
>>> root@iot2050-debian:~# ls -l /sys/class/leds/
>>> total 0
>>> lrwxrwxrwx 1 root root 0 Dec 19 09:49 green:indicator -> ../../devices/platform/leds/leds/green:indicator
>>
>> And how does your DTS look like?
>>
>> Because I also tried and it is exactly the same.
>>
>
> I played with
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
> index 402afa4bc1b6..a791444eeb93 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
> @@ -10,6 +10,7 @@
> */
>
> #include "k3-am654.dtsi"
> +#include <dt-bindings/leds/common.h>
> #include <dt-bindings/phy/phy.h>
> #include <dt-bindings/net/ti-dp83867.h>
>
> @@ -84,27 +85,39 @@ leds {
> pinctrl-0 = <&leds_pins_default>;
>
> status-led-red {
> + color = <LED_COLOR_ID_RED>;
> + function = LED_FUNCTION_STATUS;
> gpios = <&wkup_gpio0 32 GPIO_ACTIVE_HIGH>;
> panic-indicator;
And where is the label property?
Please read my message again:
>> You:
>> patch, but the node names are now part of the kernel ABI. Changing
them would break existing userland.
> Me:
> You mean label. Why node names became the ABI? Which interface exposes
them?
>> You:
>> root@iot2050-debian:~# ls -l /sys/class/leds/
> Me:
> I replied too fast previous and did not include answer here:
> You have label for that...
So again: The stable ABI is fulfilled by using label property. Not the
Devicetree "label" phandle in front of the node, but the dedicated property.
Best regards,
Krzysztof
prev parent reply other threads:[~2023-12-19 15:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-18 16:35 [PATCH 0/4] arm64: dts: iot2050: Add support for new SM variant Jan Kiszka
2023-12-18 16:35 ` [PATCH 1/4] dt-bindings: arm: ti: Add binding for Siemens IOT2050 " Jan Kiszka
2023-12-19 7:50 ` Krzysztof Kozlowski
2023-12-18 16:35 ` [PATCH 2/4] arm64: dts: ti: iot2050: Disable R5 lockstep for all PG2 boards Jan Kiszka
2023-12-18 16:35 ` [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector bits Jan Kiszka
2023-12-19 7:51 ` Krzysztof Kozlowski
2023-12-19 8:06 ` Jan Kiszka
2023-12-19 8:12 ` Krzysztof Kozlowski
2023-12-19 8:18 ` Jan Kiszka
2023-12-18 16:36 ` [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant Jan Kiszka
2023-12-19 7:54 ` Krzysztof Kozlowski
2023-12-19 8:22 ` Jan Kiszka
2023-12-19 8:48 ` Krzysztof Kozlowski
2023-12-19 9:03 ` Jan Kiszka
2023-12-19 9:45 ` Krzysztof Kozlowski
2023-12-19 9:50 ` Krzysztof Kozlowski
2023-12-19 9:54 ` Jan Kiszka
2023-12-19 9:56 ` Jan Kiszka
2023-12-19 9:58 ` Krzysztof Kozlowski
2023-12-19 15:37 ` Jan Kiszka
2023-12-19 15:39 ` Krzysztof Kozlowski
2023-12-19 15:40 ` Jan Kiszka
2023-12-19 15:42 ` Krzysztof Kozlowski
2023-12-19 15:48 ` Jan Kiszka
2023-12-19 15:56 ` Krzysztof Kozlowski [this message]
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=be4011c2-4628-45d7-a2c2-6d936ad2b636@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=baocheng.su@siemens.com \
--cc=chao.zeng@siemens.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=huaqian.li@siemens.com \
--cc=jan.kiszka@siemens.com \
--cc=kristo@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nm@ti.com \
--cc=robh+dt@kernel.org \
--cc=vigneshr@ti.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox