[PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Brian Masney]

At the 2023 Linux Plumbers Conference in Richmond VA, there was a
discussion about how large number of systems need to boot with
clk_ignore_unused. Per the discussions at the conference, the existing
behavior in the clk core is broken, and there is a desire to completely
remove this functionality.

This series introduces a new Kconfig called
CONFIG_COMMON_CLK_DISABLE_UNUSED that when set has the existing
behavior as clk_ignore_unused so that people no longer have to specify
this parameter on the kernel command line. This Kconfig is disabled by
default to keep compatibility with existing systems. A kernel that was
compiled with this Kconfig enabled can have the clk subsystem disable
the unused clocks by passing clk_ignore_unused=0 on the kernel command
line.

Note: The existing clk code calls __setup("clk_ignore_unused", ...)
without the equals in the name. So someone can actually pass a kernel
parameter today clk_ignore_unused_foo that'll also match the existing
parameter. We can't change the existing behavior, so we need to look
for the equals sign in the value.

Link: https://lpc.events/event/17/contributions/1432/
Link: https://www.youtube.com/watch?v=tXYzM8yLIQA
Signed-off-by: Brian Masney <bmasney@redhat.com>
---
I searched the mailinglist archive, and couldn't find where anyone
submitted something like this after LPC 2023. This was the last
suggestion discussed on the LPC talk, and it sounds like around 14:40
that this is an acceptable change.

I looked at adding some Kunit tests for this to clk_test.c. I planned to
export clk_ignore_unused_setup() for Kunit testing, however that will
require putting "=0" instead of just "0" in the tests. This won't match
the behavior on the kernel command line. See comment in the code about
the equals.
---
 Documentation/admin-guide/kernel-parameters.txt |  9 +++++++++
 Documentation/driver-api/clk.rst                |  7 +++++++
 drivers/clk/Kconfig                             | 16 ++++++++++++++++
 drivers/clk/clk.c                               | 17 ++++++++++++++---
 4 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index fa6171b5fdd5ff55b3203272568509bb45c69856..d559c387ca32425c0a3776bec899f48a21ed3026 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -830,6 +830,15 @@ Kernel parameters
 			platform with proper driver support.  For more
 			information, see Documentation/driver-api/clk.rst.
 
+	clk_ignore_unused=0
+			[CLK]
+			Force the clock framework to automatically gate unused
+			clocks at late init, even if CONFIG_COMMON_CLK_DISABLE_UNUSED
+			is enabled. This overrides the compile-time configuration
+			to re-enable power saving by disabling unused clocks.
+
+			For more information, see Documentation/driver-api/clk.rst.
+
 	clock=		[BUGS=X86-32, HW] gettimeofday clocksource override.
 			[Deprecated]
 			Forces specified clocksource (if available) to be used
diff --git a/Documentation/driver-api/clk.rst b/Documentation/driver-api/clk.rst
index 93bab5336dfda06069eea700d2830089bf3bce03..31ce4e3889f09a4f9c3b63cad7ded214125702f7 100644
--- a/Documentation/driver-api/clk.rst
+++ b/Documentation/driver-api/clk.rst
@@ -266,6 +266,13 @@ parameters::
 To bypass this disabling, include "clk_ignore_unused" in the bootargs to the
 kernel.
 
+Alternatively, you can enable CONFIG_COMMON_CLK_DISABLE_UNUSED at compile time
+to prevent the automatic disabling of unused clocks by default. When this
+option is enabled, unused clocks will remain enabled unless you explicitly
+force their disabling by passing "clk_ignore_unused=0" on the kernel command
+line. This can be useful for platforms that require certain clocks to remain
+enabled for proper operation, or for debugging purposes.
+
 Locking
 =======
 
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 8cc300b90b5fd9fb38ce94fcb1098810c3f52c36..d7503517f6ec1ed773b2dcb9e3a7a0b5bcdea353 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -33,6 +33,22 @@ menuconfig COMMON_CLK
 
 if COMMON_CLK
 
+config COMMON_CLK_DISABLE_UNUSED
+	bool "Do not automatically disable unused clocks"
+	help
+	  Say Y here if you want to prevent the clock framework from
+	  automatically disabling unused clocks at late initialization time.
+	  This keeps clocks running even if no driver is using them, which
+	  may be necessary for certain hardware configurations or debugging.
+
+	  By default (N), the kernel will automatically disable unused clocks
+	  to save power.
+
+	  This behavior can be overridden at boot time on the kernel command
+	  line with the parameter clk_ignore_unused.
+
+	  If unsure, say N.
+
 config COMMON_CLK_WM831X
 	tristate "Clock driver for WM831x/2x PMICs"
 	depends on MFD_WM831X
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 47093cda9df32223c1120c3710261296027c4cd3..4afbf011de6f1727a2bf330465c95407e51d04ad 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1508,10 +1508,21 @@ static void __init clk_disable_unused_subtree(struct clk_core *core)
 		clk_core_disable_unprepare(core->parent);
 }
 
-static bool clk_ignore_unused __initdata;
-static int __init clk_ignore_unused_setup(char *__unused)
+static bool clk_ignore_unused __initdata = IS_ENABLED(CONFIG_COMMON_CLK_DISABLE_UNUSED);
+static int __init clk_ignore_unused_setup(char *str)
 {
-	clk_ignore_unused = true;
+	if (!str) {
+		clk_ignore_unused = true;
+	} else {
+		/*
+		 * Typically the equals is added to the __setup below, however we
+		 * need to be able to support clk_ignore_unused without an equals
+		 * since tons of systems just pass clk_ignore_unused. So look for
+		 * the equals here.
+		 */
+		clk_ignore_unused = strcmp(str, "=0") != 0;
+	}
+
 	return 1;
 }
 __setup("clk_ignore_unused", clk_ignore_unused_setup);

