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

Message-ID: <aXqJ_TtdBnkvEZ_i@shell.armlinux.org.uk>
Date: Wed, 28 Jan 2026 22:13:17 +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 Wed, Jan 28, 2026 at 09:26:34PM +0100, Marco Felsch wrote:
> |   Some PHYs need the refclk to be a continuous clock. Therefore they don't
> |   allow turning it off and on again during operation. Nonetheless such a
> |   clock switching is performed by some ETH drivers (namely FEC [1]) for
> |   power saving reasons. An example for an affected PHY is the
> |   SMSC/Microchip LAN8720 in "REF_CLK In Mode".
> 
> This can be achieved with commit
> bedd8d78aba300860cec3f85d6ff549b3b7f2679 if specified accordingly.

I don't think this is unusual. I've just checked the 88E151x
documentation, and that also requires: 10ms after power and 10 clock
cycles on XTAL_IN before deasserting reset. The timing diagram indicates
that subsequent hardware resets must be 10ms in duration, and show the
XTAL_IN clock running during the reset.

Looking at AR8035, it is similar - the clock must be running before
releasing reset and while reset is asserted.

So, to say that LAN8710 is somehow special seems wrong to me - it isn't
just these PHYs that have the requirement to be clocked before reset is
released nor while reset is asserted.

I'm guessing the problem here is that, most cases the clock is provided
by a crystal, in these cases it's being sourced from the SoC, and that
puts the responsibility on the SoC parts to guarantee the reset timing
required for the PHY in some way.

In other words, by sourcing it from the SoC, it's not phylib nor the
PHY driver's problem (the PHY driver comes along way too late) but the
responsibility for the boot firmware / DT description / network driver
to detect this situation and give the PHY what it requires to reset
properly before registering the MDIO bus.

The boot firmware route is how this is handled with SolidRun i.MX6
based boards - the PHY reset is a GPIO, but that GPIO is *not* told to
the kernel except as a hog. u-boot takes care of setting up the 25MHz
clock for the PHY and releasing its reset - it actually does two
resets due to running off the ANATOP provided clock. This is an AR8035
PHY, which as I've mentioned above, requires the clock running before
releasing reset, just like the LAN8710-like PHY that you're discussing
here.

Given all the complexity we've had with systems with two FECs, where
the PHY for one is connected via the MDIO bus on the other FEC, it
seems to me that pushing the clocking and reset handling into the
kernel is just asking for lots of pain.

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