[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<TY3PR01MB11346E629B11BC5F812D32E0086A7A@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Fri, 5 Dec 2025 11:55:21 +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: Biju Das
> Sent: 05 December 2025 10:57
> 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
> > >>>>
> >
> > 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.
FYI, On your resume path, if the below call fails, then there is a pm imbalance for next suspend().
ret = pm_runtime_resume_and_get(dev);
Similarly, if reset_assert() fails for a shared reset.
Cheers,
Biju
Powered by blists - more mailing lists