---
base-commit: 95c541ddfb0815a0ea8477af778bb13bb075079a
change-id: 20260316-clk-ignore-unused-kconfig-7e77eb5b8306

Best regards,
-- 
Brian Masney <bmasney@redhat.com>

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

Hi,

On Mon, Mar 16, 2026 at 06:33:45PM -0400, Brian Masney wrote:
> At the 2023 Linux Plumbers Conference in Richmond VA, there was a
> discussion about how large number of systems need to boot with
> clk_ignore_unused. Per the discussions at the conference, the existing
> behavior in the clk core is broken, and there is a desire to completely
> remove this functionality.

Broken how?

clk_ignore_unused is to a point where it's seriously cargo-culted and
documented as a silver bullet, when in reality it's just a debug tool
for broken drivers, and the driver must be fixed.

But nobody is actually fixing it.

See
https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems#How_To_Test
for example. The affected clock could be marked as CLK_IS_CRITICAL, and
fedora wouldn't have to package anything, change anything, etc. But no,
the problem is clk_ignore_unused.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Hans de Goede]

Hi Maxime,

On 17-Mar-26 08:30, Maxime Ripard wrote:
> Hi,
> 
> On Mon, Mar 16, 2026 at 06:33:45PM -0400, Brian Masney wrote:
>> At the 2023 Linux Plumbers Conference in Richmond VA, there was a
>> discussion about how large number of systems need to boot with
>> clk_ignore_unused. Per the discussions at the conference, the existing
>> behavior in the clk core is broken, and there is a desire to completely
>> remove this functionality.
> 
> Broken how?
> 
> clk_ignore_unused is to a point where it's seriously cargo-culted and
> documented as a silver bullet, when in reality it's just a debug tool
> for broken drivers, and the driver must be fixed.
> 
> But nobody is actually fixing it.
> 
> See
> https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems#How_To_Test
> for example. The affected clock could be marked as CLK_IS_CRITICAL, and
> fedora wouldn't have to package anything, change anything, etc. But no,
> the problem is clk_ignore_unused.

Both things can be true at the same time. Yes there are ways to work
around issues causes by clk_ignore_unused and those ways should be
used more often. And in example of the X1E laptops I do indeed want
to try and figure out which clocks must not be turned off and
try to see if it will be accepted to mark these as CLK_IS_CRITICAL.

But at the same time the fundamental concept of turning off all unused
clocks as soon as all *builtin* drivers are done probing is a broken
concept when working with generic distro kernels where many drivers
are modules. To me it looks like this was very much made with
embedded systems with device specific kernels where all drivers for
the used SoC are builtin.

The problem basically is, that if we want something like disabling
unused clocks at all (1), it should happen when all drivers including
those build as module have had a chance to run. ATM the clocks
simply get turned off too soon.

Also see Stephen Boyd's LPC talk about this:

"Make sync_state()/handoff work for the common clk framework"
https://lpc.events/event/17/contributions/1432/

When the clk framework maintainer themselves are arguing for
replacing the way unused clks are disabled atm with something
better then to me that is a clear sign that there is something
wrong with the current mechanism.

Arguably it would be better to tie this into the deferred_probe_timeout
mechanism with some way for subsystems to register callbacks for
when the deferred_probe_timeout triggers. This way there will at
least be some attempt by the kernel to delay it until all probing
is done.

Even though we do really have a problem here I'm not convinced
that this patch, which allows disabling the entire mechanism
by default, is a good idea though. There will likely be issues
with systems consuming more power then they should, especially
when suspended when unused clocks are not disabled. So allowing
to change the default behavior will just swap one set of problems
for another.

Regards,

Hans



1) One can also argue that the need to do this at all is broken in
itself. If all clks have a consumer driver they will get turned off
anyways; and if they lack a consumer driver then maybe they should
have never turned on by the bootloader in the first place. I would
expect any hw critical enough for the bootloader to also have an
actual Linux driver.


> 
> Maxime

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Brian Masney]

On Tue, Mar 17, 2026 at 12:53:10PM +0100, Hans de Goede wrote:
> On 17-Mar-26 08:30, Maxime Ripard wrote:
> > On Mon, Mar 16, 2026 at 06:33:45PM -0400, Brian Masney wrote:
> >> At the 2023 Linux Plumbers Conference in Richmond VA, there was a
> >> discussion about how large number of systems need to boot with
> >> clk_ignore_unused. Per the discussions at the conference, the existing
> >> behavior in the clk core is broken, and there is a desire to completely
> >> remove this functionality.
> > 
> > Broken how?

One of the problems that I am aware of is that clk_disable_unused() runs
in late_initcall_sync(), and the intention was for it to run after all
of the deferred probing happens, however, it actually runs in parallel
with async and deferred probing. So there's a race between these
actions.

> > clk_ignore_unused is to a point where it's seriously cargo-culted and
> > documented as a silver bullet, when in reality it's just a debug tool
> > for broken drivers, and the driver must be fixed.
> > 
> > But nobody is actually fixing it.
> > 
> > See
> > https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems#How_To_Test
> > for example. The affected clock could be marked as CLK_IS_CRITICAL, and
> > fedora wouldn't have to package anything, change anything, etc. But no,
> > the problem is clk_ignore_unused.
> 
> Both things can be true at the same time. Yes there are ways to work
> around issues causes by clk_ignore_unused and those ways should be
> used more often. And in example of the X1E laptops I do indeed want
> to try and figure out which clocks must not be turned off and
> try to see if it will be accepted to mark these as CLK_IS_CRITICAL.
> 
> But at the same time the fundamental concept of turning off all unused
> clocks as soon as all *builtin* drivers are done probing is a broken
> concept when working with generic distro kernels where many drivers
> are modules. To me it looks like this was very much made with
> embedded systems with device specific kernels where all drivers for
> the used SoC are builtin.
> 
> The problem basically is, that if we want something like disabling
> unused clocks at all (1), it should happen when all drivers including
> those build as module have had a chance to run. ATM the clocks
> simply get turned off too soon.
> 
> Also see Stephen Boyd's LPC talk about this:
> 
> "Make sync_state()/handoff work for the common clk framework"
> https://lpc.events/event/17/contributions/1432/
> 
> When the clk framework maintainer themselves are arguing for
> replacing the way unused clks are disabled atm with something
> better then to me that is a clear sign that there is something
> wrong with the current mechanism.
> 
> Arguably it would be better to tie this into the deferred_probe_timeout
> mechanism with some way for subsystems to register callbacks for
> when the deferred_probe_timeout triggers. This way there will at
> least be some attempt by the kernel to delay it until all probing
> is done.

