Re: [PATCH v3 02/10] arm: dts: renesas: r8a7740: Add clocks for FSI

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] System hang regression due to bisectability breakage (clock disabled by framework).
- [Low] DT Binding Schema Violation due to skipped positional items in the `clocks` array.
--

commit 2d24adee7eadd7ba80ff4dc222250fe7259e1d9e
Author: bui duc phuc <phucduc.bui@gmail.com>

arm: dts: renesas: r8a7740: Add clocks for FSI

Add the SPU clock to the FSI node to ensure it is enabled before register
access, preventing potential system hangs.
Add missing clocks for FSI (icka/b, xcka/b).

> diff --git a/arch/arm/boot/dts/renesas/r8a7740.dtsi b/arch/arm/boot/dts/renesas/r8a7740.dtsi
> index d13ab86c3ab47..6f9d9bbfd159a 100644
> --- a/arch/arm/boot/dts/renesas/r8a7740.dtsi
> +++ b/arch/arm/boot/dts/renesas/r8a7740.dtsi
> @@ -393,7 +393,11 @@ sh_fsi2: sound@fe1f0000 {
>  		compatible = "renesas,fsi2-r8a7740", "renesas,sh_fsi2";
>  		reg = <0xfe1f0000 0x400>;
>  		interrupts = <GIC_SPI 9 0x4>;
> -		clocks = <&mstp3_clks R8A7740_CLK_FSI>;
> +		clocks = <&mstp3_clks R8A7740_CLK_FSI>, <&spu_clk>,
> +			<&fsia_clk>, <&fsib_clk>, <&fsiack_clk>,
> +			<&fsibck_clk>;

Will adding the spu clock to the device tree without the corresponding driver
support cause the common clock framework to automatically disable it during
system initialization?

If the bootloader leaves the spu clock enabled, and the kernel disables it
because the driver hasn't claimed it yet, could this cause a regression where
the system hangs on subsequent register accesses by the fsi driver?

To maintain bisectability, should the driver be updated to manage the spu
clock before or in the same commit as this device tree update? I see this
regression was addressed in a later commit adding spu clock control in
hw_startup/shutdown, but it may break bisectability here.

> +		clock-names = "fck", "spu", "icka", "ickb", "xcka",
> +				"xckb";

Does appending the external clocks (xcka and xckb) here without the internal
dividers (diva and divb) violate the strict positional order defined in the
device tree binding schema?

The dt-binding schema for renesas,sh_fsi2 defines the clocks property as an
ordered list where the 5th and 6th items are the internal dividers, and the
7th and 8th are the external clocks.

Since dt-validate evaluates array items positionally, will it evaluate the
external clocks against the internal divider descriptions? Should the array
be padded with dummy elements (like <0>) to maintain the strict positional
order?

>  		power-domains = <&pd_a4mp>;
>  		status = "disabled";
>  	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260510084303.122426-1-phucduc.bui@gmail.com?part=2