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. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
