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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
