[PATCH] clk: qcom: gcc-ipq5018: mark 'gpll0_main' clock as critical

[PATCH] clk: qcom: gcc-ipq5018: mark 'gpll0_main' clock as critical

[Gabor Juhos]

On IPQ5018, the APCS core clock feeds the CPUs. It can use
different clocks as its parent, but during system boot it
utilizes GPLL0.

Under some cicumstances, the 'gpll0_main' clock is getting
disabled during kernel start which results in a system hang
then the hardware watchdog restarts the board after a while.

This can happen when a driver gets a clock in its probe function,
then releases it either directly or by devres cleanup on probe
failure.

For example, since v6.18 the kernel often fails to boot on the
TP-Link Archer AX55 v1 board by using the in-tree dts. In the
failing configuration, the 'ipq-cmn-pll' driver is built into
the kernel and the problem is caused by the pm_runtim_put()
call in the ipq_cmn_pll_clk_probe() function. Due to this call,
runtime pm disables the 'gcc_cmn_blk_ahb_clk' clock asynchronously
which results in disabling 'gpll0_main' as well.

Mark the clock as critical in order to avoid such hangs.

Cc: stable@vger.kernel.org
Fixes: e3fdbef1bab8 ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
---
Note:
There is a patch [1] awaiting upstream which intends to solve the
problem in the case of the 'ipq-cmn-pll' driver. However the same
hang can be reproduced with several other drivers by triggering a
probe failure in them.

The actual patch aims to solve the root cause.

Link: https://lore.kernel.org/r/20260813093351.178419-1-kuncy7@gmail.com # [1]
---
 drivers/clk/qcom/gcc-ipq5018.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/clk/qcom/gcc-ipq5018.c b/drivers/clk/qcom/gcc-ipq5018.c
index 594dae3bac4c..46da652956fb 100644
--- a/drivers/clk/qcom/gcc-ipq5018.c
+++ b/drivers/clk/qcom/gcc-ipq5018.c
@@ -68,6 +68,15 @@ static struct clk_alpha_pll gpll0_main = {
 			.parent_data = gcc_xo_data,
 			.num_parents = ARRAY_SIZE(gcc_xo_data),
 			.ops = &clk_alpha_pll_stromer_ops,
+			/*
+			 * During system boot, this PLL feeds the CPUs.
+			 * Mark it as critical to ensure that CCF does
+			 * not disable it, even if there are no active
+			 * consumers. This is needed to avoid a system
+			 * hang caused by turning off the clock driving
+			 * the CPUs.
+			 */
+			.flags = CLK_IS_CRITICAL,
 		},
 	},
 };

---
base-commit: 55981579b27b6541aeeab81c768f248dba0491ac
change-id: 20260917-ipq5018-mark-gpll0_main-critical-f3ba32e1f054

Best regards,
-- 
Gabor Juhos <j4g8y7@gmail.com>

Re: [PATCH] clk: qcom: gcc-ipq5018: mark 'gpll0_main' clock as critical

[Stanislaw Pal]

Tested-by: Stanislaw Pal <kuncy7@gmail.com>

Tested on the TP-Link Archer AX55 v1, the board named in the commit
message, on OpenWrt main with kernel 6.18.44 and ipq-cmn-pll built in.

The image carries your patch and not the ipq-cmn-pll one, so this is
your fix on its own: devm_pm_runtime_get_noresume() is absent from
ipq_cmn_pll_clk_probe() and the CLK_IS_CRITICAL flag is the only change
against main. The board boots reliably, with no hang and no watchdog
reset.

/sys/kernel/debug/clk/clk_summary shows the flag doing its work:
gpll0_main sits at enable count 3 here, against 2 on an image that keeps
the PLL alive through the ipq-cmn-pll reference instead. The chain you
describe is visible on the hardware as well:

  gcc_cmn_blk_ahb_clk -> pcnoc_bfdcd_clk_src -> gpll0 -> gpll0_main

Once the board is up, gpll0 has four other enabled consumers (USB, QPIC,
MDIO, BLSP AHB) while the CPUs have already moved to a53pll. That
matches the failure being confined to the probe window, when none of
those exist yet and the CPUs still run off GPLL0.

For what it is worth on the scope question: on this board the hang was
reproducible with ipq-cmn-pll alone, which is what my patch addresses,
but I agree the root cause is the one you are fixing here - any driver
that takes and releases a clock early enough can pull the PLL out from
under the CPUs. Happy to see it handled in gcc-ipq5018.