On Mon, 26 Nov 2012, Sarah Sharp wrote: > On Mon, Nov 26, 2012 at 01:29:33PM -0500, Alan Stern wrote: > > On Mon, 26 Nov 2012, Sarah Sharp wrote: > > > > > > > This will cause > > > > > the port reset to fail until the device is logically disconnected. > > > > > > > > > > Fix this by ignoring the return value of the HCD reset_device callback. > > > > > > > > Does this really fix anything? Since the device can't be reset after > > > > the first attempt, the end result is bound to be a failure anyway. > > > > > > I'm not sure what you mean by "can't be reset after the first attempt". > > > The xHC thinks the device is already reset after the first Reset Device > > > command, so the second command is basically a no-op. > > > > That's what I meant. When you ignore the return value of a no-op, what > > are you fixing? The device will still end up being logically > > disconnected, since it will see only one reset no matter how many you > > try to do. > > The Reset Device command just changes the xHC device context state. > Unlike the Address Device command, the host hardware does not issue the > port reset itself. Instead, software has to issue the control transfer > to start the port reset, time it, etc. This patch just allows software > to issue multiple port resets by ignoring the error status of the no-op > Reset Device command. So this fix does have an effect on how many port > resets the device sees. > > Does that clarify why this patch is needed? Yes, a lot. From the patch description, I thought the controller was preventing you from resetting the port when the device was in the Default state. I didn't realize that the Reset Device command was separate from resetting the port. Alan Stern -- 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
