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

[Brian Masney <bmasney@redhat.com>]

Hi Peter,

On Fri, Aug 28, 2026 at 03:38:03PM +0200, Peter Zijlstra wrote:
> 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?

I'm one of the two new co-maintainers for the clk subsystem. Do you have
a suggestion for how you would change this locking in the core clk
framework? Long term I'd like to see more fine grained locking since I
see at boot up on my Thinkpad x13s laptop that it takes ~10ms in some
cases to acquire the prepare lock.

Brian