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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aQIZvDt5gooZSTcp@debianbuilder>
Date: Wed, 29 Oct 2025 14:42:20 +0100
From: Buday Csaba <buday.csaba@...lan.hu>
To: Andrew Lunn <andrew@...n.ch>
CC: Heiner Kallweit <hkallweit1@...il.com>, Russell King
	<linux@...linux.org.uk>, "David S. Miller" <davem@...emloft.net>, "Eric
 Dumazet" <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>, Philipp Zabel <p.zabel@...gutronix.de>,
	<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next v5 0/4] net: mdio: implement optional PHY reset
 before MDIO access

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