Re: [PATCH v4 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] Applying the microSD overlay causes a 3.3V overvoltage on the eMMC's 1.8V domain pins.
- [Medium] Misplaced `dr_mode` property in USB PHY nodes.
--

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

Add support for the SolidRun RZ/G2L SoM on Hummingboard IIoT. The SoM
features Ethernet, eMMC, DDR, WiFi/Bluetooth, and SDHI Mux.

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
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/rzg2l-hummingboard-iiot-common.dtsi
[ ... ]
> +&usb2_phy0 {
> +	dr_mode = "host";
> +	vbus-supply = <&vbus1>;
> +};
> +
> +&usb2_phy1 {
> +	dr_mode = "host";
> +};

[Severity: Medium]
Does setting dr_mode directly on the PHY nodes work as intended here?

The phy-rcar-gen3-usb2.c driver calls of_usb_get_dr_mode_by_phy() to extract
this property, which iterates over the PHY's consumers (the controller nodes).

Because dr_mode is placed on the PHY node instead of the consumer controller
nodes, it appears it will return USB_DR_MODE_UNKNOWN, skipping OTG
initialization. Should this property be moved to the appropriate controller
nodes?

> diff --git a/arch/arm64/boot/dts/renesas/rzg2l-hummingboard-iiot-microsd.dtso b/arch/arm64/boot/dts/renesas/rzg2l-hummingboard-iiot-microsd.dtso
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/rzg2l-hummingboard-iiot-microsd.dtso
[ ... ]
> +&sdhi0 {
> +	bus-width = <4>;
> +	full-pwr-cycle;
> +	mux-states = <&sdhi0_mux 1>;
> +	pinctrl-0 = <&sdhi0_pins>, <&sdhi0_cd_pins>;
> +	pinctrl-1 = <&sdhi0_uhs_pins>, <&sdhi0_cd_pins>;

[Severity: High]
Could applying the sdhi0_pins group here cause a 3.3V overvoltage on the
eMMC's 1.8V pins?

The hardware mux sdhi0_mux only switches SD0_DATA0 through SD0_DATA3,
SD0_CMD, and SD0_CLK. This leaves SD0_DATA4 through SD0_DATA7 permanently
connected to the eMMC, which operates on a fixed 1.8V domain.

However, sdhi0_pins configures all 8 pins (including SD0_DATA4 through
SD0_DATA7) with power-source = <3300>:

arch/arm64/boot/dts/renesas/rzg2l-sr-som.dtsi:
    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>;
    };

When this microSD overlay is loaded and the controller operates at 3.3V, does
this apply 3.3V to the 1.8V eMMC pins? Should there be a dedicated 4-bit
pinctrl group for microSD mode that excludes DAT4-7?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730-rzg2-sr-boards-v4-0-08bc459578dc@solid-run.com?part=3