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

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

[Ivan Vecera]

Hi all,

I would like to ask for your opinion regarding an ACPI implementation
detail for a patch-set I currently have on the netdev mailing list [1].

The patch-set adds support for modeling the relationship between a DPLL
device (provider) and an Ethernet controller/PHY (consumer) to support
SyncE (Synchronous Ethernet). The topology requires the Ethernet
controller/PHY to reference specific pins (sub-nodes) of the DPLL
device.

Although the target driver (ice) in the patch-set is primarily used in
ACPI environments, I aimed for a firmware-agnostic approach using the
fwnode API.

Provider (DPLL):
The DPLL device uses _DSD properties mirroring the definition in the DT
bindings [2]. The pins are represented as sub-nodes. ACPI example [3].

Consumer (Ethernet):
I defined a new DT schema for the consumer using properties dpll-pins
nd dpll-pin-names. And in ACPI, I intend to use hierarchical data
extension (_DSD) to reference the DPLL pin sub-nodes from the Ethernet 
controller package [4], effectively mirroring the DT phandle referencing
mechanism.

Question:
Is reusing the DT binding definitions within ACPI _DSD (to allow unified
fwnode property parsing) the recommended approach for this type of
device relationship?

Or should I define strictly ACPI-specific bindings/objects, considering
that the DT bindings for this feature are also new and currently under
review?

I want to ensure I am not violating any ACPI abstraction layers by
relying too heavily on the DT-style representation in _DSD.

Thanks for your guidance.

Regards,
Ivan

[1] 
https://patchwork.kernel.org/project/netdevbpf/list/?series=1040080&state=*
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dpll
[3] https://github.com/ivecera/zl3073x-acpi/blob/main/sample1.asl
[4] https://github.com/ivecera/zl3073x-acpi/blob/main/dpllnic.asl

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

[Andy Shevchenko]

On Wed, Jan 14, 2026 at 08:19:05PM +0100, Ivan Vecera wrote:

> I would like to ask for your opinion regarding an ACPI implementation
> detail for a patch-set I currently have on the netdev mailing list [1].
> 
> The patch-set adds support for modeling the relationship between a DPLL
> device (provider) and an Ethernet controller/PHY (consumer) to support
> SyncE (Synchronous Ethernet). The topology requires the Ethernet
> controller/PHY to reference specific pins (sub-nodes) of the DPLL
> device.
> 
> Although the target driver (ice) in the patch-set is primarily used in
> ACPI environments, I aimed for a firmware-agnostic approach using the
> fwnode API.
> 
> Provider (DPLL):
> The DPLL device uses _DSD properties mirroring the definition in the DT
> bindings [2]. The pins are represented as sub-nodes. ACPI example [3].
> 
> Consumer (Ethernet):
> I defined a new DT schema for the consumer using properties dpll-pins
> nd dpll-pin-names. And in ACPI, I intend to use hierarchical data
> extension (_DSD) to reference the DPLL pin sub-nodes from the Ethernet
> controller package [4], effectively mirroring the DT phandle referencing
> mechanism.
> 
> Question:
> Is reusing the DT binding definitions within ACPI _DSD (to allow unified
> fwnode property parsing) the recommended approach for this type of
> device relationship?

TL;DR: Seems to me you are pretty much doing an ugly hack and yes, you violate
the existing ACPI resources. More details below.

> Or should I define strictly ACPI-specific bindings/objects, considering
> that the DT bindings for this feature are also new and currently under
> review?
> 
> I want to ensure I am not violating any ACPI abstraction layers by
> relying too heavily on the DT-style representation in _DSD.
> 
> Thanks for your guidance.

