[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.

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

[Mieczyslaw Nalewaj]

On 9/18/2026 11:27 AM, Gabor Juhos wrote:
> 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.
[...]
> 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>

Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>

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

[Konrad Dybcio]

On 9/18/26 11:27 AM, Gabor Juhos wrote:
> 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.

This is a good workaround. Ideally, we would resolve why this
happens in the first place.

At a glance, we have the CPUs consuming
&apcs_glb APCS_ALIAS0_CORE_CLK

which takes XO/GPLL0/A53PLL as parents.

GPLL0 is a child of GPLL0_MAIN, so this should never be gated in
practice. devlink and probe deferrals should make sure you always
get a valid clock handle for the cpufreq driver..

In any case:

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

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

[Bjorn Andersson]

On Fri, 18 Sep 2026 11:27:49 +0200, Gabor Juhos wrote:
> 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.
> 
> [...]

Applied, thanks!

[1/1] clk: qcom: gcc-ipq5018: mark 'gpll0_main' clock as critical
      commit: 00c90797607cf10f23ec5cf5aa4d2ef74366a2f2

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>

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

[Gabor Juhos]

Hi Konrad,

2026. 09. 23. 15:32 keltezéssel, Konrad Dybcio írta:
> On 9/18/26 11:27 AM, Gabor Juhos wrote:
>> 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.
> 
> This is a good workaround. Ideally, we would resolve why this
> happens in the first place.
> 
> At a glance, we have the CPUs consuming
> &apcs_glb APCS_ALIAS0_CORE_CLK
> 
> which takes XO/GPLL0/A53PLL as parents.
> 
> GPLL0 is a child of GPLL0_MAIN, so this should never be gated in
> practice. devlink and probe deferrals should make sure you always
> get a valid clock handle for the cpufreq driver..

Yes, the cpufreq driver gets a valid clock handle. However the hang happens
early, when the 'apcs_alias0_core' clock is not registered yet. So CCF does not
know that the clock (hence the CPU) is a consumer of GPLL0.

The reason behind the late registration of the 'apcs_alias0_core' clock is that
probing of the 'mailbox@b111000' device is deferred probably because it requires
the '&a53pll' and the '&gcc GPLL0' clocks. This can be easily seen by enabling
debug in 'drivers/base/dd.c':

...[    0.627289] platform b111000.mailbox: bus: 'platform':
__driver_probe_device: matched device with driver qcom_apcs_ipc
[    0.627535] platform b111000.mailbox: Added to deferred list
...
[    0.967199] platform 9b000.clock-controller: bus: 'platform':
__driver_probe_device: matched device with driver ipq_cmn_pll
[    0.974373] platform 9b000.clock-controller: bus: 'platform': really_probe:
probing driver ipq_cmn_pll with device
...
### without the patch, the hang happens here ###...
[    2.272775] platform b111000.mailbox: Retrying from deferred list
[    2.280683] platform b111000.mailbox: bus: 'platform': __driver_probe_device:
matched device with driver qcom_apcs_ipc
[    2.286054] platform b111000.mailbox: bus: 'platform': really_probe: probing
driver qcom_apcs_ipc with device
[    2.301354] platform qcom,apss-ipq6018-clk.0.auto: bus: 'platform':
__driver_probe_device: matched device with driver qcom,apss-ipq6018-clk
[    2.306621] platform qcom,apss-ipq6018-clk.0.auto: bus: 'platform':
really_probe: probing driver qcom,apss-ipq6018-clk with device
[    2.323267] qcom,apss-ipq6018-clk qcom,apss-ipq6018-clk.0.auto: driver:
'qcom,apss-ipq6018-clk': driver_bound: bound to device
[    2.332307] qcom,apss-ipq6018-clk qcom,apss-ipq6018-clk.0.auto: bus:
'platform': really_probe: bound device to driver qcom,apss-ipq6018-clk
[    2.342573] qcom_apcs_ipc b111000.mailbox: driver: 'qcom_apcs_ipc':
driver_bound: bound to device
[    2.355998] qcom_apcs_ipc b111000.mailbox: bus: 'platform': really_probe:
bound device to driver qcom_apcs_ipc
Now that the 'apcs_alias0_core' clock is registered, the cpufreq driver can
switch the clock's parent from GPLL0 to A53PLL:

[    2.427166] platform cpufreq-dt: Retrying from deferred list
[    2.437131] platform cpufreq-dt: bus: 'platform': __driver_probe_device:
matched device with driver cpufreq-dt
[    2.442776] platform cpufreq-dt: bus: 'platform': really_probe: probing
driver cpufreq-dt with device
[    2.461285] cpufreq: cpufreq_policy_online: CPU0: Running at unlisted initial
frequency: 799999 kHz, changing to: 800000 kHz
[    2.479751] cpufreq-dt cpufreq-dt: driver: 'cpufreq-dt': driver_bound: bound
to device
[    2.481435] cpufreq-dt cpufreq-dt: bus: 'platform': really_probe: bound
device to driver cpufreq-dt

I have not found a better solution which prevents 'gpll0_main' from being
disabled until the 'apcs_alias0_core' clock gets registered.

On the vast majority of the boards, one or more consumers of the PLL are always
active during runtime, so in practice it always runs anyway.

Regards,
Gabor

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

[Konrad Dybcio]

On 9/24/26 1:33 PM, Gabor Juhos wrote:
> Hi Konrad,
> 
> 2026. 09. 23. 15:32 keltezéssel, Konrad Dybcio írta:
>> On 9/18/26 11:27 AM, Gabor Juhos wrote:
>>> On IPQ5018, the APCS core clock feeds the CPUs. It can use
>>> different clocks as its parent, but during system boot it
>>> utilizes GPLL0.

[...]

>> At a glance, we have the CPUs consuming
>> &apcs_glb APCS_ALIAS0_CORE_CLK
>>
>> which takes XO/GPLL0/A53PLL as parents.
>>
>> GPLL0 is a child of GPLL0_MAIN, so this should never be gated in
>> practice. devlink and probe deferrals should make sure you always
>> get a valid clock handle for the cpufreq driver..
> 
> Yes, the cpufreq driver gets a valid clock handle. However the hang happens
> early, when the 'apcs_alias0_core' clock is not registered yet. So CCF does not
> know that the clock (hence the CPU) is a consumer of GPLL0.

So is that the late_initcall kicking in early, disabling unused
clocks, or is there some other logic that ends up disabling the
GPLL?

Konrad

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

[Gabor Juhos]

2026. 10. 01. 18:15 keltezéssel, Konrad Dybcio írta:
> On 9/24/26 1:33 PM, Gabor Juhos wrote:
>> Hi Konrad,
>>
>> 2026. 09. 23. 15:32 keltezéssel, Konrad Dybcio írta:
>>> On 9/18/26 11:27 AM, Gabor Juhos wrote:
>>>> On IPQ5018, the APCS core clock feeds the CPUs. It can use
>>>> different clocks as its parent, but during system boot it
>>>> utilizes GPLL0.
> 
> [...]
> 
>>> At a glance, we have the CPUs consuming
>>> &apcs_glb APCS_ALIAS0_CORE_CLK
>>>
>>> which takes XO/GPLL0/A53PLL as parents.
>>>
>>> GPLL0 is a child of GPLL0_MAIN, so this should never be gated in
>>> practice. devlink and probe deferrals should make sure you always
>>> get a valid clock handle for the cpufreq driver..
>>
>> Yes, the cpufreq driver gets a valid clock handle. However the hang happens
>> early, when the 'apcs_alias0_core' clock is not registered yet. So CCF does not
>> know that the clock (hence the CPU) is a consumer of GPLL0.
> 
> So is that the late_initcall kicking in early, disabling unused
> clocks,

No, disabling unused clocks happens much later.

> or is there some other logic that ends up disabling the
> GPLL?

In the actual case, it is being disabled by runtime PM, which happens due to the
pm_runtime_put() call in the 'ipq_cmn_pll' driver's probe function.

Adding a WARN() into the clk_alpha_pll_disable() function results in this message:

  WARNING: disabling 'gpll0_main', expect a system hang!!!
  WARNING: at clk_alpha_pll_disable+0xd8/0x108, CPU#0: kworker/u8:0/11
  Modules linked in:
  CPU: 0 UID: 0 PID: 11 Comm: kworker/u8:0 Not tainted 7.3.0-rc1 #0 PREEMPT
  Hardware name: TP-Link Archer AX55 v1 (DT)
  Workqueue: pm pm_runtime_work
  ...
  Call trace:
   clk_alpha_pll_disable+0xd8/0x108 (P)
   clk_core_disable+0xec/0x278                 # gpll0_main
   clk_core_disable+0x110/0x278                # gpll0
   clk_core_disable+0x110/0x278                # pcnoc_bfdcd_clk_src
   clk_core_disable+0x110/0x278                # pcnoc_clk_src
   clk_core_disable+0x110/0x278                # gcc_cmn_blk_ahb_clk
   clk_disable+0x38/0x60
   pm_clk_suspend+0x120/0x170
   pm_generic_runtime_suspend+0x34/0x58
   __rpm_callback+0x50/0x200
   rpm_callback+0x60/0x78
   rpm_suspend+0xf4/0x5e8
   pm_runtime_work+0xd4/0xe0
   process_one_work+0x258/0x860
   worker_thread+0x1c8/0x378
   kthread+0x140/0x158
   ret_from_fork+0x10/0x20

However the problem is not specific to the ipq_cmn_pll driver. It is a race
between probing different devices.

For example, consider a simplified probe function of a driver:

  static int ipq5018_gpll0_consumer_probe(struct platform_device *pdev)
  {
          struct clk *clk;

          clk = devm_clk_get_enabled(&pdev->dev, "foo");
          if (IS_ERR(clk))
                  return PTR_ERR(clk);

          return some_function();
  }

Then assume the followings:
  - "foo" is a descendant clock of GPLL0
  - the probe function runs before probing other devices, so the probed device
    will be the first consumer of GPLL0
  - some_function() returns with an error code

The result will be the same hang. Due to the probe failure, devres disables the
clock, but since the the device is the only consumer of GPLL0, it is getting
disabled as well.

Here is the repective WARN result:

  WARNING: disabling 'gpll0_main', expect a system hang!!!
  WARNING: at clk_alpha_pll_disable+0xd8/0xf8, CPU#1: swapper/0/1
  Modules linked in:
  CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.3.0-rc1 #0 PREEMPT
  Hardware name: TP-Link Archer AX55 v1 (DT)
  ..
  Call trace:
   clk_alpha_pll_disable+0xd8/0xf8 (P)
   clk_core_disable+0xdc/0x268
   clk_disable+0x38/0x60
   clk_disable_unprepare+0x18/0x38
   devm_clk_release+0x2c/0x50
   dr_node_release+0x24/0x38
   release_nodes+0x78/0x118
   devres_release_all+0x84/0xf0
   device_unbind_cleanup+0x34/0x98
   really_probe+0x190/0x3f0
   __driver_probe_device+0x174/0x1e0
   driver_probe_device+0xc4/0x130
   __driver_attach+0x108/0x258
   bus_for_each_dev+0x6c/0xb8
   driver_attach+0x2c/0x40
   bus_add_driver+0x128/0x258
   driver_register+0x68/0x138
   __platform_driver_register+0x30/0x48
   ipq5018_gpll0_consumer_driver_init+0x2c/0x40
   do_one_initcall+0x6c/0x548
   kernel_init_freeable+0x264/0x388
   kernel_init+0x34/0x1f0
   ret_from_fork+0x10/0x20

Maybe this helps to understand the problem.

Regards,
Gabor