Re: [RFC PATCH] net: phy: integrate reset-after-clock quirk into phy_init_hw

["Russell King (Oracle)" <linux@armlinux.org.uk>]

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!