On 1/22/26 8:57 PM, Andrew Lunn wrote:

quoted

No, absolutely not. The drivers for these devices reside entirely in the
kernel. They handle all the low-level register access, mux config, and
hardware abstraction.

The userspace (e.g. synce4l daemon) is purely a Policy Engine. It uses
a  generic, hardware-agnostic Netlink API to send high-level commands
like "Lock to Pin 0" or "Set Priority 1". The in-kernel driver
translates these generic commands into the specific register writes
required for that chip (ZL3073x, etc.).

Great. But i've not seen the needed board configuration to allow
this. Where do you describe if the ingress inverter is needed? The
egress inverter? The clock divider on ingress, the clock divider on
egress. The frequency of the clock feeding the package, etc.

On this specific platform, the DPLL device is not a "blank slate" at
boot. It has internal flash that is pre-programmed by the OEM during
manufacturing. So the ACPI does not need to store exact state of each
piece of the HW you mentioned (like dividers, inverters, etc.)

The flash contains the board-specific initialization:
* Base frequencies (XO inputs)
* Default divider values
* Signal conditioning (inverters, impedance) required for the specific
   board layout.

When the OS loads, the DPLL state is already in a valid, board-compliant
state. The zl3073x driver reads this current state from the hardware.

The one thing the DPLL's internal flash cannot know is "Which OS device
is connected to my pin X?". The DPLL knows "pin X is configured for
25MHz," but it doesn't know that "pin X is physically wired to eth0
(PCIe Bus 04:00.0)." and cannot provide such information.

At this point only ACPI know such information as it knows the board
topology.

This is precisely why we need the ACPI schema I proposed. We do not need
ACPI to replicate the entire configuration that already exists in the
DPLL's flash. We only need ACPI to bridge that specific Topology Gap:

* ACPI: "DPLL pin 0 connected to this NIC as 'rclk'."
         "DPLL pin 1 connected to this NIC as 'synce_ref'."
* NIC Driver: "DPLL pin 0 is connected to my recovered clock"
               "DPLL pin 1 is connected to my SyncE ref"
* Userspace (synce4l): Uses this information map to make runtime
   decisions (e.g., "Network condition changed, switch DPLL to lock on
   NIC2's recovered-clock").

quoted

But I don't use CCF bindings in this design, this design is about
representing an opaque wire between two devices.

Is it really opaque? Don't you need to know its frequency, so you can
set the ingress divider? You can either ask it what it is, or you can
have a board property. Don't you want to know its phase? So you can
enable/disable the ingress inverter?

Yes, the system needs to know this. But the NIC driver does not. The NIC
driver just says "I am wired to pins X,Y." The DPLL driver monitors DPLL
device and its pins states by querying the hardware, reports state 
(device lock status, pins' phase offset, signal quality, fractional
frequency offset, etc.) to userspace (e.g. synce4l) and accepts new
commands from it to change the device & pins configuration (pins'
priority, phase compensation etc.).

Thanks,
Ivan