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. > > 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? 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
