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:
 <TY3PR01MB11346820489C604B63A315E8486A7A@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Fri, 5 Dec 2025 10:57:17 +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


Hi Claudiu,

> -----Original Message-----
> From: Claudiu Beznea <claudiu.beznea@...on.dev>
> Sent: 05 December 2025 10:47
> Subject: Re: [PATCH v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend to RAM support
> 
> 
> 
> On 12/5/25 12:17, Biju Das wrote:
> >
> >
> >> -----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.
> 
> Isn't this the current general approach across different drivers?

OK.

> 
> Also, take into account that this code will still be executed for suspend to idle, where power is not
> lost.

OK.

> 
> Also, for general case: if we ignore any failure, just because we may resume from a power down state
> (where Linux state is preserved in RAM and most of the SoC parts are powered off), there are resources
> that are reference counted (e.g., clocks, some resets). Ignoring failures in those cases wouldn't
> necessary make them work after resume just because the system resumes from a power down state. The
> reference counters may not have the right values for the proper registers to be updated.

OK.

> 
> > See the case 2 in logs[1] and system keeps draining the power.
> 
> Case 2 in the pointed logs seems related to resume, are we talk about suspend, resume or both?
> 
> Also, case 2 points to a resume function that returns error w/o taking it into account. The resume
> code proposed here takes into account any errors on the resume path and put the HW in a power saving
> state as otherwise it can't be runtime recovered.
> 
> >
> > Again, if system tries to do shut down
> 
> I guess, here you are talking about suspend with power cut.

It was a typo. System tries to suspend again.

> 
> > the same device will fail again in similar way and The system will
> > never enter into suspend state.
> 
> From my previous experience with suspend/resume implementations, I can say restoring the system in
> failure cases in suspend/resume or not, is up to the subsystem maintainer. So, I'll let Philipp to
> decide how he wants to go with it in this driver.
> 

Agreed.

> They are still supporting suspend to idle, where power is maintained, right? Shouldn't we cover this
> case?

Yes, I agree. Probably best thing is zero failures, if there is a failure in suspend
path, the same device will fail in similar fashion, and the system never enters suspend state.

So, report the failure and debug and fix the issue.


Cheers,
Biju