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

[Maxime Ripard]

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: signature.asc
Description: PGP signature