Re: [PATCH v1 02/19] dt-bindings: clock: tegra20: Add IDs for CSI PAD clocks

[Krzysztof Kozlowski <krzk@kernel.org>]

On 27/08/2025 12:27, Mikko Perttunen wrote:
> On Wednesday, August 27, 2025 1:28 PM Svyatoslav wrote:
>> 27 серпня 2025 р. 07:19:39 GMT+03:00, Mikko Perttunen 
> <mperttunen@nvidia.com> пише:
>>> On Tuesday, August 19, 2025 9:16 PM Svyatoslav Ryhel wrote:
>>>> Tegra30 has CSI PAD clock enable bits embedded into PLLD/PLLD2 registers.
>>>> Add ids for these clocks.
>>>>
>>>> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>>>> ---
>>>>
>>>>  include/dt-bindings/clock/tegra30-car.h | 4 +++-
>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/include/dt-bindings/clock/tegra30-car.h
>>>> b/include/dt-bindings/clock/tegra30-car.h index
>>>> f193663e6f28..14b83e90a0fc
>>>> 100644
>>>> --- a/include/dt-bindings/clock/tegra30-car.h
>>>> +++ b/include/dt-bindings/clock/tegra30-car.h
>>>> @@ -271,6 +271,8 @@
>>>>
>>>>  #define TEGRA30_CLK_AUDIO3_MUX 306
>>>>  #define TEGRA30_CLK_AUDIO4_MUX 307
>>>>  #define TEGRA30_CLK_SPDIF_MUX 308
>>>>
>>>> -#define TEGRA30_CLK_CLK_MAX 309
>>>> +#define TEGRA30_CLK_CSIA_PAD 309
>>>> +#define TEGRA30_CLK_CSIB_PAD 310
>>>> +#define TEGRA30_CLK_CLK_MAX 311
>>>>
>>>>  #endif	/* _DT_BINDINGS_CLOCK_TEGRA30_CAR_H */
>>>
>>> The commit message refers to tegra20, but contents are tegra30.
>>
>> My, bad, it should be tegra30
>>
>>> Regarding the CLK_MAX define, I agree that it would be better to get rid of
>>> it. Perhaps you can check if it would be reasonable to calculate it
>>> dynamically in the driver, but a define and sanity check in the driver
>>> would work too, I think.
>>
>> It is not unreasonable, but moving this elsewhere may cause issues with
>> adding new clocks. Addind new clocks would require updating not only header

No, there are no such issues.

>> but also a place where max clocks are moved to and ai am not sure how can I
>> dinamically calculate amount of clocks in the driver without updating both
>> header and driver with each new clock added. Maybe you can propose a
>> method?
> 
> Looking at the code, it's probably better to just move the CLK_MAX define into 

Just like every other driver.

> the source code. We can leave a comment here as reminder to update the define 
> in the code if any new clocks are added. This happens so rarely that I don't 
> think it should be a problem.
No, don't leave comments here. There is no single risk of breakage,
there is no issue to fix with that comment.

If you add clock to the driver WITHOUT binding, nothing, absolutely
nothing bad will happen. You will just not have a way to use that clock
in DTS.

Best regards,
Krzysztof