From: Brian Masney <bmasney@redhat.com>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: Stephen Boyd <sboyd@kernel.org>,
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
Florian Fainelli <florian.fainelli@broadcom.com>,
Konrad Dybcio <konradybcio@kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
Marijn Suijten <marijn.suijten@somainline.org>,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Subject: Re: [PATCH] clk: Warn (and therefore taint the kernel) on clk_ignore_unused
Date: Mon, 2 Jun 2025 20:31:24 -0400 [thread overview]
Message-ID: <aD5CXNy5Qtbe5cOb@x1> (raw)
In-Reply-To: <16fd590e-7a00-4e71-a003-d6aafa83567d@oss.qualcomm.com>
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
next prev parent reply other threads:[~2025-06-03 0:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-01 16:52 [PATCH] clk: Warn (and therefore taint the kernel) on clk_ignore_unused Konrad Dybcio
2025-03-03 22:48 ` Stephen Boyd
2025-03-03 23:16 ` Florian Fainelli
2025-03-03 23:17 ` Dmitry Baryshkov
2025-03-04 19:34 ` Stephen Boyd
2025-05-22 19:47 ` Konrad Dybcio
2025-06-03 0:31 ` Brian Masney [this message]
2025-06-03 1:20 ` Bjorn Andersson
2025-06-03 1:23 ` Bjorn Andersson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aD5CXNy5Qtbe5cOb@x1 \
--to=bmasney@redhat.com \
--cc=bjorn.andersson@oss.qualcomm.com \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=florian.fainelli@broadcom.com \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=mturquette@baylibre.com \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).