From: Rafael J. Wysocki <rafael@kernel.org>
Sent: Thursday, January 22, 2026 7:04 PM

Hi,

On Wed, Jan 21, 2026 at 3:43 PM Ivan Vecera [off-list ref] wrote:

quoted

Hi Andy, Rafael and others,

(based on the previous thread [1] - now involving more people from
  networking and DPLL)

Thank you for the insights on _CRS and ClockInput.

I think we have circled the issue enough to identify the core
disconnect:
* 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).
* Instead, the NIC driver simply needs a Topology Map. It needs to know:
   "My Port 0 (Consumer) is physically wired to DPLL Pin 3 (Provider)."

The NIC driver needs this Pin Index (3) specifically to report it via
the RtNetlink. This allows the userspace daemon (e.g., synce4l or
linux-ptp) to see the relationship and decide to configure the DPLL
via the DPLL Netlink API to lock onto that specific input.

A generic ClockInput resource in _CRS is anonymous and unordered. The
OS abstracts it into a handle, but it fails to convey the specific pin
index required for this userspace reporting.

Since ACPI lacks a native "Graph/Topology" object for inter-device
dependencies of this nature, and _CRS obscures the index information
required by userspace, I propose we treat _DSD properties as the
de-facto standard [2] for modeling SyncE topology in ACPI.

If you want to call something a "standard", especially if it involves
ACPI, it is generally not sufficient to talk to Linux kernel people only
about it.

ACPI is about agreements between multiple parties, including multiple OS
providers (Linux being just one of them) and multiple platform vendors
(OEMs).

To a minimum, you'd need commitment from at least one platform vendor to
ship the requisite _DSD data in their platform firmware.

quoted

To avoid the confusion Andy mentioned regarding "Clock Bindings" in
ACPI, I suggest we explicitly define a schema using 'dpll-' prefixed
properties. This effectively decouples it from the Clock subsystem
expectations and treats it purely as a wiring map.

Proposed ACPI Representation with proposed documentation [3]

If the ACPI maintainers and Netdev maintainers agree that this

So long as you don't try to update the general ACPI support code in
drivers/acpi/ or the related header files, the matter is beyond the role
of the "ACPI maintainers".

That code though is based on the ACPI specification and the related
support documentation, modulo what is actually shipping in platform
firmware on systems in the field, so if you want or plan to modify it,
that needs to be based on something beyond kernel documentation.

quoted

_DSD-based topology map is the acceptable "Pragmatic Standard" for
this feature, I will document this schema in the kernel documentation
and proceed with the implementation.

Kernel documentation is generally insufficient for defining new OS-
firmware interfaces based on ACPI because there are parties involved in
ACPI development beyond the kernel that may be interested in the given
interface and they may be able to provide useful feedback.

I, personally, cannot really say how useful the interface you are
proposing would be and what it would be useful for.  Even if I liked it,
there still would be a problem of getting at least one platform vendor on
board.

Hi Rafael,

Thank you for your review!

Yes, we are here, do you need someone/someway specific to step up and
provide such proof?
The patch series proposed by Ivan, which is part of this discussion also
contains intel patches.

quoted

This solves the immediate need for an upcoming Intel SyncE enabled
platform and provides a consistent blueprint for other vendors
implementing SyncE on ACPI.

And what if, say, MSFT come up with their own version of an interface
addressing the same problem space in the meantime and convince platform
vendors to ship support for their variant instead of yours?

We can only believe that some expert/maintainer would catch it during the
review process?
Or else we would end up in situation where 2 interfaces are similar.

Thank you!
Arkadiusz

quoted

[1]
https://lore.kernel.org/linux-acpi/3bf214b9-8691-44f7-aa13-8169276a6c2
b@redhat.com/ [2]
https://docs.kernel.org/firmware-guide/acpi/dsd/data-node-references.h
tml [3]
https://gist.github.com/ivecera/964c25f47f688f44ec70984742cf7fbd