Re: [Question] Best practice for ACPI representation of DPLL/Ethernet dependencies (SyncE)

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Thu, Jan 15, 2026 at 03:09:53PM +0100, Ivan Vecera wrote:
> On 1/15/26 2:18 PM, Andy Shevchenko wrote:
> > On Thu, Jan 15, 2026 at 08:34:05AM +0100, Ivan Vecera wrote:
> > > On 1/14/26 9:45 PM, Andy Shevchenko wrote:
> > > > On Wed, Jan 14, 2026 at 08:19:05PM +0100, Ivan Vecera wrote:

...

> > > This is not a GPIO or Pin Control scenario. The "pins" I am referring to are
> > > clock input/output pads dedicated to frequency synchronization (Synchronous
> > > Ethernet). They carry continuous clock signals (e.g., 10MHz, 25MHz, or
> > > recovered network clock), not logic levels controllable via a GPIO
> > > subsystem.
> > > 
> > > The Hardware Setup:
> > > 
> > > Control Plane: A user configures the DPLL device (e.g., via I2C/SPI
> > > managed by standard ACPI resources/drivers). This part is standard.
> > > 
> > > Data/Clock/Signal Plane (The issue at hand): There are physical clock
> > > traces on the board connecting the Ethernet PHY directly to the DPLL.
> > > 
> > > PHY Output(s) -> DPLL Input Pin(s) (Recovered Clock)
> > > 
> > > DPLL Output Pin(s) -> PHY Input(s) (Clean Reference Clock)
> > > 
> > > Since these are purely clock signals between two peripheral devices (not
> > > connected to the CPU's GPIO controller), standard ACPI _CRS resources
> > > like GpioIo or PinFunction do not seem applicable here. To my knowledge,
> > > ACPI does not have a native "Clock Resource" descriptor for inter-device
> > > clock dependencies.
> > > 
> > > My intention with _DSD was to model this clock dependency graph, similar
> > > to how clocks and clock-names are handled in Device Tree (or how camera
> > > sensors often use _DSD to reference related components).
> > > 
> > > Does your objection regarding the "ugly hack" still stand, or is
> > > modeling these clock dependencies via _DSD properties (referencing
> > > sub-nodes) an acceptable approach in the absence of a dedicated ACPI
> > > Clock Resource?
> > 
> > Now my "ugly hack" is irrelevant, but still sounds not good.
> > I hope you have researched what has been done before [6].
> > 
> > (Please, return links to the our emails, as it helps to understand the
> >   discussion.)
> Returned.
> 
> > I.o.w. there was an attempt a few years ago to fill the gaps, one of which
> > you are mentioning here. Note that the ACPI specification gains something
> > related (but I don't remember from top of my head what exactly, please
> > refer to it directly [7]).
> > 
> > > I can provide a simple ASCII diagram of the board layout if that helps
> > > clarify the signal flow.
> > 
> > Yes, please.
> 
> In SyncE (Synchronous Ethernet) scenarios, an Ethernet controller or PHY
> is typically connected to a DPLL device that provides frequency
> synchronization, holdover, and jitter filtering.
> 
> A SyncE-capable Ethernet PHY (or controller) usually has:
> Output(s): Recovered clock signal connected to a DPLL input pin.
> Input(s): Connected to a DPLL output pin.
> 
> Example:
>      ETH controller or PHY
>     +--------------------+
> +---| rclk0              |
> |+--| rclk1    synce_ref |<-+
> ||  +--------------------+  |
> ||                          |
> ||           DPLL           |
> ||  +--------------------+  |
> |+->| ref1n              |  |
> +-->| ref3n        out1p |--+
>     +--------------------+
> 
> In DT this could look like:
>   ...
>   &dpll0 {
>     ...
>     input-pins {
>       pin@3 {
>         ...
>       };
>       pin@5 {
>         ...
>       };
>     };
>     output-pins {
>       pin@2 {
>         ...
>       };
>     };
>   };
>   &phy2 {
>     ...
>     dpll-pin-names = "rclk0", "rclk1", "synce_ref";
>     dpll-pins = <&dpll0 3 DPLL_PIN_INPUT>,
>                 <&dpll0 5 DPLL_PIN_INPUT>,
>                 <&dpll0 2 DPLL_PIN_OUTPUT>;
>     ...
>   };
> 
> For ACPI I have followed [8][9][10] to create ASL code for the following
> system (Intel GNR-D):
> 1. There is an I2C Mux (pca9546) connected to system SMBus
> 2. On the 3rd channel there is a I2C DPLL device (ZL30732) at address
>    0x70
> 3. There is 4-port NIC (E825C) on PCIe bus
> 
> [3] is sample SSDT that adds the I2C mux and the DPLL device
> [4] is sample SSDT that adds to the NICs 'dpll-pins' and
>     'dpll-pin-names' properties to 2 NICs.
> 
> The goal of the patch-set [1] is that NIC driver (ice) will be able to
> check what DPLL pins are used for its recovered clock outputs and what
> DPLL pin provides the cleaned/synchronized signal for its input.
> If so the NIC driver can report these DPLL pin IDs to the userspace
> and a user can configure/monitor these pins accordingly.

So, this is not so bad as I thought initially. Still the open question if you
studied [6][7] and learnt anything new about clocks and ACPI integration?

P.S. Currently I can consider this as Plan B if we found no other better designs.
However it would be nice to see some review from network people, such as
Andrew Lunn and Vladimir Oltean. They know much more about networking HW
topologies and they have an expertise in ACPI.

> Links:
> [1]
> https://patchwork.kernel.org/project/netdevbpf/list/?series=1040080&state=*
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dpll
> [3] https://github.com/ivecera/zl3073x-acpi/blob/main/sample1.asl
> [4] https://github.com/ivecera/zl3073x-acpi/blob/main/dpllnic.asl
> [5] https://lore.kernel.org/r/20221130164027.682898-1-niyas.sait@linaro.org
> [6] https://linaro.atlassian.net/wiki/spaces/CLIENTPC/overview
> [7] https://uefi.org/specs/ACPI/6.6/
> [8] https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf
> [9] https://docs.kernel.org/firmware-guide/acpi/i2c-muxes.html
> [10]
> https://docs.kernel.org/firmware-guide/acpi/dsd/data-node-references.html

-- 
With Best Regards,
Andy Shevchenko