From: Hans de Goede <hansg@kernel.org>
To: Brian Masney <bmasney@redhat.com>,
Abel Vesa <abel.vesa@oss.qualcomm.com>
Cc: Maxime Ripard <mripard@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>, Abel Vesa <abelvesa@kernel.org>,
Saravana Kannan <saravanak@kernel.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-clk@vger.kernel.org
Subject: Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks
Date: Tue, 17 Mar 2026 16:14:59 +0100 [thread overview]
Message-ID: <24801cf0-2c68-4b8c-b35f-b95e9688fcf5@kernel.org> (raw)
In-Reply-To: <ablslaSoUraCRPKl@redhat.com>
Hi,
On 17-Mar-26 16:00, Brian Masney wrote:
> On Tue, Mar 17, 2026 at 04:20:06PM +0200, Abel Vesa wrote:
>> On 26-03-17 10:13:08, Brian Masney wrote:
>>> FWIW, the only reason I posted this patch is because at the end of
>>> Stephen's LPC talk I got the impression that this was also an acceptable
>>> change. I'm fine with dropping this change.
>>
>> Here is the scenario that proves adding such config isn't the right
>> solution: think of single kernel image working with different SoCs from
>> different vendors. This is actually the case where distros need to have
>> a way to provide one kernel image + thousands of DTBs and be able to
>> boot one each one of the boards. Whatever this config is set to in the
>> kernel image, it will not work with all platforms.
>
> Agreed.
>
> However, with or without this new Kconfig, we have this problem today.
> Right now the kernel isn't bootable on large numbers of systems, and
> people have to manually add clk_ignore_unused.
>
> I agree though that we don't want to penalize boards that are doing
> things right, and have a full clock tree described with higher power
> draw.
>
> As a test, on my Thinkpad x13s (sc8280xp) clk_disable_unused on Fedora
> 43 turns off 96 clocks on this laptop! I can infer what some of the
> clocks do based on their names, however I'm not in Qualcomm, and some
> of these clocks I'm not entire sure which ones would need
> CLK_IGNORE_UNUSED. I got it down to a set of 7 possible clocks that
> may need that flag by excluding some classes of clocks, such as usb.
My plan for the T14s is to:
1) Make sure I've working debug output in some form at this point
of the boot, since lately the screen seems to go black during boot
until the msm driver loads. Something which I / we really need to
get to the bottom too.
2) Add printk-s of the clock name before disabling the clock,
then sleep 10s then disable clock and move on to the next 1.
So the last clock you see printed before things go sideways will
then need a CLK_IGNORE_UNUSED.
At least that is my naive plan for when I can make some time for
this.
Regards,
Hans
next prev parent reply other threads:[~2026-03-17 15:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-16 22:33 [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks Brian Masney
2026-03-17 7:30 ` Maxime Ripard
2026-03-17 11:53 ` Hans de Goede
2026-03-17 12:20 ` Brian Masney
2026-03-17 13:32 ` Maxime Ripard
2026-03-17 13:51 ` Abel Vesa
2026-03-17 14:02 ` Hans de Goede
2026-03-17 12:14 ` Abel Vesa
2026-03-17 12:16 ` Hans de Goede
2026-03-17 12:26 ` Brian Masney
2026-03-17 13:03 ` Abel Vesa
2026-03-17 13:18 ` Maxime Ripard
2026-03-17 13:22 ` Abel Vesa
2026-03-17 12:57 ` Abel Vesa
2026-03-17 13:15 ` Maxime Ripard
2026-03-17 13:21 ` Abel Vesa
2026-03-17 13:40 ` Maxime Ripard
2026-03-17 14:13 ` Brian Masney
2026-03-17 14:20 ` Abel Vesa
2026-03-17 15:00 ` Brian Masney
2026-03-17 15:14 ` Hans de Goede [this message]
2026-03-19 5:40 ` Jagadeesh Kona
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=24801cf0-2c68-4b8c-b35f-b95e9688fcf5@kernel.org \
--to=hansg@kernel.org \
--cc=abel.vesa@oss.qualcomm.com \
--cc=abelvesa@kernel.org \
--cc=bmasney@redhat.com \
--cc=corbet@lwn.net \
--cc=linux-clk@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mripard@kernel.org \
--cc=mturquette@baylibre.com \
--cc=saravanak@kernel.org \
--cc=sboyd@kernel.org \
--cc=skhan@linuxfoundation.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