Re: [PATCH net v1] net: phy: motorcomm: yt8821: disable MDIO broadcast address 0

[Jakub Vaněk]

On 2/22/26 01:18, Russell King (Oracle) wrote:
> This is too late (chicken and egg problem exists) - phylib will already
> have scanned the bus, and found a PHY at address 0 (whether it read the
> IDs correctly because of the conflict is a separate matter. If there's
> a conflict between two devices, the PHY IDs read will be a mess.)
> 
> However, if this PHY is the only PHY on the bus, and some driver uses
> phy_find_first(), it will find the PHY at address 0, but it won't
> respond anymore.
> 
> Failing the probe for address 0 doesn't solve the problem either - there
> will still be a struct phy_device created for address 0, and if this
> driver doesn't bind to it, the generic PHY driver will be bound manually
> by phylib.
> 
> I can't see a simple way to handle this in the kernel. So, I'm going
> to say this instead: boot loaders / board firmware need to sort this
> mess out and program this PHY not to respond at address 0.
> 
> To put it another way, this isn't a problem to be solved in the kernel.
> It's a board design/firmware issue, and that's where it needs to be
> solved.
> 
> One of the responsibilities of board firmware is to ensure that the
> devices on the board are configured sensibly for the operating system.
> What you've said above, where two PHYs conflict on address zero is
> a failure to configure the devices on the board sensibly.

Hello Andrew, Russell,

thank you for the explanations. I now agree that this is better solved
in the bootloader rather than in the kernel.

The affected Cudy router boots Linux via U-Boot and indeed supports TFTP
booting. From what I can tell, the stock Cudy U-Boot avoids the MDIO
conflict by only supporting the internal PHY for networking. I checked
with a multimeter that the YT8821 is held in hardware reset when U-Boot
is running and this likely prevents the YT8821 from responding on
MDIO address 0.

A while back I did some digging into how the stock Cudy Linux kernel
handles this issue. It unfortunately involves hacks such as resetting
the YT8821 through its reset pin from userspace and then calling
yt8821_config_init() again by opening a debugfs file (ouch).

On the positive side, these devices generally support replacing the
vendor U-Boot with the OpenWrt U-Boot, which would allow fixing the MDIO
addressing early. However, doing so makes reverting to the stock
firmware more difficult, this is something I'll have to balance.

Thanks again for the guidance and review.

Best regards,
Jakub