Message-ID: <20260129104123.zir4rtgeiu5qv3i7@pengutronix.de>
Date: Thu, 29 Jan 2026 11:41:23 +0100
From: Marco Felsch <m.felsch@...gutronix.de>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
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 26-01-28, Russell King (Oracle) wrote:
> 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.

This is like every external IC or internal IP ;) What's special is the
phy generic compatible handling... (please see below)

> 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.

IIRC the Linux phy framework does have this hard dependency, that a
phy needs to be accessible to make use of the generic phy compatible
probing to read-out the phy-id registers.

This requires that $someone e.g. the bootloader already did the phy
power-up sequencing for us so the phy-id can be read.

Once it comes to the FEC the situation is like this:
 - The FEC can provide the PHY clock via ("enet_out"), no external
   crystal required.
 - If the phy clk is specified the FEC will turn on this clock during
   the probe() and issues the MII bus probe incl. the phy probe().
 - Afterwards the clock is gets disabled

My patch added the support to keep to request the clock during
phy.probe() and keep phy-clock running till the phy.remove() callback
gets called. Therefore no such local quirk like PHY_RST_AFTER_CLK_EN is
required.

> 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.

This was exactly my use-case too and it's beeing addressed just fine
with no PHY_RST_AFTER_CLK_EN but the clock and reset specified within
the DTS.

> 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.

Yes but I don't see a problem at all if everything was specified
accordingly.

> 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.

Yes, it's very common that the bootloader does the initial work since
sometimes strapping pins are involved which need to be pulled too for
the reset sequence which are later on re-used for $other purpose.

As said, I don't see a problem with the LAN8710. But while checking the
Linux source code, I saw commit
57ec5a8735dc5dccd1ee68afdb1114956a3fce0d which re-introduced the reset
handling :-/

> 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.

I wouldn't recommend such setups at all. It's like asking for troubles
;)

Regards,
  Marco

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

-- 
#gernperDu 
#CallMeByMyFirstName

Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-9    |

Powered by blists - more mailing lists