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

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

[Jakub Vaněk]

The YT8821 PHY responds on two MDIO addresses by default: the address
selected by its strapping pins and the broadcast address 0.

On platforms where another PHY is hardwired to respond only on address 0
(e.g. the internal Gigabit PHY in the MediaTek MT7981B SoC), this can lead
to MDIO bus conflicts. The YT8821 may incorrectly respond to transactions
intended for the other PHY, leaving it in an inconsistent state. The
following issues were observed on a Cudy M3000 router:

- Achieving just 100 Mbps speeds on gigabit links. Dmesg would show
  messages like

    [ 133.997177] YT8821 2.5Gbps PHY mdio-bus:01: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
    [ 134.009400] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off

- Having the PHY report that the link is up, yet no data would flow.
- The YT8821 would be affected by an "ip link set dev eth1 down"
  command aimed at the other PHY.

Avoid this conflict by disabling the broadcast address 0 early in
the PHY configuration process. The .probe callback is called early
enough to stop the issues from occurring. The .config_init callback
re-establishes the workaround after the PHY undergoes a hardware
reset.

This change makes the YT8821 work reliably on the Cudy M3000 router
when running the current OpenWrt main branch with a small device tree
patch.

Link: https://github.com/openwrt/openwrt/pull/21584
Fixes: b671105b88c3 ("net: phy: Add driver for Motorcomm yt8821 2.5G ethernet phy")
Signed-off-by: Jakub Vaněk <linuxtardis@gmail.com>
---
 drivers/net/phy/motorcomm.c | 48 +++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/drivers/net/phy/motorcomm.c b/drivers/net/phy/motorcomm.c
index 42d46b5758fc..bcb60d0bcab5 100644
--- a/drivers/net/phy/motorcomm.c
+++ b/drivers/net/phy/motorcomm.c
@@ -227,6 +227,9 @@
 #define YT8521_LED_100_ON_EN			BIT(5)
 #define YT8521_LED_10_ON_EN			BIT(4)
 
+#define YTPHY_MDIO_ADDRESS_CONTROL_REG		0xA005
+#define YTPHY_MACR_EN_PHY_ADDR_0		BIT(6)
+
 #define YTPHY_MISC_CONFIG_REG			0xA006
 #define YTPHY_MCR_FIBER_SPEED_MASK		BIT(0)
 #define YTPHY_MCR_FIBER_1000BX			(0x1 << 0)
@@ -2760,6 +2763,30 @@ static int yt8821_soft_reset(struct phy_device *phydev)
 					  YT8521_CCR_SW_RST, 0);
 }
 
