Re: [PATCH v2] USB: Fix the issue of S4 wakeup queisce phase where task resumption fails due to USB status

[Deng Jie]

>> 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