Re: [PATCH v2 2/2] usb: dwc3: dwc3-generic-plat: Add Renesas R-Car Gen5 DWC3 xHCI USB controller glue

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The Renesas R-Car Gen5 glue register initialization performed during probe is not restored during system or runtime resume, leading to silent hardware state loss after a suspend cycle.
--

--- Patch [2]: [PATCH v2 2/2] usb: dwc3: dwc3-generic-plat: Add Renesas R-Car Gen5 DWC3 xHCI USB controller glue ---
commit 211fb3fb7a52e528bcd297e2261a315030e4d2c9
Author: Thanh Quan <thanh.quan.xn@renesas.com>

usb: dwc3: dwc3-generic-plat: Add Renesas R-Car Gen5 DWC3 xHCI USB controller glue

This commit extends the generic DWC3 platform driver to support the Renesas
R-Car Gen5 glue logic. It adds platform-specific initialization for the
glue registers based on the maximum speed property.

> diff --git a/drivers/usb/dwc3/dwc3-generic-plat.c b/drivers/usb/dwc3/dwc3-generic-plat.c
> index ca69ac0eb07ce..518bb40d1372c 100644
> --- a/drivers/usb/dwc3/dwc3-generic-plat.c
> +++ b/drivers/usb/dwc3/dwc3-generic-plat.c

[ ... ]

> @@ -71,6 +71,52 @@ static int dwc3_eic7700_init(struct dwc3_generic *dwc3g)
>  	return 0;
>  }
>  
> +static int dwc3_renesas_rcar_gen5_init(struct dwc3_generic *dwc3g)
> +{
> +	struct device *dev = dwc3g->dev;
> +	struct platform_device *pdev = to_platform_device(dev);
> +	const char *maximum_speed;
> +	bool use_usb3_flow;
> +	void __iomem *glue;
> +	int ret;
> +
> +	glue = devm_platform_ioremap_resource_byname(pdev, "glue");
> +	if (IS_ERR(glue))
> +		return PTR_ERR(glue);
> +
> +	ret = of_property_read_string(dev->of_node, "maximum-speed", &maximum_speed);
> +	if (ret)
> +		return dev_err_probe(dev, -ENODEV, "Failed to determine maximum speed\n");
> +
> +	use_usb3_flow = !strcmp(maximum_speed, "super-speed-plus") ||
> +			!strcmp(maximum_speed, "super-speed");
> +
> +	/*
> +	 * The datasheet describes initialization procedure without full
> +	 * information about the registers. Therefore, the source code is
> +	 * based on the bare metal code shared by the board team.
> +	 */
> +	writew(0x211, glue + 0x26);
> +
> +	/* USB3 does not need additional register programming. */
> +	if (use_usb3_flow)
> +		return 0;
> +
> +	writew(0x11, glue + 0x81c);
> +	writew(0x0, glue + 0x81a);
> +	writew(0x1, glue + 0x802);
> +
> +	usleep_range(10000, 20000);
> +
> +	writew(0x0, glue + 0x802);
> +	writew(0x1, glue + 0x2a);
> +	writew(0x1, glue + 0x81a);

[Severity: High]
Does this code lose the glue register state across power management suspend
and resume cycles?

Looking at dwc3_generic_resume() in the same file, the generic resume handler
reenables clocks and calls dwc3_pm_resume(), but it lacks any mechanism to
invoke platform-specific glue re-initialization (such as a resume callback in
struct dwc3_generic_config).

Since these stateful MMIO registers are configured exactly once during
dwc3_renesas_rcar_gen5_init() and never restored upon resume, it seems the USB
controller glue registers will silently lose their state when the power domain
is cycled during system suspend or runtime PM suspend.

Will this cause USB functionality (especially the USB2 flow) to break upon
wake?

> +
> +	usleep_range(10000, 20000);
> +
> +	return 0;
> +}
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806050422.324435-1-marek.vasut+renesas@mailbox.org?part=2