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: <23c1bed1-3f95-48b9-8ff0-71696bdcd62b@lunn.ch>
Date: Wed, 29 Oct 2025 13:43:32 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Buday Csaba <buday.csaba@...lan.hu>
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 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