Hi, On Wed, Feb 20, 2013 at 11:53:26AM -0800, Sarah Sharp wrote: > On Wed, Feb 20, 2013 at 10:14:46AM -0800, Sarah Sharp wrote: > > Are you sure the TI host and your host isn't neglecting to drop endpoint > > resources when the Reset Device command is handled? > > I double checked your test file on the latest Intel xHCI host, and it's > up to over 4,000 successful resets of a USB mouse with a periodic IN > endpoint. > > I tried it with a USB ethernet dongle, but after about a hundred resets, > the device returned different device descriptors. The USB core treated > it as a new device and assigned it a different address, which caused the > script to fail since the /dev/bus/usb files went away. Was there a > different device you would like me to test with? > > Basically, I think this is a host-specific bug. We can certainly work > around it in the xHCI driver with a quirk for all hosts that have this > resource tracking problem. We would issue a Configure Endpoint command > to drop all endpoints before the Reset Device command. However, I would > really suggest you fix your host controller. > > Can you send me the output of `sudo lspci -vvv` and `sudo lspci -vvv -n` > when the TI host is attached to your system? I'll send you a patch with > the workaround fix to test. We can also add a quirk for your host, if > your host controller is already available with this issue, and you're > planning on having the mainline kernel support your host controller. What's the actual issue here ? Can you explain to me Sarah ? This may be a known issue regarding this particular host controller and if it is, there might already be workarounds available. If the problem is related only to device reset, then it would have failed USB30CV Device Reset test which drives 500 Device Resets and checks that device reenumerates. I doubt that's the case though, since TI's TUSB7340 is built with a USB3 Certified IP. cheers -- balbi
Attachment:
signature.asc
Description: Digital signature
