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

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

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.