+/**
+ * yt8821_disable_mdio_address_zero() - disable MDIO broadcast address 0
+ * @phydev: a pointer to a &struct phy_device
+ *
+ * The YT8821 responds on two MDIO addresses by default:
+ *  - the address selected by its strapping pins
+ *  - the broadcast address 0
+ *
+ * Some other PHYs (e.g. the MT7981B internal Gigabit PHY) are hardwired to
+ * respond only on MDIO address 0. If the YT8821 also listens on address 0,
+ * it may incorrectly react to transactions intended for those PHYs.
+ *
+ * Disabling address 0 on the YT8821 early avoids such MDIO bus conflicts.
+ *
+ * Returns: 0 or negative errno code
+ */
+static int yt8821_disable_mdio_address_zero(struct phy_device *phydev)
+{
+	return ytphy_modify_ext(phydev,
+				YTPHY_MDIO_ADDRESS_CONTROL_REG,
+				YTPHY_MACR_EN_PHY_ADDR_0,
+				0);
+}
+
 /**
  * yt8821_config_init() - phy initializatioin
  * @phydev: a pointer to a &struct phy_device
@@ -2795,6 +2822,10 @@ static int yt8821_config_init(struct phy_device *phydev)
 		phydev->rate_matching = RATE_MATCH_PAUSE;
 	}
 
+	ret = yt8821_disable_mdio_address_zero(phydev);
+	if (ret < 0)
+		return ret;
+
 	ret = yt8821_serdes_init(phydev);
 	if (ret < 0)
 		return ret;
@@ -2812,6 +2843,22 @@ static int yt8821_config_init(struct phy_device *phydev)
 	return yt8821_soft_reset(phydev);
 }
 
+/**
+ * yt8821_probe() - early PHY initialization
+ * @phydev: a pointer to a &struct phy_device
+ *
+ * Returns: 0 or negative errno code
+ */
+static int yt8821_probe(struct phy_device *phydev)
+{
+	/*
+	 * Disable the MDIO broadcast address (0) as early as possible.
+	 * This prevents the YT8821 from responding to transactions
+	 * intended for a different PHY that is fixed at address 0.
+	 */
+	return yt8821_disable_mdio_address_zero(phydev);
+}
+
 /**
  * yt8821_adjust_status() - update speed and duplex to phydev
  * @phydev: a pointer to a &struct phy_device
@@ -3073,6 +3120,7 @@ static struct phy_driver motorcomm_phy_drvs[] = {
 		PHY_ID_MATCH_EXACT(PHY_ID_YT8821),
 		.name			= "YT8821 2.5Gbps PHY",
 		.get_features		= yt8821_get_features,
+		.probe			= yt8821_probe,
 		.read_page		= yt8521_read_page,
 		.write_page		= yt8521_write_page,
 		.get_wol		= ytphy_get_wol,
-- 
2.43.0

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

[Andrew Lunn]

On Sun, Feb 22, 2026 at 12:46:53AM +0100, Jakub Vaněk wrote:
> The YT8821 PHY responds on two MDIO addresses by default: the address
> selected by its strapping pins and the broadcast address 0.
> 
> On platforms where another PHY is hardwired to respond only on address 0
> (e.g. the internal Gigabit PHY in the MediaTek MT7981B SoC), this can lead
> to MDIO bus conflicts. The YT8821 may incorrectly respond to transactions
> intended for the other PHY, leaving it in an inconsistent state. The
> following issues were observed on a Cudy M3000 router:

I don't think you can reliably fix this in this way.

Linux enumerates and probes the bus in two different ways.

When mdiobus_register() is used, it enumerates the bus in address
order.  So the probe of the internal Gigabit PHY will happen first at
address 0, and then the YT8821 will later be probed, by which times it
has already caused bus conflicts and potentially messed up the
internal PHY.

If of_mdiobus_register() is used, it first probes the PHYs listed in
DT, based on the order of the child nodes. If the child nodes are
first reg=<0> for the internal PHY, and then reg=<??> for the YT8821,
you have the same issue, bus conflicts. And ordering the nodes this
way is part of the DT coding style...

Now you could vary carefully put the nodes in the correct order, with
a big fat warning that the board design is FUBAR and will only work
with the nodes in this specific order. And you need another big fat
warning in the YT8821 driver that just because broadcast is turned off
at probe does not on its own make it reliable, it could of already
destroyed another PHYs configuration by the time the driver probes.

So to me, this sounds unreliable, a potential foot gun.

I can think of two better ways to fix this:

1) In the bootloader. If the bootloader supports TFTP booting, or any
networking, it needs to fix the same issue. It can poke around on the
MDIO bus before it probes the PHYs.

2) Split of_mdiobus_register() into two, so that you can register the
bus, then do some platform specific fixups to disable the broadcast
address in the PHY, and then do the second half of
of_mdiobus_register() which probes the PHYs, once it is safe to use
address 0 on the bus.

I prefer 1).

	Andrew

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

[Jakub Vaněk]

Hello,

An alternative approach was suggested to me earlier today: changing the
probing order in (of_)mdiobus_register() so that PHY address 0 is always
probed last. The offending PHYs would be reconfigured to not listen for
broadcasts on address 0 either via the PHY driver .probe callbacks or
via non-board-specific PHY fixups.

Do you think such an approach could reliably avoid the address-0
conflict, and would a patch along these lines be acceptable upstream?

This issue does not appear to be specific to the Motorcomm YT8821.
I have found other PHYs that also respond on MDIO address 0 in addition
to their strapped address, including:

* Realtek RTL8221B and RTL8211F PHYs,
* Micrel KSZ8081, where this is acknowledged in commit 57a38effa598
  ("net: phy: micrel: disable broadcast for KSZ8081/KSZ8091")

My understanding is that this behavior may stem from differing
interpretations of IEEE 802.3-2005 Clause 22.2.4.5.5. As I read it,
the clause requires a PHY connected via a specific cable to always
respond on address 0; some vendors appear to have interpreted this
as the address 0 being a reserved broadcast address.

I also received some feedback on replacing the bootloader in various
routers. While the U-Boot can be replaced in the Cudy M3000, this may
not be the case for all manufacturers. On those platforms, a kernel-
level fix would be necessary, although it could remain as a downstream
patch in OpenWrt if the fix is unsuitable for mainline.

What are your thoughts on this?

Best regards,
Jakub

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

[Russell King (Oracle)]

On Sun, Feb 22, 2026 at 12:46:53AM +0100, Jakub Vaněk wrote:
> The YT8821 PHY responds on two MDIO addresses by default: the address
> selected by its strapping pins and the broadcast address 0.
> 
> On platforms where another PHY is hardwired to respond only on address 0
> (e.g. the internal Gigabit PHY in the MediaTek MT7981B SoC), this can lead
> to MDIO bus conflicts. The YT8821 may incorrectly respond to transactions
> intended for the other PHY, leaving it in an inconsistent state. The
> following issues were observed on a Cudy M3000 router:
> 
> - Achieving just 100 Mbps speeds on gigabit links. Dmesg would show
>   messages like
> 
>     [ 133.997177] YT8821 2.5Gbps PHY mdio-bus:01: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
>     [ 134.009400] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
> 
> - Having the PHY report that the link is up, yet no data would flow.
> - The YT8821 would be affected by an "ip link set dev eth1 down"
>   command aimed at the other PHY.
> 
> Avoid this conflict by disabling the broadcast address 0 early in
> the PHY configuration process. The .probe callback is called early
> enough to stop the issues from occurring. The .config_init callback
> re-establishes the workaround after the PHY undergoes a hardware
> reset.
> 
> This change makes the YT8821 work reliably on the Cudy M3000 router
> when running the current OpenWrt main branch with a small device tree
> patch.
> 
> Link: https://github.com/openwrt/openwrt/pull/21584
> Fixes: b671105b88c3 ("net: phy: Add driver for Motorcomm yt8821 2.5G ethernet phy")
> Signed-off-by: Jakub Vaněk <linuxtardis@gmail.com>
> ---
>  drivers/net/phy/motorcomm.c | 48 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 48 insertions(+)
> 
> diff --git a/drivers/net/phy/motorcomm.c b/drivers/net/phy/motorcomm.c
> index 42d46b5758fc..bcb60d0bcab5 100644
> --- a/drivers/net/phy/motorcomm.c
> +++ b/drivers/net/phy/motorcomm.c
> @@ -227,6 +227,9 @@
>  #define YT8521_LED_100_ON_EN			BIT(5)
>  #define YT8521_LED_10_ON_EN			BIT(4)
>  
> +#define YTPHY_MDIO_ADDRESS_CONTROL_REG		0xA005
> +#define YTPHY_MACR_EN_PHY_ADDR_0		BIT(6)
> +
>  #define YTPHY_MISC_CONFIG_REG			0xA006
>  #define YTPHY_MCR_FIBER_SPEED_MASK		BIT(0)
>  #define YTPHY_MCR_FIBER_1000BX			(0x1 << 0)
> @@ -2760,6 +2763,30 @@ static int yt8821_soft_reset(struct phy_device *phydev)
>  					  YT8521_CCR_SW_RST, 0);
>  }
>  
> +/**
> + * yt8821_disable_mdio_address_zero() - disable MDIO broadcast address 0
> + * @phydev: a pointer to a &struct phy_device
> + *
> + * The YT8821 responds on two MDIO addresses by default:
> + *  - the address selected by its strapping pins
> + *  - the broadcast address 0
> + *
> + * Some other PHYs (e.g. the MT7981B internal Gigabit PHY) are hardwired to
> + * respond only on MDIO address 0. If the YT8821 also listens on address 0,
> + * it may incorrectly react to transactions intended for those PHYs.
> + *
> + * Disabling address 0 on the YT8821 early avoids such MDIO bus conflicts.
> + *
> + * Returns: 0 or negative errno code
> + */
> +static int yt8821_disable_mdio_address_zero(struct phy_device *phydev)
> +{
> +	return ytphy_modify_ext(phydev,
> +				YTPHY_MDIO_ADDRESS_CONTROL_REG,
> +				YTPHY_MACR_EN_PHY_ADDR_0,
> +				0);
> +}
> +
>  /**
>   * yt8821_config_init() - phy initializatioin
>   * @phydev: a pointer to a &struct phy_device
> @@ -2795,6 +2822,10 @@ static int yt8821_config_init(struct phy_device *phydev)
>  		phydev->rate_matching = RATE_MATCH_PAUSE;
>  	}
>  
> +	ret = yt8821_disable_mdio_address_zero(phydev);
> +	if (ret < 0)
> +		return ret;
> +
>  	ret = yt8821_serdes_init(phydev);
>  	if (ret < 0)
>  		return ret;
> @@ -2812,6 +2843,22 @@ static int yt8821_config_init(struct phy_device *phydev)
>  	return yt8821_soft_reset(phydev);
>  }
>  
> +/**
> + * yt8821_probe() - early PHY initialization
> + * @phydev: a pointer to a &struct phy_device
> + *
> + * Returns: 0 or negative errno code
> + */
> +static int yt8821_probe(struct phy_device *phydev)
> +{
> +	/*
> +	 * Disable the MDIO broadcast address (0) as early as possible.
> +	 * This prevents the YT8821 from responding to transactions
> +	 * intended for a different PHY that is fixed at address 0.
> +	 */
> +	return yt8821_disable_mdio_address_zero(phydev);

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.

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

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

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

[Jakub Vaněk]

Hello Daniel, Qingfang, SkyLake,

do you happen to know if the MediaTek Gigabit PHY in the MT7981B
can be remapped to a MDIO address other than address 0?

I wasn't able to find public documentation describing the registers
of internal PHY or whether its MDIO address is configurable.

Being able to move the internal PHY off address 0 in U-Boot could be
a better way of resolving a MDIO address conflict between the internal
PHY and the broadcast address used by an external Motorcomm YT8821 PHY.

Any pointers would be appreciated.

Best regards,
Jakub

On 2/22/26 00:46, Jakub Vaněk wrote:
> The YT8821 PHY responds on two MDIO addresses by default: the address
> selected by its strapping pins and the broadcast address 0.
> 
> On platforms where another PHY is hardwired to respond only on address 0
> (e.g. the internal Gigabit PHY in the MediaTek MT7981B SoC), this can lead
> to MDIO bus conflicts. The YT8821 may incorrectly respond to transactions
> intended for the other PHY, leaving it in an inconsistent state. The
> following issues were observed on a Cudy M3000 router:
> 
> - Achieving just 100 Mbps speeds on gigabit links. Dmesg would show
>   messages like
> 
>     [ 133.997177] YT8821 2.5Gbps PHY mdio-bus:01: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
>     [ 134.009400] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
> 
> - Having the PHY report that the link is up, yet no data would flow.
> - The YT8821 would be affected by an "ip link set dev eth1 down"
>   command aimed at the other PHY.

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

[Andrew Lunn]

On Sun, Feb 22, 2026 at 03:32:45AM +0100, Jakub Vaněk wrote:
> Hello Daniel, Qingfang, SkyLake,
> 
> do you happen to know if the MediaTek Gigabit PHY in the MT7981B
> can be remapped to a MDIO address other than address 0?
> 
> I wasn't able to find public documentation describing the registers
> of internal PHY or whether its MDIO address is configurable.
> 
> Being able to move the internal PHY off address 0 in U-Boot could be
> a better way of resolving a MDIO address conflict between the internal
> PHY and the broadcast address used by an external Motorcomm YT8821 PHY.
> 
> Any pointers would be appreciated.

Even if you can avoid the conflict, you still need to handle the fact
the YT8821 appears on two addresses. phylib has no idea it is the same
device in two places, so it can instantiate two struct phy_device for
it. This can cause problems, i think suspend/resume will break, etc.

There is nothing in IEEE 802.3 clause 22 or 45 that allows for this
behaviour. So rather than living with all the issues it causes, you
really do want to get the PHY into standards conformance.

       Andrew

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

[Jakub Vaněk]

On 2/22/26 04:35, Andrew Lunn wrote:
> On Sun, Feb 22, 2026 at 03:32:45AM +0100, Jakub Vaněk wrote:
>> Hello Daniel, Qingfang, SkyLake,
>>
>> do you happen to know if the MediaTek Gigabit PHY in the MT7981B
>> can be remapped to a MDIO address other than address 0?
>>
>> I wasn't able to find public documentation describing the registers
>> of internal PHY or whether its MDIO address is configurable.
>>
>> Being able to move the internal PHY off address 0 in U-Boot could be
>> a better way of resolving a MDIO address conflict between the internal
>> PHY and the broadcast address used by an external Motorcomm YT8821 PHY.
>>
>> Any pointers would be appreciated.
> 
> Even if you can avoid the conflict, you still need to handle the fact
> the YT8821 appears on two addresses. phylib has no idea it is the same
> device in two places, so it can instantiate two struct phy_device for
> it. This can cause problems, i think suspend/resume will break, etc.

I had hoped this would not happen on the Cudy router. The MediaTek
Ethernet subsystem driver uses of_mdiobus_register(), so PHY address 0
should not be probed unless it is explicitly described in the device
tree. That said, I agree that with mdiobus_register() this would still
be an issue.

I was also hoping that moving the internal PHY would provide more
flexibility in the device tree description of the YT8821. If the
workaround were implemented in U-Boot by writing YT8821 MDIO registers
at boot time, Linux would not be able to assert the YT8821 reset pin
without losing that workaround.

Jakub

> There is nothing in IEEE 802.3 clause 22 or 45 that allows for this
> behaviour. So rather than living with all the issues it causes, you
> really do want to get the PHY into standards conformance.
> 
>        Andrew

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

[Russell King (Oracle)]

On Sun, Feb 22, 2026 at 05:22:55AM +0100, Jakub Vaněk wrote:
> I had hoped this would not happen on the Cudy router. The MediaTek
> Ethernet subsystem driver uses of_mdiobus_register(), so PHY address 0
> should not be probed unless it is explicitly described in the device
> tree. That said, I agree that with mdiobus_register() this would still
> be an issue.
> 
> I was also hoping that moving the internal PHY would provide more
> flexibility in the device tree description of the YT8821. If the
> workaround were implemented in U-Boot by writing YT8821 MDIO registers
> at boot time, Linux would not be able to assert the YT8821 reset pin
> without losing that workaround.

Why would you want to assert the reset pin?

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

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

[Jakub Vaněk]

On 2/22/26 09:28, Russell King (Oracle) wrote:
> On Sun, Feb 22, 2026 at 05:22:55AM +0100, Jakub Vaněk wrote:
>> I had hoped this would not happen on the Cudy router. The MediaTek
>> Ethernet subsystem driver uses of_mdiobus_register(), so PHY address 0
>> should not be probed unless it is explicitly described in the device
>> tree. That said, I agree that with mdiobus_register() this would still
>> be an issue.
>>
>> I was also hoping that moving the internal PHY would provide more
>> flexibility in the device tree description of the YT8821. If the
>> workaround were implemented in U-Boot by writing YT8821 MDIO registers
>> at boot time, Linux would not be able to assert the YT8821 reset pin
>> without losing that workaround.
> 
> Why would you want to assert the reset pin?
> 

I don't currently have a solid reason to assert the reset pin.
The two reasons I had in mind were mostly precautionary:

- I saw that the Qualcomm Atheros AR803x PHY driver relies on the
  hardware reset pin to work around a hardware errata. While the
  YT8821 appears to work just fine without asserting the reset,
  I wanted to keep the option open in case a similar need arises
  in the future.

- In the OpenWrt device trees for Cudy routers, PHY reset GPIOs
  are/were* often described on the PHY node itself. I observed that
  when the reset GPIO is associated with the PHY, the PHY core asserts
  the reset pin in response to "ip link set dev eth0 down". Moving the
  reset pin definition elsewhere changed that behavior. So far it
  appeared to be fine, but I wasn't yet entirely sure that I didn't
  subtly break something.

Jakub

* I recently moved some of the reset GPIO definitions from the PHY
  level to the MDIO bus level to make the automatic PHY type detection
  work. Doing this in U-Boot would work equally well.

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

[Andrew Lunn]

On Sun, Feb 22, 2026 at 10:52:28AM +0100, Jakub Vaněk wrote:
> On 2/22/26 09:28, Russell King (Oracle) wrote:
> > On Sun, Feb 22, 2026 at 05:22:55AM +0100, Jakub Vaněk wrote:
> >> I had hoped this would not happen on the Cudy router. The MediaTek
> >> Ethernet subsystem driver uses of_mdiobus_register(), so PHY address 0
> >> should not be probed unless it is explicitly described in the device
> >> tree. That said, I agree that with mdiobus_register() this would still
> >> be an issue.
> >>
> >> I was also hoping that moving the internal PHY would provide more
> >> flexibility in the device tree description of the YT8821. If the
> >> workaround were implemented in U-Boot by writing YT8821 MDIO registers
> >> at boot time, Linux would not be able to assert the YT8821 reset pin
> >> without losing that workaround.
> > 
> > Why would you want to assert the reset pin?
> > 
> 
> I don't currently have a solid reason to assert the reset pin.
> The two reasons I had in mind were mostly precautionary:

Being able to drive a PHY reset pin in Linux is relatively new. It was
added in 2016. Before that, we lived without this feature. If
anything, being able to reset the PHY causes more issues than it
solves.

So unless the PHY is actually broken and needs a reset to make it
work, it is probably better not to list the reset.

       Andrew

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

[Jakub Vaněk]

On 2/22/26 16:15, Andrew Lunn wrote:
> On Sun, Feb 22, 2026 at 10:52:28AM +0100, Jakub Vaněk wrote:
>> On 2/22/26 09:28, Russell King (Oracle) wrote:
>>> On Sun, Feb 22, 2026 at 05:22:55AM +0100, Jakub Vaněk wrote:
>>>> I had hoped this would not happen on the Cudy router. The MediaTek
>>>> Ethernet subsystem driver uses of_mdiobus_register(), so PHY address 0
>>>> should not be probed unless it is explicitly described in the device
>>>> tree. That said, I agree that with mdiobus_register() this would still
>>>> be an issue.
>>>>
>>>> I was also hoping that moving the internal PHY would provide more
>>>> flexibility in the device tree description of the YT8821. If the
>>>> workaround were implemented in U-Boot by writing YT8821 MDIO registers
>>>> at boot time, Linux would not be able to assert the YT8821 reset pin
>>>> without losing that workaround.
>>>
>>> Why would you want to assert the reset pin?
>>>
>>
>> I don't currently have a solid reason to assert the reset pin.
>> The two reasons I had in mind were mostly precautionary:
> 
> Being able to drive a PHY reset pin in Linux is relatively new. It was
> added in 2016. Before that, we lived without this feature. If
> anything, being able to reset the PHY causes more issues than it
> solves.
> 
> So unless the PHY is actually broken and needs a reset to make it
> work, it is probably better not to list the reset.

Thank you, that is encouraging. Handling the YT8821 PHY reset
and configuration in U-Boot should then indeed be sufficient.

Best regards,
Jakub