devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Diederik de Haas" <didi.debian@cknow.org>
To: "Heiko Stübner" <heiko@sntech.de>,
	"Krzysztof Kozlowski" <krzk@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>
Cc: <devicetree@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-rockchip@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] arm64: dts: rockchip: Add reset button to NanoPi R5S
Date: Thu, 10 Jul 2025 11:10:14 +0200	[thread overview]
Message-ID: <DB89AVFYVBG3.11WV856SX4PDP@cknow.org> (raw)
In-Reply-To: <11937120.2WqB4rESCP@diego>

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

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

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

      reply	other threads:[~2025-07-10  9:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-09 10:57 [PATCH] arm64: dts: rockchip: Add reset button to NanoPi R5S Diederik de Haas
2025-07-09 11:05 ` Krzysztof Kozlowski
2025-07-09 11:17   ` Diederik de Haas
2025-07-09 14:18     ` Krzysztof Kozlowski
2025-07-09 15:11       ` Heiko Stübner
2025-07-09 16:47       ` Diederik de Haas
2025-07-09 19:49         ` Heiko Stübner
2025-07-10  9:10           ` Diederik de Haas [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=DB89AVFYVBG3.11WV856SX4PDP@cknow.org \
    --to=didi.debian@cknow.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).