linux-kernel - Re: [RFC PATCH] net: phy: integrate reset-after-clock quirk into phy_init

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] [day] [month] [year] [list]

Message-ID: <aXtvCN6-QDUGbi0P@shell.armlinux.org.uk>
Date: Thu, 29 Jan 2026 14:30:32 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Marco Felsch <m.felsch@...gutronix.de>
Cc: Michael Nazzareno Trimarchi <michael@...rulasolutions.com>,
	Andrew Lunn <andrew@...n.ch>, Wei Fang <wei.fang@....com>,
	Shenwei Wang <shenwei.wang@....com>,
	Clark Wang <xiaoning.wang@....com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	"open list:FREESCALE IMX / MXC FEC DRIVER" <imx@...ts.linux.dev>,
	"open list:FREESCALE IMX / MXC FEC DRIVER" <netdev@...r.kernel.org>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] net: phy: integrate reset-after-clock quirk into
 phy_init_hw

On Thu, Jan 29, 2026 at 01:19:28PM +0000, Russell King (Oracle) wrote:
> On Thu, Jan 29, 2026 at 01:12:41PM +0000, Russell King (Oracle) wrote:
> > Another possible solution beyond those I've already stated, given that
> > this only afflicts the FEC driver, ould be for the FEC MDIO driver to
> > walk the child nodes, checking to see whether they require any clocks,
> > and ensuring that those are properly initialised before registering the
> > MDIO bus.
> > 
> > Since the MDIO bus layer can release the PHY reset just before probing
> > the driver, this seems to me to be the only way to guarantee that,
> > where boot firmware does not deal with this, the PHY manufacturers
> > specification for the initial release of reset can be met while keeping
> > this FEC specific behaviour out of the core MDIO/phylib layers.
> 
> I'll also add... as kernel developers, we're not very good at insisting
> on generic names for things like clocks (see the mess that is stmmac,
> where the dwmac's various clock signals are named differently in the
> many platform glues.)
> 
> So, I guess that FEC MDIO may need to have a list of clock names to
> look for when inspecting the PHY nodes if the clock is even specified
> there. If it isn't, then some other way of discovering that the PHY
> needs a clock (looking at the pinctrl configuration to see whether
> the pin is configured to output a clock to the PHY?) would need to be
> added.
> 
> However, care needs to be taken in the case where the PHY has already
> been setup by boot firmware, that the clock signal is not disturbed,
> as interrupting it could provoke PHY problems - especially if the
> platform doesn't have the PHY reset specified in DT.

A further issue to add following on from that last paragraph is whether
one is indeed permitted to stop the PHYs XTAL/reference clock or not
after the PHY has been setup. This would depend on the design of the
PHY.

The safe thing to do is not to stop the clock, but if it is desirable
to do so with PHYs that allow it, and provided they do not lose
settings as a result, then we would need some way to inform the MDIO
bus layer when it is safe to stop those clocks. That would require
phylib/mdio code changes to have the driver indicate that this PHY
permits the clock to be stopped.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!