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: <b417865397822176e83bca6b9d8094fe92ff2451.camel@pengutronix.de>
Date: Mon, 08 Dec 2025 09:34:22 +0100
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Biju Das <biju.das.jz@...renesas.com>, 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()

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().

regards
Philipp