Re: [PATCH net-next 1/2] dt-bindings: dpll: Add clock ID property

[Ivan Vecera <ivecera@redhat.com>]

On 03. 08. 25 1:12 odp., Krzysztof Kozlowski wrote:
> On 23/07/2025 09:23, Ivan Vecera wrote:
>>
>>
>> On 23. 07. 25 8:25 dop., Krzysztof Kozlowski wrote:
>>> On 21/07/2025 14:54, Ivan Vecera wrote:
>>>> On 21. 07. 25 11:23 dop., Krzysztof Kozlowski wrote:
>>>>> On Fri, Jul 18, 2025 at 02:16:41PM +0200, Ivan Vecera wrote:
>>>>>> Hi Krzysztof,
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> The clock-id property name may have been poorly chosen. This ID is used by
>>>>>> the DPLL subsystem during the registration of a DPLL channel, along with its
>>>>>> channel ID. A driver that provides DPLL functionality can compute this
>>>>>> clock-id from any unique chip information, such as a serial number.
>>>>>>
>>>>>> Currently, other drivers that implement DPLL functionality are network
>>>>>> drivers, and they generate the clock-id from one of their MAC addresses by
>>>>>> extending it to an EUI-64.
>>>>>>
>>>>>> A standalone DPLL device, like the zl3073x, could use a unique property such
>>>>>> as its serial number, but the zl3073x does not have one. This patch-set is
>>>>>> motivated by the need to support such devices by allowing the DPLL device ID
>>>>>> to be passed via the Device Tree (DT), which is similar to how NICs without
>>>>>> an assigned MAC address are handled.
>>>>>
>>>>> You use words like "unique" and MAC, thus I fail to see how one fixed
>>>>> string for all boards matches this. MACs are unique. Property value set
>>>>> in DTS for all devices is not.
>>>>>> You also need to explain who assigns this value (MACs are assigned) or
>>>>> if no one, then why you cannot use random? I also do not see how this
>>>>> property solves this...  One person would set it to value "1", other to
>>>>> "2" but third decide to reuse "1"? How do you solve it for all projects
>>>>> in the upstream?
>>>>
>>>> Some background: Any DPLL driver has to use a unique number during the
>>>> DPLL device/channel registration. The number must be unique for the
>>>> device across a clock domain (e.g., a single PTP network).
>>>>
>>>> NIC drivers that expose DPLL functionality usually use their MAC address
>>>> to generate such a unique ID. A standalone DPLL driver does not have
>>>> this option, as there are no NIC ports and therefore no MAC addresses.
>>>> Such a driver can use any other source for the ID (e.g., the chip's
>>>> serial number). Unfortunately, this is not the case for zl3073x-based
>>>> hardware, as its current firmware revisions do not expose information
>>>> that could be used to generate the clock ID (this may change in the
>>>> future).
>>>>
>>>> There is no authority that assigns clock ID value ranges similarly to
>>>> MAC addresses (OUIs, etc.), but as mentioned above, uniqueness is
>>>> required across a single PTP network so duplicates outside this
>>>> single network are not a problem.
>>>
>>> You did not address main concern. You will configure the same value for
>>> all boards, so how do you solve uniqueness within PTP network?
>>
>> This value differs across boards, similar to the local-mac-address. The
>> device tree specifies the entry, and the bootloader or system firmware
>> (like U-Boot) provides the actual value.
> This should be clearly explained in commit msg or pull request to dtschema.
> 
> Where are patches for U-Boot? lore gives me 0 results.

Hi Krzysztof,

This was just an idea how to provide such information. But...

We had a upstream meeting regarding this issue, how to deal with this
issue in situations where a DPLL device is used to drive a PHC present
in a network controller.

Let's say we have a SyncE setup with two network controllers where each
of them feeds a DPLL channel with recovered clock received from some of
its PHY. The DPLL channel cleans/stabilizes this input signal (generates
phase aligned signal locked to the same frequency as the input one) and
routes it back to the network controller.

     +-----------+
  +--|   NIC 1   |<-+
  |  +-----------+  |
  |                 |
  | RxCLK     TxCLK |
  |                 |
  |  +-----------+  |
  +->| channel 1 |--+
     |-- DPLL ---|
  +->| channel 2 |--+
  |  +-----------+  |
  |                 |
  | RxCLK     TxCLK |
  |                 |
  |  +-----------+  |
  +--|   NIC 2   |<-+
     +-----------+

The PHCs implemented by the NICs have associated the ClockIdentity
(according IEEE 1588-2008) whose value is typically derived from
the NIC's MAC address using EUI-64. The DPLL channel should be
registered to DPLL subsystem using the same ClockIdentity as the PHC
it drives. In above example DPLL channel 1 should have the same clock ID
as NIC1 PHC and channel 2 as NIC2 PHC.

During the discussion, Andrew had the idea to provide NIC phandles
instead of clock ID values.

Something like this:

diff --git a/Documentation/devicetree/bindings/dpll/dpll-device.yaml 
b/Documenta
tion/devicetree/bindings/dpll/dpll-device.yaml
index fb8d7a9a3693f..159d9253bc8ae 100644
--- a/Documentation/devicetree/bindings/dpll/dpll-device.yaml
+++ b/Documentation/devicetree/bindings/dpll/dpll-device.yaml
@@ -33,6 +33,13 @@ properties:
      items:
        enum: [pps, eec]

+  ethernet-handles:
+    description:
+      List of phandles to Ethernet devices, one per DPLL instance. Each of
+      these handles identifies Ethernet device that uses particular DPLL
+      instance to synchronize its hardware clock.
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+
    input-pins:
      type: object
      description: DPLL input pins

A DPLL driver can then use this property to identify a network
controller, use fwnode_get_mac_address() to get assigned MAC address and
generate the ClockIdentity for registration from this MAC.

WDYT about it?

Thanks,
Ivan