[v3] clk: core: Honor CLK_OPS_PARENT_ENABLE in clk_core_is_enabled

Commit Message

Chen-Yu Tsai Jan. 3, 2023, 9:23 a.m. UTC

In the previous commits that added CLK_OPS_PARENT_ENABLE, support for
this flag was only added to rate change operations (rate setting and
reparent) and disabling unused subtree. It was not added to the
clock gate related operations. Any hardware driver that needs it for
these operations will either see bogus results, or worse, hang.

This has been seen on MT8192 and MT8195, where the imp_ii2_* clk
drivers set this, but dumping debugfs clk_summary would cause it
to hang.

Prepare parent on prepare and enable parent on enable dependencies are
already handled automatically by the core as part of its sequencing.
Whether the case for "enable parent on prepare" should be supported by
this flag or not is not clear, and thus ignored for now.

This change solely fixes the handling of clk_core_is_enabled, i.e.
enabling the parent clock when reading the hardware state. Unfortunately
clk_core_is_enabled is called in a variety of places, sometimes with
the enable clock already held. To avoid deadlocking, the core will
ignore readouts and just return false if CLK_OPS_PARENT_ENABLE is set
but the parent isn't currently enabled.

Fixes: fc8726a2c021 ("clk: core: support clocks which requires parents enable (part 2)")
Fixes: a4b3518d146f ("clk: core: support clocks which requires parents enable (part 1)")
Signed-off-by: Chen-Yu Tsai <[e-mail]>
---
This is a less invasive version of "clk: core: Honor CLK_OPS_PARENT_ENABLE
for clk gate ops" [1] which caused regressions on i.MX platforms.

My guess is that the i.MX clock driver uses clk_hw_is_enabled() in it's
set_rate callback, in which the new code causes a deadlock.

v3 drops the enable parent on prepare/unprepare bits, as it's unclear
who benefits from it, and the locking is hard to get right. The part in
clk_core_is_enabled() is changed into a bypass path, as described in the
commit message. This fixes the issue I'm seeing, and hopefully doesn't
change the behavior on other platforms.

[1] https://lore.kernel.org/linux-clk/[e-mail]/

 drivers/clk/clk.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

Comments

AngeloGioacchino Del Regno Jan. 3, 2023, 11:53 a.m. UTC | #1

Il 03/01/23 10:23, Chen-Yu Tsai ha scritto:
> In the previous commits that added CLK_OPS_PARENT_ENABLE, support for
> this flag was only added to rate change operations (rate setting and
> reparent) and disabling unused subtree. It was not added to the
> clock gate related operations. Any hardware driver that needs it for
> these operations will either see bogus results, or worse, hang.
> 
> This has been seen on MT8192 and MT8195, where the imp_ii2_* clk
> drivers set this, but dumping debugfs clk_summary would cause it
> to hang.
> 
> Prepare parent on prepare and enable parent on enable dependencies are
> already handled automatically by the core as part of its sequencing.
> Whether the case for "enable parent on prepare" should be supported by
> this flag or not is not clear, and thus ignored for now.
> 
> This change solely fixes the handling of clk_core_is_enabled, i.e.
> enabling the parent clock when reading the hardware state. Unfortunately
> clk_core_is_enabled is called in a variety of places, sometimes with
> the enable clock already held. To avoid deadlocking, the core will
> ignore readouts and just return false if CLK_OPS_PARENT_ENABLE is set
> but the parent isn't currently enabled.
> 
> Fixes: fc8726a2c021 ("clk: core: support clocks which requires parents enable (part 2)")
> Fixes: a4b3518d146f ("clk: core: support clocks which requires parents enable (part 1)")
> Signed-off-by: Chen-Yu Tsai <[e-mail]>

Reviewed-by: AngeloGioacchino Del Regno <[e-mail]>

Moreover, for MT6795 Xperia M5, MT8173 Elm, MT8192 Asurada, MT8195 Tomato:

Tested-by: AngeloGioacchino Del Regno <[e-mail]>

Patch

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index e62552a75f08..496b86e2753c 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -244,6 +244,17 @@  static bool clk_core_is_enabled(struct clk_core *core)
 		}
 	}
 
+	/*
+	 * This could be called with the enable lock held, or from atomic
+	 * context. If the parent isn't enabled already, we can't do
+	 * anything here. We can also assume this clock isn't enabled.
+	 */
+	if ((core->flags & CLK_OPS_PARENT_ENABLE) && core->parent)
+		if (!clk_core_is_enabled(core->parent)) {
+			ret = false;
+			goto done;
+		}
+
 	ret = core->ops->is_enabled(core->hw);
 done:
 	if (core->rpm_enabled)