The NanoPi R5S LTS version has a reset button, which is connected via
GPIO. Note that the non-LTS version does not have the reset button and
therefore on page 19 of the schematic version 2204 it is marked 'NC',
but it is connected on the LTS version.

Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
---
 .../boot/dts/rockchip/rk3568-nanopi-r5s.dts   | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts b/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts
index 3b31f0dd8f3b..4eaedb321914 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts
@@ -17,6 +17,19 @@ aliases {
 		ethernet0 = &gmac0;
 	};
 
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-0 = <&gpio4_a0_k1>;
+		pinctrl-names = "default";
+
+		button-reset {
+			debounce-interval = <50>;
+			gpios = <&gpio4 RK_PA0 GPIO_ACTIVE_LOW>;
+			label = "RESET";
+			linux,code = <KEY_RESTART>;
+		};
+	};
+
 	gpio-leds {
 		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 {
+			rockchip,pins = <4 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
 	gpio-leds {
 		lan1_led_pin: lan1-led-pin {
 			rockchip,pins = <3 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>;
-- 
2.50.0

On 09/07/2025 12:57, Diederik de Haas wrote:
> +	gpio-keys {
> +		compatible = "gpio-keys";
> +		pinctrl-0 = <&gpio4_a0_k1>;
> +		pinctrl-names = "default";
> +
> +		button-reset {
> +			debounce-interval = <50>;
> +			gpios = <&gpio4 RK_PA0 GPIO_ACTIVE_LOW>;
> +			label = "RESET";
> +			linux,code = <KEY_RESTART>;
> +		};
> +	};
> +
>  	gpio-leds {
>  		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?

Best regards,
Krzysztof

On Wed Jul 9, 2025 at 1:05 PM CEST, Krzysztof Kozlowski wrote:
> On 09/07/2025 12:57, Diederik de Haas wrote:
>> +	gpio-keys {
>> +		compatible = "gpio-keys";
>> +		pinctrl-0 = <&gpio4_a0_k1>;
>> +		pinctrl-names = "default";
>> +
>> +		button-reset {
>> +			debounce-interval = <50>;
>> +			gpios = <&gpio4 RK_PA0 GPIO_ACTIVE_LOW>;
>> +			label = "RESET";
>> +			linux,code = <KEY_RESTART>;
>> +		};
>> +	};
>> +
>>  	gpio-leds {
>>  		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?

I did the following:

```sh
export PATH=~/dev/kernel.org/dt-schema-venv/bin/:$PATH CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64
make distclean
make debarm64_defconfig
make CHECK_DTBS=y W=1 rockchip/rk3568-nanopi-r5s.dtb
```

And it did not report any issues.
Then booted up my NanoPi R5S and verified that with the updated dtb the
reset button worked.

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?

Cheers,
  Diederik

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?
> 
> I did the following:
> 
> ```sh
> export PATH=~/dev/kernel.org/dt-schema-venv/bin/:$PATH CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64
> make distclean
> make debarm64_defconfig
> make CHECK_DTBS=y W=1 rockchip/rk3568-nanopi-r5s.dtb

This looks fine.

> ```
> 
> And it did not report any issues.
> Then booted up my NanoPi R5S and verified that with the updated dtb the
> reset button worked.
> 
> 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.

Best regards,
Krzysztof

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.

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')

I'd love to know/learn if there are actual rules for these things, but
I don't know them.

Cheers,
  Diederik

[1] https://lists.sr.ht/~diederik/pine64-discuss/%3CDAN429FK06XR.3G8JK8OMGTRKN@cknow.org%3E

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

But I think I'm just making sense of my subconscious choices
retrocactively right now and all the above sort of happened without
me thinking to much about that.


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

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

Am Mittwoch, 9. Juli 2025, 16:18:17 Mitteleuropäische Sommerzeit schrieb Krzysztof Kozlowski:
> 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?
> > 
> > I did the following:
> > 
> > ```sh
> > export PATH=~/dev/kernel.org/dt-schema-venv/bin/:$PATH CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64
> > make distclean
> > make debarm64_defconfig
> > make CHECK_DTBS=y W=1 rockchip/rk3568-nanopi-r5s.dtb
> 
> This looks fine.
> 
> > ```
> > 
> > And it did not report any issues.
> > Then booted up my NanoPi R5S and verified that with the updated dtb the
> > reset button worked.
> > 
> > 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 guess this might have more to do with how deep people submitting DTs
dive into the schematics.

The "aim" has always been to just use the schematics/TRM names, which is
true for the core soc pinctrl entries, and many if not most boards do this.

I would assume the "lan1-led-pin" below the newly added one stems from
a more "shallow dive" ;-) . I would assume that "lan1-led-pin" most
likely has a different name in the schematics, and using that would've
been better.