linux-kernel - Re: [PATCH 1/6] dt-bindings: clock: add clock and reset definitions for Ralink SoCs

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] [day] [month] [year] [list]

Message-ID: <bdaee40d-a033-40c6-b96d-d4c73410b7ee@kernel.org>
Date: Sat, 18 Jan 2025 10:11:52 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Sergio Paracuellos <sergio.paracuellos@...il.com>
Cc: linux-clk@...r.kernel.org, sboyd@...nel.org, mturquette@...libre.com,
 tsbogend@...ha.franken.de, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, matthias.bgg@...il.com,
 angelogioacchino.delregno@...labora.com, p.zabel@...gutronix.de,
 linux-mips@...r.kernel.org, devicetree@...r.kernel.org,
 yangshiji66@...look.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/6] dt-bindings: clock: add clock and reset definitions
 for Ralink SoCs

On 16/01/2025 10:53, Sergio Paracuellos wrote:
> On Thu, Jan 16, 2025 at 10:16 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>
>> On 15/01/2025 16:30, Sergio Paracuellos wrote:
>>> Add clock and reset missing definitions for RT2880, RT305X, RT3352, RT3383,
>>> RT5350, MT7620 and MT76X8 Ralink SoCs. Update bindings to clarify clock and
>>> reset cells depending on these new introduced constants so consumer nodes
>>> can easily use the correct one in DTS files.
>>
>> I asked to explain why these should be in the bindings. Usage by DTS
>> alone, if driver does not use them, is not the reason as I explained
>> last time. The reason is that your driver actually depends on these
>> specific numbers because how it is written.
> 
> The driver uses them implicitly since the clock index is registered
> for any single clock and in a specific order matching these new
> constants.

Yes and that explanation should be in commit msg, because that's the
reason for this patch.

> 
>>
>> Or I understood it wrong and this is purely for DTS?
> 
> No is not purely DTS but constants are going to be used from DTS since
> for clocks we are matching already the index registered on clk_hw
> structs (for example here: [0]) and
> for reset the cells indicate the bit within the register so BIT macro
> is used [1] with the stuff passed from consumer nodes.
> 
> So if I understand what you are asking me to say in commit "Update
> bindings to clarify clock and
> reset cells depending on these new introduced constants so consumer nodes
> can easily use the correct one in DTS files matching properly what is
> being used in driver code".

"being used in driver code (clock IDs are implicitly used there)".

> 
> Would this work for you?


Yes, I want to be sure that commit expresses that driver uses these
indices implicitly, not just passing them to the hardware like IRQ
numbers or reg addresses.


Best regards,
Krzysztof