[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <25d6b64c-41b6-4431-870c-0b26d0cc4d03@kernel.org>
Date: Wed, 22 Oct 2025 07:45:49 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Peter Griffin <peter.griffin@...aro.org>,
Krzysztof Kozlowski <krzk@...nel.org>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Alim Akhtar <alim.akhtar@...sung.com>,
André Draszik <andre.draszik@...aro.org>,
Tudor Ambarus <tudor.ambarus@...aro.org>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd
<sboyd@...nel.org>, Sam Protsenko <semen.protsenko@...aro.org>,
Sylwester Nawrocki <s.nawrocki@...sung.com>,
Chanwoo Choi <cw00.choi@...sung.com>, Will McVicker
<willmcvicker@...gle.com>, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-samsung-soc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
kernel-team@...roid.com
Subject: Re: [PATCH 8/9] clk: samsung: gs101: Enable auto_clock_gate mode for
each gs101 CMU
On 21/10/2025 23:03, Peter Griffin wrote:
>>> +}
>>> +
>>> static void __init gs101_cmu_misc_init(struct device_node *np)
>>> {
>>> + if (check_cmu_res_size(np))
>>> + return;
>>
>> You will not register CMU on old DTB.
>
> By "compatible" I meant the driver detects an old DTB with an
> incorrect reg size and issues an error message on the console to
> update your DT (as opposed to crashing trying to access a register
> that hasn't been mapped).
That's not being compatible. You should not break anything here if size
is smaller - just fallback to previous manual mode.
>
> Is it enough to re-word the commit message to make it clearer what will happen?
>
> An alternative might be to try registering all the gates in manual
> mode, but that seems like it would add more complexity for not much
> benefit. It would also require that clk_ignore_unused kernel parameter
> to have been passed (as manual clock mode has never worked without it)
> and whilst it might boot today I imagine it would bitrot fast as
> additional CMUs are added (and thus probably crash in a much more
> obscure way).
>
> Peter
Best regards,
Krzysztof
Powered by blists - more mailing lists