All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Biju Das" <biju.das.au@gmail.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org,
	wsa+renesas@sang-engineering.com
Subject: Re: [PATCH 1/3] arm64: dts: renesas: r9a08g046: Add SDHI nodes for RZ/G3L SoC and SDHI1 pincontrol on SMARC EVK
Date: Thu, 12 Nov 2026 19:25:42 +0000	[thread overview]
Message-ID: <sashiko-outbox-211760@kernel.org> (raw)
In-Reply-To: <20261112-sdhi_rzg3l-v1-1-ca30b209615d@bp.renesas.com>

Thank you for your contribution! Sashiko AI review found 4 potential
issues to consider:
- [High] arm64: dts: renesas: r9a08g046: undocumented SDHI compatible,
  clocks, and resets
- [Medium] arm64: dts: renesas: r9a08g046l48-smarc: sdhi1 left enabled
  when RZ_BOOT_MODE3=0
- [Medium] arm64: dts: renesas: r9a08g046l48-smarc: missing pull-up and
  no-op UHS pinconf
- [Medium] arm64: dts: renesas: r9a08g046: SDHI power-source not wired
  in pinctrl-rzg2l
--

commit c182c80f2e51018770e032cd10fb901dca56ea0e
Author: Biju Das <biju.das.jz@bp.renesas.com>

arm64: dts: renesas: r9a08g046: Add SDHI nodes for RZ/G3L SoC and SDHI1 pincontrol on SMARC EVK

This commit adds device tree nodes for the three SDHI controllers on the
RZ/G3L SoC (r9a08g046) and configures SDHI1 pinmux and voltage regulator
nodes on the RZ/G3L SMARC EVK board.

> diff --git a/arch/arm64/boot/dts/renesas/r9a08g046.dtsi b/arch/arm64/boot/dts/renesas/r9a08g046.dtsi
> index c63a857f0e5b0..3665ccbdd91be 100644
> --- a/arch/arm64/boot/dts/renesas/r9a08g046.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a08g046.dtsi
> @@ -762,9 +762,80 @@ dmac: dma-controller@11820000 {
>  			dma-channels = <16>;
>  		};
>  
> +		sdhi0: mmc@11c00000 {
> +			compatible = "renesas,sdhi-r9a08g046";
> +			reg = <0x0 0x11c00000 0 0x10000>;
> +			interrupts = <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cpg CPG_MOD R9A08G046_SDHI0_IMCLK>,
> +				 <&cpg CPG_MOD R9A08G046_SDHI0_CLK_HS>,
> +				 <&cpg CPG_MOD R9A08G046_SDHI0_IMCLK2>,
> +				 <&cpg CPG_MOD R9A08G046_SDHI0_IACLKM>,
> +				 <&cpg CPG_MOD R9A08G046_SDHI0_IACLKS>;
> +			clock-names = "core", "clkh", "cd", "aclkm", "aclks";
> +			max-frequency = <150000000>;
> +			resets = <&cpg R9A08G046_SDHI0_IXRST>,
> +				 <&cpg R9A08G046_SDHI0_IXRSTAXIM>,
> +				 <&cpg R9A08G046_SDHI0_IXRSTAXIS>;
> +			reset-names = "rst", "axim", "axis";
> +			power-domains = <&cpg>;
> +			status = "disabled";
> +		};

[Severity: High]
Can sdhi0, sdhi1, and sdhi2 bind to the Renesas SDHI driver or pass
dtbs_check with these properties?

"renesas,sdhi-r9a08g046" has no fallback compatible string and is not present
in renesas_sdhi_internal_dmac_of_match or
Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml.  The binding schema
also restricts clocks and clock-names to at most 4 entries, restricts resets
to 1 entry without reset-names, and only permits the vqmmc-regulator child
node (added under sdhi1 and sdhi2 below) for "renesas,sdhi-r9a09g057".  In
addition, renesas_sdhi_probe() only requests a single unnamed reset via
devm_reset_control_get_optional_exclusive_deasserted(&pdev->dev, NULL),
leaving the axim and axis resets unmanaged.

