linux-kernel - Re: [PATCH v2] usb: dwc3: core: Avoid redundant system suspend/resume callbacks

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: <480c7796-2402-4009-9463-81280f9405bd@rowland.harvard.edu>
Date: Thu, 13 Mar 2025 10:27:09 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Roy Luo <royluo@...gle.com>
Cc: Thinh.Nguyen@...opsys.com, gregkh@...uxfoundation.org,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] usb: dwc3: core: Avoid redundant system
 suspend/resume callbacks

On Wed, Mar 12, 2025 at 10:34:34PM +0000, Roy Luo wrote:
> dwc3 device suspend/resume callbacks were being triggered during system
> suspend and resume even if the device was already runtime-suspended.
> This is redundant for device mode because the suspend and resume routines
> are essentially identical for system PM and runtime PM.
> 
> To prevent these unnecessary callbacks, indicate to the PM core that it
> can safely leave the device in runtime suspend if it's already
> runtime-suspended in device mode by returning a positive value in
> prepare() callback. This optimization only applies to devices without
> pinctrl, as pinctrl has distinct logic tied to system suspend/resume.
> 
> Signed-off-by: Roy Luo <royluo@...gle.com>

Out of curiosity: What happens if the USB controller is already in 
runtime suspend (with wakeup interrupts enabled) when a system suspend 
occurs?  Does the fact that the interrupts are enabled mean the 
controller will remain able to wake up the system even if 
device_may_wakeup() is false?

Alan Stern