On Sun, 19 Feb 2012, Chen Peter-B29397 wrote:
> It depends on device. Before the suspend, we tell device it can wakeup host
> through USB_REQ_SET_FEATURE, but when it really sends wakeup signal, the host
> does not act which the device has expected. It may lose some data it wants to send Host or other
> uncertain situation. I think you do not want that confusing thing happen, so
> you design the logic at choose_wakeup.
Here's the revised patch. Can you test it to make sure it does what
you want?
Alan Stern
Index: usb-3.3/drivers/usb/core/hcd.c
===================================================================
--- usb-3.3.orig/drivers/usb/core/hcd.c
+++ usb-3.3/drivers/usb/core/hcd.c
@@ -1978,6 +1978,13 @@ 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)) {
+ hcd_bus_resume(rhdev, PMSG_AUTO_RESUME);
+ status = -EBUSY;
+ }
} else {
spin_lock_irq(&hcd_root_hub_lock);
if (!HCD_DEAD(hcd)) {
Index: usb-3.3/drivers/usb/core/hub.c
===================================================================
--- usb-3.3.orig/drivers/usb/core/hub.c
+++ usb-3.3/drivers/usb/core/hub.c
@@ -399,6 +399,11 @@ static void kick_khubd(struct usb_hub *h
usb_autopm_get_interface_no_resume(
to_usb_interface(hub->intfdev));
wake_up(&khubd_wait);
+
+ /* Did a wakeup event arrive while khubd was frozen? */
+ if (unlikely(frozen(khubd_task) &&
+ device_may_wakeup(&hub->hdev->dev)))
+ pm_wakeup_event(&hub->hdev->dev, 100);
}
spin_unlock_irqrestore(&hub_event_lock, flags);
}
--
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
