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: <6937b833-4f3b-46cc-84a6-d259c5dc842a@redhat.com>
Date: Fri, 18 Jul 2025 14:16:41 +0200
From: Ivan Vecera <ivecera@...hat.com>
To: Krzysztof Kozlowski <krzk@...nel.org>, netdev@...r.kernel.org
Cc: 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

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.

Suggestions:
1. Use the dpll-id property in dpll-device with the description:
    "Specifies the unique ID of the DPLL device if it is not retrievable
     from the hardware."
-or-
2. Use microchip,id or microchip,dpll-id with a similar description, as
    this issue is specific to this hardware, which does not provide such
    information.

Thanks for the advice.

Ivan


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