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

On 8/10/2026 12:10 AM, Stanislaw Pal wrote:
> 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

I tested the latest linux-next code with the following changes:

Enabled the MDIO interface and added the Ethernet PHY as DTS below.
Enabled CONFIG_IPQ_CMN_PLL and CONFIG_MDIO_IPQ4019 as kernel modules.

--- a/arch/arm64/boot/dts/qcom/ipq5018.dtsi



+++ b/arch/arm64/boot/dts/qcom/ipq5018.dtsi



@@ -219,12 +219,11 @@ mdio0: mdio@88000 {



                              <0x019475c4 0x4>;



                        #address-cells = <1>;



                        #size-cells = <0>;



+                       clock-frequency = <6250000>;







                        clocks = <&gcc GCC_MDIO0_AHB_CLK>;



                        clock-names = "gcc_mdio_ahb_clk";







-                       status = "disabled";



-



                        ge_phy: ethernet-phy@7 {



                                compatible = "ethernet-phy-id004d.d0c0";



                                reg = <7>;



@@ -241,11 +240,16 @@ mdio1: mdio@90000 {



                        reg = <0x00090000 0x64>;



                        #address-cells = <1>;



                        #size-cells = <0>;



+                       pinctrl-0 = <&mdio_pins>;



+                       pinctrl-names = "default";



+                       clock-frequency = <6250000>;







                        clocks = <&gcc GCC_MDIO1_AHB_CLK>;



                        clock-names = "gcc_mdio_ahb_clk";







-                       status = "disabled";



+                       ethernet-phy@1c {



+                               reg = <0x1c>;



+                       };



                };







                cmn_pll: clock-controller@9b000 {



@@ -427,6 +431,23 @@ uart1_pins: uart1-state {



                                drive-strength = <8>;



                                bias-pull-down;



                        };



+



+                       mdio_pins: mdio-state {



+                               mdc-pins {



+                                       pins = "gpio36";



+                                       function = "mdc";



+                                       drive-strength = <8>;



+                                       bias-pull-up;



+                               };



+



+                               mdio-pins {



+                                       pins = "gpio37";



+                                       function = "mdio";



+                                       drive-strength = <8>;



+                                       bias-pull-up;



+                               };



+                       };



+



                };

The board booted successfully on the IPQ5018 RDP platform.

# insmod ipq-cmn-pll.ko
#
# devmem 0x1856308
0x80000000
# devmem 0x185630c
0x80000000
#
# insmod mdio-ipq4019.ko
#
# ls -l /sys/bus/mdio_bus/devices/
88000.mdio-1:07/  90000.mdio-1:1c/
# ls -l /sys/bus/mdio_bus/devices/
total 0
lrwxrwxrwx    1 root     root             0 Jan  1 00:01 88000.mdio-1:07
->
../../../devices/platform/soc@0/88000.mdio/mdio_bus/88000.mdio-1/88000.mdio-1:07
lrwxrwxrwx    1 root     root             0 Jan  1 00:01 90000.mdio-1:1c
->
../../../devices/platform/soc@0/90000.mdio/mdio_bus/90000.mdio-1/90000.mdio-1:1c