Re: [PATCH v3 8/8] arm64: dts: renesas: r9a08g046: Enable TSU

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] arm64: dts: io-channels specifier uses software array index instead of hardware channel
--

commit e43366f80cfffd32ae026b33a6ad6c170b125e78
Author: Biju Das <biju.das.jz@bp.renesas.com>

arm64: dts: renesas: r9a08g046: Enable TSU

This commit adds cooling cells to CPU nodes and describes the ADC1 and
TSU nodes to establish a CPU thermal zone. It configures passive and
critical trip points along with cooling maps for thermal mitigation.

> diff --git a/arch/arm64/boot/dts/renesas/r9a08g046.dtsi b/arch/arm64/boot/dts/renesas/r9a08g046.dtsi
> index c63a857f0e5b0..a2f6718c0043a 100644
> --- a/arch/arm64/boot/dts/renesas/r9a08g046.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a08g046.dtsi
[ ... ]
> @@ -270,6 +274,37 @@ scif5: serial@1004e000 {
>  			status = "disabled";
>  		};
>  
> +		adc1: adc@108c0000 {
> +			compatible = "renesas,r9a08g046-adc1";
[ ... ]
> +			#io-channel-cells = <1>;
> +
> +			channel@8 {
> +				reg = <8>;
> +			};
> +		};
> +
> +		tsu: thermal@108d0000 {
> +			compatible = "renesas,r9a08g046-tsu";
> +			reg = <0 0x108d0000 0 0x10000>;
> +			clocks = <&cpg CPG_MOD R9A08G046_TSU_PCLK>;
> +			resets = <&cpg R9A08G046_TSU_PRESETN>;
> +			power-domains = <&cpg>;
> +			#thermal-sensor-cells = <0>;
> +			io-channels = <&adc1 0>;

[Severity: Medium]
Does this io-channels property correctly map to the hardware channel, or does
it bake a Linux-specific software index into the device tree?

In the tsu node of arch/arm64/boot/dts/renesas/r9a08g046.dtsi, the ADC node
explicitly defines channel 8 (channel@8), but this property uses index 0.
This violates DT principles by encoding the driver's internal software array
index rather than the physical hardware channel ID.

Because the rzg2l_adc driver currently lacks a fwnode_xlate callback, it
falls back to __fwnode_iio_simple_xlate(). The driver populates
indio_dev->channels with the single active DT channel, so
indio_dev->num_channels is 1. If the DT correctly specified <&adc1 8>, the
fallback translator would fail since 8 >= 1.

Does bypassing this failure by using <&adc1 0> introduce a brittle dependency
on the subnode order that will silently break the TSU if other channels are
ever added?

> +			io-channel-names = "tsu";
> +		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922042707.116378-1-biju.das.jz@bp.renesas.com?part=8