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

From: Dmitry Baryshkov
Date: Mon Mar 03 2025 - 18:17:40 EST


On Tue, 4 Mar 2025 at 00:16, Florian Fainelli
<florian.fainelli@xxxxxxxxxxxx> wrote:
>
> 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?

Unfortunately it's sometimes not that easy. And some developers
pretend that 'clk_ignore_unused' is a viable way to run the system.

--
With best wishes
Dmitry