On Mon, 4 Feb 2019, Mathias Nyman wrote: > >> Hi Mathias, > >> > >> I see this behavior even in 4.20.6. With the above commit reverted, my > >> laptop suspends and resumes properly again and I don't see the high > >> CPU usage of the mentioned kernel threads. > >> > >> When I suspend with the dynamic debugging enabled on 4.20.6, I see a > >> flood of xhci_hcd messages like the following: > >> > >> Feb 04 08:06:44 eric-macbookpro kernel: xhci_hcd 0000:00:14.0: Bus > >> suspend bailout, port in polling > > Ok, 4.20.6 has the 45f750c16cae "Don't prevent USB2 bus suspend" fix in, > so seems a USB3 port is stuck in polling mode in some cases, preventing suspend. > > Original patch was meant to prevent runtime suspend in case a newly attached USB3 > device was slow to enumerate, but same code is called for system suspend. > > The original patch could be limited to runtime suspend only, but looks like that > requires usb core change. > hcd->driver->bus_suspend(hcd) callback needs to provide pm_message_t as a parameter. > > Alan, would it make sense to let host controller drivers decide to prevent bus_suspend > based on port states and pm message type (runtime or system suspend)? I would prefer to see the underlying cause for this problem figured out. Why is the USB3 port stuck in polling mode? Is it a hardware issue or a software bug? More detailed debugging logs might help. Alan Stern
