Re: [PATCH 2/2] arm64: dts: rockchip: Replace deprecated snps,* props for NanoPi R5S

["Diederik de Haas" <diederik@cknow-tech.com>]

On Mon Apr 20, 2026 at 8:58 AM CEST, Tianling Shen wrote:
> On 2026/4/15 22:23, Diederik de Haas wrote:
>> On Wed Apr 1, 2026 at 3:11 PM CEST, Diederik de Haas wrote:
>>> The various snps,reset-* properties are deprecated, so convert them into
>>> their replacements.
>>>
>>> Signed-off-by: Diederik de Haas <diederik@cknow-tech.com>
>>> ---
>>>   arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts | 7 +++----
>>>   1 file changed, 3 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts b/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts
>>> index 90ce6f0e1dcf..92d044ec696b 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts
>>> @@ -85,10 +85,6 @@ &gmac0_tx_bus2
>>>   		     &gmac0_rx_bus2
>>>   		     &gmac0_rgmii_clk
>>>   		     &gmac0_rgmii_bus>;
>>> -	snps,reset-gpio = <&gpio0 RK_PC5 GPIO_ACTIVE_LOW>;
>>> -	snps,reset-active-low;
>>> -	/* Reset time is 15ms, 50ms for rtl8211f */
>>> -	snps,reset-delays-us = <0 15000 50000>;
>>>   	tx_delay = <0x3c>;
>>>   	rx_delay = <0x2f>;
>>>   	status = "okay";
>>> @@ -100,6 +96,9 @@ rgmii_phy0: ethernet-phy@1 {
>>>   		reg = <1>;
>>>   		pinctrl-0 = <&gmac0_rstn_gpio0_c5_pin>;
>>>   		pinctrl-names = "default";
>>> +		reset-assert-us = <15000>;
>>> +		reset-deassert-us = <50000>;
>>> +		reset-gpios = <&gpio0 RK_PC5 GPIO_ACTIVE_LOW>;
>>>   	};
>>>   };
>>>   
>> 
>> Please disregard/drop this patch.
>> 
>> I was recently made aware of 'sashiko.dev' and checked whether it had
>> also checked my patch, which it did:
>> https://sashiko.dev/#/patchset/20260401131551.734456-1-diederik%40cknow-tech.com
>> 
>> And it turns out that the concern raised is valid (thanks Quentin!), so
>> this patch could introduce a regression.
>> So it looks like staying with the deprecated properties is actually
>> better (in this case?).
>
> Well actually we more or less rely on U-Boot to reset the PHY first now. 

This change would introduce such a dependency where it was not there
before, so this could introduce a regression.

> Many rockchip boards in tree require a reset before the PHY can be 
> recognized, but we just use the generic "ethernet-phy-ieee802.3-c22" 
> compatible.

I've identified ~40 Rockchip based boards where there is a dependency on
the bootloader due to using that generic compatible. Some from the start
and some got it added with a similar conversion as I proposed above.
I haven't seen massive bug reports, so it looks like it's currently ok.
I don't like having such a dependency and certainly not adding one where
it previously was not the case.

In other cases, the generic compatible was replaced with a specific one
for the PHY being used, which 'circumvents' the raised concern:
https://lore.kernel.org/linux-rockchip/20260202-px30-eth-phy-v1-0-ef365be64922@cherry.de/

According to the FriendlyELEC schematics I checked, they seem to use the
RTL8211F a LOT. On the NanoPi R6* they use a/the specific compatible:
https://elixir.bootlin.com/linux/v7.0/source/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi#L348

I've sent FriendlyELEC an email to ask whether they ONLY used that PHY
in the R5S (LTS) in which case it is safe to replace the generic
compatible with the specific one. I haven't received a response yet.

> Another option is to move the reset props to mdio node instead of PHY 
> node, though.

I prefer that there's first an agreed upon 'strategy' on how to deal 
with the above mentioned raised concern so that it can be implemented
consistently.

Cheers,
  Diederik