Re: [RFC/PATCH] clk: add lockdep_ignore_clk_prepare_lock cmdline option

[Peter Zijlstra <peterz@infradead.org>]

On Fri, Aug 28, 2026 at 03:14:07PM +0200, Marek Szyprowski wrote:
> The clock framework uses a single global re-entrant mutex, prepare_lock,

There is no such primitive in the kernel -- this means the clock people
rolled their own. Why ?!

> to serialize all operations on the whole clock tree. It is taken by
> nearly every clk API call and it is held while calling into the clock
> providers, which in turn often take their own locks or trigger runtime
> PM. As a result prepare_lock sits in the middle of a large number of
> lock chains and lockdep frequently reports possible circular locking
> dependencies involving it.
> 
> Such reports are often not real deadlocks, but once the first one is hit
> lockdep turns itself off and all subsequent locking problems - including
> the ones actually being investigated - are no longer reported.
> 
> Add a "lockdep_ignore_clk_prepare_lock" kernel command line parameter,
> which marks the prepare_lock class as novalidate, so lockdep skips the
> dependency tracking for it and keeps validating the rest of the system.
> 
> The option is only available when CONFIG_LOCKDEP is enabled and is meant
> purely as a debugging aid.
> 
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> The problems with clock framework's prepare_lock are well known and
> there are machines that always report lockdep issues related to it. A
> good example are Khadas VIM3/VIM3l boards, on which prepare_lock
> interferes with locks used in PWM subsytem:
> 
> https://lore.kernel.org/all/adqtn6iljcguv3m3ovhltusbbf4mljzlwg73yklaudvjjtazxv@vyf5fvuzic6x/
> 
> This new cmdline option allows to hide prepare_lock related issues on
> the test machines possibly enabling lockdep to catch other issues.

This is horrible. Why not fix the clock framework?