netdev - Re: [Proposal,Question - refresh] ACPI representation of DPLL/Ethernet dependencies (SyncE)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0gL3MzhyS2SOELsgztdakFU984UB+TKaMA13kd+7ssj_Q@mail.gmail.com>
Date: Thu, 22 Jan 2026 19:04:26 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Ivan Vecera <ivecera@...hat.com>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, 
	"Rafael J. Wysocki" <rafael@...nel.org>, Linus Walleij <linusw@...nel.org>, Andrew Lunn <andrew@...n.ch>, 
	Mika Westerberg <mika.westerberg@...ux.intel.com>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk@...nel.org>, Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>, 
	Jiri Pirko <jiri@...nulli.us>, Vadim Fedorenko <vadim.fedorenko@...ux.dev>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	"David S. Miller" <davem@...emloft.net>, Mark Brown <broonie@...nel.org>, 
	Jan Aleszczyk <jaleszcz@...hat.com>, Michal Schmidt <mschmidt@...hat.com>, Petr Oros <poros@...hat.com>, 
	linux-acpi@...r.kernel.org, "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [Proposal,Question - refresh] ACPI representation of
 DPLL/Ethernet dependencies (SyncE)

Hi,

On Wed, Jan 21, 2026 at 3:43 PM Ivan Vecera <ivecera@...hat.com> wrote:
>
> 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.

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

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

> 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?

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