From: Rob Herring <robh@kernel.org>
To: Ivan Vecera <ivecera@redhat.com>
Cc: netdev@vger.kernel.org, mschmidt@redhat.com, poros@redhat.com,
Andrew Lunn <andrew@lunn.ch>,
Vadim Fedorenko <vadim.fedorenko@linux.dev>,
Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>,
Jiri Pirko <jiri@resnulli.us>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Prathosh Satish <Prathosh.Satish@microchip.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH net-next] dt-bindings: dpll: Add per-channel Ethernet reference property
Date: Thu, 4 Sep 2025 17:06:48 -0500 [thread overview]
Message-ID: <CAL_JsqKui29O_8xGBVx9T2e85Dy0onyAp4mGqChSuuwABOhDqA@mail.gmail.com> (raw)
In-Reply-To: <5e38e1b7-9589-49a9-8f26-3b186f54c7d5@redhat.com>
On Fri, Aug 29, 2025 at 8:29 AM Ivan Vecera <ivecera@redhat.com> wrote:
>
> Hi Rob,
>
> On 20. 08. 25 11:13 odp., Rob Herring wrote:
> > On Fri, Aug 15, 2025 at 04:47:35PM +0200, Ivan Vecera wrote:
> >> In case of SyncE scenario a DPLL channels generates a clean frequency
> >> synchronous Ethernet clock (SyncE) and feeds it into the NIC transmit
> >> path. The DPLL channel can be locked either to the recovered clock
> >> from the NIC's PHY (Loop timing scenario) or to some external signal
> >> source (e.g. GNSS) (Externally timed scenario).
> >>
> >> The example shows both situations. NIC1 recovers the input SyncE signal
> >> that is used as an input reference for DPLL channel 1. The channel locks
> >> to this signal, filters jitter/wander and provides holdover. On output
> >> the channel feeds a stable, phase-aligned clock back into the NIC1.
> >> In the 2nd case the DPLL channel 2 locks to a master clock from GNSS and
> >> feeds a clean SyncE signal into the NIC2.
> >>
> >> +-----------+
> >> +--| NIC 1 |<-+
> >> | +-----------+ |
> >> | |
> >> | RxCLK TxCLK |
> >> | |
> >> | +-----------+ |
> >> +->| channel 1 |--+
> >> +------+ |-- DPLL ---|
> >> | GNSS |---------->| channel 2 |--+
> >> +------+ RefCLK +-----------+ |
> >> |
> >> TxCLK |
> >> |
> >> +-----------+ |
> >> | NIC 2 |<-+
> >> +-----------+
> >>
> >> In the situations above the DPLL channels should be registered into
> >> the DPLL sub-system with the same Clock Identity as PHCs present
> >> in the NICs (for the example above DPLL channel 1 uses the same
> >> Clock ID as NIC1's PHC and the channel 2 as NIC2's PHC).
> >>
> >> Because a NIC PHC's Clock ID is derived from the NIC's MAC address,
> >> add a per-channel property 'ethernet-handle' that specifies a reference
> >> to a node representing an Ethernet device that uses this channel
> >> to synchronize its hardware clock. Additionally convert existing
> >> 'dpll-types' list property to 'dpll-type' per-channel property.
> >>
> >> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> >> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> >> ---
> >> .../devicetree/bindings/dpll/dpll-device.yaml | 40 ++++++++++++++++---
> >> .../bindings/dpll/microchip,zl30731.yaml | 29 +++++++++++++-
> >> 2 files changed, 62 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/dpll/dpll-device.yaml b/Documentation/devicetree/bindings/dpll/dpll-device.yaml
> >> index fb8d7a9a3693f..798c5484657cf 100644
> >> --- a/Documentation/devicetree/bindings/dpll/dpll-device.yaml
> >> +++ b/Documentation/devicetree/bindings/dpll/dpll-device.yaml
> >> @@ -27,11 +27,41 @@ properties:
> >> "#size-cells":
> >> const: 0
> >>
> >> - dpll-types:
> >> - description: List of DPLL channel types, one per DPLL instance.
> >> - $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> >> - items:
> >> - enum: [pps, eec]
> >
> > Dropping this is an ABI change. You can't do that unless you are
> > confident there are no users both in existing DTs and OSs.
>
> Get it, will keep.
>
> >> + channels:
> >> + type: object
> >> + description: DPLL channels
> >> + unevaluatedProperties: false
> >> +
> >> + properties:
> >> + "#address-cells":
> >> + const: 1
> >> + "#size-cells":
> >> + const: 0
> >> +
> >> + patternProperties:
> >> + "^channel@[0-9a-f]+$":
> >> + type: object
> >> + description: DPLL channel
> >> + unevaluatedProperties: false
> >> +
> >> + properties:
> >> + reg:
> >> + description: Hardware index of the DPLL channel
> >> + maxItems: 1
> >> +
> >> + dpll-type:
> >> + description: DPLL channel type
> >> + $ref: /schemas/types.yaml#/definitions/string
> >> + enum: [pps, eec]
> >> +
> >> + ethernet-handle:
> >> + description:
> >> + Specifies a reference to a node representing an Ethernet device
> >> + that uses this channel to synchronize its hardware clock.
> >> + $ref: /schemas/types.yaml#/definitions/phandle
> >
> > Seems a bit odd to me that the ethernet controller doesn't have a link
> > to this node instead.
>
> 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.?
>
> 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?
> +
> dpll-types:
> description: List of DPLL channel types, one per DPLL instance.
> $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> diff --git a/Documentation/devicetree/bindings/net/network-class.yaml
> b/Documentation/devicetree/bindings/net/network-class.yaml
> index 06461fb92eb84..144badb3b7ff1 100644
> --- a/Documentation/devicetree/bindings/net/network-class.yaml
> +++ b/Documentation/devicetree/bindings/net/network-class.yaml
> @@ -17,6 +17,13 @@ properties:
> default: 48
> const: 48
>
> + dpll:
> + description:
> + Specifies DPLL device phandle and index of the DPLL channel within
> + this device used by this network device to synchronize its hardware
> + clock.
> + $ref: /schemas/types.yaml#/definitions/phandle
If you have cells, then this should be phandle-array.
> +
> local-mac-address:
> description:
> Specifies MAC address that was assigned to the network device
> described by
>
next prev parent reply other threads:[~2025-09-04 22:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-15 14:47 [RFC PATCH net-next] dt-bindings: dpll: Add per-channel Ethernet reference property Ivan Vecera
2025-08-15 23:21 ` Andrew Lunn
2025-08-20 21:13 ` Rob Herring
2025-08-29 13:29 ` Ivan Vecera
2025-09-04 14:43 ` Ivan Vecera
2025-09-04 22:06 ` Rob Herring [this message]
2025-09-05 6:50 ` Ivan Vecera
2025-09-08 22:49 ` Rob Herring
2025-09-09 12:50 ` Ivan Vecera
2025-09-09 13:50 ` Andrew Lunn
2025-09-10 12:51 ` Ivan Vecera
2025-09-16 9:31 ` Jiri Pirko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAL_JsqKui29O_8xGBVx9T2e85Dy0onyAp4mGqChSuuwABOhDqA@mail.gmail.com \
--to=robh@kernel.org \
--cc=Prathosh.Satish@microchip.com \
--cc=andrew@lunn.ch \
--cc=arkadiusz.kubalewski@intel.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=ivecera@redhat.com \
--cc=jiri@resnulli.us \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mschmidt@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=poros@redhat.com \
--cc=vadim.fedorenko@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).