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: <f2c7583d863feb767b59f6b82b47a621aae8fb86.camel@pengutronix.de>
Date: Thu, 08 Jan 2026 14:09:36 +0100
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Claudiu Beznea <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

Hi Claudiu,

On Do, 2026-01-08 at 13:44 +0200, Claudiu Beznea wrote:
[...]
> > > +	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?
> 
> No, this reset is the reset of this HW block, controlled by another HW 
> block (the clock controller).
> 
> Bits in PHY_RESET_PORT and other registers specific to this driver could 
> be cleared due to the fact the power to this USB PHY CTRL HW block is 
> turned off in suspend.
> 
> The Renesas RZ/G3S SoC, that uses this HW block, has a power saving mode 
> where power to most of the SoC components, including USB PHY CTRL, is 
> turned off.
> 
> Due to this, we need to restore the previous settings. priv->rstc need 
> to also be restored as power to the clock controller is also lost.

Ok, thank you for the explanation.

> > 
> > > +	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.
> 
> That's right!
> 
> > I think you should warn if that is
> > not the case during suspend.
> 
> AFAICT, that could be done by adding extra logic in this driver to store 
> the state of the de-asserted bits. We can't interrogate directly the 
> registers as there might be the case where these resets are used by 
> previous bootloaders (that might let them in the de-assert state) but 
> not by Linux.

Isn't the RESET register initialized during rzg2l_usbphy_ctrl_probe()
before rzg2l_usbphy_ctrl_suspend() can ever be called? It seems to me
that read-back in suspend should never return a value left behind by a
previous bootloader.

[...]
> I can add those extra software cache for the hw registers but this is 
> what I've tried to avoid.
> 
> Please let me know how do you want me to proceed and I'll update.

If reading back the RESET register during suspend can be used, please
add a warning. Otherwise let me know what I'm missing, and I'll take
this as-is.

regards
Philipp