Message-ID: <bc39cdc9-c354-416d-896f-c2b3c3b64858@redhat.com>
Date: Fri, 5 Sep 2025 08:50:06 +0200
From: Ivan Vecera <ivecera@...hat.com>
To: Rob Herring <robh@...nel.org>
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 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.

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.

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?

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?

Thanks,
Ivan

Powered by blists - more mailing lists