Message-ID: <LV4PR11MB949103AF447595598F0D06789B94A@LV4PR11MB9491.namprd11.prod.outlook.com>
Date: Fri, 23 Jan 2026 09:42:39 +0000
From: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>, "Vecera, Ivan"
	<ivecera@...hat.com>
CC: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, 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>, 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>, "Schmidt, Michal"
	<mschmidt@...hat.com>, "Oros, Petr" <poros@...hat.com>,
	"linux-acpi@...r.kernel.org" <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)

>From: Rafael J. Wysocki <rafael@...nel.org>
>Sent: Thursday, January 22, 2026 7:04 PM
>
>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.
>

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.

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

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

Powered by blists - more mailing lists