One of the things to fix is that not all clks have a struct device
since some need to be initialized early. See of_clk_hw_register().

Brian

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3937 bytes --]

On Tue, Mar 17, 2026 at 12:53:10PM +0100, Hans de Goede wrote:
> Hi Maxime,
> 
> On 17-Mar-26 08:30, Maxime Ripard wrote:
> > Hi,
> > 
> > On Mon, Mar 16, 2026 at 06:33:45PM -0400, Brian Masney wrote:
> >> At the 2023 Linux Plumbers Conference in Richmond VA, there was a
> >> discussion about how large number of systems need to boot with
> >> clk_ignore_unused. Per the discussions at the conference, the existing
> >> behavior in the clk core is broken, and there is a desire to completely
> >> remove this functionality.
> > 
> > Broken how?
> > 
> > clk_ignore_unused is to a point where it's seriously cargo-culted and
> > documented as a silver bullet, when in reality it's just a debug tool
> > for broken drivers, and the driver must be fixed.
> > 
> > But nobody is actually fixing it.
> > 
> > See
> > https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems#How_To_Test
> > for example. The affected clock could be marked as CLK_IS_CRITICAL, and
> > fedora wouldn't have to package anything, change anything, etc. But no,
> > the problem is clk_ignore_unused.
> 
> Both things can be true at the same time. Yes there are ways to work
> around issues causes by clk_ignore_unused and those ways should be
> used more often. And in example of the X1E laptops I do indeed want
> to try and figure out which clocks must not be turned off and
> try to see if it will be accepted to mark these as CLK_IS_CRITICAL.
> 
> But at the same time the fundamental concept of turning off all unused
> clocks as soon as all *builtin* drivers are done probing is a broken
> concept when working with generic distro kernels where many drivers
> are modules. To me it looks like this was very much made with
> embedded systems with device specific kernels where all drivers for
> the used SoC are builtin.

It's not about embedded systems, it's about shitty, inconsistent,
closed-source bootloaders. If bootloaders weren't enabling far more than
they require and / or if we could fix them when they do, we wouldn't
have more clocks enabled than we need to.

Removing clk_ignore_unused will just make end users pissed off because
of the higher power draw.

> The problem basically is, that if we want something like disabling
> unused clocks at all (1), it should happen when all drivers including
> those build as module have had a chance to run. ATM the clocks
> simply get turned off too soon.
> 
> Also see Stephen Boyd's LPC talk about this:
> 
> "Make sync_state()/handoff work for the common clk framework"
> https://lpc.events/event/17/contributions/1432/
> 
> When the clk framework maintainer themselves are arguing for
> replacing the way unused clks are disabled atm with something
> better then to me that is a clear sign that there is something
> wrong with the current mechanism.

I have no problem with *replacing* it with something better. I looked at
that talk already, tried to make sync_state work already and suggested
it to Brian too. So I'm not saying it shouldn't replaced.

What I have a problem with is removing it with no viable alternative in
sight.

> Arguably it would be better to tie this into the deferred_probe_timeout
> mechanism with some way for subsystems to register callbacks for
> when the deferred_probe_timeout triggers. This way there will at
> least be some attempt by the kernel to delay it until all probing
> is done.
> 
> Even though we do really have a problem here I'm not convinced
> that this patch, which allows disabling the entire mechanism
> by default, is a good idea though. There will likely be issues
> with systems consuming more power then they should, especially
> when suspended when unused clocks are not disabled. So allowing
> to change the default behavior will just swap one set of problems
> for another.

I'm glad we're in violent agreement then :)

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Abel Vesa]

On 26-03-17 14:32:47, Maxime Ripard wrote:
> On Tue, Mar 17, 2026 at 12:53:10PM +0100, Hans de Goede wrote:
> > Hi Maxime,
> > 
> > On 17-Mar-26 08:30, Maxime Ripard wrote:
> > > Hi,
> > > 
> > > On Mon, Mar 16, 2026 at 06:33:45PM -0400, Brian Masney wrote:
> > >> At the 2023 Linux Plumbers Conference in Richmond VA, there was a
> > >> discussion about how large number of systems need to boot with
> > >> clk_ignore_unused. Per the discussions at the conference, the existing
> > >> behavior in the clk core is broken, and there is a desire to completely
> > >> remove this functionality.
> > > 
> > > Broken how?
> > > 
> > > clk_ignore_unused is to a point where it's seriously cargo-culted and
> > > documented as a silver bullet, when in reality it's just a debug tool
> > > for broken drivers, and the driver must be fixed.
> > > 
> > > But nobody is actually fixing it.
> > > 
> > > See
> > > https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems#How_To_Test
> > > for example. The affected clock could be marked as CLK_IS_CRITICAL, and
> > > fedora wouldn't have to package anything, change anything, etc. But no,
> > > the problem is clk_ignore_unused.
> > 
> > Both things can be true at the same time. Yes there are ways to work
> > around issues causes by clk_ignore_unused and those ways should be
> > used more often. And in example of the X1E laptops I do indeed want
> > to try and figure out which clocks must not be turned off and
> > try to see if it will be accepted to mark these as CLK_IS_CRITICAL.
> > 
> > But at the same time the fundamental concept of turning off all unused
> > clocks as soon as all *builtin* drivers are done probing is a broken
> > concept when working with generic distro kernels where many drivers
> > are modules. To me it looks like this was very much made with
> > embedded systems with device specific kernels where all drivers for
> > the used SoC are builtin.
> 
> It's not about embedded systems, it's about shitty, inconsistent,
> closed-source bootloaders. If bootloaders weren't enabling far more than
> they require and / or if we could fix them when they do, we wouldn't
> have more clocks enabled than we need to.

