On Fri, 17 Feb 2012, Chen Peter-B29397 wrote:
> > --- usb-3.3.orig/drivers/usb/core/hcd.c
> > +++ usb-3.3/drivers/usb/core/hcd.c
> > @@ -1978,6 +1978,11 @@ int hcd_bus_suspend(struct usb_device *r
> > if (status == 0) {
> > usb_set_device_state(rhdev, USB_STATE_SUSPENDED);
> > hcd->state = HC_STATE_SUSPENDED;
> > +
> > + /* Did we race with a root-hub wakeup event? */
> > + if (unlikely(HCD_POLL_PENDING(hcd) &&
> > + rhdev->do_remote_wakeup))
> > + usb_hcd_resume_root_hub(hcd);
> At hcd->driver->bus_suspend, it may put PHY to low power mode and close the related code.
> Then, the resume signal(or SOF if resume has finished) from the host will be stopped,
> it will confuse the device,
If hcd->driver->bus_suspend puts the PHY into low-power mode, then
hcd->driver->bus_resume will put the PHY back into full-power mode
before sending out the resume signal. Nothing will be confused.
> we may need to move your code before the hcd->driver->bus_suspend,
> and only resume hub driver.
That's no good. Then a wakeup signal might arrive after the new code
runs but before hcd->driver->bus_suspend is called.
> Another corner case is replace system suspend with auto-suspend at your cases,
> at that situation, we may need to return -EBUSY for hcd_bus_suspend, and let the
> system pm routine to resume hub driver, and others.
True, the new code could call hcd_bus_resume and then return
-EBUSY. I thought it was easier just to call usb_hcd_resume_root_hub
instead. Either way ought to work.
> I don't know how to distinguish auto-suspend/and system suspend, do you have better
> solution to cover these two cases?
There's no reason to treat them differently. They should do the same
thing.
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
