Re: [PATCH v5 3/5] arm64: dts: renesas: add support for solidrun rzg2l som and hb-iiot evb

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Duplicate and conflicting pin configurations for SD0_DATA4..7.
- [Medium] Incorrect regulator voltage definition for 1.2V regulator (configured as 1.8V).
--

--- Patch [3]: [PATCH v5 3/5] arm64: dts: renesas: add support for solidrun rzg2l som and hb-iiot evb ---
commit a06fa05f228a45d469963a631b35258ab838f598
Author: Josua Mayer <josua@solid-run.com>

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

This commit adds device tree support for the SolidRun RZ/G2L SoM on the
Hummingboard IIoT. The SoM features dual Ethernet, eMMC, DDR, and WiFi/BT.
Overlays are included for eMMC, microSD, and RS485 features that depend on
configurable mux states.

Link: https://www.solid-run.com/embedded-industrial-iot/renesas-rz-family/rz-g2l-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/rzg2l-hummingboard-iiot-common.dtsi b/arch/arm64/boot/dts/renesas/rzg2l-hummingboard-iiot-common.dtsi
> new file mode 100644
> index 0000000000000..ca5a647d43dcc
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/rzg2l-hummingboard-iiot-common.dtsi
> @@ -0,0 +1,560 @@

[ ... ]

> +	v_1_2: regulator-1-2 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "1v2";
> +		regulator-max-microvolt = <1800000>;
> +		regulator-min-microvolt = <1800000>;
> +	};

[Severity: Medium]
Are the regulator limits set to the intended values here?

The regulator is named v_1_2 in the node name and "1v2" in the regulator-name
property, but the regulator-max-microvolt and regulator-min-microvolt fields
are configured for 1.8V (1800000).

Could this misconfiguration cause issues on boot when downstream drivers
like the USB hub driver query this regulator?

> +
> +	v_3_3: regulator-3-3 {

[ ... ]

> diff --git a/arch/arm64/boot/dts/renesas/rzg2l-sr-som.dtsi b/arch/arm64/boot/dts/renesas/rzg2l-sr-som.dtsi
> new file mode 100644
> index 0000000000000..f08d2fbaa5211
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/rzg2l-sr-som.dtsi
> @@ -0,0 +1,461 @@

[ ... ]

> +	sdhi0_4bit_pins: sdhi0-4bit {
> +		sd0_ctrl_dat03 {
> +			pins = "SD0_DATA0", "SD0_DATA1", "SD0_DATA2", "SD0_DATA3",
> +			       "SD0_DATA4", "SD0_DATA5", "SD0_DATA6", "SD0_DATA7",
> +			       "SD0_CLK", "SD0_CMD";
> +			power-source = <3300>;
> +		};

[Severity: High]
Should SD0_DATA4 through SD0_DATA7 be included in the pins list for 
sd0_ctrl_dat03?

When sdhi0_4bit_pins is applied during probe, sd0_ctrl_dat03 configures
these pins with power-source = <3300>. The sd0_dat47 subnode directly below
configures them again with bias-disable and input-enable.

Could the short window between applying these two nodes cause default pull-ups
on the 3.3V domain to backdrive the 1.8V eMMC pins?

> +
> +		/*
> +		 * Pins 4-7 are hard-wired to eMMC with 1.8V IO voltage,
> +		 * with all pins sharing a single voltage domain.
> +		 *
> +		 * Configure as input without pull to avoid overvoltage,
> +		 * and accidental use e.g. as gpio (default pin-function).
> +		 */
> +		sd0_dat47 {
> +			bias-disable;
> +			input-enable;
> +			pins = "SD0_DATA4", "SD0_DATA5", "SD0_DATA6", "SD0_DATA7";
> +			power-source = <3300>;
> +		};
> +	};
> +
> +	sdhi0_4bit_uhs_pins: sdhi0-4bit-uhs {
> +		sd0_ctrl_dat03 {
> +			pins = "SD0_DATA0", "SD0_DATA1", "SD0_DATA2", "SD0_DATA3",
> +			       "SD0_DATA4", "SD0_DATA5", "SD0_DATA6", "SD0_DATA7",
> +			       "SD0_CLK", "SD0_CMD";
> +			power-source = <1800>;
> +		};

[Severity: High]
Does this pin list also incorrectly duplicate SD0_DATA4 through SD0_DATA7?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260809-rzg2-sr-boards-v5-0-19c662358e36@solid-run.com?part=3