This argument is wrong. Bootloaders need to leave resources enabled all
the time. Think of every possible peripheral that needs to work until
modules are provided. In fact, I'd argue that the more they leave
enabled the better it is for the boot-up process up until initramfs
comes, even beyond. In fact, the lack of bootloaders leaving stuff
enabled is one of the reasons we build in some of the clock controllers.

> 
> Removing clk_ignore_unused will just make end users pissed off because
> of the higher power draw.

With this I agree.

> 
> > The problem basically is, that if we want something like disabling
> > unused clocks at all (1), it should happen when all drivers including
> > those build as module have had a chance to run. ATM the clocks
> > simply get turned off too soon.
> > 
> > Also see Stephen Boyd's LPC talk about this:
> > 
> > "Make sync_state()/handoff work for the common clk framework"
> > https://lpc.events/event/17/contributions/1432/
> > 
> > When the clk framework maintainer themselves are arguing for
> > replacing the way unused clks are disabled atm with something
> > better then to me that is a clear sign that there is something
> > wrong with the current mechanism.
> 
> I have no problem with *replacing* it with something better. I looked at
> that talk already, tried to make sync_state work already and suggested
> it to Brian too. So I'm not saying it shouldn't replaced.
> 
> What I have a problem with is removing it with no viable alternative in
> sight.

Again, I agree. But moving this to a kernel config is wrong specially
since you want a single kernel image to work with different SoCs from
different vendors.

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Hans de Goede]

Hi,

On 17-Mar-26 14:32, Maxime Ripard wrote:
> On Tue, Mar 17, 2026 at 12:53:10PM +0100, Hans de Goede wrote:
>> Hi Maxime,
>>
>> On 17-Mar-26 08:30, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Mon, Mar 16, 2026 at 06:33:45PM -0400, Brian Masney wrote:
>>>> At the 2023 Linux Plumbers Conference in Richmond VA, there was a
>>>> discussion about how large number of systems need to boot with
>>>> clk_ignore_unused. Per the discussions at the conference, the existing
>>>> behavior in the clk core is broken, and there is a desire to completely
>>>> remove this functionality.
>>>
>>> Broken how?
>>>
>>> clk_ignore_unused is to a point where it's seriously cargo-culted and
>>> documented as a silver bullet, when in reality it's just a debug tool
>>> for broken drivers, and the driver must be fixed.
>>>
>>> But nobody is actually fixing it.
>>>
>>> See
>>> https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems#How_To_Test
>>> for example. The affected clock could be marked as CLK_IS_CRITICAL, and
>>> fedora wouldn't have to package anything, change anything, etc. But no,
>>> the problem is clk_ignore_unused.
>>
>> Both things can be true at the same time. Yes there are ways to work
>> around issues causes by clk_ignore_unused and those ways should be
>> used more often. And in example of the X1E laptops I do indeed want
>> to try and figure out which clocks must not be turned off and
>> try to see if it will be accepted to mark these as CLK_IS_CRITICAL.
>>
>> But at the same time the fundamental concept of turning off all unused
>> clocks as soon as all *builtin* drivers are done probing is a broken
>> concept when working with generic distro kernels where many drivers
>> are modules. To me it looks like this was very much made with
>> embedded systems with device specific kernels where all drivers for
>> the used SoC are builtin.
> 
> It's not about embedded systems, it's about shitty, inconsistent,
> closed-source bootloaders. If bootloaders weren't enabling far more than
> they require and / or if we could fix them when they do, we wouldn't
> have more clocks enabled than we need to.

Right, so those bootloaders are part of the reason why we need to disable
unused clocks and some point.

But the current implementation in a late initcall, with no regards for
clk consumers showing up later through module loading is something which
I believe was accepted in its somewhat broken current state in the first
place because of the module problem not being a problem for device
specific disk-images with device specific kernel-builds with all
relevant clk-consuming drivers simply being build into the kernel.

Anyways that is just speculation from my side how we ended up in this
broken state and not otherwise really relevant.

Regards,

Hans

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Abel Vesa]

On 26-03-17 08:30:24, Maxime Ripard wrote:
> Hi,
> 
> On Mon, Mar 16, 2026 at 06:33:45PM -0400, Brian Masney wrote:
> > At the 2023 Linux Plumbers Conference in Richmond VA, there was a
> > discussion about how large number of systems need to boot with
> > clk_ignore_unused. Per the discussions at the conference, the existing
> > behavior in the clk core is broken, and there is a desire to completely
> > remove this functionality.
> 
> Broken how?
> 
> clk_ignore_unused is to a point where it's seriously cargo-culted and
> documented as a silver bullet, when in reality it's just a debug tool
> for broken drivers, and the driver must be fixed.
> 
> But nobody is actually fixing it.
> 
> See
> https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems#How_To_Test
> for example. The affected clock could be marked as CLK_IS_CRITICAL, and
> fedora wouldn't have to package anything, change anything, etc. But no,
> the problem is clk_ignore_unused.

Nope. Don't ever mark clocks as critical unless system crashes without
them.

