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.

What this series does
=====================

The goal of this series is to reconfigure the YT8821 early enough so
that it stops responding on address 0 before the kernel performs the
first access to MDIO address 0.

The approach is as follows:

 1. Patches 1 and 2 modify the MDIO bus probing order so that address 0
    is scanned last. This allows PHY fixups to reconfigure PHYs found
    at addresses 1-31 before address 0 is probed. The core idea was
    suggested by @dangowrt on OpenWrt GitHub [2].

 2. Patches 3-5 implement the required PHY fixup for the YT8821.
    They introduce infrastructure for an "address 0 fixup" that can
    be reused by other affected PHYs.

I initially attempted to use the driver .probe() callback. However,
testing showed that this is insufficient: if the YT8821 driver is
built as a module, the .probe() callback does not run early
enough (i.e. before the MT7981B PHY is initialized).

Why this is done in the kernel
==============================

In the v1 discussion [1], the conclusion was that this should ideally
be handled in the bootloader. However, this is not always practical
for OpenWrt deployments:

 * On the Cudy M3000, replacing the stock U-Boot is possible, but
   doing so removes the ability to easily revert to the vendor
   firmware using the procedure described in [3].

 * On other platforms, replacing the bootloader may not be possible, and
   so OpenWrt may need to have a kernel-based workaround for them [2].

Testing
=======

The series was tested against the v6.12 kernel currently used by
OpenWrt main. It resolves the PHY issues on the Cudy M3000 with the
Motorcomm PHY and does not break networking on the Cudy WR3000H,
which uses a different Realtek PHY.

I also verified that no MDIO access to address 0 occurs before the
YT8821 is reconfigured to stop responding on that address.

The series is rebased on top of v7.0-rc1 and build-tested there.

[1]: https://lore.kernel.org/all/d3bb9c36-5a0e-4339-901d-2dd21bdba395@gmail.com/#t
[2]: https://github.com/openwrt/openwrt/pull/21584#issuecomment-3941868545
[3]: https://www.cudy.com/en-eu/blogs/faq/how-to-recovery-the-cudy-router-from-openwrt-firmware-to-cudy-official-firmware

Signed-off-by: Jakub Vaněk <linuxtardis@gmail.com>
---
Changes in v2:
- Introduce changes into the PHY core that allow the broadcast
  addresses to be disabled before the first address collision
  occurs.
- Move the early disabling of the broadcast address from the
  YT8821 .probe() callback into a PHY fixup.
- In motorcomm.c, use ytphy_read_ext_with_lock() for the disabling
  as it takes the MDIO bus lock.

Jakub Vaněk (5):
  net: mdio_bus: Scan buses in reverse order (31 -> 0)
  of: mdio: Scan PHY address 0 last
  net: phy: Support PHY fixups on Clause 45 PHYs
  net: phy: Add infrastructure for PHY address 0 fixups
  net: phy: motorcomm: yt8821: Disable MDIO broadcast

 drivers/net/mdio/of_mdio.c          | 35 +++++++++++++++--
 drivers/net/phy/Makefile            |  3 +-
 drivers/net/phy/mdio_bus_provider.c | 14 ++++++-
 drivers/net/phy/motorcomm.c         | 29 ++++++++++++++
 drivers/net/phy/phy_common_fixups.c | 59 ++++++++++++++++++++++++++++
 drivers/net/phy/phy_device.c        | 60 ++++++++++++++++++++---------
 drivers/net/phy/phylib-internal.h   |  2 +
 7 files changed, 176 insertions(+), 26 deletions(-)
 create mode 100644 drivers/net/phy/phy_common_fixups.c

-- 
2.43.0

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?

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.

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.

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.

       Andrew

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

On Sun, Mar 01, 2026 at 05:06:58PM +0100, Andrew Lunn wrote:
> 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.
> 
> I'm still not convinced Linux should be handling either of these
> conditions.

+1.

> And even if it did, it should not be in the core, but
> hidden away in a driver.

It's not something a driver can handle, because by the time a driver
gets to see anything about the devices, we could've already scanned
the addresses and read bad IDs.

I believe we've said before that the board firmware should be fixing
this, not the kernel - I know I have said that on more than one
occasion about this broken hardware.

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