Re: [PATCH] clk: Warn (and therefore taint the kernel) on clk_ignore_unused

[Florian Fainelli]

On 3/3/25 14:48, Stephen Boyd wrote:
> Quoting Konrad Dybcio (2025-02-01 08:52:30)
> > From: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>
> >
> > If any sort of ignore_unused is in place, it means one of:
> >
> > * power is going to waste
> > * the platform description is incomplete (missing consumer-provider
> >    relationships)
> > * the platform description is just broken
> >
> > Many people will happily declare their job done when a platform
> > magically happens to work as they make use of bootloader-enabled
> > resources, which then leads to double or triple the amount of work
> > of another person, as they attempt to reduce the unnecessary power
> > drainage and/or ensure stabiility throughout a suspend-resume cycle.
> >
> > Issue a good ol' warning (and taint the kernel) to make such cases
> > obvious and hopefully draw more attention to it. This way, it'll be
> > easier to avoid effectively untested code or DT description getting
> > merged into the kernel, or worse, going into production.
> >
> > The clock subsystem plays a crucial part in this quest, as even if
> > the clock controllers themselves don't draw a lot of power when on
> > (comparatively), improper description of clock requirements has been
> > the #1 cause of incomplete/incorrect devicetree bindings in my
> > experience.
>
> What is a user supposed to do about this warning stack? We already print
> a warning. I don't see us dumping the stack when a driver is unfinished
> and doesn't implement runtime PM to save power.

Agreed, I don't think this is tremendously helpful given that it does 
not even tell you what part is incomplete, it's just a broad warning for 
the entire system.

Assuming you have a clock provided that can be used to turn clocks off, 
and you did not boot with 'clk_ignore_unused' set on the kernel command 
line, then you should discover pretty quickly which driver is not 
managing the clocks as it should no?
--
Florian