Here is an example or why clocks cannot be marked as critical but need
to be kept by the clk_ignore_unused: display driver probes later.
If you mark it as critical you just made the clock stay enabled even
when display is off.

And this is just one example.

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Hans de Goede]

Hi,

On 17-Mar-26 13:14, Abel Vesa wrote:
> On 26-03-17 08:30:24, Maxime Ripard wrote:
>> Hi,
>>
>> On Mon, Mar 16, 2026 at 06:33:45PM -0400, Brian Masney wrote:
>>> At the 2023 Linux Plumbers Conference in Richmond VA, there was a
>>> discussion about how large number of systems need to boot with
>>> clk_ignore_unused. Per the discussions at the conference, the existing
>>> behavior in the clk core is broken, and there is a desire to completely
>>> remove this functionality.
>>
>> Broken how?
>>
>> clk_ignore_unused is to a point where it's seriously cargo-culted and
>> documented as a silver bullet, when in reality it's just a debug tool
>> for broken drivers, and the driver must be fixed.
>>
>> But nobody is actually fixing it.
>>
>> See
>> https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems#How_To_Test
>> for example. The affected clock could be marked as CLK_IS_CRITICAL, and
>> fedora wouldn't have to package anything, change anything, etc. But no,
>> the problem is clk_ignore_unused.
> 
> Nope. Don't ever mark clocks as critical unless system crashes without
> them.
> 
> Here is an example or why clocks cannot be marked as critical but need
> to be kept by the clk_ignore_unused: display driver probes later.
> If you mark it as critical you just made the clock stay enabled even
> when display is off.
> 
> And this is just one example.

Interesting, so maybe we need a new way flag to mark clocks as not to
be turned off when turning unused clocks off, which does not block
them getting disabled normally later ?

(I was under the mistaken impression this is what CLK_IS_CRITICAL did)

Regards,

Hans

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Brian Masney]

Hi Hans,

On Tue, Mar 17, 2026 at 01:16:33PM +0100, Hans de Goede wrote:
> On 17-Mar-26 13:14, Abel Vesa wrote:
> > On 26-03-17 08:30:24, Maxime Ripard wrote:
> >> On Mon, Mar 16, 2026 at 06:33:45PM -0400, Brian Masney wrote:
> >>> At the 2023 Linux Plumbers Conference in Richmond VA, there was a
> >>> discussion about how large number of systems need to boot with
> >>> clk_ignore_unused. Per the discussions at the conference, the existing
> >>> behavior in the clk core is broken, and there is a desire to completely
> >>> remove this functionality.
> >>
> >> Broken how?
> >>
> >> clk_ignore_unused is to a point where it's seriously cargo-culted and
> >> documented as a silver bullet, when in reality it's just a debug tool
> >> for broken drivers, and the driver must be fixed.
> >>
> >> But nobody is actually fixing it.
> >>
> >> See
> >> https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems#How_To_Test
> >> for example. The affected clock could be marked as CLK_IS_CRITICAL, and
> >> fedora wouldn't have to package anything, change anything, etc. But no,
> >> the problem is clk_ignore_unused.
> > 
> > Nope. Don't ever mark clocks as critical unless system crashes without
> > them.
> > 
> > Here is an example or why clocks cannot be marked as critical but need
> > to be kept by the clk_ignore_unused: display driver probes later.
> > If you mark it as critical you just made the clock stay enabled even
> > when display is off.
> > 
> > And this is just one example.
> 
> Interesting, so maybe we need a new way flag to mark clocks as not to
> be turned off when turning unused clocks off, which does not block
> them getting disabled normally later ?
> 
> (I was under the mistaken impression this is what CLK_IS_CRITICAL did)

There's a separate flag CLK_IGNORE_UNUSED that can be used instead.

Brian

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Abel Vesa]

On 26-03-17 08:26:27, Brian Masney wrote:
> Hi Hans,
> 
> On Tue, Mar 17, 2026 at 01:16:33PM +0100, Hans de Goede wrote:
> > On 17-Mar-26 13:14, Abel Vesa wrote:
> > > On 26-03-17 08:30:24, Maxime Ripard wrote:
> > >> On Mon, Mar 16, 2026 at 06:33:45PM -0400, Brian Masney wrote:
> > >>> At the 2023 Linux Plumbers Conference in Richmond VA, there was a
> > >>> discussion about how large number of systems need to boot with
> > >>> clk_ignore_unused. Per the discussions at the conference, the existing
> > >>> behavior in the clk core is broken, and there is a desire to completely
> > >>> remove this functionality.
> > >>
> > >> Broken how?
> > >>
> > >> clk_ignore_unused is to a point where it's seriously cargo-culted and
> > >> documented as a silver bullet, when in reality it's just a debug tool
> > >> for broken drivers, and the driver must be fixed.
> > >>
> > >> But nobody is actually fixing it.
> > >>
> > >> See
> > >> https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems#How_To_Test
> > >> for example. The affected clock could be marked as CLK_IS_CRITICAL, and
> > >> fedora wouldn't have to package anything, change anything, etc. But no,
> > >> the problem is clk_ignore_unused.
> > > 
> > > Nope. Don't ever mark clocks as critical unless system crashes without
> > > them.
> > > 
> > > Here is an example or why clocks cannot be marked as critical but need
> > > to be kept by the clk_ignore_unused: display driver probes later.
> > > If you mark it as critical you just made the clock stay enabled even
> > > when display is off.
> > > 
> > > And this is just one example.
> > 
> > Interesting, so maybe we need a new way flag to mark clocks as not to
> > be turned off when turning unused clocks off, which does not block
> > them getting disabled normally later ?
> > 
> > (I was under the mistaken impression this is what CLK_IS_CRITICAL did)
> 
> There's a separate flag CLK_IGNORE_UNUSED that can be used instead.

But figuring out which clock needs to stay enabled until whatever
consumer module is provided and probes is a mess.

