On Thu, Oct 10, 2024 at 08:46:55AM +0800, Deng Jie wrote: > Hi Alan > I'm thrilled to receive your reply. Thank you very much. > Sorry for the late response due to the holiday. > 1. Although during the S4 quiesce phase, the do_remote_wakeup flag is set > to 0 within the usb_suspend->choose_wakeup function, the subsequent sequence > of usb_suspend->usb_suspend_both->usb_suspend_device->hcd_bus_suspend-> > xhci_bus_suspend will disable remote wakeup for the RootHub port. > 2. However, during the loading image phase prior to the S4 quiesce phase, > the USB device may have generated an interrupt, setting the WAKEUP_PENDING flag. > Additionally, due to the execution of freeze_kernel_threads before the loading > image phase, the USB interrupt generated during the loading image phase is > unable to execute its interrupt handler's bottom half, resulting in the > WAKEUP_PENDING flag remaining uncleared. > 3. Therefore, even though the remote wakeup for the RootHub is disabled in > usb_suspend_both() during the quiesce phase, due to the WAKEUP_PENDING flag not > being cleared, the xhci still believes that the RootHub has generated a wakeup > event when it attempts to suspend. Consequently, the xhci suspend function > returns an -EBUSY error and does not proceed with the suspend operation. > > >Now maybe things are't working the way they are supposed to. If that's > >so then you should submit a patch fixing the code so that it _does_ work > >this way. > > > >For instance, in suspend_common(), do_wakeup is derived from > >device_may_wakeup(rhdev), which is determined by > >rhdev->power.should_wakeup -- see the definition in > >include/linux/pm_wakeup.h. Maybe this flag isn't getting cleared > >properly. (In fact, at the moment I don't see where that flag gets set > >or cleared at all...) > > After configuring CONFIG_PM_SLEEP, the return value of device_may_wakeup > should be equal to dev->power.can_wakeup && !!dev->power.wakeup. Please see my reply on this other email thread, which concerns the same problem: https://lore.kernel.org/linux-usb/2c368013-8363-4a4e-bfee-2f0b14d01162@xxxxxxxxxxxxxxxxxxx/ I should have CC'ed you on that message, but I didn't think of it at the time. Alan Stern
