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 01:12:41PM +0000, Russell King (Oracle) wrote:
> 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.

I'll also add... as kernel developers, we're not very good at insisting
on generic names for things like clocks (see the mess that is stmmac,
where the dwmac's various clock signals are named differently in the
many platform glues.)

So, I guess that FEC MDIO may need to have a list of clock names to
look for when inspecting the PHY nodes if the clock is even specified
there. If it isn't, then some other way of discovering that the PHY
needs a clock (looking at the pinctrl configuration to see whether
the pin is configured to output a clock to the PHY?) would need to be
added.

However, care needs to be taken in the case where the PHY has already
been setup by boot firmware, that the clock signal is not disturbed,
as interrupting it could provoke PHY problems - especially if the
platform doesn't have the PHY reset specified in DT.

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