netdev - Re: [RFC PATCH net-next] dt-bindings: dpll: Add per-channel Ethernet reference property

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_JsqL5wQ+0Xcdo5T3FTyoa2csQ9aW8ZxxMxVOhRJpzc7fGhA@mail.gmail.com>
Date: Mon, 8 Sep 2025 17:49:28 -0500
From: Rob Herring <robh@...nel.org>
To: Ivan Vecera <ivecera@...hat.com>
Cc: netdev@...r.kernel.org, mschmidt@...hat.com, poros@...hat.com, 
	Andrew Lunn <andrew@...n.ch>, Vadim Fedorenko <vadim.fedorenko@...ux.dev>, 
	Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>, Jiri Pirko <jiri@...nulli.us>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Prathosh Satish <Prathosh.Satish@...rochip.com>, 
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH net-next] dt-bindings: dpll: Add per-channel Ethernet
 reference property

On Fri, Sep 5, 2025 at 1:50 AM Ivan Vecera <ivecera@...hat.com> wrote:
>
>
>
> On 05. 09. 25 12:06 dop., Rob Herring wrote:
> > On Fri, Aug 29, 2025 at 8:29 AM Ivan Vecera <ivecera@...hat.com> wrote:
> >> ...
> >>
> >> Do you mean to add a property (e.g. dpll-channel or dpll-device) into
> >> net/network-class.yaml ? If so, yes, it would be possible, and the way
> >> I look at it now, it would probably be better. The DPLL driver can
> >> enumerate all devices across the system that has this specific property
> >> and check its value.
> >
> > Yes. Or into ethernet-controller.yaml. Is a DPLL used with wifi,
> > bluetooth, etc.?
>
> AFAIK no... ethernet-controller makes sense.
>
> >>
> >> See the proposal below...
> >>
> >> Thanks,
> >> Ivan
> >>
> >> ---
> >>    Documentation/devicetree/bindings/dpll/dpll-device.yaml  | 6 ++++++
> >>    Documentation/devicetree/bindings/net/network-class.yaml | 7 +++++++
> >>    2 files changed, 13 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/dpll/dpll-device.yaml
> >> b/Documentation/devicetree/bindings/dpll/dpll-device.yaml
> >> index fb8d7a9a3693f..560351df1bec3 100644
> >> --- a/Documentation/devicetree/bindings/dpll/dpll-device.yaml
> >> +++ b/Documentation/devicetree/bindings/dpll/dpll-device.yaml
> >> @@ -27,6 +27,12 @@ properties:
> >>      "#size-cells":
> >>        const: 0
> >>
> >> +  "#dpll-cells":
> >> +    description: |
> >> +      Number of cells in a dpll specifier. The cell specifies the index
> >> +      of the channel within the DPLL device.
> >> +    const: 1
> >
> > If it is 1 for everyone, then you don't need a property for it. The
> > question is whether it would need to vary. Perhaps some configuration
> > flags/info might be needed? Connection type or frequency looking at
> > the existing configuration setting?
>
> Connection type maybe... What I am trying to do is define a relationship
> between the network controller and the DPLL device, which together form
> a single entity from a use-case perspective (e.g., Ethernet uses an
> external DPLL device either to synchronize the recovered clock or to
> provide a SyncE signal synchronized with an external 1PPS source).
>
> Yesterday I was considering the implementation from the DPLL driver's
> perspective and encountered a problem when the relation is defined from
> the Ethernet controller's perspective. In that case, it would be
> necessary to enumerate all devices that contain a “dpll” property whose
> value references this DPLL device.

Why is that?

>
> This approach seems quite complicated, as it would require searching
> through all buses, all connected devices, and checking each fwnode for a
> “dpll” property containing the given reference. I don’t think this would
> be the right solution.

for_each_node_with_property() provides that. No, it's not efficient,
but I doubt it needs to be. As you'd only need to do it once.

> I then came across graph bindings and ACPI graph extensions, which are
> widely used in the media and DRM subsystems to define relations between
> devices. Would this be an appropriate way to define a binding between an
> Ethernet controller and a DPLL device?

Usually the graph is used to handle complex chains of devices and how
the data flows. I'm not sure that applies here.

> If so, what would such a binding roughly look like? I’m not very
> experienced in this area, so I would appreciate any guidance.
>
> If not, wouldn’t it be better to define the relation from the DPLL
> device to the network controller, as originally proposed?

I have no idea really. I would think the DPLL is the provider and an
ethernet device is the consumer. And if the ethernet device is unused
(or disabled), then the DPLL connection associated with it is unused.
If that's the case, then I think the property belongs in the ethernet
node.

Rob