The solution is drop the clk_ignore_unused and rely on the sync_state of
each provider to do the job. Sync state isn't reached until all
providers probes, therefore the clocks stay on until then.

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]

On Tue, Mar 17, 2026 at 03:03:01PM +0200, Abel Vesa wrote:
> On 26-03-17 08:26:27, Brian Masney wrote:
> > Hi Hans,
> > 
> > On Tue, Mar 17, 2026 at 01:16:33PM +0100, Hans de Goede wrote:
> > > On 17-Mar-26 13:14, Abel Vesa wrote:
> > > > On 26-03-17 08:30:24, Maxime Ripard wrote:
> > > >> On Mon, Mar 16, 2026 at 06:33:45PM -0400, Brian Masney wrote:
> > > >>> At the 2023 Linux Plumbers Conference in Richmond VA, there was a
> > > >>> discussion about how large number of systems need to boot with
> > > >>> clk_ignore_unused. Per the discussions at the conference, the existing
> > > >>> behavior in the clk core is broken, and there is a desire to completely
> > > >>> remove this functionality.
> > > >>
> > > >> Broken how?
> > > >>
> > > >> clk_ignore_unused is to a point where it's seriously cargo-culted and
> > > >> documented as a silver bullet, when in reality it's just a debug tool
> > > >> for broken drivers, and the driver must be fixed.
> > > >>
> > > >> But nobody is actually fixing it.
> > > >>
> > > >> See
> > > >> https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems#How_To_Test
> > > >> for example. The affected clock could be marked as CLK_IS_CRITICAL, and
> > > >> fedora wouldn't have to package anything, change anything, etc. But no,
> > > >> the problem is clk_ignore_unused.
> > > > 
> > > > Nope. Don't ever mark clocks as critical unless system crashes without
> > > > them.
> > > > 
> > > > Here is an example or why clocks cannot be marked as critical but need
> > > > to be kept by the clk_ignore_unused: display driver probes later.
> > > > If you mark it as critical you just made the clock stay enabled even
> > > > when display is off.
> > > > 
> > > > And this is just one example.
> > > 
> > > Interesting, so maybe we need a new way flag to mark clocks as not to
> > > be turned off when turning unused clocks off, which does not block
> > > them getting disabled normally later ?
> > > 
> > > (I was under the mistaken impression this is what CLK_IS_CRITICAL did)
> > 
> > There's a separate flag CLK_IGNORE_UNUSED that can be used instead.
> 
> But figuring out which clock needs to stay enabled until whatever
> consumer module is provided and probes is a mess.

And yet, plenty of platforms are doing it just fine.

> The solution is drop the clk_ignore_unused and rely on the sync_state of
> each provider to do the job. Sync state isn't reached until all
> providers probes, therefore the clocks stay on until then.

The problem here isn't that providers have to be there, you said it
yourself, it's about when consumers will be loaded and get their clock.
Either way, sync_states don't seem to move forward much when it comes to
clocks, so it might be something that we converge to eventually, but it
won't help this patch today.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Abel Vesa]

On 26-03-17 14:18:56, Maxime Ripard wrote:
> On Tue, Mar 17, 2026 at 03:03:01PM +0200, Abel Vesa wrote:
> > On 26-03-17 08:26:27, Brian Masney wrote:
> > > Hi Hans,
> > > 
> > > On Tue, Mar 17, 2026 at 01:16:33PM +0100, Hans de Goede wrote:
> > > > On 17-Mar-26 13:14, Abel Vesa wrote:
> > > > > On 26-03-17 08:30:24, Maxime Ripard wrote:
> > > > >> On Mon, Mar 16, 2026 at 06:33:45PM -0400, Brian Masney wrote:
> > > > >>> At the 2023 Linux Plumbers Conference in Richmond VA, there was a
> > > > >>> discussion about how large number of systems need to boot with
> > > > >>> clk_ignore_unused. Per the discussions at the conference, the existing
> > > > >>> behavior in the clk core is broken, and there is a desire to completely
> > > > >>> remove this functionality.
> > > > >>
> > > > >> Broken how?
> > > > >>
> > > > >> clk_ignore_unused is to a point where it's seriously cargo-culted and
> > > > >> documented as a silver bullet, when in reality it's just a debug tool
> > > > >> for broken drivers, and the driver must be fixed.
> > > > >>
> > > > >> But nobody is actually fixing it.
> > > > >>
> > > > >> See
> > > > >> https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems#How_To_Test
> > > > >> for example. The affected clock could be marked as CLK_IS_CRITICAL, and
> > > > >> fedora wouldn't have to package anything, change anything, etc. But no,
> > > > >> the problem is clk_ignore_unused.
> > > > > 
> > > > > Nope. Don't ever mark clocks as critical unless system crashes without
> > > > > them.
> > > > > 
> > > > > Here is an example or why clocks cannot be marked as critical but need
> > > > > to be kept by the clk_ignore_unused: display driver probes later.
> > > > > If you mark it as critical you just made the clock stay enabled even
> > > > > when display is off.
> > > > > 
> > > > > And this is just one example.
> > > > 
> > > > Interesting, so maybe we need a new way flag to mark clocks as not to
> > > > be turned off when turning unused clocks off, which does not block
> > > > them getting disabled normally later ?
> > > > 
> > > > (I was under the mistaken impression this is what CLK_IS_CRITICAL did)
> > > 
> > > There's a separate flag CLK_IGNORE_UNUSED that can be used instead.
> > 
> > But figuring out which clock needs to stay enabled until whatever
> > consumer module is provided and probes is a mess.
> 
> And yet, plenty of platforms are doing it just fine.
> 
> > The solution is drop the clk_ignore_unused and rely on the sync_state of
> > each provider to do the job. Sync state isn't reached until all
> > providers probes, therefore the clocks stay on until then.
> 
> The problem here isn't that providers have to be there, you said it
> yourself, it's about when consumers will be loaded and get their clock.
> Either way, sync_states don't seem to move forward much when it comes to
> clocks, so it might be something that we converge to eventually, but it
> won't help this patch today.

