> ----------------------------- Eaton Industries Manufacturing GmbH ~ Registered place of business: Route de la Longeraie 7, 1110, Morges, Switzerland ----------------------------- -----Original Message----- > From: Andrew Lunn <andrew@xxxxxxx> > Sent: Wednesday, November 04, 2020 2:11 PM > To: Badel, Laurent <LaurentBadel@xxxxxxxxx> > Cc: Marco Felsch <m.felsch@xxxxxxxxxxxxxx>; davem@xxxxxxxxxxxxx; > fugang.duan@xxxxxxx; kuba@xxxxxxxxxx; Heiner Kallweit > <hkallweit1@xxxxxxxxx>; linux@xxxxxxxxxxxxxxx; p.zabel@xxxxxxxxxxxxxx; > lgirdwood@xxxxxxxxx; broonie@xxxxxxxxxx; robh+dt@xxxxxxxxxx; > richard.leitner@xxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; > devicetree@xxxxxxxxxxxxxxx; f.fainelli@xxxxxxxxx; Quette, Arnaud > <ArnaudQuette@xxxxxxxxx> > 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.
