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? > > > Would it be simpler to just forget about the loop (set the number of > > > tries to 1) in usb_reset_and_verify_device for SuperSpeed devices? > > > > Remember that we can have USB 2.0 devices under an xHCI host. We need > > to be able to reset them multiple times as well. > > That's why I suggested using a single iteration for SuperSpeed devices. > Since USB-2 devices aren't SuperSpeed, they can continue to have > multiple iterations. > > > For example, I know some devices take a long time to respond to the Set > > Address command once they receive power. I know Keith Packard is > > attempting to bit-bang USB serial with an 8051, and it takes a long time > > for the board to start responding to USB requests. So his device won't > > work under xHCI unless the USB core attempts to enumerate the device > > multiple times. > > Does the xHCI controller allow multiple resets of non-SuperSpeed > devices? See above. Sarah Sharp -- 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
