[RFC PATCH] arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing

[RFC PATCH] arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing

[Zhyi]

arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing

The RTL8211F on the HINLINK H28K (RK3528) is held in reset at power-on:
its reset line (gpio4 RK_PC2, pin 146) is left unconfigured and reads
low. The PHY node's reset-gpios are only acted upon after the PHY has
been found on MDIO (fwnode_mdiobus_register_phy() reads the PHY ID
before it requests and toggles the reset GPIO), so the first probe
deadlocks and eth0 never gets a link:

    mdio_bus stmmac-0: MDIO device at address 1 is missing.
    rk_gmac-dwmac ffbe0000.ethernet eth0: cannot attach to PHY (error: -ENODEV)

Release the reset from the MAC node via snps,reset-gpios so it is
deasserted before MDIO scanning, and drop the PHY-node reset-gpios (a
second consumer on the same GPIO is rejected with -EBUSY).

This is an RFC: snps,reset-gpios is deprecated in favour of the
ethernet-PHY reset bindings, so feedback on the preferred way to release
the reset early is welcome.

Fixes: 145d4af4b204 ("arm64: dts: rockchip: Add HINLINK H28K")
Signed-off-by: Zhyi <zyheihei_123@163.com>
---
diff --git a/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts b/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
index 0ec50e9..9d7e33a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
@@ -191,6 +191,8 @@
 		    <&rgmii_rx_bus2>,
 		    <&rgmii_rgmii_clk>,
 		    <&rgmii_rgmii_bus>;
+	snps,reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
+	snps,reset-delays-us = <0 20000 100000>;
 	status = "okay";
 };
 
@@ -205,9 +207,6 @@
 		reg = <0x1>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&gmac1_rstn_l>;
-		reset-assert-us = <20000>;
-		reset-deassert-us = <100000>;
-		reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
 	};
 };
 

Re: [RFC PATCH] arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Device Tree binding schema violation and dependency failure due to plural `snps,reset-gpios` property.
- [Medium] Introduction of deprecated MAC-level PHY reset properties instead of using standard PHY or MDIO bus resets.
- [Medium] Pinctrl configuration mismatch caused by stranded `pinctrl-0` reference in the PHY node.
--

--- Patch [1]: [RFC PATCH] arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing ---
commit b9933a1b302b2f683cf8eb84eb27dfe653094785
Author: Zhyi <zyheihei_123@163.com>

arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing

This commit attempts to fix a PHY probe deadlock on the HINLINK H28K board
by moving the reset GPIO configuration from the PHY node to the MAC node.
It uses the snps,reset-gpios properties on the MAC to release the reset
before the MDIO bus scan happens.

> diff --git a/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts b/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
> index 0ec50e9156eb1..9d7e33a92cfed 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
> @@ -191,6 +191,8 @@ &gmac1 {
>  		    <&rgmii_rx_bus2>,
>  		    <&rgmii_rgmii_clk>,
>  		    <&rgmii_rgmii_bus>;
> +	snps,reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
> +	snps,reset-delays-us = <0 20000 100000>;

[Severity: Medium]
Will this fail device tree schema validation? The snps,dwmac.yaml schema
strictly defines the singular snps,reset-gpio property rather than the plural
snps,reset-gpios used here. Furthermore, the schema has a strict dependency
where snps,reset-delays-us requires the singular snps,reset-gpio property
to be present, so this dependency check may fail.

[Severity: Medium]
Is this the preferred approach for handling early PHY resets? The patch moves
the reset properties into the MAC node using the deprecated snps prefix.

The upstream-approved solutions for early PHY resets prior to MDIO probing
are typically to either declare the PHY ID explicitly in the PHY node
compatible string (e.g. compatible = "ethernet-phy-idXXXX.XXXX") so the MDIO
core skips the hardware read, or to use the standard reset-gpios inside the
parent mdio node.

>  	status = "okay";
>  };
>  
> @@ -205,9 +207,6 @@ rgmii_phy: ethernet-phy@1 {
>  		reg = <0x1>;
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&gmac1_rstn_l>;
> -		reset-assert-us = <20000>;
> -		reset-deassert-us = <100000>;
> -		reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
>  	};
>  };

