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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <65e558ee-0b74-4197-91bf-e109662e5fd6@redhat.com>
Date: Fri, 23 Jan 2026 10:18:14 +0100
From: Ivan Vecera <ivecera@...hat.com>
To: Andrew Lunn <andrew@...n.ch>,
 Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
 Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
 Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>,
 "Nitka, Grzegorz" <grzegorz.nitka@...el.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Linus Walleij
 <linusw@...nel.org>, Mika Westerberg <mika.westerberg@...ux.intel.com>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>,
 Jiri Pirko <jiri@...nulli.us>, 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>, Sakari Ailus <sakari.ailus@...ux.intel.com>
Subject: Re: [Proposal,Question - refresh] ACPI representation of
 DPLL/Ethernet dependencies (SyncE)

On 1/22/26 8:57 PM, Andrew Lunn wrote:
>> 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.

On this specific platform, the DPLL device is not a "blank slate" at
boot. It has internal flash that is pre-programmed by the OEM during
manufacturing. So the ACPI does not need to store exact state of each
piece of the HW you mentioned (like dividers, inverters, etc.)

The flash contains the board-specific initialization:
* Base frequencies (XO inputs)
* Default divider values
* Signal conditioning (inverters, impedance) required for the specific
   board layout.

When the OS loads, the DPLL state is already in a valid, board-compliant
state. The zl3073x driver reads this current state from the hardware.

The one thing the DPLL's internal flash cannot know is "Which OS device
is connected to my pin X?". The DPLL knows "pin X is configured for
25MHz," but it doesn't know that "pin X is physically wired to eth0
(PCIe Bus 04:00.0)." and cannot provide such information.

At this point only ACPI know such information as it knows the board
topology.

This is precisely why we need the ACPI schema I proposed. We do not need
ACPI to replicate the entire configuration that already exists in the
DPLL's flash. We only need ACPI to bridge that specific Topology Gap:

* ACPI: "DPLL pin 0 connected to this NIC as 'rclk'."
         "DPLL pin 1 connected to this NIC as 'synce_ref'."
* NIC Driver: "DPLL pin 0 is connected to my recovered clock"
               "DPLL pin 1 is connected to my SyncE ref"
* Userspace (synce4l): Uses this information map to make runtime
   decisions (e.g., "Network condition changed, switch DPLL to lock on
   NIC2's recovered-clock").

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

Yes, the system needs to know this. But the NIC driver does not. The NIC
driver just says "I am wired to pins X,Y." The DPLL driver monitors DPLL
device and its pins states by querying the hardware, reports state 
(device lock status, pins' phase offset, signal quality, fractional
frequency offset, etc.) to userspace (e.g. synce4l) and accepts new
commands from it to change the device & pins configuration (pins'
priority, phase compensation etc.).

Thanks,
Ivan