>
> > > --- 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.
>
The time of resume signal is 1-15ms for remote wakeup featured device,
The code routine(hcd->driver->bus_suspend-> hcd->driver->bus_resume) is process context,
it will have schedule switch, I have ever met one 3G modem which only sends 3ms resume signal,
how to guarantee the above routine can be finished within 3ms?
> > 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.
>
Do not need to return -EBUSY? Only calling usb_hcd_resume_root_hub can quit
system pm routine? I will have a test next week, and give you result.
> > 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
