netdev - Re: [PATCH RFC net-next 01/13] dt-bindings: net: ethernet-controller: Add DPLL pin properties

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_JsqJoybgJTAbSjGbTBxo-v=dbYY68tT309CV98=ohWhnC=w@mail.gmail.com>
Date: Wed, 7 Jan 2026 09:15:36 -0600
From: Rob Herring <robh@...nel.org>
To: Ivan Vecera <ivecera@...hat.com>
Cc: Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org, 
	Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Vadim Fedorenko <vadim.fedorenko@...ux.dev>, 
	Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>, Grzegorz Nitka <grzegorz.nitka@...el.com>, 
	Jiri Pirko <jiri@...nulli.us>, Petr Oros <poros@...hat.com>, 
	Michal Schmidt <mschmidt@...hat.com>, Prathosh Satish <Prathosh.Satish@...rochip.com>, 
	Tony Nguyen <anthony.l.nguyen@...el.com>, Przemek Kitszel <przemyslaw.kitszel@...el.com>, 
	Saeed Mahameed <saeedm@...dia.com>, Leon Romanovsky <leon@...nel.org>, Tariq Toukan <tariqt@...dia.com>, 
	Mark Bloch <mbloch@...dia.com>, Richard Cochran <richardcochran@...il.com>, 
	Jonathan Lemon <jonathan.lemon@...il.com>, Simon Horman <horms@...nel.org>, 
	Alexander Lobakin <aleksander.lobakin@...el.com>, Willem de Bruijn <willemb@...gle.com>, 
	Stefan Wahren <wahrenst@....net>, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	intel-wired-lan@...ts.osuosl.org, linux-rdma@...r.kernel.org, 
	Horatiu Vultur <Horatiu.Vultur@...rochip.com>
Subject: Re: [PATCH RFC net-next 01/13] dt-bindings: net: ethernet-controller:
 Add DPLL pin properties

On Mon, Jan 5, 2026 at 10:24 AM Ivan Vecera <ivecera@...hat.com> 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