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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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.

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.

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.

      Andrew




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux