On Thu, Jan 22, 2026 at 12:50:50PM +0100, Ivan Vecera wrote:

Hi Andrew,

(Adding Sakari Ailus to CC, who might have insights on modeling
 component topologies in ACPI).

On 1/22/26 1:09 AM, Andrew Lunn wrote:

quoted

quoted

* While the physical signals on these wires are indeed clocks (10MHz,
   etc.), from the OS driver perspective, this is not a "Clock Resource"
   issue. The NIC driver does not need to gate, rate-set, or power-manage
   these clocks (which is what _CRS/ClockInput implies).

Is this a peculiarity of the zl3073x? No gating, no rate-set, no power
management?

I had a quick look at the Renesas 8V89307

https://www.renesas.com/en/document/dst/8v89307-final-data-sheet?r=177681

Two of the three inputs have an optional inverter. CCF has
clk_set_phase(), which when passed 180 would be a good model for this.
The inputs then have dividers which can be configured. I would
probably model them using CCF clk-divider.c for that. There is then a
mux, which clk-mux.c could model. After the DPLL there are more muxes
to optionally route the output through an APLL. The output block then
has yet more muxes and dividers.

All that could be described using a number of CCF parts chained
together in a clock tree.

And what about the TI LMK05028

https://www.ti.com/product/LMK05028

It also has inverters and muxes, but no dividers.

Analog Devices ad9546 also has lots of internal components which could
be described using CCF

https://www.analog.com/media/en/technical-documentation/data-sheets/ad9546.pdf

I agree with you that the hardware itself (ZL3073x, Renesas 8V89307,
etc.) is complex and has internal structures (dividers, muxes) that
technically fit the CCF model.

However, I believe the distinction lies in how the inter-device topology
is used versus how the device is managed internally.

The kernel now uses the dedicated DPLL Subsystem (drivers/dpll) for
SyncE and similar applications. This subsystem was created because CCF
captures "rate and parent" well, but does not capture SyncE-specific
aspects like lock status, holdover, priority lists, and phase-slope
limiting.

In our architecture, the complex configuration you mentioned (dividers,
muxes) is managed via the DPLL Netlink ABI. The control logic largely
resides in userspace daemons (e.g., synce4l), which send Netlink
commands to the DPLL driver to configure those internal muxes/dividers
based on network conditions.

So you are effectively doing user space drivers? You have a library of
DPLL drivers, which gets linked to synce4l? The library can then poke
registers in the device to configure all the muxes, inverters,
dividers?

But doesn't that also require that synce4l/the library knows about
every single board? It needs to know if the board requires the input
clock to be inverted? The output clock needs to be inverted? It needs
to know about the PHY, is it producing a 50Mhz clock, or 125MHz which
some devices provide, so will need the divider to reduce it to 50MHz?
Doesn't the library also need to know the clock driving the DPLL
package? Some of these products allow you to apply dividers to that as
well, and that clock is a board property.

To me, it seems like there are a collection of board properties, and
to make this scale, those need to be in DT/ACPI, not a user space
library. 

The NIC driver's role here is passive; it effectively operates in a
"bypass" mode regarding these signals. The NIC does not need to call
clk_set_rate() or clk_prepare_enable() on these pins to function. It
simply needs to report the physical wiring linkage: "My input / output
is wired to DPLL pin with index X."

I can understand this bit, although actually using
clk_prepare_enable() would allow for runtime power management.

But i'm thinking more about these board properties. If i model the
internals of the DPLL using CCF, CCF probably has all the needed
control interfaces. The board properties then just set these controls.
It then seems odd that i have a Linux standard description of the
internals of the DPLL using CCF, i use the CCF binding to describe the
external interconnects, but don't actually use CCF to implement these
external interconnect?

If we use standard Clock bindings (CCF), we imply a functional
dependency where the NIC acts as a controller/consumer that actively
manages the clock's state. In reality, the NIC is just a conduit mapping
a local port to a remote pin index.

If you look at MAC drivers, all they really do is
clk_prepare_enable(). Few do more than that. So i don't really see
this as being a burden.

	Andrew