[RFC/PATCH] clk: add lockdep_ignore_clk_prepare_lock cmdline option

[RFC/PATCH] clk: add lockdep_ignore_clk_prepare_lock cmdline option

[Marek Szyprowski]

The clock framework uses a single global re-entrant mutex, prepare_lock,
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.

Best regards,
Marek Szyprowski
---
 drivers/clk/clk.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index fef87167a60b..a5c8c4256102 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -168,6 +168,17 @@ struct clk {
 	struct hlist_node clks_node;
 };
 
+#ifdef CONFIG_LOCKDEP
+static int __init lockdep_ignore_clk_prepare_lock_setup(char *__unused)
+{
+	lockdep_set_novalidate_class(&prepare_lock);
+	pr_warn("lockdep: ignoring prepare_lock class in clock subsystem\n");
+	return 1;
+}
+__setup("lockdep_ignore_clk_prepare_lock",
+	lockdep_ignore_clk_prepare_lock_setup);
+#endif
+
 /***           runtime pm          ***/
 static int clk_pm_runtime_get(struct clk_core *core)
 {
-- 
2.43.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The conditionally compiled `__setup` parameter leaks to the init process when CONFIG_LOCKDEP is disabled, breaking systemd boots.
--

commit 85a755ef5489c876625f9877594712083467cf23
Author: Marek Szyprowski <m.szyprowski@samsung.com>

clk: add lockdep_ignore_clk_prepare_lock cmdline option

This commit introduces a new kernel command line parameter,
lockdep_ignore_clk_prepare_lock, to skip dependency tracking for the
prepare_lock class in the clock subsystem. This helps prevent lockdep
from turning itself off due to false positive circular dependencies.

> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 048adfa86a5d0..adf7d83c854a9 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -117,6 +117,17 @@ struct clk {
>  	struct hlist_node clks_node;
>  };
>  
> +#ifdef CONFIG_LOCKDEP
> +static int __init lockdep_ignore_clk_prepare_lock_setup(char *__unused)
> +{
> +	lockdep_set_novalidate_class(&prepare_lock);
> +	pr_warn("lockdep: ignoring prepare_lock class in clock subsystem\n");
> +	return 1;
> +}
> +__setup("lockdep_ignore_clk_prepare_lock",
> +	lockdep_ignore_clk_prepare_lock_setup);
> +#endif

[Severity: High]
Will this break the boot process if a user passes the parameter on a kernel
built without CONFIG_LOCKDEP?

Because the __setup() macro is conditionally compiled inside the
#ifdef CONFIG_LOCKDEP block, the parameter handler is completely omitted when
lockdep is disabled. 

When this happens, the kernel treats the unrecognized parameter as an unknown
positional argument and passes it to the init process.

Standard init systems like systemd strictly interpret unknown positional
arguments as the default boot target (for example, attempting to load
lockdep_ignore_clk_prepare_lock.target). Since this target does not exist,
the system will fail to boot and instead drop into an emergency shell.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828131409.962825-1-m.szyprowski@samsung.com?part=1

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

[Peter Zijlstra]

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?