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

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

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