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

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

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

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.

We are effectively modeling a graph linkage (similar to ports / remote-
endpoint in media graphs) rather than a functional resource (like
clocks=<&clk0> or regulators=<&some_reg>).

We are utilizing _DSD properties to model this topology edge, which is
consistent with how other subsystems (like Media) utilize firmware node
graphs in ACPI to describe complex non-resource connections.

This provides the NIC driver with the "remote endpoint ID" (the pin
index) it needs to populate the Netlink ABI, without forcing the driver
to import the complexity of a full Clock Tree that it has no intention
of managing.

Does this distinction—modelling the "topology graph" rather than
a "clock resource" make sense as a rationale for using _DSD here?

Regards,
Ivan

So i do wounder if we are being short sighted by using the clock
bindings but not Linux clocks.

	Andrew