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

On 7/30/26 13:49, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] The SDHI0 mux logical state mapping and GPIO polarity are inverted relative to the shared device tree overlays, breaking both eMMC and microSD routing.
> --
>
> --- Patch [5]: [PATCH v4 5/5] arm64: dts: renesas: add support for solidrun rzg2lc som and hb-iiot evb ---
> commit 5989cde52b0b479fb2863119947d3305e7ea28ea
> Author: Josua Mayer <[email protected]>
>
> arm64: dts: renesas: add support for solidrun rzg2lc som and hb-iiot evb
>
> Add support for the SolidRun RZ/G2LC SoM on Hummingboard IIoT.
>
>> diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
>> index 5242eff76ef54..79c06db9ab138 100644
>> --- a/arch/arm64/boot/dts/renesas/Makefile
>> +++ b/arch/arm64/boot/dts/renesas/Makefile
>> @@ -165,6 +165,15 @@ dtb-$(CONFIG_ARCH_R9A07G043) += r9a07g043u11-smarc-du-adv7513.dtb
>>   r9a07g043u11-smarc-pmod-dtbs := r9a07g043u11-smarc.dtb r9a07g043-smarc-pmod.dtbo
>>   dtb-$(CONFIG_ARCH_R9A07G043) += r9a07g043u11-smarc-pmod.dtb
>>   
>> +dtb-$(CONFIG_ARCH_R9A07G044) += r9a07g044c2-hummingboard-iiot.dtb
>> +r9a07g044c2-hummingboard-iiot-emmc-dtbs := r9a07g044c2-hummingboard-iiot.dtb rzg2l-sr-som-emmc.dtbo
>> +dtb-$(CONFIG_ARCH_R9A07G044) += r9a07g044c2-hummingboard-iiot-emmc.dtb
>> +r9a07g044c2-hummingboard-iiot-microsd-dtbs := r9a07g044c2-hummingboard-iiot.dtb rzg2l-hummingboard-iiot-microsd.dtbo
> [ ... ]
>
>> 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..59635ac842d36
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/renesas/rzg2lc-sr-som.dtsi
>> @@ -0,0 +1,374 @@
>> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +/*
>> + * Device Tree Source for the RZ/G2LC Solidrun SOM
>> + *
>> + * Copyright 2023 SolidRun Ltd.
>> + * Copyright 2025 Josua Mayer <[email protected]>
>> + */
> [ ... ]
>
>> +	sdhi0_mux: mux-controller-0 {
>> +		compatible = "gpio-mux";
>> +		#mux-control-cells = <0>;
>> +		#mux-state-cells = <1>;
>> +		/*
>> +		 * Mux switches SD0_DATA[0-3], SD0_CMD & SD0_CLK between
>> +		 * on-SoM eMMC and board-to-board connector using one gpio:
>> +		 * 0 = connector, 1 = eMMC.
>> +		 */
>> +		mux-gpios = <&pinctrl RZG2L_GPIO(22, 1) GPIO_ACTIVE_HIGH>;
> [Severity: High]
> Does this inverted mux logical state mapping break the eMMC and microSD routing?
>
> The Makefile applies shared overlays (rzg2l-sr-som-emmc.dtbo and
> rzg2l-hummingboard-iiot-microsd.dtbo) to this base DT.
>
> The shared eMMC overlay hardcodes mux-states = <&sdhi0_mux 0>, and the
> microSD overlay hardcodes mux-states = <&sdhi0_mux 1>.
>
> Since this file defines the mux with GPIO_ACTIVE_HIGH and a logical mapping
> of 0 = connector, 1 = eMMC (which is inverted from the G2L base DT that uses
> GPIO_ACTIVE_LOW and 0 = eMMC, 1 = connector), the shared overlays will request
> the wrong logical states.
>
> Will this cause the eMMC overlay to incorrectly route SDHI0 to the connector,
> and the microSD overlay to incorrectly route it to the eMMC?
The polarity of the mux gpio control is in fact swapped between RZ/G2L
and RZ/G2LC SoM, so this works exactly as intended.

The overlay shared by G2L and G2LC SoMs selects the mux,
and the SoM dtsi describes the mux.