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:

quoted

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."

quoted

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.

quoted

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

quoted

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