Re: [PATCH] net: phy: return EPROBE_DEFER if PHY is not accessible

From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "Buzarra, Arturo" <Arturo.Buzarra@digi.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: [PATCH] net: phy: return EPROBE_DEFER if PHY is not accessible
Date: Thu, 23 Mar 2023 14:35:31 +0000	[thread overview]
Message-ID: <ZBxjs4arSTq4cDgf@shell.armlinux.org.uk> (raw)
In-Reply-To: <156b7aee-b61a-40b9-ac51-59bcaef0c129@lunn.ch>

On Thu, Mar 23, 2023 at 03:19:21PM +0100, Andrew Lunn wrote:
> > Gigabit PHY has its own Crystal, however the 10/100 PHY uses a clock
> > from the CPU and it is the root cause of the issue because when
> > Linux asks the PHY capabilities the clock is not ready yet.
> 
> O.K, now we are getting closer.
> 
> Which clock is it exactly? Both for the MAC and the PHY?

Just a passing observation but... considering stmmac needs the clock
from the PHY in order to do even basic things, it doesn't surprise me
that there's a PHY out there that doesn't work without a clock provided
from the "other side" to also do the most basic things such as read the
IDs!

Hardware folk always find wonderful ways to break stuff and then need
software to fix it... :/

That all said, if the clock that's being discussed is the MDC signal
(MDIO interface clock) then /really/ (and obviously) that's a matter
for the MDIO driver to ensure that clock is available to run before
registering itself.

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