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 03:18:24PM +0100, Rafael J. Wysocki wrote:
> On Tue, Jan 20, 2026 at 2:31 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, Jan 20, 2026 at 01:30:57PM +0100, Rafael J. Wysocki wrote:
> > > On Tue, Jan 20, 2026 at 8:17 AM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > 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.
> > >
> > > And no one will ship the requisite data in the firmware.
> > >
> > > > One note nevertheless, instead of "reg" property the ACPI has concept of _ADR
> > > > method. We even have acpi_get_local_address() helper for that.
> > >
> > > It's not exactly that.  _ADR is for device lookup on self-enumerable
> > > buses, and I'm not sure if that's the use case here.
> >
> > Ah, thanks for chiming in. Indeed, 6.1.1. "_ADR (Address)" specifies that.
> > Although we have some (mis)uses of _ADR in the cases when it corresponds
> > to 'reg', exempli gratia the I²C mux ASL requires _ADR while I²C bus (behind
> > the mux) is arguably self-enumerable.
> 
> There are exceptions, but let's not go into that territory.
> 
> As a rule, a "reg" would correspond to a resource in _CRS, except for
> the cases like _CPC when registers are pointed to individually through
> GAS structures.
> 
> Generally speaking, using device properties for describing resources
> in ACPI is not something people are used to.  _CRS is used for that in
> general.

Right, we have 19.6.157. ClockInput (Clock Input Resource Descriptor Macro).
(Note, it's unordered, should be not at the end of the list, can the spec be fixed?)
In case these signals are clocks that resource probably needs to be used.
I dunno, I'm still didn't get what is the functional point of view on those
wires and why they should be described in the FW. Choosing the right concept
will allow to produce the acceptable solution, but I admit I have not enough
knowledge in networking DPLL/PHY area to judge the choice.

-- 
With Best Regards,
Andy Shevchenko