Revert "clk: Respect CLK_OPS_PARENT_ENABLE during recalc"

PATCH In review Stephen Boyd 6 participants 6 messages Feb 3 – Feb 5 Common clk

Share & tools

Stephen Boyd

author maintainer

2026-02-03 00:24 UTC #0 lore raw

PATCH 1/1 Revert "clk: Respect CLK_OPS_PARENT_ENABLE during recalc"

This reverts commit 669917676e93fca5ea3c66fc9539830312bec58e. It's been shown to cause problems on i.MX and STM32 platforms where the board doesn't boot. In one case, a clk with CLK_IS_CRITICAL and CLK_OPS_PARENT_ENABLE is being registered causing the parent to be enabled, the rate recalculated, and then the parent is disabled causing the critical clk being registered to stop clocking.

A fix for that would be to calculate the rate of the clk after enabling the critical clk itself, but that wouldn't fix another problem where a clk with CLK_OPS_PARENT_ENABLE is registered before the parent is registered. In this case the hardware access in the clk_ops::recalc_rate() function would fail if the parent is disabled.

There are even more problems exposed by this patch because it introduces logic that disables clks earlier in system boot than has existed previously. Historically we've not disabled clks until late init (clk_disable_unused) under the assumption that clks have been registered enough to have a consistent view of the clk tree. The clk_disable_unused logic doesn't work very well though, leading to quite a few devices booting with clk_ignore_unused on the kernel command line.

Long story short, disabling clks during clk registration is full of pitfalls. Revert this commit until a proper solution can be found.

Reported-by Alexander Stein <[email protected]>

Closes https://lore.kernel.org/r/6239343.lOV4Wx5bFT@steina-w open here

Reported-by Mark Brown <[email protected]>

Closes https://lore.kernel.org/r/[email protected] open here

Cc Nicolas Frattaroli <[email protected]>

Cc Brian Masney <[email protected]>

Cc AngeloGioacchino Del Regno <[email protected]>

Cc Chen-Yu Tsai <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

---
 drivers/clk/clk.c | 13 -------------
 1 file changed, 13 deletions(-)

drivers/clk/clk.c +0 ~~-13~~

