On Mon, Jan 5, 2026 at 10:24 AM Ivan Vecera <[email protected]> wrote: > > On 12/17/25 1:49 AM, Rob Herring wrote: > > On Thu, Dec 11, 2025 at 08:56:52PM +0100, Andrew Lunn wrote: > >> On Thu, Dec 11, 2025 at 08:47:44PM +0100, Ivan Vecera wrote: > >>> Ethernet controllers may be connected to DPLL (Digital Phase Locked Loop) > >>> pins for frequency synchronization purposes, such as in Synchronous > >>> Ethernet (SyncE) configurations. > >>> > >>> Add 'dpll-pins' and 'dpll-pin-names' properties to the generic > >>> ethernet-controller schema. This allows describing the physical > >>> connections between the Ethernet controller and the DPLL subsystem pins > >>> in the Device Tree, enabling drivers to request and manage these > >>> resources. > >> > >> Please include a .dts patch in the series which actually makes use of > >> these new properties. > > > > Actually, first you need a device (i.e. a specific ethernet > > controller bindings) using this and defining the number of dpll-pins > > entries and the names. > > The goal of this patch is to define properties that allow referencing > dpll pins from other devices. I included it in this series to allow > implementing helpers that use the property names defined in the schema. > > This series implements the dpll pin consumer in the ice driver. This is > usually present on ACPI platforms, so the properties are stored in _DSD > ACPI nodes. Although I don't have a DT user right now, isn't it better > to define the schema now?
I have no idea what makes sense for ACPI and little interest in reviewing ACPI bindings. While I think the whole idea of shared bindings is questionable, really it's a question of review bandwidth and so far no one has stepped up to review ACPI bindings. > Thinking about this further, consumers could be either an Ethernet > controller (where the PHY is not exposed and is driven directly by the > NIC driver) or an Ethernet PHY. > > For the latter case (Ethernet PHY), I have been preparing a similar > implementation for the Micrel phy driver (lan8814) on the Microchip EDS2 > board (pcb8385). Unfortunately, the DTS is not upstreamed yet [1], so I > cannot include the necessary bindings here. > > Since there can be multiple consumer types (Ethernet controller or PHY), > would it be better to define a dpll-pin-consumer.yaml schema instead > (similar to mux-consumer)? The consumer type doesn't matter for that. What matters is you have specific device bindings and if they are consumers of some provider/consumer style binding, then typically each device binding has to define the constraints if there can be multiple entries/connections (e.g. how many interrupts, clocks, etc. and what each one is). Hard to say what's needed for DPLL exactly because I know next to nothing about it. Rob
