[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <DB89AVFYVBG3.11WV856SX4PDP@cknow.org>
Date: Thu, 10 Jul 2025 11:10:14 +0200
From: "Diederik de Haas" <didi.debian@...ow.org>
To: Heiko Stübner <heiko@...ech.de>, "Krzysztof Kozlowski"
<krzk@...nel.org>, "Rob Herring" <robh@...nel.org>, "Krzysztof Kozlowski"
<krzk+dt@...nel.org>, "Conor Dooley" <conor+dt@...nel.org>
Cc: <devicetree@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
<linux-rockchip@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: dts: rockchip: Add reset button to NanoPi R5S
On Wed Jul 9, 2025 at 9:49 PM CEST, Heiko Stübner wrote:
> Am Mittwoch, 9. Juli 2025, 18:47:47 Mitteleuropäische Sommerzeit schrieb Diederik de Haas:
>> On Wed Jul 9, 2025 at 4:18 PM CEST, Krzysztof Kozlowski wrote:
>> > On 09/07/2025 13:17, Diederik de Haas wrote:
>> >>>> compatible = "gpio-leds";
>> >>>> pinctrl-names = "default";
>> >>>> @@ -127,6 +140,12 @@ eth_phy0_reset_pin: eth-phy0-reset-pin {
>> >>>> };
>> >>>> };
>> >>>>
>> >>>> + gpio-keys {
>> >>>> + gpio4_a0_k1: gpio4-a0-k1 {
>> >>>
>> >>> Are you sure that this passes checks?
>> >>
>> >> If it's about the 'weird' name/label, it is what is used in the
>> >> schematic document I have and I asked Heiko (on IRC) if using
>> >> ``reset_button_pin: gpio4-a0-k1`` would not be better. That would make
>> >> it more descriptive while also having the schematic traceability in it.
>> >> The answer was no, use the form I used in this patch.
>> >>
>> >> Am I missing checks I should've done as well?
>> > I meant that usually nodes, including pin controller mux/config nodes,
>> > have specific prefixes or suffixes. Other cases have here as well. Your
>> > does not.
>>
>> I agree I've done it inconsistent with how I did the other pinctrl
>> nodes, so I should've added the '-pin' suffix. For consistency.
>
> Also fine by me :-) .
>
>
>> I've been wondering whether there are rules for naming [1], both for the
>> grouping and the node names. Some DTS files use a '-pin' suffix, others
>> don't. And it's not uncommon to see both variants in the same dts file.
>>
>> One of the examples I looked at was ``rk3568-qnap-ts433.dts``. While it
>> uses 'keys' as grouping node, I went with 'gpio-keys' as that was used
>> more often (in other files). While the gmac0/keys/leds subnodes under
>> ``&pinctrl`` use the '-pin' suffix, the pmic/usb subnodes do not.
>> (and I just noticed 'hdd4_led-pin' should be 'hdd4-led-pin')
>
> The TS433 suffers from that "no schematics" thing I mentioned in the
> other mail, so the device-specific pins are named after their functon.
> As I was assuming the TS433 will follow the reference design, those
> pins are named after how other boards do it
That sounds (very) sensible for the 'base' name.
What I'm trying to figure out is whether there are some rules which
determine whether the should be a '-pin' suffix or not.
Because some have and some don't.
>> I'd love to know/learn if there are actual rules for these things, but
>> I don't know them.
>
> From looking at pinctrl bindings, it seems patterns are set per controller
> with no global rules. Which makes sense in a way, because they do
> represent pin(-groups) differently each.
I think I don't understand this.
I know there are pattternProperties which describe the format for
several node names, but I haven't found a rule for '-pin' suffix.
The "rockchip,pins" property is defined in pinctrl/rockchip,pinctrl.yaml
and I don't see it there. And in the example in that binding file, there
is one node with a "rockchip,pins" property ... and it does not have a
'-pin' suffix.
I'll sent a v2 with the '-pin' suffix even though I still don't know
why. It looks more consistent though.
Cheers,
Diederik
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists