>> 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. > Thank you for your reply. I will analyze it carefully. Thanks, Deng Jie
