On Sun, Jun 22, 2014 at 7:33 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sun, 22 Jun 2014, Wang, Yu wrote: > >> From: "Wang, Yu" <yu.y.wang@xxxxxxxxx> >> >> The system suspend flow as following: >> 1, Freeze all user processes and kenrel threads. >> >> 2, Trying to suspend all devices. >> >> 2.1, If pci device under RPM suspended state, then pci driver will try >> to resume it to RPM active state in prepare stage. >> >> 2.2, xhci_resume function will call usb_hcd_resume_root_hub to queue two >> workqueue items to resume usb2&usb3 roothub devices. >> >> 2.3, Call suspend callbacks of devices. >> >> 2.3.1, All suspend callbacks be called of all hcd's children included >> roothub devices. >> >> 2.3.2, Fianlly, hcd_pci_suspend callback be called. >> >> Due to workqueue threads were already frozen in step 1. So the workqueue >> items can't be scheduled which will cause roothub devices can't be >> resumed in this flow. Then HCD_FLAG_WAKEUP_PENDING flags will not be >> clear which set in usb_hcd_resume_root_hub function. Finally, >> hcd_pci_suspend will return -EBUSY, and system suspend is failed. >> >> The reason why this issue doesn't show up very often, it is due to >> choose_wakeup will be called in step step 2.3.1. In step 2.3.1 >> udev->do_remote_wakeup is not equal device_may_wakeup(&udev->dev), then >> udev will be resume to RPM active for change the wakeup settings. This >> is one be resumed to RPM active to change lucky hit which hides this >> issue. >> >> For some special xHCI controllers which have no USB2 port, then roothub >> will not match hub driver due to probe failed. Then its >> do_remote_wakeup will be set to zero, then will not hit above lucky. >> >> Actually, xhci driver needn't to resume roothub devices everytime like >> above case. It's only needed when there are pending event TRBs. >> >> Signed-off-by: Wang, Yu <yu.y.wang@xxxxxxxxx> > > Acked-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> Alan, I'm wondering if we should be looking at a change in the core to prevent these rpm_suspend() vs dpm_suspend() collisions? I.e. waking up runtime suspended hubs prior to khubd being frozen? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