> diff --git a/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts b/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
> index 5289efd1a430a..0b6b7e109200f 100644
> --- a/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
> +++ b/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
> @@ -14,6 +14,7 @@
>  #define SW_GPIO4		1
>  #define SW_I3C_EN		0
>  #define SW_SER0_PMOD		1
> +#define SW_SDIO_M2E		0
>  
>  #define PMOD_GPIO4		0
>  #define PMOD_GPIO6		0
> @@ -38,6 +39,7 @@ / {
>  	aliases {
>  		i2c2 = &i2c2;
>  		i2c3 = &i2c3;
> +		mmc1 = &sdhi1;
>  		serial0 = &rsci2;
>  		serial1 = &rsci3;
>  		serial2 = &rsci1;

[ ... ]

> @@ -175,6 +190,68 @@ scif0_pins: scif0 {
>  		power-source = <1800>;
>  	};
>  
> +#if RZ_BOOT_MODE3
> +	sd1-pwr-en-hog {
> +		gpio-hog;
> +		gpios = <RZG3L_GPIO(J, 2) GPIO_ACTIVE_HIGH>;
> +		output-high;
> +		line-name = "sd1_pwr_en";
> +	};
> +#endif
> +
> +	sdhi1_pins: sd1 {
> +		sd1-cd {
> +			pinmux = <RZG3L_PORT_PINMUX(J, 0, 8)>; /* SD1_CD */
> +		};
> +
> +		sd1-clk {
> +			pinmux = <RZG3L_PORT_PINMUX(G, 0, 1)>; /* SD1_CLK */
> +			power-source = <3300>;
> +		};
> +
> +		sd1-cmd {
> +			pinmux = <RZG3L_PORT_PINMUX(G, 1, 1)>; /* SD1_CMD */
> +			input-enable;
> +			power-source = <3300>;
> +			bias-pull-up;
> +		};
> +
> +		sd1-data {
> +			pinmux = <RZG3L_PORT_PINMUX(G, 2, 1)>, /* SD1_DAT0 */
> +				 <RZG3L_PORT_PINMUX(G, 3, 1)>, /* SD1_DAT1 */
> +				 <RZG3L_PORT_PINMUX(G, 4, 1)>, /* SD1_DAT2 */
> +				 <RZG3L_PORT_PINMUX(G, 5, 1)>; /* SD1_DAT3 */
> +			input-enable;
> +			power-source = <3300>;
> +		};
> +	};
> +
> +	sdhi1_uhs_pins: sd1-uhs {
> +		sd1-cd {
> +			pinmux = <RZG3L_PORT_PINMUX(J, 0, 8)>; /* SD1_CD */
> +		};
> +
> +		sd1-clk {
> +			pinmux = <RZG3L_PORT_PINMUX(G, 0, 1)>; /* SD1_CLK */
> +			power-source = <1800>;
> +		};
> +
> +		sd1-cmd {
> +			pinmux = <RZG3L_PORT_PINMUX(G, 1, 1)>; /* SD1_CMD */
> +			input-enable;
> +			power-source = <1800>;
> +		};

[Severity: Medium]
Should sd1-cmd in sdhi1_uhs_pins also keep bias-pull-up like sd1-cmd in
sdhi1_pins?  Also, neither sdhi1_pins nor sdhi1_uhs_pins specifies
drive-strength-microamp on the PG0..PG5 pins, where PIN_CFG_SOFT_PS only
uses power-source to select the drive-strength table.

> +
> +		sd1-data {
> +			pinmux = <RZG3L_PORT_PINMUX(G, 2, 1)>, /* SD1_DAT0 */
> +				 <RZG3L_PORT_PINMUX(G, 3, 1)>, /* SD1_DAT1 */
> +				 <RZG3L_PORT_PINMUX(G, 4, 1)>, /* SD1_DAT2 */
> +				 <RZG3L_PORT_PINMUX(G, 5, 1)>; /* SD1_DAT3 */
> +			input-enable;
> +			power-source = <1800>;
> +		};
> +	};

[Severity: Medium]
Does setting power-source on PG0..PG5 in sdhi1_pins and sdhi1_uhs_pins
actually program the SD_CH1_POC register during signal voltage switching?

In drivers/pinctrl/renesas/pinctrl-rzg2l.c, r9a08g046_variable_pin_cfg
configures RZG3L_PG pins 0..5 (and RZG3L_PH pins 0..5 for SD2) with
RZG3L_MPXED_PIN_FUNCS(B), which sets PIN_CFG_SOFT_PS rather than
PIN_CFG_IO_VMC_SD1:

drivers/pinctrl/renesas/pinctrl-rzg2l.c:rzg2l_set_power_source() {
    ...
	if (caps & PIN_CFG_SOFT_PS) {
		pctrl->settings[pin].power_source = ps;
		return 0;
	}
    ...
}

Because rzg2l_set_power_source() returns early when PIN_CFG_SOFT_PS is set,
switching between sdhi1_pins and sdhi1_uhs_pins never writes to the SD_CH
register at .sd_ch = 0x3004.  Similarly, rzg3l_dedicated_pins defines the
SD0_* pins with neither PIN_CFG_IO_VMC_SD0 nor PIN_CFG_SOFT_PS, so applying
power-source on SD0 pins in commit "arm64: dts: renesas: rzg3l-smarc-som:
Enable SD/eMMC on SDHI0" fails with -EINVAL in rzg2l_caps_to_pwr_reg().

[ ... ]

> @@ -230,6 +307,17 @@ &scif0 {
>  	pinctrl-names = "default";
>  };
>  
> +#if RZ_BOOT_MODE3
> +&sdhi1 {
> +	pinctrl-0 = <&sdhi1_pins>;
> +	pinctrl-1 = <&sdhi1_uhs_pins>;
> +	pinctrl-names = "default", "state_uhs";
> +
> +	vmmc-supply = <&reg_3p3v>;
> +	vqmmc-supply = <&vqmmc_sd1_pvdd>;
> +};
> +#endif

[Severity: Medium]
Does &sdhi1 remain enabled without pinctrl or regulators when RZ_BOOT_MODE3
is 0?

renesas-smarc2.dtsi unconditionally sets status = "okay" on &sdhi1, and mmc1
= &sdhi1 in /aliases above is also outside #if RZ_BOOT_MODE3.  When
RZ_BOOT_MODE3 is set to 0 (routing PJ0..PJ3 to JTAG instead of SD1 CD, IOVS,
and PWEN), &sdhi1 lacks an #else branch setting status = "disabled" and will
probe without pinctrl, sd1-pwr-en-hog, vmmc-supply, or vqmmc-supply.  Also,
SW_SDIO_M2E is defined at the top of the file but never used.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261112-sdhi_rzg3l-v1-0-ca30b209615d@bp.renesas.com?part=1

  reply	other threads:[~2026-11-12 19:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12 18:48 [PATCH 0/3] Enable RZ/G3L SDHI Biju Das
2026-11-12 18:48 ` [PATCH 1/3] arm64: dts: renesas: r9a08g046: Add SDHI nodes for RZ/G3L SoC and SDHI1 pincontrol on SMARC EVK Biju Das
2026-11-12 19:25   ` sashiko-bot [this message]
2026-11-12 18:48 ` [PATCH 2/3] arm64: dts: renesas: rzg3l-smarc-som: Enable SD/eMMC on SDHI0 Biju Das
2026-11-12 19:07   ` sashiko-bot
2026-11-12 18:48 ` [PATCH 3/3] arm64: dts: renesas: rzg3l-smarc-som: Enable SDHI2 Biju Das
2026-11-12 19:09   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-211760@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=biju.das.au@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wsa+renesas@sang-engineering.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.