Re: [PATCH v4 9/9] arm64: dts: renesas: r9a08g046l48-smarc: Add USB2.0 support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incomplete and inconsistent USB OTG configuration for Port 0
--

--- Patch [9]: [PATCH v4 9/9] arm64: dts: renesas: r9a08g046l48-smarc: Add USB2.0 support ---
commit 1964bef80a134cfc6d3060cab9485db22da3e126
Author: Biju Das <biju.das.jz@bp.renesas.com>

arm64: dts: renesas: r9a08g046l48-smarc: Add USB2.0 support

This commit enables USB2.0 on the RZ/G3L SMARC board. It configures Port 0
as OTG and Port 1 as host-only, including the respective pinmuxing, VBUS
supplies, and PHY resets.

> diff --git a/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts b/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
> index 5289efd1a430a..6096137e193a1 100644
> --- a/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
> +++ b/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
> @@ -71,6 +71,16 @@ codec_dai: codec {
>  #endif
>  };
>  
> +&ehci0 {
> +	dr_mode = "otg";

[Severity: High]
Does this configuration work properly without a peripheral controller (hsusb)
defined in the SoC DTSI to handle device-mode traffic?

> +	status = "okay";
> +};
> +
> +&ehci1 {

[ ... ]

> @@ -181,6 +205,16 @@ ssi0_pins: ssi0 {
>  			 <RZG3L_PORT_PINMUX(H, 2, 9)>, /* SSIF0_RCK */
>  			 <RZG3L_PORT_PINMUX(H, 3, 9)>; /* SSIF0_TXD */
>  	};
> +
> +	usb0_pins: usb0 {
> +		pinmux = <RZG3L_PORT_PINMUX(3, 0, 12)>, /* USB20_OVRCUR */
> +			 <RZG3L_PORT_PINMUX(3, 1, 12)>; /* USB20_VBUSEN */
> +	};

[Severity: High]
Is there an OTG ID pin that should be routed in this pinmux?

Without the ID pin mapped, cable insertions might not be detected for hardware
role switching.

> +
> +	usb1_pins: usb1 {

[ ... ]

> @@ -241,3 +275,18 @@ &ssi0 {
>  	status = "okay";
>  };
>  #endif
> +
> +&usb2_phy0 {
> +	pinctrl-0 = <&usb0_pins>;
> +	pinctrl-names = "default";
> +	vbus-supply = <&usb0_vbus_otg>;

[Severity: High]
Because the ID pin is not mapped in usb0_pins, should this node include the
renesas,no-otg-pins property?

Without it, the PHY driver might attempt to switch roles using a floating
ID pin state. If the unmapped pin floats high, the PHY driver could
unexpectedly switch to device mode and internally disconnect the EHCI/OHCI
controllers, making Port 0 non-functional.

> +	status = "okay";
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709083108.108370-1-biju.das.jz@bp.renesas.com?part=9