[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <16fd590e-7a00-4e71-a003-d6aafa83567d@oss.qualcomm.com>
Date: Thu, 22 May 2025 21:47:35 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Stephen Boyd <sboyd@...nel.org>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Florian Fainelli <florian.fainelli@...adcom.com>
Cc: Konrad Dybcio <konradybcio@...nel.org>,
Michael Turquette <mturquette@...libre.com>,
Marijn Suijten <marijn.suijten@...ainline.org>,
linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
Bjorn Andersson <bjorn.andersson@....qualcomm.com>,
Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Subject: Re: [PATCH] clk: Warn (and therefore taint the kernel) on
clk_ignore_unused
On 3/4/25 8:34 PM, Stephen Boyd wrote:
> Quoting Dmitry Baryshkov (2025-03-03 15:17:21)
>> On Tue, 4 Mar 2025 at 00:16, Florian Fainelli
>> <florian.fainelli@...adcom.com> wrote:
>>>
>>> On 3/3/25 14:48, Stephen Boyd wrote:
>>>> Quoting Konrad Dybcio (2025-02-01 08:52:30)
> [...]
>>>>>
>>>>> The clock subsystem plays a crucial part in this quest, as even if
>>>>> the clock controllers themselves don't draw a lot of power when on
>>>>> (comparatively), improper description of clock requirements has been
>>>>> the #1 cause of incomplete/incorrect devicetree bindings in my
>>>>> experience.
>>>>
>>>> What is a user supposed to do about this warning stack? We already print
>>>> a warning. I don't see us dumping the stack when a driver is unfinished
>>>> and doesn't implement runtime PM to save power.
>>>>
>>>
>>> Agreed, I don't think this is tremendously helpful given that it does
>>> not even tell you what part is incomplete, it's just a broad warning for
>>> the entire system.
>>>
>>> Assuming you have a clock provided that can be used to turn clocks off,
>>> and you did not boot with 'clk_ignore_unused' set on the kernel command
>>> line, then you should discover pretty quickly which driver is not
>>> managing the clocks as it should no?
>>
>> Unfortunately it's sometimes not that easy. And some developers
>> pretend that 'clk_ignore_unused' is a viable way to run the system.
>>
>
> Maybe we would be better off with a config option that removes the clk
> ignore unused ability entirely. Then you can have a kernel config check
> somewhere in the build process that verifies that a user can't even set
> the kernel commandline to change the behavior.
I used WARN specifically to taint the kernel (which would in turn throw off
any reasonable CI checks). Perhaps we could add a Kconfig entry (unless
there already is one) that would do the same, and clk_ignore_unused could
be gated behind it.
But then, it would make it harder to debug production kernels with that
parameter, which could potentially come in handy too
Konrad
Powered by blists - more mailing lists