[Severity: Medium]
Will this cause pinctrl settings for the reset line to be applied too late?

The consumer of the reset GPIO has moved to the MAC node (gmac1), which
will now request and toggle the GPIO during its probe. However, the pinctrl-0
reference for gmac1_rstn_l remains here in the PHY node. 

Since the PHY is probed after the MAC, the pin's pinctrl settings might not
be applied before the MAC toggles the reset. When the PHY later probes and
applies the pinctrl, could it glitch the already-active reset pin?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260803104646.26836-1-zyheihei_123@163.com?part=1

Re: [RFC PATCH] arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing

[Chukun Pan]

Hi,

> Release the reset from the MAC node via snps,reset-gpios so it is
> deasserted before MDIO scanning, and drop the PHY-node reset-gpios (a
> second consumer on the same GPIO is rejected with -EBUSY).

This is incorrect. Has your uboot's DT been synchronized with the kernel?
Normally, U-Boot will reset this GPIO. Another way to solve your problem
is to hardcode the PHY ID here. However, considering that manufacturers
might use either RTL8211F or YT8531, it's best to let U-Boot handle it.

For reference: https://github.com/openwrt/openwrt/commit/384127320e0b

By the way, you sent this patch twice within two hours...

[RFC PATCH v2] arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing

[Zhyi]

arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing

On the HINLINK H28K (RK3528), the RTL8211F reset line (gpio4 RK_PC2,
pin 146) is left unconfigured at power-on and reads low, holding the
PHY in reset. The PHY node's reset-gpios are only acted upon after the
PHY has been found on MDIO (fwnode_mdiobus_register_phy() reads the
PHY ID before it requests and toggles the reset GPIO), so the first
probe deadlocks and eth0 never gets a link:

    mdio_bus stmmac-0: MDIO device at address 1 is missing.
    rk_gmac-dwmac ffbe0000.ethernet eth0: cannot attach to PHY
    (error: -ENODEV)

Move the reset to the MDIO bus level: mdiobus_register() asserts and
releases the bus reset-gpios before scanning the bus, so the PHY is
out of reset when its ID is read. The PHY node no longer declares
reset-gpios for the same GPIO (a second consumer would be rejected
with -EBUSY).

Fixes: 145d4af4b204 ("arm64: dts: rockchip: Add HINLINK H28K")
Signed-off-by: Zhyi <zyheihei_123@163.com>
Assisted-by: Codex:gpt-5
---
Changes in v2:
- The root-cause analysis and this fix were developed with the
  assistance of an AI coding assistant (Codex, GPT-5). The resulting
  DTS change is minimal and the hardware validation was done by a
  human on a stock HINLINK H28K board.
- This v2 supersedes the accidental duplicate of my v1 RFC sent from
  my Outlook address (Message-ID:
  SJ2PR04MB851017E50140354C2F5B3FF3B5D52@SJ2PR04MB8510.namprd04.prod.outlook.com);
  apologies for the duplicate.
- Use the standard MDIO bus reset properties (mdio.yaml reset-gpios,
  reset-delay-us, reset-post-delay-us) instead of the deprecated
  snps,reset-gpios on the MAC node, as suggested by Andrew Lunn.
- The PHY ID is not hardcoded, so boards populated with either the
  RTL8211F or the YT8531 work unchanged (as noted by Chukun Pan).
- Thanks to Andrew Lunn and Chukun Pan for the review feedback.
- Validated on the stock HINLINK H28K board with Linux 7.1.5:
  eth0 shows "PHY [stmmac-0:01] driver [RTL8211F Gigabit Ethernet]"
  and phy_id 0x001cc916; both eth0 (GMAC) and eth1 (PCIe RTL8111H)
  work.
- The U-Boot side (generic RK3528 DT does not configure the reset
  line) is out of scope for this DTS fix and may be addressed
  separately.
diff --git a/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts b/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
index 0ec50e9..7ba3fa4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
@@ -200,14 +200,14 @@
 };
 
 &mdio1 {
+	reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
+	reset-delay-us = <20000>;
+	reset-post-delay-us = <100000>;
 	rgmii_phy: ethernet-phy@1 {
 		compatible = "ethernet-phy-ieee802.3-c22";
 		reg = <0x1>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&gmac1_rstn_l>;
-		reset-assert-us = <20000>;
-		reset-deassert-us = <100000>;
-		reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
 	};
 };
 

