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

Message-ID:
 <TY3PR01MB1134603CBC4385178E2E57E3886A2A@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Mon, 8 Dec 2025 07:50:18 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Alan Stern <stern@...land.harvard.edu>, biju.das.au
	<biju.das.au@...il.com>
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Philipp Zabel
	<p.zabel@...gutronix.de>, 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 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.

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

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.

Cheers,
Biju