Re: [PATCH v2 2/3] arm64: dts: rockchip: Split out the common NanoPi RK3528 parts

On Wed, Sep 09, 2026 at 04:47:16PM +0300, Andrey Korshunov wrote:

of_mdio_bus_register() reads the PHY ID with get_phy_device() before
phy_device_register() fetches the PHY node's reset-gpios, so a PHY that
the bootloader left in reset is simply not found:

  mdio_bus stmmac-0: MDIO device at address 1 is missing.

Thanks, the diagnosis is right and I have reproduced the ordering in
the code: `__of_mdiobus_register()` registers the bus before it walks the
children. And for a PHY node with only the generic c22 compatible,
`fwnode_mdiobus_register_phy()` reads the PHY ID via `get_phy_device()`
before `phy_device_register()` gets as far as requesting reset-gpios.

Describing the reset on the MAC instead makes stmmac install it
as mii_bus->reset, which runs before the bus is scanned:

    &gmac1 {
        snps,reset-active-low;
        snps,reset-delays-us = <0 20000 100000>;
        snps,reset-gpio = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
    };

But I would rather not use those: snps,reset-gpio, snps,reset-active-low
and snps,reset-delays-us are all deprecated in snps,dwmac.yaml,
so a new DTS using them is unlikely to get through netdev.

The MDIO bus level reset in mdio.yaml solves the same ordering problem
without using deprecated property. `__mdiobus_register()` asserts and
releases it before any device on the bus is registered, so it also
covers the DT described case where the bus is not scanned at all:

	&mdio1 {
		reset-delay-us = <20000>;
		reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
		reset-post-delay-us = <100000>;

		rgmii_phy: ethernet-phy@1 {
			compatible = "ethernet-phy-ieee802.3-c22";
			reg = <0x1>;
		};
	};

with gmac1_rstn_l moved to the MAC's pinctrl-0, since the MDIO bus has
no device of its own for pinctrl to bind to. There is only one PHY on
mdio1, so a bus wide reset is equivalent to the per-PHY one.

v3 carries this as patch 1, against the NanoPi Zero2 and ahead of the
move, so it can be backported:

<https://lore.kernel.org/r/20260909-r28s-upstream-v3-0-ee3e1a34a353@proton.me (local)>

A `Tested-by` on that form would be very welcome, since it is not the
variant you tested.

I had an R28S series of my own out before I saw yours; I am dropping it.

Sorry about the duplicated effort.

Thanks,
Rong An.