Re: [PATCH v3 4/4] arm64: dts: renesas: add support for solidrun rzg2lc som and hb-iiot evb

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Device tree node name collision for sdhi0 pins causes 1.8V override for 3.3V state.
- [High] Statically allocated reserved-memory ranges fall outside defined physical RAM.
- [High] Devicetree configuration contradiction for vmmc GPIO polarity.
--

commit 07693c5c9c5d074ca939a25ad18d8d94023515ac
Author: Josua Mayer <josua@solid-run.com>

arm64: dts: renesas: add support for solidrun rzg2lc som and hb-iiot evb

Add support for the SolidRun RZ/G2LC SoM on Hummingboard IIoT. The RZ/G2LC
SoM was designed to be pin compatible to G2L SoM, with slightly reduced
feature set.

Link: https://www.solid-run.com/embedded-industrial-iot/renesas-rz-family/rz-g2lc-som/
Link: https://www.solid-run.com/embedded-industrial-iot/renesas-rz-family/hummingboard-rz-series-sbcs/hummingboard-rz-g2l-iot-sbc/

> diff --git a/arch/arm64/boot/dts/renesas/r9a07g044c2-hummingboard-iiot.dts b/arch/arm64/boot/dts/renesas/r9a07g044c2-hummingboard-iiot.dts
> new file mode 100644
> index 0000000000000..06d9d031cbe91
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r9a07g044c2-hummingboard-iiot.dts
[ ... ]
> +&vmmc {
> +	gpio = <&pinctrl RZG2L_GPIO(18, 1) GPIO_ACTIVE_LOW>;
> +};

In the common file rzg2l-hummingboard-iiot-common.dtsi, vmmc is defined
with the enable-active-high boolean property. Since this overrides the gpio
property to use GPIO_ACTIVE_LOW, does the enable-active-high property need
to be explicitly removed using /delete-property/ enable-active-high;?

According to fixed-regulator bindings, if enable-active-high is present, it
forces the GPIO line to be active high, overriding the GPIO_ACTIVE_LOW flag.
Will this result in the SD power control signal functioning with inverted
polarity and breaking SD card power sequencing?

> diff --git a/arch/arm64/boot/dts/renesas/rzg2lc-sr-som.dtsi b/arch/arm64/boot/dts/renesas/rzg2lc-sr-som.dtsi
> new file mode 100644
> index 0000000000000..0505af6926a5e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/rzg2lc-sr-som.dtsi
[ ... ]
> +	reserved-memory {
> +		ranges;
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +
> +		mmp_reserved: linux,multimedia@68000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x0 0x68000000 0x0 0x8000000>;
> +			reusable;
> +		};
> +
> +		global_cma: linux,cma@58000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x0 0x58000000 0x0 0x10000000>;
> +			reusable;
> +			linux,cma-default;
> +		};
> +	};
[ ... ]
> +	memory@40000000 {
> +		reg = <0x0 0x40000000 0x0 0x20000000>;
> +		device_type = "memory";
> +	};

The standard memory configuration is defined as 512MB ending at 0x60000000.
Do these static reserved-memory ranges fall outside the defined physical
RAM?

The global_cma reservation ends at 0x68000000 and mmp_reserved ends at
0x70000000. Will attempting to reserve and map non-existent physical
memory cause the CMA allocator to fail or the kernel to panic during early
boot on 512MB hardware variants?

Could these use dynamic allocation with alloc-ranges instead of fixed reg
properties, or be resized to fit strictly within the minimum supported RAM
size?

[ ... ]
> +&pinctrl {
[ ... ]
> +	sdhi0_pins: sdhi0 {
> +		pins = "SD0_DATA0", "SD0_DATA1", "SD0_DATA2", "SD0_DATA3",
> +		       "SD0_DATA4", "SD0_DATA5", "SD0_DATA6", "SD0_DATA7",
> +		       "SD0_CLK", "SD0_CMD";
> +		power-source = <3300>;
> +	};
> +
> +	sdhi0_uhs_pins: sdhi0 {
> +		pins = "SD0_DATA0", "SD0_DATA1", "SD0_DATA2", "SD0_DATA3",
> +		       "SD0_DATA4", "SD0_DATA5", "SD0_DATA6", "SD0_DATA7",
> +		       "SD0_CLK", "SD0_CMD";
> +		power-source = <1800>;
> +	};

Does this cause a device tree node name collision? Both sdhi0_pins and
sdhi0_uhs_pins define a child node named sdhi0 inside pinctrl.

Because the Device Tree Compiler merges sibling nodes with identical names,
the properties of sdhi0_uhs_pins will overwrite sdhi0_pins. Both phandles
will point to a merged node with power-source = <1800>.

Will this break standard 3.3V SD card initialization since the pinctrl
subsystem will configure the default pins for 1.8V instead? Could the UHS
node be renamed to something like sdhi0-uhs to avoid the collision?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260512-rzg2-sr-boards-v3-0-f033fc96c906@solid-run.com?part=4