Sorry, I meant "until all consumers probe". My bad.

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Abel Vesa]

On 26-03-17 13:16:33, Hans de Goede wrote:
> Hi,
> 
> On 17-Mar-26 13:14, Abel Vesa wrote:
> > On 26-03-17 08:30:24, Maxime Ripard wrote:
> >> Hi,
> >>
> >> On Mon, Mar 16, 2026 at 06:33:45PM -0400, Brian Masney wrote:
> >>> At the 2023 Linux Plumbers Conference in Richmond VA, there was a
> >>> discussion about how large number of systems need to boot with
> >>> clk_ignore_unused. Per the discussions at the conference, the existing
> >>> behavior in the clk core is broken, and there is a desire to completely
> >>> remove this functionality.
> >>
> >> Broken how?
> >>
> >> clk_ignore_unused is to a point where it's seriously cargo-culted and
> >> documented as a silver bullet, when in reality it's just a debug tool
> >> for broken drivers, and the driver must be fixed.
> >>
> >> But nobody is actually fixing it.
> >>
> >> See
> >> https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems#How_To_Test
> >> for example. The affected clock could be marked as CLK_IS_CRITICAL, and
> >> fedora wouldn't have to package anything, change anything, etc. But no,
> >> the problem is clk_ignore_unused.
> > 
> > Nope. Don't ever mark clocks as critical unless system crashes without
> > them.
> > 
> > Here is an example or why clocks cannot be marked as critical but need
> > to be kept by the clk_ignore_unused: display driver probes later.
> > If you mark it as critical you just made the clock stay enabled even
> > when display is off.
> > 
> > And this is just one example.
> 
> Interesting, so maybe we need a new way flag to mark clocks as not to
> be turned off when turning unused clocks off, which does not block
> them getting disabled normally later ?
> 
> (I was under the mistaken impression this is what CLK_IS_CRITICAL did)

Nope. Critical means system cannot work without it, so do not gate ever.

There is however the CLK_IGNORE_UNUSED flag, but then we need to figure
out which clocks should have the flag. Which is basically a whack-a-mole
game until we get it right in all scenarios, on all platforms.

I think Stephen at some point said he will drop the clk_ignore_unused
late_initcall entirely, but I guess that didn't happen.

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1521 bytes --]

On Tue, Mar 17, 2026 at 02:14:25PM +0200, Abel Vesa wrote:
> On 26-03-17 08:30:24, Maxime Ripard wrote:
> > Hi,
> > 
> > On Mon, Mar 16, 2026 at 06:33:45PM -0400, Brian Masney wrote:
> > > At the 2023 Linux Plumbers Conference in Richmond VA, there was a
> > > discussion about how large number of systems need to boot with
> > > clk_ignore_unused. Per the discussions at the conference, the existing
> > > behavior in the clk core is broken, and there is a desire to completely
> > > remove this functionality.
> > 
> > Broken how?
> > 
> > clk_ignore_unused is to a point where it's seriously cargo-culted and
> > documented as a silver bullet, when in reality it's just a debug tool
> > for broken drivers, and the driver must be fixed.
> > 
> > But nobody is actually fixing it.
> > 
> > See
> > https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems#How_To_Test
> > for example. The affected clock could be marked as CLK_IS_CRITICAL, and
> > fedora wouldn't have to package anything, change anything, etc. But no,
> > the problem is clk_ignore_unused.
> 
> Nope. Don't ever mark clocks as critical unless system crashes without
> them.
> 
> Here is an example or why clocks cannot be marked as critical but need
> to be kept by the clk_ignore_unused: display driver probes later.
> If you mark it as critical you just made the clock stay enabled even
> when display is off.
> 
> And this is just one example.

Then use CLK_IGNORE_UNUSED.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Abel Vesa]

On 26-03-17 14:15:50, Maxime Ripard wrote:
> On Tue, Mar 17, 2026 at 02:14:25PM +0200, Abel Vesa wrote:
> > On 26-03-17 08:30:24, Maxime Ripard wrote:
> > > Hi,
> > > 
> > > On Mon, Mar 16, 2026 at 06:33:45PM -0400, Brian Masney wrote:
> > > > At the 2023 Linux Plumbers Conference in Richmond VA, there was a
> > > > discussion about how large number of systems need to boot with
> > > > clk_ignore_unused. Per the discussions at the conference, the existing
> > > > behavior in the clk core is broken, and there is a desire to completely
> > > > remove this functionality.
> > > 
> > > Broken how?
> > > 
> > > clk_ignore_unused is to a point where it's seriously cargo-culted and
> > > documented as a silver bullet, when in reality it's just a debug tool
> > > for broken drivers, and the driver must be fixed.
> > > 
> > > But nobody is actually fixing it.
> > > 
> > > See
> > > https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems#How_To_Test
> > > for example. The affected clock could be marked as CLK_IS_CRITICAL, and
> > > fedora wouldn't have to package anything, change anything, etc. But no,
> > > the problem is clk_ignore_unused.
> > 
> > Nope. Don't ever mark clocks as critical unless system crashes without
> > them.
> > 
> > Here is an example or why clocks cannot be marked as critical but need
> > to be kept by the clk_ignore_unused: display driver probes later.
> > If you mark it as critical you just made the clock stay enabled even
> > when display is off.
> > 
> > And this is just one example.
> 
> Then use CLK_IGNORE_UNUSED.

But there is no way of knowing in advance to which clocks should this
flag be applied. As I mentioned on this thread already, we will be
playing whack-a-mole with clocks for a long time before we get this
right.

