Some Ethernet PHY devices require a hard reset before any MDIO access can
be safely performed. This includes the auto-detection of the PHY ID, which
is necessary to bind the correct driver to the device.

The kernel currently does not provide a way to assert the reset before
reading the ID, making these devices usable only when the ID is hardcoded
in the Device Tree 'compatible' string.
(One notable exception is the FEC driver and its now deprecated
`phy-reset-gpios` property).

This patchset implements an optional reset before reading of the PHY ID
register, allowing such PHYs to be used with auto-detected ID. The reset
is only asserted when the current logic fails to detect the ID, ensuring
compatibility with existing systems.

There have been several earlier attempts to implement such functionality,
of which I have collected a few in the links section.

The links to the previous versions are also provided.
The most notable changes compared to v4 are:
 - -EPROBE_DEFER during the reset is propagated upward, while any other
   errors retain the original error code
 - The info level message for asserting the reset is split into a
   separate commit.

Link: https://lore.kernel.org/lkml/1499346330-12166-2-git-send-email-richard.leitner@skidata.com/
Link: https://lore.kernel.org/all/20230405-net-next-topic-net-phy-reset-v1-0-7e5329f08002@pengutronix.de/
Link: https://lore.kernel.org/netdev/20250709133222.48802-4-buday.csaba@prolan.hu/
Link: https://lore.kernel.org/all/20251013135557.62949-1-buday.csaba@prolan.hu/
Link: https://lore.kernel.org/all/20251015134503.107925-1-buday.csaba@prolan.hu/
Link: https://lore.kernel.org/netdev/cover.1760620093.git.buday.csaba@prolan.hu/
Link: https://lore.kernel.org/netdev/cover.1761124022.git.buday.csaba@prolan.hu/

Buday Csaba (4):
  net: mdio: common handling of phy reset properties
  net: mdio: change property read from fwnode_property_read_u32() to
    device_property_read_u32()
  net: mdio: reset PHY before attempting to access registers in
    fwnode_mdiobus_register_phy
  net: mdio: add message when resetting a PHY before registration

 drivers/net/mdio/fwnode_mdio.c | 48 +++++++++++++++++++++----
 drivers/net/phy/mdio_bus.c     | 39 ++------------------
 drivers/net/phy/mdio_device.c  | 66 ++++++++++++++++++++++++++++++++++
 include/linux/mdio.h           |  3 ++
 4 files changed, 113 insertions(+), 43 deletions(-)


base-commit: 00922eeaca3c5c2001781bcad40e0bd54d0fdbb6
-- 
2.39.5

On Wed, Oct 29, 2025 at 11:23:40AM +0100, Buday Csaba wrote:
> Some Ethernet PHY devices require a hard reset before any MDIO access can
> be safely performed. This includes the auto-detection of the PHY ID, which
> is necessary to bind the correct driver to the device.

nitpicking a bit, but this last part is not strictly correct. You can
also bind the correct driver to the PHY using a compatible. So it is
not 'necessary'. It is maybe the preferred way to do it, although the
DT Maintainers my disagree and say compatible is the preferred way.

> The kernel currently does not provide a way to assert the reset before
> reading the ID, making these devices usable only when the ID is hardcoded
> in the Device Tree 'compatible' string.

Which is what you say here.

> (One notable exception is the FEC driver and its now deprecated
> `phy-reset-gpios` property).

> This patchset implements an optional reset before reading of the PHY ID
> register, allowing such PHYs to be used with auto-detected ID. The reset
> is only asserted when the current logic fails to detect the ID, ensuring
> compatibility with existing systems.

O.K, that is new.

One of the arguments raised against making this more complex is that
next somebody will want to add clock support. And should that be
enabled before or after the reset? And then regulators, and what order
should that be done in? The core cannot answer these questions, only
the driver can. The compatible should be used to get the driver loaded
and then it can enable these resources in the correct order.

I will look at the patches anyway.

  Andrew

On Wed, Oct 29, 2025 at 01:43:32PM +0100, Andrew Lunn wrote:
> On Wed, Oct 29, 2025 at 11:23:40AM +0100, Buday Csaba wrote:
> > Some Ethernet PHY devices require a hard reset before any MDIO access can
> > be safely performed. This includes the auto-detection of the PHY ID, which
> > is necessary to bind the correct driver to the device.
> 
> nitpicking a bit, but this last part is not strictly correct. You can
> also bind the correct driver to the PHY using a compatible. So it is
> not 'necessary'. It is maybe the preferred way to do it, although the
> DT Maintainers my disagree and say compatible is the preferred way.
> 

I have also gotten the impression, that DT people generally prefer
hardcoding the ID. I can not argue with that. But that should be clearly
reflected in the documentation. Now the description in ethernet-phy.yaml
suggests that a correct ID only is a workaround for misbehaving PHYs:

"If the PHY reports an incorrect ID (or none at all) then the
compatible list may contain an entry with the correct PHY ID
in the above form."

> > The kernel currently does not provide a way to assert the reset before
> > reading the ID, making these devices usable only when the ID is hardcoded
> > in the Device Tree 'compatible' string.
> 
> Which is what you say here.
> 
> > (One notable exception is the FEC driver and its now deprecated
> > `phy-reset-gpios` property).
> 
> > This patchset implements an optional reset before reading of the PHY ID
> > register, allowing such PHYs to be used with auto-detected ID. The reset
> > is only asserted when the current logic fails to detect the ID, ensuring
> > compatibility with existing systems.
> 
> O.K, that is new.
> 
> One of the arguments raised against making this more complex is that
> next somebody will want to add clock support. And should that be
> enabled before or after the reset? And then regulators, and what order
> should that be done in? The core cannot answer these questions, only
> the driver can. The compatible should be used to get the driver loaded
> and then it can enable these resources in the correct order.
> 

Again, I can not argue with that. I can only tell that these patch fixed
our problem - I hope that others may also benefit from it.

> I will look at the patches anyway.
> 
>   Andrew
> 

Really appreciate it, thanks!

Csaba