On Thu, 13 Mar 2014, Alan Stern wrote:
> Ah, now I understand. We are talking about mode-switching devices that
> revert to their default mode following a reset, as opposed to losing
> their firmware contents (although the mode switch may involve a change
> to the descriptors too). This sort of thing doesn't fit cleanly into
> the two classes of errors outlined above.
>
> In this situation we have a choice. We could do a reset and then
> rebind all the interfaces, or we could do a logical disconnect and then
> rediscover the reverted device. I think the second approach is
> cleaner, because it would generate the appropriate udev events for
> userspace hooks. (For example, it would allow the usb_modeswitch
> program to do its job properly.)
>
> This reasoning suggests that when QUIRK_RESET is present, we should
> always skip reset-resume and go directly to logical disconnect.
So Oliver, what do you think about this patch?
Alan Stern
Index: usb-3.14/drivers/usb/core/hub.c
===================================================================
--- usb-3.14.orig/drivers/usb/core/hub.c
+++ usb-3.14/drivers/usb/core/hub.c
@@ -3098,10 +3098,20 @@ static int finish_port_resume(struct usb
* operation is carried out here, after the port has been
* resumed.
*/
- if (udev->reset_resume)
+ if (udev->reset_resume) {
+ /*
+ * If the device morphs or changes modes when it is reset,
+ * we don't want to perform a reset-resume. We'll fail the
+ * resume, which will cause a logical disconnect, and then
+ * the device will be rediscovered.
+ */
retry_reset_resume:
- status = usb_reset_and_verify_device(udev);
-
+ if (udev->quirks & USB_QUIRK_RESET)
+ status = -ENODEV;
+ else
+ status = usb_reset_and_verify_device(udev);
+ }
+
/* 10.5.4.5 says be sure devices in the tree are still there.
* For now let's assume the device didn't go crazy on resume,
* and device drivers will know about any resume quirks.
--
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
