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

[Jakub Vaněk]

On 3/1/26 18:03, Russell King (Oracle) wrote:
> 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.
> 

I have observed something similar -- when the YT8821 driver was
built as a module, the .probe callback was indeed not called early
enough. This is why I rewrote the patch to use a PHY fixup --
the fixups are called synchronously from phy_device_register() and
don't depend on the driver in any way. I thus agree that it is
not feasible to handle this inside the YT8821 kernel driver.

Jakub