[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aD5CXNy5Qtbe5cOb@x1>
Date: Mon, 2 Jun 2025 20:31:24 -0400
From: Brian Masney <bmasney@...hat.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Stephen Boyd <sboyd@...nel.org>,
Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
Florian Fainelli <florian.fainelli@...adcom.com>,
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>
Subject: Re: [PATCH] clk: Warn (and therefore taint the kernel) on
clk_ignore_unused
On Thu, May 22, 2025 at 09:47:35PM +0200, Konrad Dybcio wrote:
> On 3/4/25 8:34 PM, Stephen Boyd wrote:
> > 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
In addition to clk_ignore_unused, there's also regulator_ignore_unused
and pd_ignore_unused that should also be considered.
>From a power-management perspective, a userspace tool like powertop will
warn about various things that could be improved. For example, on my
Thinkpad x13s laptop, one of the warnings given is:
Bad Runtime PM for PCI Device Qualcomm Technologies,
Inc QCNFA765 Wireless Network Adapter
I think it would be useful to add a check to powertop for the presence
of any of these three kernel parameters.
I know that power management isn't the only reason for the original
patch, and this won't cover the case to give some kind of warning where
the various core parts of the system controlled by Linux are not
described in device tree, and the system is relying on a resource setup
by the bootloader.
Brian
Powered by blists - more mailing lists