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.

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?

This design is not a classic consumer/producer. The DPLL driver doesn't
care where its inputs and outputs are connected, it doesn't need to
know.

I really doubt that. Given how configurable these devices are, there
must be a need to know what is around them, in order for all this
configuration to make sense.

	Andrew