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] [day] [month] [year] [list]

Message-ID:
 <TY3PR01MB113462F232165CDB2208E19F586AAA@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Tue, 16 Dec 2025 09:16:35 +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: 16 December 2025 09:04
> Subject: Re: [PATCH v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend to RAM support
> 
> Hi, Biju,
> 
> On 12/7/25 13:02, Biju Das wrote:
> > Hi Claudiu,
> >
> >> -----Original Message-----
> >> From: Claudiu Beznea <claudiu.beznea@...on.dev>
> >> Sent: 05 December 2025 10:00
> >> 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().
> >
> > After rechecking, the cleanup() in the suspend code making usage count unbalanced.
> >
> > Eg:
> >  Suspend returns error with the following usage count incremented
> >
> > static int rzg2l_usbphy_ctrl_suspend(struct device *dev) {
> > reset_deassert:
> > +	reset_control_deassert(priv->rstc);
> > +rpm_resume:
> > +	pm_runtime_resume_and_get(dev);
> > +	return ret;
> > }
> >
> >
> > The suspend error code invokes device resume[1] and in that you are
> > again calling
> > reset_control_deassert() and pm_runtime_resume_and_get() which makes
> > the usage count unbalanced forever.
> >
> > So, looks like the current logic in the Add suspend to RAM support patch is wrong.
> 
> Seeing [1], [2], [3] being posted by you, and [2] following the same pattern as proposed in this
> patch, are you still considering the approach in this patch being wrong ?

LGTM. as reset failures will be automatically taken care in patch[3].

Assert failure in suspend(): set to deassert state
Deassert failure in resume(): set to assert stae.

Reviewed-by: Biju Das <biju.das.jz@...renesas.com>

Cheers,
Biju

> 
> Thank you,
> Claudiu
> 
> [1]
> https://lore.kernel.org/all/20251207124742.96526-1-biju.das.jz@bp.renesas.com
> [2]
> https://lore.kernel.org/all/20251208152133.269316-8-biju.das.jz@bp.renesas.com
> [3]
> https://lore.kernel.org/all/20251208101356.101379-1-biju.das.jz@bp.renesas.com