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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 16/01/2025 10:53, Sergio Paracuellos wrote:
> On Thu, Jan 16, 2025 at 10:16 AM Krzysztof Kozlowski <krzk@kernel.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