Hi Rob,
On 1/7/26 4:15 PM, Rob Herring wrote:
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.
It depends... shared bindings allow drivers to read property values
without need to have separate OF and ACPI codepaths.
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.
The motivation is to describe the interconnection between an Ethernet
controller (or PHY) and a DPLL device. In SyncE scenarios, the NIC or
PHY provides a recovered clock output received from the physical port,
and the signal is routed to specific DPLL pin(s). The DPLL device then
locks onto this signal, filters jitter/wander, and provides a stable,
phase-aligned clock back to the NIC. When a NIC or PHY package supports
multiple Ethernet ports, it may allow selecting which port's recovered
clock signal is routed to the DPLL pin.
The goal of this entire series is to allow NIC drivers to register their
own pins (per port) on top of existing pins from the DPLL device. To do
so, it is necessary to know which DPLL device pin is connected to the
NIC's recovered clock output.
The NIC/PHY acts as a consumer of the DPLL pin(s) provided by the DPLL
device. As I mentioned in my previous email, I am working on the
implementation of this feature (recovered clock selection) for the
Micrel driver (a DT area user). If it is acceptable to you, I can omit
the first patch that introduces DT properties from this series and add
it to the series that will introduce the feature for the Micrel driver.
Thanks,
Ivan
