Re: [PATCH 1/1] arm64: dts: s32g: add SAR ADC support for s32g2 and s32g3

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The 'vref' property included in the 'adc0' and 'adc1' nodes violates the devicetree binding schema for 'nxp,s32g2-sar-adc' and will cause 'make dtbs_check' failures.
- [Low] The 'adc1: adc@402e8000' node is placed out of order by unit address in both 's32g2.dtsi' and 's32g3.dtsi'.
--

commit 7673e90a3952520a499f13a94f36f7b0fd2320e8
Author: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>

arm64: dts: s32g: add SAR ADC support for s32g2 and s32g3

This commit adds ADC0 and ADC1 nodes for S32G2 and S32G3 SoCs.

> diff --git a/arch/arm64/boot/dts/freescale/s32g2.dtsi b/arch/arm64/boot/dts/freescale/s32g2.dtsi
> --- a/arch/arm64/boot/dts/freescale/s32g2.dtsi
> +++ b/arch/arm64/boot/dts/freescale/s32g2.dtsi
[ ... ]
> @@ -554,6 +554,28 @@ i2c2: i2c@401ec000 {
>  			status = "disabled";
>  		};
>  
> +		adc0: adc@401f8000 {
> +			compatible = "nxp,s32g2-sar-adc";
> +			reg = <0x401f8000 0x1000>;
> +			interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&clks 0x41>;
> +			dmas = <&edma0 0 32>;
> +			dma-names = "rx";
> +			vref = <1800>;

Does the vref property violate the nxp,s32g2-sar-adc devicetree binding
schema? The schema sets additionalProperties to false and does not define a
vref property, which will cause make dtbs_check failures. The standard
practice is to use a vref-supply phandle rather than a raw integer value.

> +			status = "disabled";
> +		};
> +
> +		adc1: adc@402e8000 {
> +			compatible = "nxp,s32g2-sar-adc";
> +			reg = <0x402e8000 0x1000>;
> +			interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&clks 0x41>;
> +			dmas = <&edma1 1 32>;
> +			dma-names = "rx";
> +			vref = <1800>;
> +			status = "disabled";
> +		};
> +
>  		swt4: watchdog@40200000 {

Should the adc1 node be placed after the swt4 node to maintain ascending
unit address sorting? 0x402e8000 is greater than 0x40200000.

> diff --git a/arch/arm64/boot/dts/freescale/s32g3.dtsi b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> --- a/arch/arm64/boot/dts/freescale/s32g3.dtsi
> +++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
[ ... ]
> @@ -617,6 +617,28 @@ i2c2: i2c@401ec000 {
>  			status = "disabled";
>  		};
>  
> +		adc0: adc@401f8000 {
> +			compatible = "nxp,s32g3-sar-adc", "nxp,s32g2-sar-adc";
> +			reg = <0x401f8000 0x1000>;
> +			interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&clks 0x41>;
> +			dmas = <&edma0 0 32>;
> +			dma-names = "rx";
> +			vref = <1800>;

Is this vref property intended? Similar to the s32g2.dtsi file, this will
trigger schema validation errors.

> +			status = "disabled";
> +		};
> +
> +		adc1: adc@402e8000 {
> +			compatible = "nxp,s32g3-sar-adc", "nxp,s32g2-sar-adc";
> +			reg = <0x402e8000 0x1000>;
> +			interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&clks 0x41>;
> +			dmas = <&edma1 1 32>;
> +			dma-names = "rx";
> +			vref = <1800>;
> +			status = "disabled";
> +		};
> +
>  		swt4: watchdog@40200000 {

Does this adc1 node placement also violate ascending unit address sorting
rules here in s32g3.dtsi?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513142948.640057-2-khristineandreea.barbulescu@oss.nxp.com?part=1