First of all, if I understood the HW topology right — it has an I²C muxer
which has a channel connected to DPLL, which among other functions provides
some kind of GPIO/pin muxing facility — (correct me, if I'm wrong), the
irrelevant to ACPI hack is an avoidance of having proper GPIO controller
driver / description provided with likely pin control and pin muxing
flavours, which is missing (hence drivers/pinctrl/... should be and it should
be described in DT).

Second, ACPI provides the _CRS resources specifically for pin configuration,
pin control (pin muxing as well). In case it's related those resources must
be used. The caveat, however, the Linux kernel has not yet implemented the
glue layer between ACPICA and pin control subsystem (see [5] for more).

It might be that I didn't get the picture correctly, but it smells badly to me.
In any case, I would like to help you and I'm open to more details about this
case.

> [1]
> https://patchwork.kernel.org/project/netdevbpf/list/?series=1040080&state=*
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dpll
> [3] https://github.com/ivecera/zl3073x-acpi/blob/main/sample1.asl
> [4] https://github.com/ivecera/zl3073x-acpi/blob/main/dpllnic.asl

[5]: https://lore.kernel.org/r/20221130164027.682898-1-niyas.sait@linaro.org

-- 
With Best Regards,
Andy Shevchenko

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

[Ivan Vecera]

Hi Andy,

thank you for the honest feedback. I suspect I might have described the 
topology poorly in my previous email, leading to a misunderstanding 
regarding the nature of the "pins".

On 1/14/26 9:45 PM, Andy Shevchenko wrote:
> On Wed, Jan 14, 2026 at 08:19:05PM +0100, Ivan Vecera wrote:
> 
>> I would like to ask for your opinion regarding an ACPI implementation
>> detail for a patch-set I currently have on the netdev mailing list [1].
>> ...
>> Question:
>> Is reusing the DT binding definitions within ACPI _DSD (to allow unified
>> fwnode property parsing) the recommended approach for this type of
>> device relationship?
> 
> TL;DR: Seems to me you are pretty much doing an ugly hack and yes, you violate
> the existing ACPI resources. More details below.
> 
>> Or should I define strictly ACPI-specific bindings/objects, considering
>> that the DT bindings for this feature are also new and currently under
>> review?
>>
>> I want to ensure I am not violating any ACPI abstraction layers by
>> relying too heavily on the DT-style representation in _DSD.
>>
>> Thanks for your guidance.
> 
> First of all, if I understood the HW topology right — it has an I²C muxer
> which has a channel connected to DPLL, which among other functions provides
> some kind of GPIO/pin muxing facility — (correct me, if I'm wrong), the
> irrelevant to ACPI hack is an avoidance of having proper GPIO controller
> driver / description provided with likely pin control and pin muxing
> flavours, which is missing (hence drivers/pinctrl/... should be and it should
> be described in DT).

This is not a GPIO or Pin Control scenario. The "pins" I am referring to 
are clock input/output pads dedicated to frequency synchronization 
(Synchronous Ethernet). They carry continuous clock signals (e.g., 
10MHz, 25MHz, or recovered network clock), not logic levels controllable 
via a GPIO subsystem.

The Hardware Setup:

Control Plane: A user configures the DPLL device (e.g., via I2C/SPI
managed by standard ACPI resources/drivers). This part is standard.

Data/Clock/Signal Plane (The issue at hand): There are physical clock
traces on the board connecting the Ethernet PHY directly to the DPLL.

PHY Output(s) -> DPLL Input Pin(s) (Recovered Clock)

DPLL Output Pin(s) -> PHY Input(s) (Clean Reference Clock)

Since these are purely clock signals between two peripheral devices (not
connected to the CPU's GPIO controller), standard ACPI _CRS resources
like GpioIo or PinFunction do not seem applicable here. To my knowledge,
ACPI does not have a native "Clock Resource" descriptor for inter-device
clock dependencies.

My intention with _DSD was to model this clock dependency graph, similar
to how clocks and clock-names are handled in Device Tree (or how camera
sensors often use _DSD to reference related components).

Does your objection regarding the "ugly hack" still stand, or is
modeling these clock dependencies via _DSD properties (referencing
sub-nodes) an acceptable approach in the absence of a dedicated ACPI
Clock Resource?

I can provide a simple ASCII diagram of the board layout if that helps 
clarify the signal flow.

> Second, ACPI provides the _CRS resources specifically for pin configuration,
> pin control (pin muxing as well). In case it's related those resources must
> be used. The caveat, however, the Linux kernel has not yet implemented the
> glue layer between ACPICA and pin control subsystem (see [5] for more).
> 
> It might be that I didn't get the picture correctly, but it smells badly to me.
> In any case, I would like to help you and I'm open to more details about this
> case.

Thanks for your willingness to help.

Regards,
Ivan

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

[Andy Shevchenko]

On Thu, Jan 15, 2026 at 08:34:05AM +0100, Ivan Vecera wrote:

> thank you for the honest feedback.

You're welcome!

> I suspect I might have described the
> topology poorly in my previous email, leading to a misunderstanding
> regarding the nature of the "pins".

Quite possible.

> On 1/14/26 9:45 PM, Andy Shevchenko wrote:
> > On Wed, Jan 14, 2026 at 08:19:05PM +0100, Ivan Vecera wrote:
> > 
> > > I would like to ask for your opinion regarding an ACPI implementation
> > > detail for a patch-set I currently have on the netdev mailing list [1].
> > > ...
> > > Question:
> > > Is reusing the DT binding definitions within ACPI _DSD (to allow unified
> > > fwnode property parsing) the recommended approach for this type of
> > > device relationship?
> > 
> > TL;DR: Seems to me you are pretty much doing an ugly hack and yes, you violate
> > the existing ACPI resources. More details below.
> > 
> > > Or should I define strictly ACPI-specific bindings/objects, considering
> > > that the DT bindings for this feature are also new and currently under
> > > review?
> > > 
> > > I want to ensure I am not violating any ACPI abstraction layers by
> > > relying too heavily on the DT-style representation in _DSD.
> > > 
> > > Thanks for your guidance.
> > 
> > First of all, if I understood the HW topology right — it has an I²C muxer
> > which has a channel connected to DPLL, which among other functions provides
> > some kind of GPIO/pin muxing facility — (correct me, if I'm wrong), the
> > irrelevant to ACPI hack is an avoidance of having proper GPIO controller
> > driver / description provided with likely pin control and pin muxing
> > flavours, which is missing (hence drivers/pinctrl/... should be and it should
> > be described in DT).
> 
> This is not a GPIO or Pin Control scenario. The "pins" I am referring to are
> clock input/output pads dedicated to frequency synchronization (Synchronous
> Ethernet). They carry continuous clock signals (e.g., 10MHz, 25MHz, or
> recovered network clock), not logic levels controllable via a GPIO
> subsystem.
> 
> The Hardware Setup:
> 
> Control Plane: A user configures the DPLL device (e.g., via I2C/SPI
> managed by standard ACPI resources/drivers). This part is standard.
> 
> Data/Clock/Signal Plane (The issue at hand): There are physical clock
> traces on the board connecting the Ethernet PHY directly to the DPLL.
> 
> PHY Output(s) -> DPLL Input Pin(s) (Recovered Clock)
> 
> DPLL Output Pin(s) -> PHY Input(s) (Clean Reference Clock)
> 
> Since these are purely clock signals between two peripheral devices (not
> connected to the CPU's GPIO controller), standard ACPI _CRS resources
> like GpioIo or PinFunction do not seem applicable here. To my knowledge,
> ACPI does not have a native "Clock Resource" descriptor for inter-device
> clock dependencies.
> 
> My intention with _DSD was to model this clock dependency graph, similar
> to how clocks and clock-names are handled in Device Tree (or how camera
> sensors often use _DSD to reference related components).
> 
> Does your objection regarding the "ugly hack" still stand, or is
> modeling these clock dependencies via _DSD properties (referencing
> sub-nodes) an acceptable approach in the absence of a dedicated ACPI
> Clock Resource?

Now my "ugly hack" is irrelevant, but still sounds not good.
I hope you have researched what has been done before [6].

(Please, return links to the our emails, as it helps to understand the
 discussion.)

I.o.w. there was an attempt a few years ago to fill the gaps, one of which
you are mentioning here. Note that the ACPI specification gains something
related (but I don't remember from top of my head what exactly, please
refer to it directly [7]).

> I can provide a simple ASCII diagram of the board layout if that helps
> clarify the signal flow.

Yes, please.

> > Second, ACPI provides the _CRS resources specifically for pin configuration,
> > pin control (pin muxing as well). In case it's related those resources must
> > be used. The caveat, however, the Linux kernel has not yet implemented the
> > glue layer between ACPICA and pin control subsystem (see [5] for more).
> > 
> > It might be that I didn't get the picture correctly, but it smells badly to me.
> > In any case, I would like to help you and I'm open to more details about this
> > case.

[1]: <please return them>
...
[6]: https://linaro.atlassian.net/wiki/spaces/CLIENTPC/overview
[7]: https://uefi.org/specs/ACPI/6.6/


-- 
With Best Regards,
Andy Shevchenko

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

[Ivan Vecera]

On 1/15/26 2:18 PM, Andy Shevchenko wrote:
> On Thu, Jan 15, 2026 at 08:34:05AM +0100, Ivan Vecera wrote:
> 
>> thank you for the honest feedback.
> 
> You're welcome!
> 
>> I suspect I might have described the
>> topology poorly in my previous email, leading to a misunderstanding
>> regarding the nature of the "pins".
> 
> Quite possible.
> 
>> On 1/14/26 9:45 PM, Andy Shevchenko wrote:
>>> On Wed, Jan 14, 2026 at 08:19:05PM +0100, Ivan Vecera wrote:
>> ...
>> This is not a GPIO or Pin Control scenario. The "pins" I am referring to are
>> clock input/output pads dedicated to frequency synchronization (Synchronous
>> Ethernet). They carry continuous clock signals (e.g., 10MHz, 25MHz, or
>> recovered network clock), not logic levels controllable via a GPIO
>> subsystem.
>>
>> The Hardware Setup:
>>
>> Control Plane: A user configures the DPLL device (e.g., via I2C/SPI
>> managed by standard ACPI resources/drivers). This part is standard.
>>
>> Data/Clock/Signal Plane (The issue at hand): There are physical clock
>> traces on the board connecting the Ethernet PHY directly to the DPLL.
>>
>> PHY Output(s) -> DPLL Input Pin(s) (Recovered Clock)
>>
>> DPLL Output Pin(s) -> PHY Input(s) (Clean Reference Clock)
>>
>> Since these are purely clock signals between two peripheral devices (not
>> connected to the CPU's GPIO controller), standard ACPI _CRS resources
>> like GpioIo or PinFunction do not seem applicable here. To my knowledge,
>> ACPI does not have a native "Clock Resource" descriptor for inter-device
>> clock dependencies.
>>
>> My intention with _DSD was to model this clock dependency graph, similar
>> to how clocks and clock-names are handled in Device Tree (or how camera
>> sensors often use _DSD to reference related components).
>>
>> Does your objection regarding the "ugly hack" still stand, or is
>> modeling these clock dependencies via _DSD properties (referencing
>> sub-nodes) an acceptable approach in the absence of a dedicated ACPI
>> Clock Resource?
> 
> Now my "ugly hack" is irrelevant, but still sounds not good.
> I hope you have researched what has been done before [6].
> 
> (Please, return links to the our emails, as it helps to understand the
>   discussion.)
Returned.

> I.o.w. there was an attempt a few years ago to fill the gaps, one of which
> you are mentioning here. Note that the ACPI specification gains something
> related (but I don't remember from top of my head what exactly, please
> refer to it directly [7]).
> 
>> I can provide a simple ASCII diagram of the board layout if that helps
>> clarify the signal flow.
> 
> Yes, please.

In SyncE (Synchronous Ethernet) scenarios, an Ethernet controller or PHY
is typically connected to a DPLL device that provides frequency
synchronization, holdover, and jitter filtering.

A SyncE-capable Ethernet PHY (or controller) usually has:
Output(s): Recovered clock signal connected to a DPLL input pin.
Input(s): Connected to a DPLL output pin.

Example:
      ETH controller or PHY
     +--------------------+
+---| rclk0              |
|+--| rclk1    synce_ref |<-+
||  +--------------------+  |
||                          |
||           DPLL           |
||  +--------------------+  |
|+->| ref1n              |  |
+-->| ref3n        out1p |--+
     +--------------------+

In DT this could look like:
   ...
   &dpll0 {
     ...
     input-pins {
       pin@3 {
         ...
       };
       pin@5 {
         ...
       };
     };
     output-pins {
       pin@2 {
         ...
       };
     };
   };
   &phy2 {
     ...
     dpll-pin-names = "rclk0", "rclk1", "synce_ref";
     dpll-pins = <&dpll0 3 DPLL_PIN_INPUT>,
                 <&dpll0 5 DPLL_PIN_INPUT>,
                 <&dpll0 2 DPLL_PIN_OUTPUT>;
     ...
   };

For ACPI I have followed [8][9][10] to create ASL code for the following
system (Intel GNR-D):
1. There is an I2C Mux (pca9546) connected to system SMBus
2. On the 3rd channel there is a I2C DPLL device (ZL30732) at address
    0x70
3. There is 4-port NIC (E825C) on PCIe bus

[3] is sample SSDT that adds the I2C mux and the DPLL device
[4] is sample SSDT that adds to the NICs 'dpll-pins' and
     'dpll-pin-names' properties to 2 NICs.

The goal of the patch-set [1] is that NIC driver (ice) will be able to
check what DPLL pins are used for its recovered clock outputs and what
DPLL pin provides the cleaned/synchronized signal for its input.
If so the NIC driver can report these DPLL pin IDs to the userspace
and a user can configure/monitor these pins accordingly.

Thank you,
Ivan

Links:
[1]
https://patchwork.kernel.org/project/netdevbpf/list/?series=1040080&state=*
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dpll
[3] https://github.com/ivecera/zl3073x-acpi/blob/main/sample1.asl
[4] https://github.com/ivecera/zl3073x-acpi/blob/main/dpllnic.asl
[5] https://lore.kernel.org/r/20221130164027.682898-1-niyas.sait@linaro.org
[6] https://linaro.atlassian.net/wiki/spaces/CLIENTPC/overview
[7] https://uefi.org/specs/ACPI/6.6/
[8] https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf
[9] https://docs.kernel.org/firmware-guide/acpi/i2c-muxes.html
[10] 
https://docs.kernel.org/firmware-guide/acpi/dsd/data-node-references.html

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

[Andy Shevchenko]

On Thu, Jan 15, 2026 at 03:09:53PM +0100, Ivan Vecera wrote:
> On 1/15/26 2:18 PM, Andy Shevchenko wrote:
> > On Thu, Jan 15, 2026 at 08:34:05AM +0100, Ivan Vecera wrote:
> > > On 1/14/26 9:45 PM, Andy Shevchenko wrote:
> > > > On Wed, Jan 14, 2026 at 08:19:05PM +0100, Ivan Vecera wrote:

...

> > > This is not a GPIO or Pin Control scenario. The "pins" I am referring to are
> > > clock input/output pads dedicated to frequency synchronization (Synchronous
> > > Ethernet). They carry continuous clock signals (e.g., 10MHz, 25MHz, or
> > > recovered network clock), not logic levels controllable via a GPIO
> > > subsystem.
> > > 
> > > The Hardware Setup:
> > > 
> > > Control Plane: A user configures the DPLL device (e.g., via I2C/SPI
> > > managed by standard ACPI resources/drivers). This part is standard.
> > > 
> > > Data/Clock/Signal Plane (The issue at hand): There are physical clock
> > > traces on the board connecting the Ethernet PHY directly to the DPLL.
> > > 
> > > PHY Output(s) -> DPLL Input Pin(s) (Recovered Clock)
> > > 
> > > DPLL Output Pin(s) -> PHY Input(s) (Clean Reference Clock)
> > > 
> > > Since these are purely clock signals between two peripheral devices (not
> > > connected to the CPU's GPIO controller), standard ACPI _CRS resources
> > > like GpioIo or PinFunction do not seem applicable here. To my knowledge,
> > > ACPI does not have a native "Clock Resource" descriptor for inter-device
> > > clock dependencies.
> > > 
> > > My intention with _DSD was to model this clock dependency graph, similar
> > > to how clocks and clock-names are handled in Device Tree (or how camera
> > > sensors often use _DSD to reference related components).
> > > 
> > > Does your objection regarding the "ugly hack" still stand, or is
> > > modeling these clock dependencies via _DSD properties (referencing
> > > sub-nodes) an acceptable approach in the absence of a dedicated ACPI
> > > Clock Resource?
> > 
> > Now my "ugly hack" is irrelevant, but still sounds not good.
> > I hope you have researched what has been done before [6].
> > 
> > (Please, return links to the our emails, as it helps to understand the
> >   discussion.)
> Returned.
> 
> > I.o.w. there was an attempt a few years ago to fill the gaps, one of which
> > you are mentioning here. Note that the ACPI specification gains something
> > related (but I don't remember from top of my head what exactly, please
> > refer to it directly [7]).
> > 
> > > I can provide a simple ASCII diagram of the board layout if that helps
> > > clarify the signal flow.
> > 
> > Yes, please.
> 
> In SyncE (Synchronous Ethernet) scenarios, an Ethernet controller or PHY
> is typically connected to a DPLL device that provides frequency
> synchronization, holdover, and jitter filtering.
> 
> A SyncE-capable Ethernet PHY (or controller) usually has:
> Output(s): Recovered clock signal connected to a DPLL input pin.
> Input(s): Connected to a DPLL output pin.
> 
> Example:
>      ETH controller or PHY
>     +--------------------+
> +---| rclk0              |
> |+--| rclk1    synce_ref |<-+
> ||  +--------------------+  |
> ||                          |
> ||           DPLL           |
> ||  +--------------------+  |
> |+->| ref1n              |  |
> +-->| ref3n        out1p |--+
>     +--------------------+
> 
> In DT this could look like:
>   ...
>   &dpll0 {
>     ...
>     input-pins {
>       pin@3 {
>         ...
>       };
>       pin@5 {
>         ...
>       };
>     };
>     output-pins {
>       pin@2 {
>         ...
>       };
>     };
>   };
>   &phy2 {
>     ...
>     dpll-pin-names = "rclk0", "rclk1", "synce_ref";
>     dpll-pins = <&dpll0 3 DPLL_PIN_INPUT>,
>                 <&dpll0 5 DPLL_PIN_INPUT>,
>                 <&dpll0 2 DPLL_PIN_OUTPUT>;
>     ...
>   };
> 
> For ACPI I have followed [8][9][10] to create ASL code for the following
> system (Intel GNR-D):
> 1. There is an I2C Mux (pca9546) connected to system SMBus
> 2. On the 3rd channel there is a I2C DPLL device (ZL30732) at address
>    0x70
> 3. There is 4-port NIC (E825C) on PCIe bus
> 
> [3] is sample SSDT that adds the I2C mux and the DPLL device
> [4] is sample SSDT that adds to the NICs 'dpll-pins' and
>     'dpll-pin-names' properties to 2 NICs.
> 
> The goal of the patch-set [1] is that NIC driver (ice) will be able to
> check what DPLL pins are used for its recovered clock outputs and what
> DPLL pin provides the cleaned/synchronized signal for its input.
> If so the NIC driver can report these DPLL pin IDs to the userspace
> and a user can configure/monitor these pins accordingly.

So, this is not so bad as I thought initially. Still the open question if you
studied [6][7] and learnt anything new about clocks and ACPI integration?

P.S. Currently I can consider this as Plan B if we found no other better designs.
However it would be nice to see some review from network people, such as
Andrew Lunn and Vladimir Oltean. They know much more about networking HW
topologies and they have an expertise in ACPI.

> Links:
> [1]
> https://patchwork.kernel.org/project/netdevbpf/list/?series=1040080&state=*
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dpll
> [3] https://github.com/ivecera/zl3073x-acpi/blob/main/sample1.asl
> [4] https://github.com/ivecera/zl3073x-acpi/blob/main/dpllnic.asl
> [5] https://lore.kernel.org/r/20221130164027.682898-1-niyas.sait@linaro.org
> [6] https://linaro.atlassian.net/wiki/spaces/CLIENTPC/overview
> [7] https://uefi.org/specs/ACPI/6.6/
> [8] https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf
> [9] https://docs.kernel.org/firmware-guide/acpi/i2c-muxes.html
> [10]
> https://docs.kernel.org/firmware-guide/acpi/dsd/data-node-references.html

-- 
With Best Regards,
Andy Shevchenko

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

[Andrew Lunn]

> P.S. Currently I can consider this as Plan B if we found no other better designs.
> However it would be nice to see some review from network people, such as
> Andrew Lunn and Vladimir Oltean. They know much more about networking HW
> topologies and they have an expertise in ACPI.

I've been reviewing the DT parts. And the DT Maintainers are also
looking at the patches.

But the question being addressed here is, do we want an ACPI binding,
following ACPI guidelines etc. Or is it OK to just stuff the DT
binding as is into ACPI tables?  No native ACPI binding?

Putting DT into ACPI seems to be accepted when there is a long
established DT binding, but ACPI has nothing. Which is common for
networking with SoCs and Linux driving the hardware, not firmware. But
this is all new, its a new DT binding, should there also be a new ACPI
binding?

	Andrew

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

[Andy Shevchenko]

On Mon, Jan 19, 2026 at 06:43:55PM +0100, Andrew Lunn wrote:
> > P.S. Currently I can consider this as Plan B if we found no other better designs.
> > However it would be nice to see some review from network people, such as
> > Andrew Lunn and Vladimir Oltean. They know much more about networking HW
> > topologies and they have an expertise in ACPI.
> 
> I've been reviewing the DT parts. And the DT Maintainers are also
> looking at the patches.
> 
> But the question being addressed here is, do we want an ACPI binding,
> following ACPI guidelines etc. Or is it OK to just stuff the DT
> binding as is into ACPI tables?  No native ACPI binding?

It depends. If [6] was trying to address what [7] describes in the specification
and if the current problem with clock fits into all this, perhaps we need to
finalize the work started in [6].

> Putting DT into ACPI seems to be accepted when there is a long
> established DT binding, but ACPI has nothing. Which is common for
> networking with SoCs and Linux driving the hardware, not firmware. But
> this is all new, its a new DT binding, should there also be a new ACPI
> binding?

Yeah, I understood that point. Unfortunately I'm not so fluent in the Clock
related parts in ACPI, and I remember that Niyas did something in the area
while he was working for Linaro. Personally, I was interested only in pin
control integration part, so I haven't ever looked into other (missing)
parts he tried to develop.

-- 
With Best Regards,
Andy Shevchenko

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

[Ivan Vecera]

On 1/19/26 6:49 PM, Andy Shevchenko wrote:
> On Mon, Jan 19, 2026 at 06:43:55PM +0100, Andrew Lunn wrote:
>>> P.S. Currently I can consider this as Plan B if we found no other better designs.
>>> However it would be nice to see some review from network people, such as
>>> Andrew Lunn and Vladimir Oltean. They know much more about networking HW
>>> topologies and they have an expertise in ACPI.
>>
>> I've been reviewing the DT parts. And the DT Maintainers are also
>> looking at the patches.
>>
>> But the question being addressed here is, do we want an ACPI binding,
>> following ACPI guidelines etc. Or is it OK to just stuff the DT
>> binding as is into ACPI tables?  No native ACPI binding?
> 
> It depends. If [6] was trying to address what [7] describes in the specification
> and if the current problem with clock fits into all this, perhaps we need to
> finalize the work started in [6].
> 
>> Putting DT into ACPI seems to be accepted when there is a long
>> established DT binding, but ACPI has nothing. Which is common for
>> networking with SoCs and Linux driving the hardware, not firmware. But
>> this is all new, its a new DT binding, should there also be a new ACPI
>> binding?
> 
> Yeah, I understood that point. Unfortunately I'm not so fluent in the Clock
> related parts in ACPI, and I remember that Niyas did something in the area
> while he was working for Linaro. Personally, I was interested only in pin
> control integration part, so I haven't ever looked into other (missing)
> parts he tried to develop.
> 

Hi all,
per Rob's advice, we should reuse existing clock bindings for the
relationship between DPLL device and network controller / phy.

SyncE typically involves one or more clock outputs from network device
connected to DPLL device and one output from DPLL routed back to the
network device. The net device sends a signal received from the ethernet
port to the DPLL. DPLL then locks on this signal, clears jitter and
provides phase-aligned output signal back to the network device.

This setup can be defined by this simplified DT example:

&dpll0 {
	...
	#clock-cells = <1>;
	clock-names = "ref0";
	clocks = <&ethernet0 0>;
	...
};
&ethernet0 {
	...
	#clock-cells = <0>;
	clock-names = "synce_ref";
	clocks = <&dpll0 5>;
	...
};

In this example ethernet0's output 0 (aka rclk) produces clock for
dpll0's input pin named "ref0" and dpll0's 5th output produces clock for
ethernet0's input labelled "synce_ref".

Based on [1] example this clock relationship can be represented by _DSD.
Is it correct?

Thanks,
Ivan

[1] 
https://uefi.org/specs/ACPI/6.6/06_Device_Configuration.html#dsd-device-specific-data

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

[Andy Shevchenko]

On Mon, Jan 19, 2026 at 08:23:30PM +0100, Ivan Vecera wrote:
> On 1/19/26 6:49 PM, Andy Shevchenko wrote:
> > On Mon, Jan 19, 2026 at 06:43:55PM +0100, Andrew Lunn wrote:

...

> > > > P.S. Currently I can consider this as Plan B if we found no other better designs.
> > > > However it would be nice to see some review from network people, such as
> > > > Andrew Lunn and Vladimir Oltean. They know much more about networking HW
> > > > topologies and they have an expertise in ACPI.
> > > 
> > > I've been reviewing the DT parts. And the DT Maintainers are also
> > > looking at the patches.
> > > 
> > > But the question being addressed here is, do we want an ACPI binding,
> > > following ACPI guidelines etc. Or is it OK to just stuff the DT
> > > binding as is into ACPI tables?  No native ACPI binding?
> > 
> > It depends. If [6] was trying to address what [7] describes in the specification
> > and if the current problem with clock fits into all this, perhaps we need to
> > finalize the work started in [6].
> > 
> > > Putting DT into ACPI seems to be accepted when there is a long
> > > established DT binding, but ACPI has nothing. Which is common for
> > > networking with SoCs and Linux driving the hardware, not firmware. But
> > > this is all new, its a new DT binding, should there also be a new ACPI
> > > binding?
> > 
> > Yeah, I understood that point. Unfortunately I'm not so fluent in the Clock
> > related parts in ACPI, and I remember that Niyas did something in the area
> > while he was working for Linaro. Personally, I was interested only in pin
> > control integration part, so I haven't ever looked into other (missing)
> > parts he tried to develop.
> 
> Hi all,
> per Rob's advice, we should reuse existing clock bindings for the
> relationship between DPLL device and network controller / phy.

Why? If ACPI gains proper concept of clocks, the usage of DT bindings will be
a hack.

> SyncE typically involves one or more clock outputs from network device
> connected to DPLL device and one output from DPLL routed back to the
> network device. The net device sends a signal received from the ethernet
> port to the DPLL. DPLL then locks on this signal, clears jitter and
> provides phase-aligned output signal back to the network device.
> 
> This setup can be defined by this simplified DT example:
> 
> &dpll0 {
> 	...
> 	#clock-cells = <1>;
> 	clock-names = "ref0";
> 	clocks = <&ethernet0 0>;
> 	...
> };
> &ethernet0 {
> 	...
> 	#clock-cells = <0>;
> 	clock-names = "synce_ref";
> 	clocks = <&dpll0 5>;
> 	...
> };
> 
> In this example ethernet0's output 0 (aka rclk) produces clock for
> dpll0's input pin named "ref0" and dpll0's 5th output produces clock for
> ethernet0's input labelled "synce_ref".
> 
> 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?

> [1] https://uefi.org/specs/ACPI/6.6/06_Device_Configuration.html#dsd-device-specific-data

-- 
With Best Regards,
Andy Shevchenko

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

[Ivan Vecera]

On 1/19/26 8:42 PM, Andy Shevchenko wrote:
> On Mon, Jan 19, 2026 at 08:23:30PM +0100, Ivan Vecera wrote:
>> On 1/19/26 6:49 PM, Andy Shevchenko wrote:
>>> On Mon, Jan 19, 2026 at 06:43:55PM +0100, Andrew Lunn wrote:
> 
> ...
> 
>>>>> P.S. Currently I can consider this as Plan B if we found no other better designs.
>>>>> However it would be nice to see some review from network people, such as
>>>>> Andrew Lunn and Vladimir Oltean. They know much more about networking HW
>>>>> topologies and they have an expertise in ACPI.
>>>>
>>>> I've been reviewing the DT parts. And the DT Maintainers are also
>>>> looking at the patches.
>>>>
>>>> But the question being addressed here is, do we want an ACPI binding,
>>>> following ACPI guidelines etc. Or is it OK to just stuff the DT
>>>> binding as is into ACPI tables?  No native ACPI binding?
>>>
>>> It depends. If [6] was trying to address what [7] describes in the specification
>>> and if the current problem with clock fits into all this, perhaps we need to
>>> finalize the work started in [6].
>>>
>>>> Putting DT into ACPI seems to be accepted when there is a long
>>>> established DT binding, but ACPI has nothing. Which is common for
>>>> networking with SoCs and Linux driving the hardware, not firmware. But
>>>> this is all new, its a new DT binding, should there also be a new ACPI
>>>> binding?
>>>
>>> Yeah, I understood that point. Unfortunately I'm not so fluent in the Clock
>>> related parts in ACPI, and I remember that Niyas did something in the area
>>> while he was working for Linaro. Personally, I was interested only in pin
>>> control integration part, so I haven't ever looked into other (missing)
>>> parts he tried to develop.
>>
>> Hi all,
>> per Rob's advice, we should reuse existing clock bindings for the
>> relationship between DPLL device and network controller / phy.
> 
> Why? If ACPI gains proper concept of clocks, the usage of DT bindings will be
> a hack.

I have been wanting to propose a new consumer / supplier schema for
dpll-pins [1] but it was advised to use existing clock-binding schema to
represent this relationships.

>> SyncE typically involves one or more clock outputs from network device
>> connected to DPLL device and one output from DPLL routed back to the
>> network device. The net device sends a signal received from the ethernet
>> port to the DPLL. DPLL then locks on this signal, clears jitter and
>> provides phase-aligned output signal back to the network device.
>>
>> This setup can be defined by this simplified DT example:
>>
>> &dpll0 {
>> 	...
>> 	#clock-cells = <1>;
>> 	clock-names = "ref0";
>> 	clocks = <&ethernet0 0>;
>> 	...
>> };
>> &ethernet0 {
>> 	...
>> 	#clock-cells = <0>;
>> 	clock-names = "synce_ref";
>> 	clocks = <&dpll0 5>;
>> 	...
>> };
>>
>> In this example ethernet0's output 0 (aka rclk) produces clock for
>> dpll0's input pin named "ref0" and dpll0's 5th output produces clock for
>> ethernet0's input labelled "synce_ref".
>>
>> 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...

Thanks,
Ivan

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

[Ivan Vecera]

On January 19, 2026 8:55:40 PM GMT+01:00, Ivan Vecera <ivecera@redhat.com> wrote:
>On 1/19/26 8:42 PM, Andy Shevchenko wrote:
>> On Mon, Jan 19, 2026 at 08:23:30PM +0100, Ivan Vecera wrote:
>>> On 1/19/26 6:49 PM, Andy Shevchenko wrote:
>>>> On Mon, Jan 19, 2026 at 06:43:55PM +0100, Andrew Lunn wrote:
>> 
>> ...
>> 
>>>>>> P.S. Currently I can consider this as Plan B if we found no other better designs.
>>>>>> However it would be nice to see some review from network people, such as
>>>>>> Andrew Lunn and Vladimir Oltean. They know much more about networking HW
>>>>>> topologies and they have an expertise in ACPI.
>>>>> 
>>>>> I've been reviewing the DT parts. And the DT Maintainers are also
>>>>> looking at the patches.
>>>>> 
>>>>> But the question being addressed here is, do we want an ACPI binding,
>>>>> following ACPI guidelines etc. Or is it OK to just stuff the DT
>>>>> binding as is into ACPI tables?  No native ACPI binding?
>>>> 
>>>> It depends. If [6] was trying to address what [7] describes in the specification
>>>> and if the current problem with clock fits into all this, perhaps we need to
>>>> finalize the work started in [6].
>>>> 
>>>>> Putting DT into ACPI seems to be accepted when there is a long
>>>>> established DT binding, but ACPI has nothing. Which is common for
>>>>> networking with SoCs and Linux driving the hardware, not firmware. But
>>>>> this is all new, its a new DT binding, should there also be a new ACPI
>>>>> binding?
>>>> 
>>>> Yeah, I understood that point. Unfortunately I'm not so fluent in the Clock
>>>> related parts in ACPI, and I remember that Niyas did something in the area
>>>> while he was working for Linaro. Personally, I was interested only in pin
>>>> control integration part, so I haven't ever looked into other (missing)
>>>> parts he tried to develop.
>>> 
>>> Hi all,
>>> per Rob's advice, we should reuse existing clock bindings for the
>>> relationship between DPLL device and network controller / phy.
>> 
>> Why? If ACPI gains proper concept of clocks, the usage of DT bindings will be
>> a hack.
>
>I have been wanting to propose a new consumer / supplier schema for
>dpll-pins [1] but it was advised to use existing clock-binding schema to
>represent this relationships.


Sorry, I forgot to add [1] link

<https://github.com/devicetree-org/dt-schema/pull/183>

Ivan

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

[Andy Shevchenko]

On Mon, Jan 19, 2026 at 08:55:40PM +0100, Ivan Vecera wrote:
> On 1/19/26 8:42 PM, Andy Shevchenko wrote:
> > On Mon, Jan 19, 2026 at 08:23:30PM +0100, Ivan Vecera wrote:
> > > On 1/19/26 6:49 PM, Andy Shevchenko wrote:
> > > > On Mon, Jan 19, 2026 at 06:43:55PM +0100, Andrew Lunn wrote:

...

> > > > > > P.S. Currently I can consider this as Plan B if we found no other better designs.
> > > > > > However it would be nice to see some review from network people, such as
> > > > > > Andrew Lunn and Vladimir Oltean. They know much more about networking HW
> > > > > > topologies and they have an expertise in ACPI.
> > > > > 
> > > > > I've been reviewing the DT parts. And the DT Maintainers are also
> > > > > looking at the patches.
> > > > > 
> > > > > But the question being addressed here is, do we want an ACPI binding,
> > > > > following ACPI guidelines etc. Or is it OK to just stuff the DT
> > > > > binding as is into ACPI tables?  No native ACPI binding?
> > > > 
> > > > It depends. If [6] was trying to address what [7] describes in the specification
> > > > and if the current problem with clock fits into all this, perhaps we need to
> > > > finalize the work started in [6].
> > > > 
> > > > > Putting DT into ACPI seems to be accepted when there is a long
> > > > > established DT binding, but ACPI has nothing. Which is common for
> > > > > networking with SoCs and Linux driving the hardware, not firmware. But
> > > > > this is all new, its a new DT binding, should there also be a new ACPI
> > > > > binding?
> > > > 
> > > > Yeah, I understood that point. Unfortunately I'm not so fluent in the Clock
> > > > related parts in ACPI, and I remember that Niyas did something in the area
> > > > while he was working for Linaro. Personally, I was interested only in pin
> > > > control integration part, so I haven't ever looked into other (missing)
> > > > parts he tried to develop.
> > > 
> > > per Rob's advice, we should reuse existing clock bindings for the
> > > relationship between DPLL device and network controller / phy.
> > 
> > Why? If ACPI gains proper concept of clocks, the usage of DT bindings will be
> > a hack.
> 
> I have been wanting to propose a new consumer / supplier schema for
> dpll-pins [1] but it was advised to use existing clock-binding schema to
> represent this relationships.
> 
> > > SyncE typically involves one or more clock outputs from network device
> > > connected to DPLL device and one output from DPLL routed back to the
> > > network device. The net device sends a signal received from the ethernet
> > > port to the DPLL. DPLL then locks on this signal, clears jitter and
> > > provides phase-aligned output signal back to the network device.
> > > 
> > > This setup can be defined by this simplified DT example:
> > > 
> > > &dpll0 {
> > > 	...
> > > 	#clock-cells = <1>;
> > > 	clock-names = "ref0";
> > > 	clocks = <&ethernet0 0>;
> > > 	...
> > > };
> > > &ethernet0 {
> > > 	...
> > > 	#clock-cells = <0>;
> > > 	clock-names = "synce_ref";
> > > 	clocks = <&dpll0 5>;
> > > 	...
> > > };
> > > 
> > > In this example ethernet0's output 0 (aka rclk) produces clock for
> > > dpll0's input pin named "ref0" and dpll0's 5th output produces clock for
> > > ethernet0's input labelled "synce_ref".
> > > 
> > > 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.

-- 
With Best Regards,
Andy Shevchenko

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

[Linus Walleij]

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!

Yours,
Linus Walleij

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

[Ivan Vecera]

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!
> 
> Yours,
> Linus Walleij

Hi all,
I think we might be getting sidetracked by the specific subsystems
(pinctrl/GPIO/Clock).

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

Thanks,
Ivan

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

[Andy Shevchenko]

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

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

[Rafael J. Wysocki]

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.

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

[Andy Shevchenko]

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.

-- 
With Best Regards,
Andy Shevchenko

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

[Rafael J. Wysocki]

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.

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

[Andy Shevchenko]

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