Re: [PATCH net-next 2/2] dt-bindings: net: microchip,ksz: document microchip,rmii-clk-internal

[Conor Dooley]

On Tue, Oct 17, 2023 at 02:59:46PM +0200, Andrew Lunn wrote:
> > The switch always provides it's own external reference, wut? Why would
> > anyone actually bother doing this instead of just using the internal
> > reference?
> 
> I think you are getting provider and consumer mixed up.

The comment suggested that it was acting as both, via an external
loopback:
> > > In both cases (external and internal), the KSZ88X3 is actually providing the
> > > RMII reference clock. Difference is only will the clock be routed as external
> > > copper track (pin REFCLKO -> pin REFCLKI), or will it be routed internally.

If there's another interpretation for that, it's lost on me.
A later mail goes on to say:
> > > The KSZ88x3 does not have to provide the reference clock, it can be provided 
> > > externally, by some other device, for example the uC.

So I think I was just picking up on a mistaken explanation.

> Lets simplify to just a MAC and a PHY. There needs to be a shared
> clock between these two. Sometimes the PHY is the provider and the MAC
> is the consumer, sometimes the MAC is the provider, and the PHY is the
> consumer. Sometimes the hardware gives you no choices, sometimes it
> does. Sometimes a third party provides the clock, and both are
> consumers.
> 
> With the KSZ, we are talking about a switch, so there are multiple
> MACs and PHYs. They can all share the same clock, so long as you have
> one provider, and the rest are consumers. Or each pair can figure out
> its provider/consumer etc.

Thanks for the explanation. I'm still not really sure why someone would
want to employ external loopback, instead of the internal one though.

> How this is described in DT has evolved over time. We don't have clean
> clock provider/consumer relationships. The PHYs and MACs are generally
> not CCF consumers/providers. They just have a property to enable the
> to output a clock, or maybe a property to disable the clock output in
> order to save power. There are a few exceptions, but that tends to be
> where the clock provider is already CCF clock, e.g. a SoC clock.

Yeah, I did acknowledge that at the end of my mail (although I managed
to typo "that ship has sailed").
Doing ccf stuff doesn't seem viable given there's currently no required
clocks in the binding despite there likely being some in use.

I'm fine acking the binding with the change I suggested, I was just
looking to understand why a clocks property could not be used and I
think I have my answer to that now :)

Cheers,
Conor.

Attachment: signature.asc
Description: PGP signature