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

[Ivan Vecera]

On 09. 09. 25 12:49 dop., Rob Herring wrote:
> On Fri, Sep 5, 2025 at 1:50 AM Ivan Vecera <ivecera@xxxxxxxxxx> wrote:
> > On 05. 09. 25 12:06 dop., Rob Herring wrote:
> > > On Fri, Aug 29, 2025 at 8:29 AM Ivan Vecera <ivecera@xxxxxxxxxx> 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?

Because the DPLL driver has to find a mac-address of the ethernet
controller to generate clock identity that is used for DPLL device
registration.

> > 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.

Yes, for_each_node_with_property() could be used but only for OF case. I
would like to use firmware type agnostic interface to cover also ACPI
systems where the zl3073x driver is/will be used.

I'm not aware of similar functionality for fwnode... is it an option
to write FW type agnostic macro for_each_fwnode_with_property() that
would cover OF, ACPI, software_node...?

> > 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.

Agree.

> > 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.

From this point of view, this is true. DPLL is signal provider and
ethernet controller its consumer. Or in other words the PHC in the NIC
is driven by this DPLL OR the DPLL drives the PHC in this NIC.
It depends on point of view.

Thanks,
Ivan