index 1b0f9d567f48..85d2f2481acf 100644
@@ -1921,14 +1921,7 @@ static unsigned long clk_recalc(struct clk_core *core,
 	unsigned long rate = parent_rate;
 
 	if (core->ops->recalc_rate && !clk_pm_runtime_get(core)) {
-		if (core->flags & CLK_OPS_PARENT_ENABLE)
-			clk_core_prepare_enable(core->parent);
-
 		rate = core->ops->recalc_rate(core->hw, parent_rate);
-
-		if (core->flags & CLK_OPS_PARENT_ENABLE)
-			clk_core_disable_unprepare(core->parent);
-
 		clk_pm_runtime_put(core);
 	}
 	return rate;

@@ -4038,9 +4031,6 @@ static int __clk_core_init(struct clk_core *core)
 	 */
 	clk_core_update_duty_cycle_nolock(core);
 
-	if (core->flags & CLK_OPS_PARENT_ENABLE)
-		clk_core_prepare_enable(core->parent);
-
 	/*
 	 * Set clk's rate.  The preferred method is to use .recalc_rate.  For
 	 * simple clocks and lazy developers the default fallback is to use the

@@ -4056,9 +4046,6 @@ static int __clk_core_init(struct clk_core *core)
 		rate = 0;
 	core->rate = core->req_rate = rate;
 
-	if (core->flags & CLK_OPS_PARENT_ENABLE)
-		clk_core_disable_unprepare(core->parent);
-
 	/*
 	 * Enable CLK_IS_CRITICAL clocks so newly added critical clocks
 	 * don't get accidentally disabled when walking the orphan tree and

base-commit: aa2ad19210a6a444111bce55e8b69579f29318fb

Signature · 2 lines

https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git

Peng Fan

Tested-by on v1 1/1

2026-02-03 02:55 UTC #1 lore raw

Quoted 28 lines · Stephen Boyd

This reverts commit 669917676e93fca5ea3c66fc9539830312bec58e. It's been shown to cause problems on i.MX and STM32 platforms where the board doesn't boot. In one case, a clk with CLK_IS_CRITICAL and CLK_OPS_PARENT_ENABLE is being registered causing the parent to be enabled, the rate recalculated, and then the parent is disabled causing the critical clk being registered to stop clocking.
A fix for that would be to calculate the rate of the clk after enabling the critical clk itself, but that wouldn't fix another problem where a clk with CLK_OPS_PARENT_ENABLE is registered before the parent is registered. In this case the hardware access in the clk_ops::recalc_rate() function would fail if the parent is disabled.
There are even more problems exposed by this patch because it introduces logic that disables clks earlier in system boot than has existed previously. Historically we've not disabled clks until late init (clk_disable_unused) under the assumption that clks have been registered enough to have a consistent view of the clk tree. The clk_disable_unused logic doesn't work very well though, leading to quite a few devices booting with clk_ignore_unused on the kernel command line.
Long story short, disabling clks during clk registration is full of pitfalls. Revert this commit until a proper solution can be found.

Quoted 9 lines

Reported-by Alexander Stein <[email protected]>
Closes https://lore.kernel.org/r/6239343.lOV4Wx5bFT@steina-w open here
Reported-by Mark Brown <[email protected]>
Closes https://lore.kernel.org/r/[email protected] open here
Cc Nicolas Frattaroli <[email protected]>
Cc Brian Masney <[email protected]>
Cc AngeloGioacchino Del Regno <[email protected]>
Cc Chen-Yu Tsai <[email protected]>
Signed-off-by Stephen Boyd <[email protected]>

Tested-by Peng Fan <[email protected]>

Alexander Stein

Tested-by on v1 1/1

2026-02-03 07:33 UTC #2 lore raw

In reply to Stephen Boyd

Am Dienstag, 3. Februar 2026, 01:24:38 CET schrieb Stephen Boyd:

Quoted 28 lines

This reverts commit 669917676e93fca5ea3c66fc9539830312bec58e. It's been shown to cause problems on i.MX and STM32 platforms where the board doesn't boot. In one case, a clk with CLK_IS_CRITICAL and CLK_OPS_PARENT_ENABLE is being registered causing the parent to be enabled, the rate recalculated, and then the parent is disabled causing the critical clk being registered to stop clocking.
A fix for that would be to calculate the rate of the clk after enabling the critical clk itself, but that wouldn't fix another problem where a clk with CLK_OPS_PARENT_ENABLE is registered before the parent is registered. In this case the hardware access in the clk_ops::recalc_rate() function would fail if the parent is disabled.
There are even more problems exposed by this patch because it introduces logic that disables clks earlier in system boot than has existed previously. Historically we've not disabled clks until late init (clk_disable_unused) under the assumption that clks have been registered enough to have a consistent view of the clk tree. The clk_disable_unused logic doesn't work very well though, leading to quite a few devices booting with clk_ignore_unused on the kernel command line.
Long story short, disabling clks during clk registration is full of pitfalls. Revert this commit until a proper solution can be found.

Quoted 9 lines

Reported-by Alexander Stein <[email protected]>
Closes https://lore.kernel.org/r/6239343.lOV4Wx5bFT@steina-w open here
Reported-by Mark Brown <[email protected]>
Closes https://lore.kernel.org/r/[email protected] open here
Cc Nicolas Frattaroli <[email protected]>
Cc Brian Masney <[email protected]>
Cc AngeloGioacchino Del Regno <[email protected]>
Cc Chen-Yu Tsai <[email protected]>
Signed-off-by Stephen Boyd <[email protected]>

Tested-by Alexander Stein <[email protected]>

Quoted 46 lines

---
 drivers/clk/clk.c | 13 -------------
 1 file changed, 13 deletions(-)

drivers/clk/clk.c +0 ~~-13~~

index 1b0f9d567f48..85d2f2481acf 100644
@@ -1921,14 +1921,7 @@ static unsigned long clk_recalc(struct clk_core *core,
 	unsigned long rate = parent_rate;
 
 	if (core->ops->recalc_rate && !clk_pm_runtime_get(core)) {
-		if (core->flags & CLK_OPS_PARENT_ENABLE)
-			clk_core_prepare_enable(core->parent);
-
 		rate = core->ops->recalc_rate(core->hw, parent_rate);
-
-		if (core->flags & CLK_OPS_PARENT_ENABLE)
-			clk_core_disable_unprepare(core->parent);
-
 		clk_pm_runtime_put(core);
 	}
 	return rate;

@@ -4038,9 +4031,6 @@ static int __clk_core_init(struct clk_core *core)
 	 */
 	clk_core_update_duty_cycle_nolock(core);
 
-	if (core->flags & CLK_OPS_PARENT_ENABLE)
-		clk_core_prepare_enable(core->parent);
-
 	/*
 	 * Set clk's rate.  The preferred method is to use .recalc_rate.  For
 	 * simple clocks and lazy developers the default fallback is to use the

@@ -4056,9 +4046,6 @@ static int __clk_core_init(struct clk_core *core)
 		rate = 0;
 	core->rate = core->req_rate = rate;
 
-	if (core->flags & CLK_OPS_PARENT_ENABLE)
-		clk_core_disable_unprepare(core->parent);
-
 	/*
 	 * Enable CLK_IS_CRITICAL clocks so newly added critical clocks
 	 * don't get accidentally disabled when walking the orphan tree and

base-commit: aa2ad19210a6a444111bce55e8b69579f29318fb

Signature · 4 lines

TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Brian Masney

Reviewed-by on v1 1/1

2026-02-03 15:15 UTC #3 lore raw

In reply to Stephen Boyd

Quoted 28 lines · Stephen Boyd

This reverts commit 669917676e93fca5ea3c66fc9539830312bec58e. It's been shown to cause problems on i.MX and STM32 platforms where the board doesn't boot. In one case, a clk with CLK_IS_CRITICAL and CLK_OPS_PARENT_ENABLE is being registered causing the parent to be enabled, the rate recalculated, and then the parent is disabled causing the critical clk being registered to stop clocking.
A fix for that would be to calculate the rate of the clk after enabling the critical clk itself, but that wouldn't fix another problem where a clk with CLK_OPS_PARENT_ENABLE is registered before the parent is registered. In this case the hardware access in the clk_ops::recalc_rate() function would fail if the parent is disabled.
There are even more problems exposed by this patch because it introduces logic that disables clks earlier in system boot than has existed previously. Historically we've not disabled clks until late init (clk_disable_unused) under the assumption that clks have been registered enough to have a consistent view of the clk tree. The clk_disable_unused logic doesn't work very well though, leading to quite a few devices booting with clk_ignore_unused on the kernel command line.
Long story short, disabling clks during clk registration is full of pitfalls. Revert this commit until a proper solution can be found.

Quoted 9 lines

Reported-by Alexander Stein <[email protected]>
Closes https://lore.kernel.org/r/6239343.lOV4Wx5bFT@steina-w open here
Reported-by Mark Brown <[email protected]>
Closes https://lore.kernel.org/r/[email protected] open here
Cc Nicolas Frattaroli <[email protected]>
Cc Brian Masney <[email protected]>
Cc AngeloGioacchino Del Regno <[email protected]>
Cc Chen-Yu Tsai <[email protected]>
Signed-off-by Stephen Boyd <[email protected]>

Reviewed-by Brian Masney <[email protected]>

Mark Brown

Tested-by on v1 1/1

2026-02-03 17:43 UTC #4 lore raw

In reply to Stephen Boyd

Quoted 7 lines · Stephen Boyd

This reverts commit 669917676e93fca5ea3c66fc9539830312bec58e. It's been shown to cause problems on i.MX and STM32 platforms where the board doesn't boot. In one case, a clk with CLK_IS_CRITICAL and CLK_OPS_PARENT_ENABLE is being registered causing the parent to be enabled, the rate recalculated, and then the parent is disabled causing the critical clk being registered to stop clocking.

Tested-by Mark Brown <[email protected]>

AngeloGioacchino Del Regno

Reviewed-by on v1 1/1

2026-02-05 11:43 UTC #5 lore raw

In reply to Stephen Boyd

Il 03/02/26 01:24, Stephen Boyd ha scritto:

Quoted 28 lines

This reverts commit 669917676e93fca5ea3c66fc9539830312bec58e. It's been shown to cause problems on i.MX and STM32 platforms where the board doesn't boot. In one case, a clk with CLK_IS_CRITICAL and CLK_OPS_PARENT_ENABLE is being registered causing the parent to be enabled, the rate recalculated, and then the parent is disabled causing the critical clk being registered to stop clocking.
A fix for that would be to calculate the rate of the clk after enabling the critical clk itself, but that wouldn't fix another problem where a clk with CLK_OPS_PARENT_ENABLE is registered before the parent is registered. In this case the hardware access in the clk_ops::recalc_rate() function would fail if the parent is disabled.
There are even more problems exposed by this patch because it introduces logic that disables clks earlier in system boot than has existed previously. Historically we've not disabled clks until late init (clk_disable_unused) under the assumption that clks have been registered enough to have a consistent view of the clk tree. The clk_disable_unused logic doesn't work very well though, leading to quite a few devices booting with clk_ignore_unused on the kernel command line.
Long story short, disabling clks during clk registration is full of pitfalls. Revert this commit until a proper solution can be found.

Quoted 9 lines

Reported-by Alexander Stein <[email protected]>
Closes https://lore.kernel.org/r/6239343.lOV4Wx5bFT@steina-w open here
Reported-by Mark Brown <[email protected]>
Closes https://lore.kernel.org/r/[email protected] open here
Cc Nicolas Frattaroli <[email protected]>
Cc Brian Masney <[email protected]>
Cc AngeloGioacchino Del Regno <[email protected]>
Cc Chen-Yu Tsai <[email protected]>
Signed-off-by Stephen Boyd <[email protected]>

Makes sense, and I agree.

Reviewed-by AngeloGioacchino Del Regno <[email protected]>