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

From: Xu Yang

Date: Thu Mar 05 2026 - 02:26:35 EST


On Wed, Mar 04, 2026 at 10:24:09AM -0500, Alan Stern wrote:
> 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.

Making runtime PM workqueue freezable is to prevent runtime PM tasks from
interfering with the system PM tasks. We also don't want usb wakeup work
to affect the root hub device system resume process, right?

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

Good question, it seems like commit 79989bd4ab86 ("xhci: always resume
roothubs if xHC was reset during resume") is added to fix some issues.

I also find ohci_resume will do the same thing: a8b43c00ef06 ("USB: Fix
runtime wakeup on OHCI")

Assume the above fixes are necessary, then switch to system_freezable_wq
should be a proper fix. Because this just restores it to a previous state.
Otherwise, the fixes need to be implemented in other ways.

Thanks,
Xu Yang