On Thu, Mar 13, 2025 at 7:27 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx> > > 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
