Re: [PATCH net-next v5 0/4] net: mdio: implement optional PHY reset before MDIO access

[Buday Csaba <buday.csaba@prolan.hu>]

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