linux-kernel - Re: [PATCH net-next 03/12] dpll: Add helpers to find DPLL pin fwnode

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: <fcc35747-81f3-4a3a-8b5d-cf29e9c52bb2@kernel.org>
Date: Mon, 12 Jan 2026 17:20:40 +0100
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>,
 Tony Nguyen <anthony.l.nguyen@...el.com>,
 Przemek Kitszel <przemyslaw.kitszel@...el.com>,
 Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Saeed Mahameed <saeedm@...dia.com>, Leon Romanovsky <leon@...nel.org>,
 Tariq Toukan <tariqt@...dia.com>, Mark Bloch <mbloch@...dia.com>,
 Jonathan Lemon <jonathan.lemon@...il.com>,
 Richard Cochran <richardcochran@...il.com>,
 Alexander Lobakin <aleksander.lobakin@...el.com>,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 intel-wired-lan@...ts.osuosl.org, linux-rdma@...r.kernel.org,
 Michal Schmidt <mschmidt@...hat.com>, Petr Oros <poros@...hat.com>,
 Grzegorz Nitka <grzegorz.nitka@...el.com>
Subject: Re: [PATCH net-next 03/12] dpll: Add helpers to find DPLL pin fwnode

On 09/01/2026 15:19, Ivan Vecera wrote:
> 
> 
> On 1/9/26 10:55 AM, Krzysztof Kozlowski wrote:
>> On Thu, Jan 08, 2026 at 07:23:09PM +0100, Ivan Vecera wrote:
>>> Add helper functions to the DPLL core to retrieve a DPLL pin's firmware
>>> node handle based on the "dpll-pins" and "dpll-pin-names" properties.
>>>
>>> * `fwnode_dpll_pin_node_get()`: matches the given name against the
>>>    "dpll-pin-names" property to find the correct index, then retrieves
>>>    the reference from "dpll-pins".
>>> * `device_dpll_pin_node_get()`: a wrapper around the fwnode helper for
>>>    convenience when using a `struct device`.
>>>
>>> These helpers simplify the process for consumer drivers (such as Ethernet
>>> controllers or PHYs) to look up their associated DPLL pins defined in
>>> the DT or ACPI, which can then be passed to the DPLL subsystem to acquire
>>> the pin object.
>>>
>>> Signed-off-by: Ivan Vecera <ivecera@...hat.com>
>>> ---
>>>   drivers/dpll/dpll_core.c | 20 ++++++++++++++++++++
>>>   include/linux/dpll.h     | 15 +++++++++++++++
>>>   2 files changed, 35 insertions(+)
>>>
>>
>> I don't see cells defined in your binding. Neither updated property.c.
> 
> And if the cells are not required? I mean that dpll-names only specifies
> array of phandles without parameters...
> 
> e.g.
> dpll-pin-names = "abc", "def";
> dpll-pins = <&dpll_pin_abc>, <&dpll_pin_def>;
> 
> Should '#dpll-pin-cells' be defined as constantly equal to 0?

I don't understand how can you guarantee for every possible future
device to have always cells=0. If that's the case then indeed you do not
need cells, but this needs explanation. You are designing now entire
ABI, so you must design it fully, not just "works for me now".

Lack of complete DTS - nothing here, nothing in the changelog - is IMO
reason to NAK this patchset completely, also for reason me guessing the
entire design instead of seeing the big picture.

Best regards,
Krzysztof