netdev - 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: <aXqLBXs0fUIVkQg_@shell.armlinux.org.uk>
Date: Wed, 28 Jan 2026 22:17:41 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: Michael Nazzareno Trimarchi <michael@...rulasolutions.com>,
	Marco Felsch <m.felsch@...gutronix.de>, 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 10:45:32PM +0100, Andrew Lunn wrote:
> On Wed, Jan 28, 2026 at 10:04:03PM +0100, Michael Nazzareno Trimarchi wrote:
> > Hi
> > 
> > On Wed, Jan 28, 2026 at 9:51 PM Andrew Lunn <andrew@...n.ch> wrote:
> > >
> > > > The issue was with the out-of-band reset coming from the FEC driver
> > > > which doesn't honor the phy state-machine.
> > >
> > > Could you explain this is more details. Is the FEC doing something
> > > wrong?
> > 
> > The fact that the phy should be reset when the clk is provided to it, is not
> > connected at all with the fec. I think that fec_main does not register itself
> > as clock provider, You "should" define the phy to have a clock if this is needed
> > during the restoration and we should not give any "magic" at controller level.
> 
> Do we know which clock the PHY is consuming?
> 
> The FEC has code for the clock "enet_out" which it enables and
> disables. If the PHY is also consuming this clock, we could also make
> it a consumer. The CCF reference counts enables/disables of clocks, so
> if the PHY enables it, the MAC won't be able to disable it.

As I've just mentioned earlier in this thread, there seems to be nothing
special about the LAN8710-like PHYs requiring their XTAL clock to be
running for reset to be functional. The same is true of AR8035 used
on i.MX6 SolidRun platforms, and Marvell 88E151x PHYs that I've looked
at. I would suggest that, in general, _all_ PHYs require their XTAL
clock to be running.

Therefore, this is not a work of the PHY at all.

It is a quirk of the board design to provide the PHY's XTAL clock from
the SoC, and this _seems_ to be common with FEC based systems, probably
because there's an easy way to get the clock from the FEC, thus saving
the cost of a crystal.

I stated how SolidRun handles this quirk entirely in uboot so the kernel
doesn't have to care about this at all, and the kernel doesn't get to
even know that the PHY has a reset GPIO.

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