linux-kernel - RE: [PATCH v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend to RAM 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:
 <TY3PR01MB11346625CD598704CC36C63AE86A7A@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Fri, 5 Dec 2025 10:17:45 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Claudiu.Beznea <claudiu.beznea@...on.dev>, "p.zabel@...gutronix.de"
	<p.zabel@...gutronix.de>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
	Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: RE: [PATCH v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend to RAM
 support



> -----Original Message-----
> From: Claudiu Beznea <claudiu.beznea@...on.dev>
> Sent: 05 December 2025 10:00
> To: Biju Das <biju.das.jz@...renesas.com>; p.zabel@...gutronix.de
> Cc: linux-kernel@...r.kernel.org; linux-renesas-soc@...r.kernel.org; Claudiu Beznea
> <claudiu.beznea.uj@...renesas.com>
> Subject: Re: [PATCH v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend to RAM support
> 
> Hi, Biju,
> 
> On 12/5/25 10:53, Biju Das wrote:
> >
> >
> > Hi Claudiu,
> >
> >> -----Original Message-----
> >> From: Claudiu Beznea <claudiu.beznea@...on.dev>
> >> Sent: 04 December 2025 18:26
> >> Subject: Re: [PATCH v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend to
> >> RAM support
> >>
> >> Hi, Philipp,
> >>
> >> Could you please let me know if there's anything I should do for this series?
> >
> > If rzg2l_usbphy_ctrl_suspend() fails, What is the probability that it
> > will suspend again without any issue
> 
> How can I measure this?
> 
> The idea with this code was the following: if any instruction of suspend fails, the suspend is
> aborted, thus code in rzg2l_usbphy_ctrl_suspend() is trying to restore the runtime state of the HW so
> that no runtime users of it to be affected. This is also how core suspend code is doing, e.g.
> suspend_devices_and_enter().

The entire system suspend is aborted. See the case 2 in logs[1] and system keeps draining the power.

Again, if system tries to do shut down the same device will fail again in similar way and 
The system will never enter into suspend state.

[1] https://lore.kernel.org/all/TY3PR01MB11346A7B16CB3267F1A57302B86DBA@TY3PR01MB11346.jpnprd01.prod.outlook.com/



> 
> > as currently we abort system suspend
> > and enable clocks/deassert reset which keep draining the power.
> The code is restoring the clocks and resets to their previous runtime state so that any users of it to
> not be affected. Later, at runtime, if any power needs to be saved the runtime PM framework will do
> its job.

The system is enters into suspend state for saving power. Not to consume because of failure.
Our SoCs will power down during suspend and device reset will happen during wakeup
So everything will work as usual if there is device specific failures during suspend.
See case 3 in logs[1]

Cheers,
Biju