> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to