On Wed, 27 Feb 2013, Paul Zimmerman wrote: > > Paul: > > > > I'm a little puzzled how this driver manages without a > > clear_tt_buffer_complete callback, or indeed, without calling > > usb_hub_clear_tt_buffer anywhere. Does the hardware manage this for > > you automatically, or is it an oversight? > > Hi Alan, > > That involves sending a Clear_TT_Buffer request to the downstream hub, > right? No, the hardware doesn't do that automatically, so I guess this is an > oversight. > > I can implement that, but do you know of any practical way to test it? > That would involve inducing some sort of error on the bus during a > split transaction, right? Yes indeed. Any non-high speed device could be used for testing, provided you can set up a long-running series of control or bulk transfers. Unplug the device while the transfers are going on and see if the Clear-TT-Buffer request gets sent properly. For example, if you have a full-speed mass-storage device, that would work. Just run a "dd" job to read from the device and then unplug it. If all your mass-storage devices are high-speed, you can force one to run at full speed by putting it behind a USB-1.1 hub. Or if you want to get a little more exotic, test an ordinary USB mouse. Unbind it from the usbhid driver and load the usbtest driver with the appropriate vendor and product IDs. Then run the testusb program with test #10. 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
