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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXtcydbhclLAxDWZ@shell.armlinux.org.uk>
Date: Thu, 29 Jan 2026 13:12:41 +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 12:17:26PM +0100, Marco Felsch wrote:
> IMHO this flag should be removed completely because it makes the
> phy-driver mac-driver dependent. Since the FEC is the only driver
> checking this flag.

>From what I can see, the _only_ caller of phy_reset_after_clk_enable()
is the FEC driver. However, we seem to have DP83848C, DP83848C,
DP83620, TLK10X, LAN8710, LAN8720, LAN8740, and LAN8742 all needing
this flag. As also pointed out, other PHYs also require their XTAL
based clock to be running before reset is released.

This reconfirms my statements that this is *not* a PHY issue, but an
issue that afflicts FEC based systems because, on these systems, there
seems to be a tendency for hardware designers to omit the PHY's crystal
and source the PHY clock from the SoC.

My guess is that this doesn't happen anywhere else (since no workaround
is necessary.)

So, this backs up my stance that "this PHY requires a special reset
sequence" is incorrect.

Hence, I think PHY_RST_AFTER_CLK_EN + phy_reset_after_clk_enable()
should be entirely removed.

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.

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