linux-kernel - RE: [PATCH 0/2] usb: host: Drop resume calls on {e,o}hci_platform

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:
 <TY3PR01MB11346C2B0649321D81E9626B586A2A@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Mon, 8 Dec 2025 10:16:55 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Philipp Zabel <p.zabel@...gutronix.de>, Alan Stern
	<stern@...land.harvard.edu>, biju.das.au <biju.das.au@...il.com>
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Claudiu Beznea
	<claudiu.beznea.uj@...renesas.com>, "linux-usb@...r.kernel.org"
	<linux-usb@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Geert Uytterhoeven <geert+renesas@...der.be>,
	Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>
Subject: RE: [PATCH 0/2] usb: host: Drop resume calls on
 {e,o}hci_platform_suspend()

Hi Philipp Zabel,

> -----Original Message-----
> From: Philipp Zabel <p.zabel@...gutronix.de>
> Sent: 08 December 2025 08:34
> Subject: Re: [PATCH 0/2] usb: host: Drop resume calls on {e,o}hci_platform_suspend()
> 
> On Mo, 2025-12-08 at 07:50 +0000, Biju Das wrote:
> > Hi Alan Stern,
> >
> > > -----Original Message-----
> > > From: Alan Stern <stern@...land.harvard.edu>
> > > Sent: 07 December 2025 16:36
> > > Subject: Re: [PATCH 0/2] usb: host: Drop resume calls on
> > > {e,o}hci_platform_suspend()
> > >
> > > On Sun, Dec 07, 2025 at 12:47:25PM +0000, Biju wrote:
> > > > From: Biju Das <biju.das.jz@...renesas.com>
> > > >
> > > > As per the suspend_devices_and_enter() [1], if .suspend() fails,
> > > > it invoke the .resume() callback.
> > >
> > > Quite wrong.  If .suspend() fails, the core assumes the device is
> > > still at full power.  It does not try to resume the device.
> >
> > But now in ehci/ohci suspend() is calling ehci_resume without checking
> > the status of reset_deassert that can lead to synchronous abort and reboot is the only way to
> recover.
> >
> > For the reset_assert failure cases in suspend(),
> >
> > Case 1) Exclusive reset assert, reset register bit set to assert, but status bit is not set, so we
> get timeout error
> > 	  The following access to ehci registers can lead to synchronous abort.
> 
> Let the reset controller driver set the reset register bit back to deasserted state when returning a
> timeout error after waiting for the status bit to change.
> 
> > Case 2) Array reset assert, reset register bit is set to deassert, but we are not checking the
> status bit
> >         and if the device not transitioned to deassert state, then
> > that can lead to synchronous abort
> 
> The status of array resets can not be checked with the current API.
> 
> > I guess we should explicirtly call reset_control_deassert(priv->rsts)
> > to make sure the device is in deasserted state before calling ehci_resume().
> >
> > I may be wrong. Please correct me if I am wrong.
> 
> The reset controller driver should leave the reset in a deasserted state when returning an error from
> reset_control_assert().

OK. Posted the patch[1]

[1] https://lore.kernel.org/all/20251208101356.101379-1-biju.das.jz@bp.renesas.com/

Cheers,
Biju