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

On 8/11/2026 Jie Luo wrote:
> The board booted successfully on the IPQ5018 RDP platform.
>
> # insmod ipq-cmn-pll.ko
> # devmem 0x1856308
> 0x80000000
> # insmod mdio-ipq4019.ko
> # ls -l /sys/bus/mdio_bus/devices/
> 88000.mdio-1:07/  90000.mdio-1:1c/

Thank you for running this. Your result is correct, and I can now
reproduce the equivalent on the failing board - together the experiments
finally bound the problem tightly. I spent the evening on a GL-B3000
running three variants of the same tree, all with the fix reverted
(i.e. vanilla put in probe). Full data below.

Variant 1: gate delayed to idle. Vanilla behaviour, but the last
reference is dropped via pm_runtime_put_autosuspend() with a 60 s
autosuspend delay, and uniphy (the only in-tree consumer of the PLL
outputs in the OpenWrt tree; mainline has none) disabled in DT so the
gate actually lands. Result: the gate lands at ~75 s on an idle system
and the board does not care. runtime_status reads "suspended", both
WiFi radios keep serving clients, the console works, nothing in dmesg.
This is your RDP result reproduced on the board that dies: with the
system quiet, gating these clocks is harmless, and nothing in steady
state needs them - your efficiency argument is confirmed.

Variant 2: same DT (uniphy disabled), unmodified vanilla driver, so the
same gate lands right after probe, during early boot. Result over seven
boots of the identical image: one survived, six died with the familiar
signature - silence before the serial console comes up, then a watchdog
reset. So the crash does not need the ethernet path at all: it happens
with every PLL consumer disabled in DT, and it is probabilistic.

Variant 3 is the stock configuration (uniphy enabled): 100% boot loop
on this board, and the same on three boards from three vendors.

One methodological note for fairness: variants 1 and 2 are initramfs
images booted from RAM over tftp, so their early-boot activity profile
differs from a normal flash boot (no UBI attach in the fatal window,
for one). The 6-of-7 ratio is specific to that path and I would not
generalize the number. The stock 100% failure, however, *is* the
normal NAND boot path, so both paths are represented in the data and
both die - only the probability differs with the timing profile, which
is itself consistent with the collision picture.

Putting it together:

  gate at idle          -> safe, deterministically (your RDP, my V1)
  gate during boot      -> dies, probabilistically (V2: 6 of 7)
  never gate (this fix) -> boots, deterministically (3 boards)

The only variable separating V1 from V2 is *when* the gate lands. That
also retires my earlier "shared CSR bridge" theory - with the whole
ethernet path disabled the board still dies - and explains every odd
observation from the last month: the victim being whichever device
probes next, and the failure probability swinging wildly with binary
layout (both are just micro-timing of an asynchronous pm_clk_suspend
landing somewhere in early-boot bus activity; which transaction it
collides with is still not pinned down).

It also shows why a consumer-based model cannot close this hole: the
fatal window lies *between* the cmn-pll probe and the moment any
consumer could possibly take its first reference. On boards where
Linux is entered with these clocks running (every bootloader does), the
put in probe is what creates that window.

I am open on the shape of the fix - if you would rather see the
reference dropped once boot has settled, or a synchronous gate, I will
gladly test that on this board. But the boards are unbootable today,
and holding the reference is the smallest change that deterministically
removes the window, so I would still ask for v3 (or an equivalent) now,
with refinements as follow-ups.

Thanks,
Stanislaw