On Wed, 8 Oct 2014, Alan Stern wrote:

> What actually happened on Dmitry's system is a little strange.  When he
> plugged in the device there was a wakeup request, and the
> port-connect-status-change bit was set.  But the port-connect-status
> bit was _not_ set, even after a 100 ms delay, so the system tried to
> suspend the root hub again.  Without my patch, resuming_ports wasn't
> set, and so the suspend succeeded and the connection ended up getting
> lost.  With my patch, resuming_ports was set, and so the suspend was
> aborted and the connection was eventually detected.

Dmitry, this gave me another idea.  Can you test the patch below,
_without_ the previous patch?  And post the corresponding usbmon trace
and dmesg log?

Alan Stern



Index: usb-3.17/drivers/usb/core/hub.c
===================================================================
--- usb-3.17.orig/drivers/usb/core/hub.c
+++ usb-3.17/drivers/usb/core/hub.c
@@ -1171,7 +1171,8 @@ static void hub_activate(struct usb_hub
                         * check for a new connection
                         */
                        if (udev || (portstatus & USB_PORT_STAT_CONNECTION) ||
-                           (portstatus & USB_PORT_STAT_OVERCURRENT))
+                           (portstatus & USB_PORT_STAT_OVERCURRENT) ||
+                           (portchange & USB_PORT_STAT_C_CONNECTION))
                                set_bit(port1, hub->change_bits);
 
                } else if (portstatus & USB_PORT_STAT_ENABLE) {

--
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

Reply via email to