Re: [PATCH] usb: hub: Use correct reset for wedged USB3 devices thatare NOTATTACHED
From: Julius Werner
Date: Wed Nov 06 2013 - 17:42:09 EST
> Who makes those calls, drivers? Any specific ones that you know need to
be fixed?
Well, the one I'm worried about is the one this patch is fixing, in
hub_events(). I have seen this happen when having certain USB3 devices
plugged into a host controller that always looses power on
suspend-to-ram (dwc3-exynos). Since the host controller resets itself
the port no longer has PORT_STAT_ENABLE set and that causes
hub_activate() to mark the device as USB_STATE_NOTATTACHED. The next
time khubd runs hub_events(), the port may be in Compliance Mode
(because the unexpected HC reset can confuse the link state machines
on both sides) and the kernel correctly tries to reset it, but doesn't
take the fact into account that usb_reset_device() doesn't work on
NOTATTACHED devices.
> But what can a user do if those messages show up?
Nothing. I was just thinking this might help developers follow the
kernel decisions better and understand a potential problem faster
(e.g. if the user posted his log in a bug report somewhere).
> What if the device is in USB_STATE_SUSPENDED?
I'm not sure that is possible at that point in hub_events(), I don't
know of a way that could lead to this situation. I could still add the
check just to be sure if you want it, though.
> Not at all. If a device is unplugged, its state changes to NOTATTACHED
> before the driver is unbound. During that time, the driver will see
> all its URBs failing, so it may very well try to reset the device.
> (For example, usbhid behaves like this.) That isn't a bug.
Oh, okay, I wasn't quite sure how that plays together. Would you think
it's still valuable to print it out (maybe as dev_info() instead of
dev_warn()) instead of just silently ignoring the reset request? It
would have certainly been useful for me to find this problem faster,
but I can take it out again if you think it would result in too much
noise.
--
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/