Re: [PATCH] clk: qcom: ipq-cmn-pll: keep the CMN block bus clocks enabled

[Stanislaw Pal]

On 8/8/2026 Mieczyslaw Nalewaj wrote:
> Given the hang is reportedly 100% reproducible pre-userspace, is there
> a concrete next step to root-cause it, or is v3 the right call for now
> with a follow-up tracked separately?

There is a concrete step, and I ran it today on a third board - this
time with no code of mine involved at all.

Hardware: GL.iNet GL-B3000 (IPQ5018), a supported in-tree OpenWrt
board, running the current bone-stock OpenWrt snapshot (kernel
6.18.41, which does not carry this patch). Out of the box it boot
loops: the last line on earlycon is at ~0.39s (the final initcall
before the driver probes start), then silence and a watchdog reset,
100% reproducible.

Adding exactly one thing to the kernel command line - no rebuild, no
patch:

    initcall_blacklist=ipq_cmn_pll_clk_driver_init

makes the same image boot: serial, SPI-NAND, SMEM partitions,
remoteproc all come up.

Combined with what we already know from the other two boards, this
isolates the trigger fairly tightly:

  - cmn-pll probe runs, last PM reference dropped (vanilla): dies
  - cmn-pll probe never runs (blacklist, clocks stay as the
    bootloader left them, i.e. enabled): boots
  - cmn-pll probe runs, reference held: boots - verified on this same
    board today with an image carrying v3 of this patch and nothing
    else changed; it comes up fully (shell over SSH, NAND, remoteproc),
    and clk_summary shows the CMN block bus clocks held enabled by the
    provider device.

The only variable separating the dying case from both surviving ones
is the AHB/SYS gate after probe. What exactly performs the fatal
access afterwards is the remaining open question - and this board is
well suited to answer it, since it has full U-Boot control and can run
experiment kernels from RAM. I intend to bisect that next (my current
suspicion is that the CMN block AHB clock also feeds the register path
of neighbouring blocks in the same region - MDIO at 0x88000/0x90000,
uniphy at 0x98000, CMN at 0x9b000 - which would explain why the CCF's
own runtime PM handling around the clk ops cannot help here). I am
happy to run any experiment Jie would like to see on this hardware.

So to answer the question directly: I believe v3 is the right call now
- three IPQ5018 boards, including a stock-image one, cannot boot
without it and the cost of keeping two bus clocks of a small block
enabled is negligible - with the exact-access root-causing tracked as
a follow-up. If the follow-up ends up pointing at a cleaner fix (e.g.
describing the real consumers of these bus clocks in DT), I will
gladly send it as a successor.

Thanks,
Stanislaw