linux-kernel - Re: [PATCH net-next 1/2] dt-bindings: dpll: Add clock ID 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: <20250721-lean-strong-sponge-7ab0be@kuoka>
Date: Mon, 21 Jul 2025 11:23:31 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Ivan Vecera <ivecera@...hat.com>
Cc: netdev@...r.kernel.org, Vadim Fedorenko <vadim.fedorenko@...ux.dev>, 
	Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>, Jiri Pirko <jiri@...nulli.us>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Prathosh Satish <Prathosh.Satish@...rochip.com>, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Michal Schmidt <mschmidt@...hat.com>, Petr Oros <poros@...hat.com>
Subject: Re: [PATCH net-next 1/2] dt-bindings: dpll: Add clock ID property

On Fri, Jul 18, 2025 at 02:16:41PM +0200, Ivan Vecera wrote:
> Hi Krzysztof,
> 
> On 18. 07. 25 8:55 dop., Krzysztof Kozlowski wrote:
> > On 17/07/2025 19:10, Ivan Vecera wrote:
> > > Add property to specify the ID of the clock that the DPLL device
> > > drives. The ID value represents Unique Clock Identified (EUI-64)
> > > defined by IEEE 1588 standard.
> > 
> > With the exception of clock-output-names and gpio-hogs, we do not define
> > how the output looks like in the provider bindings.
> > 
> > I also don't understand how this maps to channels and what "device
> > drives a clock" means. Plus how this is not deducible from the compatible...
> 
> 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?

All this must be clearly explained when you add new, generic property.

Best regards,
Krzysztof