The solution has been already discussed for a long time now and it is:
drop the clk_ignore_unused late_initcall entirely and then make a
generic sync_state callback that the clock providers can use (or they
could implement one themselves). This way, until sync_state is reached
for a specific clock provider driver, all unused clocks remain as is.

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2804 bytes --]

On Tue, Mar 17, 2026 at 03:21:17PM +0200, Abel Vesa wrote:
> On 26-03-17 14:15:50, Maxime Ripard wrote:
> > On Tue, Mar 17, 2026 at 02:14:25PM +0200, Abel Vesa wrote:
> > > On 26-03-17 08:30:24, Maxime Ripard wrote:
> > > > Hi,
> > > > 
> > > > On Mon, Mar 16, 2026 at 06:33:45PM -0400, Brian Masney wrote:
> > > > > At the 2023 Linux Plumbers Conference in Richmond VA, there was a
> > > > > discussion about how large number of systems need to boot with
> > > > > clk_ignore_unused. Per the discussions at the conference, the existing
> > > > > behavior in the clk core is broken, and there is a desire to completely
> > > > > remove this functionality.
> > > > 
> > > > Broken how?
> > > > 
> > > > clk_ignore_unused is to a point where it's seriously cargo-culted and
> > > > documented as a silver bullet, when in reality it's just a debug tool
> > > > for broken drivers, and the driver must be fixed.
> > > > 
> > > > But nobody is actually fixing it.
> > > > 
> > > > See
> > > > https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems#How_To_Test
> > > > for example. The affected clock could be marked as CLK_IS_CRITICAL, and
> > > > fedora wouldn't have to package anything, change anything, etc. But no,
> > > > the problem is clk_ignore_unused.
> > > 
> > > Nope. Don't ever mark clocks as critical unless system crashes without
> > > them.
> > > 
> > > Here is an example or why clocks cannot be marked as critical but need
> > > to be kept by the clk_ignore_unused: display driver probes later.
> > > If you mark it as critical you just made the clock stay enabled even
> > > when display is off.
> > > 
> > > And this is just one example.
> > 
> > Then use CLK_IGNORE_UNUSED.
> 
> But there is no way of knowing in advance to which clocks should this
> flag be applied. As I mentioned on this thread already, we will be
> playing whack-a-mole with clocks for a long time before we get this
> right.

Oh, I know, I did my fair share of these already.

> The solution has been already discussed for a long time now and it is:
> drop the clk_ignore_unused late_initcall entirely and then make a
> generic sync_state callback that the clock providers can use (or they
> could implement one themselves). This way, until sync_state is reached
> for a specific clock provider driver, all unused clocks remain as is.

I don't argue with sync_state being the way forward. It seems
reasonable, even though I'm not sure how we can reasonably expect all
consumers to show up, and / or if we would need some kind of timeout or
something for disabled drivers for example. Anyway. What I'm saying is
that we shouldn't remove that mechanism, no matter how imperfect it is,
without any viable alternative.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Brian Masney]

On Tue, Mar 17, 2026 at 03:21:17PM +0200, Abel Vesa wrote:
> The solution has been already discussed for a long time now and it is:
> drop the clk_ignore_unused late_initcall entirely and then make a
> generic sync_state callback that the clock providers can use (or they
> could implement one themselves). This way, until sync_state is reached
> for a specific clock provider driver, all unused clocks remain as is.

I'm willing to work on the sync state support once my clk scaling
series [1] lands upstream. I believe that Saravana posted a series
related to clk sync state, and I need to look at that.

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.

[1] https://lore.kernel.org/linux-clk/20260313-clk-scaling-v6-0-ce89968c5247@redhat.com/

Brian

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Abel Vesa]

On 26-03-17 10:13:08, Brian Masney wrote:
> On Tue, Mar 17, 2026 at 03:21:17PM +0200, Abel Vesa wrote:
> > The solution has been already discussed for a long time now and it is:
> > drop the clk_ignore_unused late_initcall entirely and then make a
> > generic sync_state callback that the clock providers can use (or they
> > could implement one themselves). This way, until sync_state is reached
> > for a specific clock provider driver, all unused clocks remain as is.
> 
> I'm willing to work on the sync state support once my clk scaling
> series [1] lands upstream. I believe that Saravana posted a series
> related to clk sync state, and I need to look at that.

Yeah, I've spent time on it a couple of years as well, but got side
tracked...

I'd be nice if this actually lands soon.

> 
> 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.

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Brian Masney]

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.

Brian

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Hans de Goede]

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

Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

[Jagadeesh Kona]

On 3/17/2026 7:50 PM, Abel Vesa wrote:
> On 26-03-17 10:13:08, Brian Masney wrote:
>> On Tue, Mar 17, 2026 at 03:21:17PM +0200, Abel Vesa wrote:
>>> The solution has been already discussed for a long time now and it is:
>>> drop the clk_ignore_unused late_initcall entirely and then make a
>>> generic sync_state callback that the clock providers can use (or they
>>> could implement one themselves). This way, until sync_state is reached
>>> for a specific clock provider driver, all unused clocks remain as is.
>>
>> I'm willing to work on the sync state support once my clk scaling
>> series [1] lands upstream. I believe that Saravana posted a series
>> related to clk sync state, and I need to look at that.
> 
> Yeah, I've spent time on it a couple of years as well, but got side
> tracked...
> 
> I'd be nice if this actually lands soon.
> 

Yeah, In Qualcomm SoCs, we have use cases where certain consumer drivers are
probed after the late init call. These drivers rely on clocks that are already
enabled by the bootloader and expect those clocks to remain ON until their probe
completes, after which these consumer drivers can vote on the required clocks.
Supporting sync_state for clocks appears to be the right mechanism to address
this requirement.

Thanks,
Jagadeesh

>>
>> 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.
>