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

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: <e705ec14-cba6-4e86-88c9-c418c15e5c7c@kernel.org>
Date: Fri, 29 Aug 2025 08:54:57 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Mikko Perttunen <mperttunen@...dia.com>,
 Thierry Reding <thierry.reding@...il.com>,
 Thierry Reding <treding@...dia.com>, Jonathan Hunter <jonathanh@...dia.com>,
 Sowjanya Komatineni <skomatineni@...dia.com>,
 Luca Ceresoli <luca.ceresoli@...tlin.com>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Peter De Schrijver <pdeschrijver@...dia.com>,
 Prashant Gaikwad <pgaikwad@...dia.com>,
 Michael Turquette <mturquette@...libre.com>, Stephen Boyd
 <sboyd@...nel.org>, Mauro Carvalho Chehab <mchehab@...nel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Dmitry Osipenko <digetx@...il.com>,
 Charan Pedumuru <charan.pedumuru@...il.com>, Svyatoslav <clamor95@...il.com>
Cc: linux-media@...r.kernel.org, linux-tegra@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
 linux-staging@...ts.linux.dev
Subject: Re: [PATCH v1 02/19] dt-bindings: clock: tegra20: Add IDs for CSI PAD
 clocks

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@...dia.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@...il.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