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:

[  344.255749] ------------[ cut here ]------------
[  344.277740] URB 000000004aae4ad1 submitted while active
[  344.282996] WARNING: drivers/usb/core/urb.c:379 at usb_submit_urb+0x5a4/0x5e0, CPU#2: kworker/u16:14/964
[  344.292477] Modules linked in:
[  344.295532] CPU: 2 UID: 0 PID: 964 Comm: kworker/u16:14 Not tainted 7.0.0-rc2-next-20260303-00006-gf03fe0b53b39-dirty #100 PREEMPT
[  344.307341] Hardware name: NXP i.MX943 EVK board (DT)
[  344.312386] Workqueue: async async_run_entry_fn
[  344.316919] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  344.323862] pc : usb_submit_urb+0x5a4/0x5e0
[  344.328046] lr : usb_submit_urb+0x5a4/0x5e0
[  344.332217] sp : ffff800083283b30
[  344.335528] x29: ffff800083283b30 x28: ffff000082631000 x27: 0000000000000000
[  344.342661] x26: 0000000000000003 x25: 0000000000000c00 x24: 0000000000000000
[  344.349793] x23: 0000000000000004 x22: 0000000000000010 x21: 0000000000000000
[  344.356917] x20: 0000000000000002 x19: ffff00008253ce40 x18: ffff000089e4eec0
[  344.364050] x17: 000000040044ffff x16: 000005d9d87f6289 x15: 0000000000000000
[  344.371174] x14: ffff000089e4eec0 x13: 6576697463612065 x12: 6c69687720646574
[  344.378298] x11: 0000000000000058 x10: 0000000000000001 x9 : 0000000000000001
[  344.385431] x8 : 0000000000000000 x7 : 0000005028dd0800 x6 : 0000000000000002
[  344.392563] x5 : ffffc48f74e9daf8 x4 : 0000000000000000 x3 : 0000000000000000
[  344.399696] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000089e4ee40
[  344.406835] Call trace:
[  344.409280]  usb_submit_urb+0x5a4/0x5e0 (P)
[  344.413456]  hub_activate+0x268/0x878
[  344.417116]  hub_resume+0x5c/0x10c
[  344.420522]  usb_resume_interface.isra.0+0xa8/0x110
[  344.425393]  usb_resume_both+0x10c/0x1e0
[  344.429310]  usb_resume+0x1c/0x70
[  344.432621]  usb_dev_resume+0x14/0x20
[  344.436278]  dpm_run_callback.isra.0+0x38/0xf8
[  344.440715]  device_resume+0xec/0x1e8
[  344.444373]  async_resume+0x20/0x38
[  344.447848]  async_run_entry_fn+0x34/0xe0
[  344.451852]  process_one_work+0x150/0x290
[  344.455856]  worker_thread+0x18c/0x300
[  344.459600]  kthread+0x118/0x124
[  344.462824]  ret_from_fork+0x10/0x20

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.

Fixes: 4fb352df14de ("PM: sleep: Do not flag runtime PM workqueue as freezable")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
 drivers/usb/core/hcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index dee842ea6931..89221f1ce769 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2403,7 +2403,7 @@ void usb_hcd_resume_root_hub (struct usb_hcd *hcd)
 	if (hcd->rh_registered) {
 		pm_wakeup_event(&hcd->self.root_hub->dev, 0);
 		set_bit(HCD_FLAG_WAKEUP_PENDING, &hcd->flags);
-		queue_work(pm_wq, &hcd->wakeup_work);
+		queue_work(system_freezable_wq, &hcd->wakeup_work);
 	}
 	spin_unlock_irqrestore (&hcd_root_hub_lock, flags);
 }
-- 
2.34.1

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

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

On Thu, Mar 05, 2026 at 03:18:29PM +0800, Xu Yang wrote:
> 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?

You're right.  My first reaction to the patch was too hasty; I 
apologize.

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

The changelog for that commit says that it was meant to take care of 
problems during runtime resume, but it also affects system resume.  This 
appears to be an oversight.

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

Yes, okay, I withdraw my objections to this patch.

Acked-by: Alan Stern <stern@rowland.harvard.edu>

Alan Stern

On 3/5/26 17:47, Alan Stern wrote:

> 
>>> 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.
> 
> The changelog for that commit says that it was meant to take care of
> problems during runtime resume, but it also affects system resume.  This
> appears to be an oversight.

That is possible

We should probably limit the all the usb_hcd_resume_root_hub() calls in
xhci_resume() to runtime resume cases only.

There is a similar case further down in xhci_resume() where driver is looking
for pending port events.

Thanks
Mathias