>
> > > Here's the revised patch. Can you test it to make sure it does what
> > > you want?
> > >
> > > Alan Stern
> > >
> > Alan, we have a similar debug yesterday, the system still enters
> > suspend which remote wakeup occurs, and we find it is due to:
> >
> > commit 0af212ba8f123c2eba151af7726c34a50b127962
> > USB: don't let errors prevent system sleep
> >
> > Tony, I know you are working on this issue. please share your results
> > and discuss with Alan about the solution.
>
> Heh, that's pretty funny. I was so eager to prevent problems from
> blocking system suspend that now wakeup events can't block it either!
>
> This patch on top of the other one should help. Let me know.
Hi Alan, I am out of office these days, will have a test once come back office.
But, our whole solution may diff with you has suggested, as we don't want suspend
host controller when it is sending the resume signal, it may break the hardware.
In our hardware (I think most of others are the same) the host resume will be sent
immediately once it receives device remote wakeup signal.
>
> Alan Stern
>
>
> Index: usb-3.3/drivers/usb/core/driver.c
> ===================================================================
> --- usb-3.3.orig/drivers/usb/core/driver.c
> +++ usb-3.3/drivers/usb/core/driver.c
> @@ -1190,8 +1190,13 @@ static int usb_suspend_both(struct usb_d
> if (status == 0) {
> status = usb_suspend_device(udev, msg);
>
> - /* Again, ignore errors during system sleep transitions */
> - if (!PMSG_IS_AUTO(msg))
> + /*
> + * Ignore errors from non-root-hub devices during
> + * system sleep transitions. For the most part,
> + * these devices should go to low power anyway when
> + * the entire bus is suspended.
> + */
> + if (udev->parent && !PMSG_IS_AUTO(msg))
> status = 0;
> }
>
>
--
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