Re: [RFC PATCH v2] arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The pinctrl configuration for the PHY reset GPIO (`&gmac1_rstn_l`) was incorrectly left on the PHY node after the `reset-gpios` control was moved to the MDIO bus node, resulting in the pinmux being applied too late.
--

--- Patch [1]: [RFC PATCH v2] arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing ---
commit ed5c8c6d0629795b93f02fb617db0f38d4725c0d
Author: Zhyi <zyheihei_123@163.com>

arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing

Move the reset-gpios property to the MDIO bus level to ensure the RTL8211F
PHY is released from reset before scanning the bus. This fixes an issue
where the PHY cannot be found during probe.

> diff --git a/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts b/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
> index 0ec50e9156eb1..7ba3fa46c8610 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
[ ... ]
>  &mdio1 {
> +	reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
> +	reset-delay-us = <20000>;
> +	reset-post-delay-us = <100000>;
>  	rgmii_phy: ethernet-phy@1 {
>  		compatible = "ethernet-phy-ieee802.3-c22";
>  		reg = <0x1>;
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&gmac1_rstn_l>;

[Severity: Medium]
Will this pinctrl configuration be applied too late since it was left on the
PHY node?

During initialization, mdiobus_register() parses reset-gpios from the &mdio1
node and toggles it before scanning for PHY devices on the bus.

The driver core only applies a device's pinctrl when that specific device
is probed. Since the PHY device is only created and probed after the MDIO
bus scan successfully discovers it, the pinctrl configuration is applied
after the reset phase has already completed.

Should the pinctrl-0 = <&gmac1_rstn_l> property also be moved to the parent
&gmac1 node to ensure it is applied before the MDIO bus reset sequence?

> -		reset-assert-us = <20000>;
> -		reset-deassert-us = <100000>;
> -		reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
>  	};
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/178577533421.26919.15449256732994709630.h28k-rfc-v2@163.com?part=1

Re: [RFC PATCH v2] arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing

[Jonas Karlman]

Hi Zhyi,

On 8/3/2026 6:42 PM, Zhyi wrote:
> arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing
> 
> On the HINLINK H28K (RK3528), the RTL8211F reset line (gpio4 RK_PC2,
> pin 146) is left unconfigured at power-on and reads low, holding the
> PHY in reset. The PHY node's reset-gpios are only acted upon after the
> PHY has been found on MDIO (fwnode_mdiobus_register_phy() reads the
> PHY ID before it requests and toggles the reset GPIO), so the first
> probe deadlocks and eth0 never gets a link:
> 
>     mdio_bus stmmac-0: MDIO device at address 1 is missing.
>     rk_gmac-dwmac ffbe0000.ethernet eth0: cannot attach to PHY
>     (error: -ENODEV)
> 
> Move the reset to the MDIO bus level: mdiobus_register() asserts and
> releases the bus reset-gpios before scanning the bus, so the PHY is
> out of reset when its ID is read. The PHY node no longer declares
> reset-gpios for the same GPIO (a second consumer would be rejected
> with -EBUSY).
> 
> Fixes: 145d4af4b204 ("arm64: dts: rockchip: Add HINLINK H28K")
> Signed-off-by: Zhyi <zyheihei_123@163.com>
> Assisted-by: Codex:gpt-5
> ---
> Changes in v2:
> - The root-cause analysis and this fix were developed with the
>   assistance of an AI coding assistant (Codex, GPT-5). The resulting
>   DTS change is minimal and the hardware validation was done by a
>   human on a stock HINLINK H28K board.
> - This v2 supersedes the accidental duplicate of my v1 RFC sent from
>   my Outlook address (Message-ID:
>   SJ2PR04MB851017E50140354C2F5B3FF3B5D52@SJ2PR04MB8510.namprd04.prod.outlook.com);
>   apologies for the duplicate.
> - Use the standard MDIO bus reset properties (mdio.yaml reset-gpios,
>   reset-delay-us, reset-post-delay-us) instead of the deprecated
>   snps,reset-gpios on the MAC node, as suggested by Andrew Lunn.
> - The PHY ID is not hardcoded, so boards populated with either the
>   RTL8211F or the YT8531 work unchanged (as noted by Chukun Pan).
> - Thanks to Andrew Lunn and Chukun Pan for the review feedback.
> - Validated on the stock HINLINK H28K board with Linux 7.1.5:
>   eth0 shows "PHY [stmmac-0:01] driver [RTL8211F Gigabit Ethernet]"
>   and phy_id 0x001cc916; both eth0 (GMAC) and eth1 (PCIe RTL8111H)
>   work.
> - The U-Boot side (generic RK3528 DT does not configure the reset
>   line) is out of scope for this DTS fix and may be addressed
>   separately.
> diff --git a/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts b/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
> index 0ec50e9..7ba3fa4 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
> @@ -200,14 +200,14 @@
>  };
>  
>  &mdio1 {
> +	reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
> +	reset-delay-us = <20000>;
> +	reset-post-delay-us = <100000>;

This is not really a correct description of the hardware. The GPIO4_C2
pin is used for PHY reset, not to reset the MDIO bus. The device tree
should describe hardware, not be used to workaround issues in software.
Please see [1] for my prior analysis of this software issue.

Please add the rk3528-hinlink-h28k board as a target in mainline U-Boot
using the board specific device tree. That should help reset the
Ethernet PHY before Linux is started and solve your issue, as Chukun Pan
already suggested.

[1] https://lore.kernel.org/linux-rockchip/47d55aca-bee6-810f-379f-9431649fefa6@kwiboo.se/

Regards,
Jonas

>  	rgmii_phy: ethernet-phy@1 {
>  		compatible = "ethernet-phy-ieee802.3-c22";
>  		reg = <0x1>;
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&gmac1_rstn_l>;
> -		reset-assert-us = <20000>;
> -		reset-deassert-us = <100000>;
> -		reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
>  	};
>  };
>  
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [RFC PATCH v2] arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing

[Zhyi]

Hi Jonas,

Thanks for the analysis, and for the pointer to your earlier write-up
on the rock-3a issue [1].

You are right: GPIO4_C2 is the RTL8211F reset line, so describing it on
the PHY node is the accurate hardware description, and the MDIO bus
reset in my RFC was a software workaround rather than a correct device
tree. I withdraw the RFC v2 change; the kernel DTS stays as the
accepted upstream commit 145d4af4b204 ("arm64: dts: rockchip: Add
HINLINK H28K").

I will follow your suggestion and add the rk3528-hinlink-h28k board as
a target in mainline U-Boot using the board-specific device tree, so
the Ethernet PHY is reset before Linux starts.

Thanks,
Zhyi

[1] https://lore.kernel.org/linux-rockchip/47d55aca-bee6-810f-379f-9431649fefa6@kwiboo.se/

Re: [RFC PATCH] arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing

[Andrew Lunn]

> This is an RFC: snps,reset-gpios is deprecated in favour of the
> ethernet-PHY reset bindings, so feedback on the preferred way to release
> the reset early is welcome.

> + snps,reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
> + snps,reset-delays-us = <0 20000 100000>;

  snps,reset-gpio:
    deprecated: true
    maxItems: 1
    description:
      PHY Reset GPIO

  snps,reset-active-low:
    deprecated: true
    $ref: /schemas/types.yaml#/definitions/flag
    description:
      Indicates that the PHY Reset is active low

  snps,reset-delays-us:
    deprecated: true
    description:
      Triplet of delays. The 1st cell is reset pre-delay in micro
      seconds. The 2nd cell is reset pulse in micro seconds. The 3rd
      cell is reset post-delay in micro seconds.
    minItems: 3
    maxItems: 3

As you say, deprecated: true. You should not be adding new uses of
deprecated properties.

Try using the reset properties in mdio.yaml

    Andrew

Re: [RFC PATCH] arm64: dts: rockchip: H28K: release RTL8211F reset before MDIO probing

[Zhyi]

Hi all,

apologies for the duplicate: this v1 was accidentally sent twice. The
revised [RFC PATCH v2] is on the main thread:

https://lore.kernel.org/all/20260803104646.26836-1-zyheihei_123@163.com/

Please follow up there instead.

Thanks,
Zhyi <zyheihei_123@163.com>