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.