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: <24e081fd-1b59-4951-96fc-f87ef7f3172f@lunn.ch>
Date: Thu, 22 Jan 2026 20:57:55 +0100
From: Andrew Lunn <andrew@...n.ch>
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>,
	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>,
	Sakari Ailus <sakari.ailus@...ux.intel.com>
Subject: Re: [Proposal,Question - refresh] ACPI representation of
 DPLL/Ethernet dependencies (SyncE)

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

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

> This design is not a classic consumer/producer. The DPLL driver doesn't
> care where its inputs and outputs are connected, it doesn't need to
> know.

I really doubt that. Given how configurable these devices are, there
must be a need to know what is around them, in order for all this
configuration to make sense.

	Andrew