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