Re: [PATCH v3 8/9] arm64: dts: renesas: r9a08g046: Add USB2.0 device nodes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Low] module_platform_driver() is invoked twice in the same C file, which will cause a build failure when compiled as a loadable module.

Pre-existing issues:
- [High] The fix for the VBUS regulator enable_count leak is incomplete and leaves the count unbalanced if the driver explicitly calls regulator_enable() on a pre-enabled regulator.
--

--- Patch [8]: [PATCH v3 8/9] arm64: dts: renesas: r9a08g046: Add USB2.0 device nodes ---
commit 5af51dcc7dc2267ce2a724cd23f6ac8e1361e710
Author: Biju Das <biju.das.jz@bp.renesas.com>

regulator: renesas-usb-vbus-regulator: Add RZ/G3L VBUS regulator support

Add dual USB VBUS regulator support for the RZ/G3L (r9a08g046) SoC.
Register a separate rzg3l-usb-vbus-regulator platform driver for it.

> diff --git a/drivers/regulator/renesas-usb-vbus-regulator.c b/drivers/regulator/renesas-usb-vbus-regulator.c
> index 9ba791bd72eca..9028340008749 100644
> --- a/drivers/regulator/renesas-usb-vbus-regulator.c
> +++ b/drivers/regulator/renesas-usb-vbus-regulator.c

[ ... ]

> @@ -64,6 +108,15 @@ static struct platform_driver rzg2l_usb_vbus_regulator_driver = {
>  };
>  module_platform_driver(rzg2l_usb_vbus_regulator_driver);
>  
> +static struct platform_driver rzg3l_usb_vbus_regulator_driver = {
> +	.probe = rzg3l_usb_vbus_regulator_probe,
> +	.driver	= {
> +		.name = "rzg3l-usb-vbus-regulator",
> +		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
> +	},
> +};
> +module_platform_driver(rzg3l_usb_vbus_regulator_driver);

[Severity: Low]
Will this cause a build failure when compiled as a loadable module?

The module_platform_driver() macro is invoked twice in the same C file, which
will expand to redefine the init_module and cleanup_module alias functions.


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

phy: renesas: phy-rcar-gen3-usb2: Fix devm action registration for disabled VBUS regulator

Fix the devm disable action registration to base it on actual enabled state via
regulator_is_enabled(), regardless of whether the caller requested an explicit
enable.

> diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> index d06fb52ed5f1b..ef38c3b365d42 100644
> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c

[ ... ]

> @@ -905,15 +905,17 @@ static int rcar_gen3_phy_usb2_vbus_regulator_get_exclusive_enable(struct rcar_ge
>  	if (IS_ERR(channel->vbus))
>  		return PTR_ERR(channel->vbus);
>  
> -	if (!enable)
> -		return 0;
> +	if (enable) {
> +		ret = regulator_enable(channel->vbus);
> +		if (ret)
> +			return ret;
> +	}
>  
> -	ret = regulator_enable(channel->vbus);
> -	if (ret)
> -		return ret;
> +	if (regulator_is_enabled(channel->vbus))
> +		return devm_add_action_or_reset(dev, rcar_gen3_phy_usb2_vbus_disable_action,
> +						channel->vbus);

[Severity: High]
This isn't a bug introduced by this patch, but does this leave the enable_count
unbalanced if the driver explicitly calls regulator_enable() on a pre-enabled
regulator?

If the enable parameter is true, regulator_enable() increments the count.
If the regulator was already enabled by hardware, registering a single devm
disable action here fails to account for the double-incremented enable_count.

This would trigger a WARN_ON during device removal, which could panic the
kernel if panic_on_warn is set.

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