>
----------------------------- Eaton Industries Manufacturing GmbH ~ Registered place of business: Route de la Longeraie 7, 1110, Morges, Switzerland ----------------------------- -----Original Message----- > From: Andrew Lunn <and...@lunn.ch> > Sent: Wednesday, November 04, 2020 2:11 PM > To: Badel, Laurent <laurentba...@eaton.com> > Cc: Marco Felsch <m.fel...@pengutronix.de>; da...@davemloft.net; > fugang.d...@nxp.com; k...@kernel.org; Heiner Kallweit > <hkallwe...@gmail.com>; li...@armlinux.org.uk; p.za...@pengutronix.de; > lgirdw...@gmail.com; broo...@kernel.org; robh...@kernel.org; > richard.leit...@skidata.com; netdev@vger.kernel.org; > devicet...@vger.kernel.org; f.faine...@gmail.com; Quette, Arnaud > <arnaudque...@eaton.com> > Subject: Re: [EXTERNAL] Re: [PATCH net 0/4] Restore and fix PHY reset for > SMSC LAN8720 > > > > > (ii) This defeats the purpose of a previous commit [2] that > > > > disabled the ref clock for power saving reasons. If a ref clock > > > > for the PHY is specified in DT, the SMSC driver will keep it > > > > always on (confirmed with scope). > > > > > > NACK, the clock provider can be any clock. This has nothing to do > > > with the FEC clocks. The FEC _can_ be used as clock provider. > > > > I'm sure you understand this much better than I do. What I can say is > > that I directly measured the ref clk and found that when I add the > > clock to the DT the clock stays on forever. Basically it seems like > > the FEC calls to > > clk_disable_unprepare() don't work in this case, though I'm not sure > > about the reason behind this. > > The reason is easy to explain. The clock API is reference counted. It counts > how many times a clock is turned on and off. A clock has to be turned off as > many times as it was turned on before the hardware actually turns off. So > you have the FEC turning the clock on during probe, followed by the phy > turning the clock on. Some time later the FEC turns the clock off for run time > power saving, but there is still one reference to the clock held by the PHY, > so > the hardware is left ticking. > > Andrew That makes a lot of sense, thanks very much for the explanation.
