/drivers/usb/core/hub.c: USB3 devices "lost for good" when in SS.inactive or Compliance Mode - intended behavior?

[Robert Schlabbach]

Dear Linux kernel experts,

I recently ran into an issue where Linux (kernel 3.19.0-16 amd64 from
Ubuntu 15.04) would frequently "lose" a USB 3.0 stick it was supposed
to boot from and bomb out because it couldn't mount the root fs.

Upon closer investigation, I found that the hub port the USB 3.0 stick
is connected to apparently likes to go into SS.inactive state at
initialization. Now looking at the code, it looks as if a "warm reset"
is supposed to fix that. But in fact, it can't. Here's a crude draft
of the calls inside /drivers/usb/core/hub.c I observed:

1. hub_port_reset()
2. > hub_port_wait_reset()
3. > > hub_port_status() returns port status 0x02C0
       (link state = USB_SS_PORT_LS_SS_INACTIVE)
4. > > hub_port_warm_reset_required() returns TRUE due to
       link_state == USB_SS_PORT_LS_SS_INACTIVE
5. > hub_port_wait_reset() returns -ENOTCONN due to the TRUE result
     from hub_port_warm_reset_required()
6. > hub_port_finish_reset(... *status = -ENOTCONN)
7. > > usb_set_device_state(udev, USB_STATE_NOTATTACHED)

And that's the problem: USB device state USB_STATE_NOTATTACHED is a
dead end as usb_set_device_state() does not seem to allow ever leaving
that state:
Â
if (udev->state == USB_STATE_NOTATTACHED) {
 ; /* do nothing */
}
Â
Is that the intended behavior, that once a hub port goes into SS.inactive
or Compliance Mode state, the USB devices connected to it are left
inoperable even after a warm reset and have to be physically unplugged
and replugged to be used again?
Â
I tried altering the end of hub_port_finish_reset() to:
Â
 if (udev)
ÂÂ usb_set_device_state(udev, *status
ÂÂÂÂ ? USB_STATE_ATTACHED // FIX: was USB_STATE_NOTATTACHED
ÂÂÂÂ : USB_STATE_DEFAULT);
Â
and that fixed the problem I was seeing, but I'm not sure if this is the
proper way to fix this, or if it should be fixed e.g. in hub_port_reset()
when it knows that a warm reset will still be tried.

Any thoughts?

Best Regards,
-Robert Schlabbach
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/