Re: [Question] Best practice for ACPI representation of DPLL/Ethernet dependencies (SyncE)

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, Jan 20, 2026 at 06:39:31AM +0100, Ivan Vecera wrote:
> On 1/20/26 12:34 AM, Linus Walleij wrote:
> > On Mon, Jan 19, 2026 at 9:28 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:

(...)

> > > > > > Based on [1] example this clock relationship can be represented by _DSD.
> > > > > > Is it correct?
> > > > > 
> > > > > I didn't really get, is this a clock provider-consumer relations or pin
> > > > > connections? If this is a pin connections, why there is no pin mux driver
> > > > > for it?
> > > > 
> > > > In fact this should be dpll provider-consumer schema. Consumer (e.g.
> > > > net device, phy...) uses (consumes) DPLL service (frequency
> > > > synchronization, ...) and DPLL device provides such service.
> > > > 
> > > > Note that the pin in this context is DPLL pin not pin related to pinctrl
> > > > or so...
> > > 
> > > Right, so these are pins with special functions, which are not GPIO like.
> > > But pin mux is not only about GPIO, that's the nice part of it.
> > > 
> > > +Cc: Linus for his view on this issue.
> > 
> > In theory a pin controller can be instantiated in any random driver that
> > controls a few pins of its own to the outside world, just like we have a few
> > few-pin GPIO chips here and there such as for USB serial adapters.
> > 
> > In practice nobody does this, they have some driver-local way of handling
> > pins and mux them around for their special use case.
> > 
> > Graphic cards or audio would be an example. Much custom muxing
> > happening there I think.
> > 
> > I have no strong opinion on the subject, it's up to the driver author I think.
> > 
> > ACPI aspects I can't talk about because I don't understand them...
> > 
> > Hope this helps!
> 
> I think we might be getting sidetracked by the specific subsystems
> (pinctrl/GPIO/Clock).

Yes, and this happens due to the DT point of view as far as I understood their
preferences. If it's modeled as clock inputs and outputs we should consider the
same in ACPI, otherwise it will be custom hack on top of the (agreed) way of
solving the issue.

Nature of the connection (and hence the responsible subsystem in the software)
is the key here. Until we fully understand what's this, we can't properly model
it.

> The core problem I am trying to solve is modeling the linkage between
> the two devices. The NIC acts as a consumer that needs to "know" about
> the DPLL (the supplier) in the ACPI table.
> 
> We need a way to tell the NIC driver: "Here is a handle to the DPLL

"handle to device" in ACPI assumes the Device() object somewhere in
the namespace. This is what you have in the ASL example.

> device you are connected to, and here are the specific resource IDs
> (pins) you are wired to. So a user (userspace) can monitor/configure
> such DPLL inputs and outputs using DPLL Netlink API."
> 
> Regardless of whether the underlying signal is a clock or a logic level,
> the immediate requirement is simply resolving this cross-device dependency
> so the NIC can identify these resources and report their IDs into userspace.

Yes, but "simply" not always means "the best" in the long-term. As I said,
your proposed idea doesn't contradict ACPI concepts, the problem is that
it may lead to custom solution for the specific hardware and next one will
create their own N + 1 way of solving the same issue.

One note nevertheless, instead of "reg" property the ACPI has concept of _ADR
method. We even have acpi_get_local_address() helper for that.

-- 
With Best Regards,
Andy Shevchenko