Re: [PATCH v10 08/12] clk: zte: Introduce a driver for zx297520v3 top clocks
flat view
From: sashiko-bot@kernel.org
Date: 2026-08-10 07:15:01
Also in:
linux-phy
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [Medium] `ahb-wclk` is assigned the wrong parent mux, breaking the clock topology. - [Low] The driver fails to compile because it uses `const` variables to initialize static array elements, which violates the C standard for constant expressions. --
--- Patch [8]: [PATCH v10 08/12] clk: zte: Introduce a driver for zx297520v3 top clocks ---commit e0f9a1aafed8640102d7aca0bbb0d89079e89c5f Author: Stefan Dösinger [off-list ref] clk: zte: Introduce a driver for zx297520v3 top clocks This commit introduces a new clock driver for the ZTE zx297520v3 SoC. It supports basic clocks, including PLLs, the AHB bus, timers, and the USB controller.
quoted hunk ↗ jump to hunk
diff --git a/drivers/clk/zte/clk-zx297520v3.c b/drivers/clk/zte/clk-zx297520v3.c new file mode 100644 index 0000000000000..504075590e6d2 --- /dev/null +++ b/drivers/clk/zte/clk-zx297520v3.c
[ ... ]
+static const struct zx_clock zx297520v3_top_clocks[] = {[ ... ]
+ /* osc26m division for clk_outX */
+ [ZX_CLK_OSC26M_D2] = FIXED_DIV("osc26m-d2", clk_main[0], 2),[Severity: Low] Will this cause a compiler error? In standard C, variables qualified with const are not considered constant expressions. Using clk_main array elements here to initialize elements of a static array will likely trigger an initializer element is not constant error. [ ... ]
quoted hunk ↗ jump to hunk
+ [ZX_CLK_WDT_T18_DIV] = DIV("wdt-t18-div", PARENT_ID(ZX_CLK_WDT_T18_MUX), + 0x48, 8, 4), + [ZX_CLK_USIM1_DIV] = DIV("usim1-div", clk_unknown, + 0x48, 12, 1),
[Severity: Low] Is this another place where a const variable (clk_unknown) will trigger a compiler error when used as a static array initializer? [ ... ]
quoted hunk ↗ jump to hunk
+ /* + * AHB clock gates: Disabling these cuts off the A53 from register access into 0x130000/ + * 0x140000, including the topcrm region, so it can't be re-enabled. Mark them critical for + * that reason. + * + * Gating this off does not stop the M0 rproc, nor does it stop M0 from accessing topcrm. It + * does however gate off M0 from the AXI interconnect, so it can't read RAM, Matrix, etc. So + * these bits here merely gate the bus, not the actual devices. + */ + [ZX_CLK_AHB_PCLK] = GATE("ahb-pclk", PARENT_ID(ZX_CLK_AHB_MUX), 0x54, 12, + CLK_IS_CRITICAL), + [ZX_CLK_AHB_WCLK] = GATE("ahb-wclk", PARENT_ID(ZX_CLK_M0_MUX), 0x54, 13, + CLK_IS_CRITICAL),
[Severity: Medium] Does ahb-wclk have the wrong parent mux assigned here? It is currently assigned ZX_CLK_M0_MUX instead of ZX_CLK_AHB_MUX. The comments state that changing the AHB mux affects USB network speeds, which implies that ZX_CLK_AHB_MUX is the actual hardware parent. [ ... ]
quoted hunk ↗ jump to hunk
+ /* + * How does this RTC work? I don't know, the ZTE kernel does not talk to it. The actual RTC + * is on the I2C-connected PMIC. + */ + [ZX_CLK_RTC_WCLK] = GATE("rtc-wclk", clk_unknown, 0x54, 1, 0),
[Severity: Low] Will this face the same static array initializer error as the other usages of clk_unknown? -- Sashiko AI review · https://sashiko.dev/#/patchset/20260810-zx29clk-v10-0-63846490712c@gmail.com?part=8