Re: [PATCH v5 9/9] arm64: dts: nuvoton: ma35d1: Add LXT crystal and correct HXT name

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] clk: nuvoton: DT change panics older kernels via name collision
--

commit bbea265e667383111c175f21144622719e32c1cb
Author: Miquel Raynal <miquel.raynal@bootlin.com>

arm64: dts: nuvoton: ma35d1: Add LXT crystal and correct HXT name

The clock controller takes its two crystal oscillator inputs from the
board: HXT and LXT. This commit fixes the HXT clock output name to "hxt"
instead of "clk_hxt", and adds the LXT fixed clock node.

> diff --git a/arch/arm64/boot/dts/nuvoton/ma35d1-iot-512m.dts b/arch/arm64/boot/dts/nuvoton/ma35d1-iot-512m.dts
> index 78534d613486a..cb7d6f9ee297e 100644
> --- a/arch/arm64/boot/dts/nuvoton/ma35d1-iot-512m.dts
> +++ b/arch/arm64/boot/dts/nuvoton/ma35d1-iot-512m.dts
> @@ -35,7 +35,14 @@ clk_hxt: clock-hxt {
>  		compatible = "fixed-clock";
>  		#clock-cells = <0>;
>  		clock-frequency = <24000000>;
> -		clock-output-names = "clk_hxt";
> +		clock-output-names = "hxt";

[Severity: High]
Could this change cause a regression with older kernels?

When booting an older kernel with this newly updated Device Tree,
of_clk_init() parses the DT and registers a fixed clock named "hxt".
Later, in drivers/clk/nuvoton/clk-ma35d1.c:ma35d1_clocks_probe(), the
driver unconditionally attempts to register its own fixed clock also named
"hxt", which fails due to the name collision and returns ERR_PTR(-EEXIST):

    hws[HXT] = ma35d1_clk_fixed("hxt", 24000000);

The driver does not validate the pointer and passes the ERR_PTR as a parent
for derived clocks like CAPLL:

    hws[CAPLL] = ma35d1_reg_clk_pll(dev, CAPLL, pllmode[0], "capll",
                                    hws[HXT], clk_base + REG_CLK_PLL0CTL0);

The Common Clock Framework (CCF) then dereferences the error pointer in
clk_core_fill_parent_index(), causing a fatal kernel panic on boot.

Although another commit in this series fixes the crash for the current
kernel by avoiding the error pointer dereference, it does not prevent the
regression on older kernels. The new DT will still crash older kernels
in the wild. Is there a way to describe the hardware without causing this
name collision?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260929-perso-ma35d1-upstream-clk-v5-0-68533e935ee4@bootlin.com?part=9