linux-kernel - Re: [PATCH v3 2/2] reset: rzg2l-usbphy-ctrl: Add suspend/resume support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7b4aa36772039d6607bf0aee38bd897b773e3f7f.camel@pengutronix.de>
Date: Thu, 08 Jan 2026 12:19:18 +0100
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Claudiu <claudiu.beznea@...on.dev>
Cc: linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org
Subject: Re: [PATCH v3 2/2] reset: rzg2l-usbphy-ctrl: Add suspend/resume
 support

On Do, 2026-01-08 at 12:26 +0200, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
> 
> The RZ/G2L USBPHY control driver is also used on the RZ/G3S SoC.
> The RZ/G3S SoC supports a power-saving mode in which power to most USB
> components (including the USBPHY control block) is turned off. Because of
> this, the USBPHY control block needs to be reconfigured when returning
> from power-saving mode.
> 
> Add suspend/resume support to handle runtime suspend/resume of the device,
> assert/deassert the reset signal, and reinitialize the USBPHY control
> block.
> 
> Reviewed-by: Biju Das <biju.das.jz@...renesas.com>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
> ---
> 
> Changes in v3:
> - collected tags
> 
> Changes in v2:
> - used pm_runtime_put_sync() in rzg2l_usbphy_ctrl_suspend()
> 
>  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 94 +++++++++++++++++++++----
>  1 file changed, 79 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> index 9ce0c1f5d465..1a1581643bf3 100644
> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
[...]
> @@ -266,10 +273,67 @@ static void rzg2l_usbphy_ctrl_remove(struct platform_device *pdev)
[...]
> +static int rzg2l_usbphy_ctrl_resume(struct device *dev)
> +{
> +	struct rzg2l_usbphy_ctrl_priv *priv = dev_get_drvdata(dev);
> +	int ret;
> +
> +	ret = rzg2l_usbphy_ctrl_set_pwrrdy(priv->pwrrdy, true);
> +	if (ret)
> +		return ret;
> +
> +	ret = reset_control_deassert(priv->rstc);
> +	if (ret)
> +		goto pwrrdy_off;

Do I understand correctly that this reset clears PHY_RESET_PORT[12]
bits in the RESET register such that rzg2l_usbphy_ctrl_init() must be
called below?

> +	ret = pm_runtime_resume_and_get(dev);
> +	if (ret)
> +		goto reset_assert;
> +
> +	rzg2l_usbphy_ctrl_init(priv);

This assumes that consumers requested PHY_RESET_PORT[12] resets to be
asserted in their suspend function. I think you should warn if that is
not the case during suspend. Saving the relevant RESET bits during
suspend and restoring them here is probably not useful.

Otherwise,

Reviewed-by: Philipp Zabel <p.zabel@...gutronix.de>

regards
Philipp