Re: [PATCH] usb: hcd: queue wakeup_work to system_freezable_wq workqueue

[Alan Stern]

On Wed, Mar 04, 2026 at 07:57:29PM +0800, Xu Yang wrote:
> After commit 4fb352df14de ("PM: sleep: Do not flag runtime PM workqueue
> as freezable"), pm_wq workqueue will be unfreezable during system pm. This
> brings issue as below:

...

> The reason is if the host controller resume routine xhci_resume() call
> usb_hcd_resume_root_hub(), wakeup_work will be queued and run immediately.
> Then usb_autoresume_device() will be called and usb device will exit
> runtime suspended state (if it was suspended before). For a hub device,
> hub_resume()/hub_reset_resume() will be called accordingly.
> 
> After the host controller device system resume is finished, the root hub
> usb device "usb1" will do system resume too. Then hub_resume() will be
> called again.
> 
> Above sequence will cause hub->urb to be submitted twice. To avoid this
> issue, restore the previous behavior by queuing wakeup_work to
> system_freezable_wq workqueue.

I don't think this patch is an appropriate fix for the problem.  One 
indication of this is the fact that you have not considered the reasons 
for making the runtime PM workqueue freezable in the first place, as 
described in the 4fb352df14de commit.

A better question to ask would be: Why does xhci_resume() call 
usb_hcd_resume_root_hub()?  That does not seem like the right thing to 
do -- at least, not in this scenario.  The proper time to resume the 
root hub after a system sleep is when the PM core calls its resume 
routine.

Alan Stern