On Wed, 21 Jan 2015, Rafael J. Wysocki wrote:
> Well, OK, so there is the case when the controller is not suspended, but it
> doesn't generate interrupts for wakeup signals from devices, which generally
> is different from the case when the controller itself is suspended too that
> requires it to be wakeup-capable for things to work.
>
> An additional flag may still be better then.
We can do that if it turns out to be necessary, but let's try something
simpler first. Nicolas, does this patch fix the problem?
Alan Stern
Index: usb-3.19/drivers/usb/host/isp1760-hcd.c
===================================================================
--- usb-3.19.orig/drivers/usb/host/isp1760-hcd.c
+++ usb-3.19/drivers/usb/host/isp1760-hcd.c
@@ -1321,7 +1321,10 @@ static int isp1760_run(struct usb_hcd *h
u32 command;
u32 chipid;
+ /* Use old-style polling to detect wakeup requests */
+#if 0
hcd->uses_new_polling = 1;
+#endif
hcd->state = HC_STATE_RUNNING;
--
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
