Re: [PATCH net-next v2 1/5] net: mdiobus: Scan buses in reverse order (31 -> 0)

[Russell King (Oracle)]

On Sun, Mar 01, 2026 at 12:22:37AM +0100, Jakub Vaněk wrote:
> Some PHY devices incorrectly treat address 0 as a broadcast address.
> As a result, accesses to address 0 may cause multiple PHYs to respond,
> making one or both PHYs work unreliably. In other cases, the PHY may be
> detected twice by Linux: once at address 0 and once at its actual
> address).
> 
> On several PHYs (e.g. Motorcomm YT8821 and Realtek RTL8221B), this
> behavior can be disabled via a vendor-specific internal register.
> However, for that to be useful, that register would have to be
> programmed before address 0 is accessed for the first time.
> 
> On non-Device Tree systems, MDIO buses are typically scanned in
> mdiobus_register(). Change the address scan order from 0->31 to 31->0
> so that PHY fixups are applied to addresses 1-31 before address 0
> is probed. This way the address collision can be avoided.

I've said no to this before.

The order of scanning may affect the order in which devices are added.
However, that doesn't really have that much bearing in the order in
which devices are bound to their drivers.

If the drivers are already registered, then as each device is
registered with the driver model, it will be offered to drivers. So
in this case, the order in which devices are proed will be the order
in which they are scanned.

However, if a driver is loaded after scanning is complete, then the
order in which devices are presented to the driver is not under the
control of phylib, but is down to the driver model code. The driver
model scans the bus_type's devices in some order, and attempts to
match each with the new driver.

If the driver is not present, then even if you scan in reverse order,
the "ghost" at address 0 will be found, because the driver hasn't had
the opportunity to reprogram the PHY to disable that.

In both cases, things get worse if -EPROBE_DEFER happens.

So, you can't definitively control the order in which devices are
probed, which means that anything that depends on that will be fragile.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!