Re: [PATCH net-next v2 0/5] net: phy: Disable MDIO broadcast address on YT8821

["Jakub Vaněk" <linuxtardis@gmail.com>]

On 3/1/26 17:06, Andrew Lunn wrote:
> On Sun, Mar 01, 2026 at 12:22:36AM +0100, Jakub Vaněk wrote:
>> Hello,
>>
>> this series is a rewrite of patch [1], which attempted to make the
>> Motorcomm YT8821 PHY operate reliably in the Cudy M3000 WiFi router.
>>
>> Background
>> ==========
>>
>> The issue on the Cudy M3000 is an MDIO address collision at address 0:
>>
>>  * The MediaTek MT7981B internal Gigabit PHY appears to be hardwired
>>    to respond only at MDIO address 0.
>>
>>  * The Motorcomm YT8821 external PHY responds, by default, at address 0
>>    in addition to address 1 selected by its strapping pins.
>>
>> At a minimum, this means that MDIO transactions intended for the
>> MT7981B PHY are also interpreted by the YT8821, which causes the
>> YT8821 to not work reliably.
>>
>> The YT8821 is not unique in this regard. At least two other vendors
>> ship PHYs with similar behavior:
>>
>>  * Realtek RTL8221B-VB-CG
>>  * Micrel KSZ8081
>>
>> It appears to me that multiple vendors may have interpreted IEEE 802.3
>> Clause 22.2.4.5.5 to mean that MDIO address 0 is a reserved broadcast
>> address ("A PHY [...] shall always respond to transactions addressed
>> to PHY Address zero"). However, the omitted part of that sentence
>> limits the scope, and it does not apply to many PHY types.
> 
> I stopped being lazy and looked at 802.3:
> 
>   22.2.4.5.5 PHYAD (PHY Address)
> 
>   The PHY Address is five bits, allowing 32 unique PHY addresses. The
>   first PHY address bit transmitted and received is the MSB of the
>   address. A PHY that is connected to the station management entity
>   via the mechanical interface defined in 22.6 shall always respond to
>   transactions addressed to PHY Address zero <00000>. A station
>   management entity that is attached to multiple PHYs has to have
>   prior knowledge of the appropriate PHY Address for each PHY.
> 
> And
> 
>   22.6 Mechanical characteristics
> 
>   When the MII is used to interconnect two printed circuit assemblies
>   via a short length of cable, the cable shall be connected to the
>   circuit assembly that implements the Reconciliation sublayer by
>   means of the mechanical interface defined in this clause.
> 
>   22.6.1 Definition of mechanical interface
> 
>   A 40-pole connector having the mechanical mateability dimensions as
>   specified in IEC 61076-3-101:1997 shall be used for the MII
>   connector. The circuit assembly that contains the MAC sublayer and
>   Reconciliation sublayer shall have a female connector with screw
>   locks, and the mating cable shall have a male connector with jack
>   screws.
> 
> Does your board have this 40-pole connector and screw locks?
> 

No, it doesn't :D

> I don't think i have seen one of these in the last 30 years. I do
> remember during my University times some Sun Microsystems, maybe a
> Sun-2, with a fat maybe 2 meter cable running into the false floor to
> a transceiver box onto the one Ethernet cable which snaked around the
> Computing Department.
> 
> So this should not apply to any board from this century which is
> conforming to the 802.3 standard.
> 

I agree with that, this is what I was originally trying to say by
the omitted part limiting the scope, I just got the wording of the
last part of that sentence wrong.

The reason I think that some vendors must have misinterpreted the
specification is that they have claims in their datasheets like
(Micrel KSZ8081RNA datasheet [1]):

| PHY address 0h is defined as the broadcast PHY address according
| to the IEEE 802.3 Specification, and can be used to read/write to
| a single PHY device, or write to multiple PHY devices simultaneously

and so I don't necessarily think they intentionally wanted to
violate the spec (nor I think you implied that, though).

[1]: https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ8081RNA-RND-10BASE-T-100-BASE-TX-PHY-with-RMII-Support-DS00002199F.pdf

> So i would say the board you are trying to support is broken twice.
> 
> 1) It is using part of 802.3 which does not apply.
> 
> 2) It has two PHYs which using the same address.
> 
> I can understand a PHY might support this, optionally, with a
> pull-up/down strapping, saying "Break the standard, also respond to
> address 0". But this clearly should be an opt in, and an extra
> component is required.
> 

This appears to be the case for some PHYs. I found that e.g. Micrel
KSZ8081MNX is documented to have a dedicated B-CAST_OFF pin that
does something like that. But e.g. Micrel KSZ8081RNA is shipped in
a smaller package that lacks that pin and its default is to use
address 0 as a broadcast address.

> I'm still not convinced Linux should be handling either of these
> conditions. And even if it did, it should not be in the core, but
> hidden away in a driver.
> 

ACK. Unfortunately I don't think it is feasible to move this into
the driver because of the probing order issues.

>        Andrew

Jakub