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

Message-ID: <CA+zupgxoHjK_JU-2djDa-bPFCn97gHDMnz0GSvXtJfL2mpFyyg@mail.gmail.com>
Date: Thu, 13 Mar 2025 12:30:09 -0700
From: Roy Luo <royluo@...gle.com>
To: Alan Stern <stern@...land.harvard.edu>
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 Thu, Mar 13, 2025 at 7:27 AM Alan Stern <stern@...land.harvard.edu> wrote:
>
> 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

For this specific device-mode scenario, "runtime suspend (with wakeup
interrupts enabled)" seems unlikely to happen, all irqs are masked as a
part of dwc3_gadget_suspend() and then the dwc3 core is torn down.
If this really happens in a hypothetical scenario, I would expect
device_may_wakeup() set to true when wakeup interrupt is enabled.
In device_suspend(), it does explicitly check
"(device_may_wakeup(dev) || device_wakeup_path(dev))"
and won't enable direct_complete if the device could wake up.

Best,
Roy