> On Thu, 19 Jun 2014, Wang, Yu Y wrote: > > > > I'm not sure of the right way to solve this problem. Probably > > > xhci_resume() should check the root-hub statuses to see if either > > > root hub really needs to be resumed before calling > > > usb_hcd_resume_root_hub(); I think that will work. > > > > [Yu:] I understand your point. From the big picture, to my > > understanding, there have three scenarios. > > > > The first one is USB device trigger remote wakeup. > > > > The second one is user space trying to resume xHC which will queue URBs. > > > > The third one is PCI driver try to resume pci device during S3 > > entering if the device under suspended state. > > > > Your patch is focus on the first case. Avoid xHCI re-enter RPM > > suspended in the gap between HCD resumed and activate the IRQ, right? > > Right. > > > But your patch will cause this BUG for the third case. And the second case > should be fine. > > So my understanding is to find one way to distinguish the first one and second > one. > > We need to confirm if RH need to resume before trigger resume in > xhci_resume. > > During xhci_resume function, after set USBCMD.R/S bit, then the controller > can get IRQ. > > So we can check USBSTS.EINT or USBSTS.PCD bit to determine if need to > > resume the root hubs to handle these events. > > Yes, that is what I recommended above. [Yu:] Get it. I will prepare one patch. Thanks Yu > > Alan Stern -- 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
