On Fri, 17 Aug 2012, Antti Pulakka wrote: > Hi, > > I have been analyzing USB traffic with USB 2.0 protocol analyzer. In > my test setup I have a Full-Speed USB serial device connected to > High-Speed hub which is connected to Linux host. The protocol analyzer > is connected between the Linux host and the High-Speed hub. The test > case which I have been analyzing opens the serial device, writes a few > bytes to the device and closes the device. The USB serial device has a > bulk IN endpoint and a bulk OUT endpoint for data transfer. > > When the device node of the USB serial device is closed from user > space, I can see that usually the last transaction to the bulk IN > endpoint of the USB serial device is a start-split transaction without > a corresponding complete-split transaction. Sometimes the split > transaction is completed with the corresponding complete-split but > most often not. The transaction translator buffer of the High-Speed > hub is always cleared with ClearTTBuffer request regardless if the > split transaction was completed or not. > > I have tested this case with a USB to serial converter (pl2303) using > pl2303 driver and usbserial_generic driver. I also used USB CDC device > with cdc_acm driver. The results are the same with every case. > > My question is that why is ClearTTBuffer request always used in this > case? According to the USB 2.0 specification paragraph 11.17.5 (on > page 372), ClearTTBuffer should be used as a part of endpoint halt > processing when split transactions have failed. Wouldn't it be better > to always complete the started split transaction instead of always > send ClearTTBuffer request? There are really two different questions here. First, would it be better to complete the transaction? No, because an IN transaction can take an arbitrarily long time to complete. In this case, the transaction gets cancelled when your program closes the device node; halt processing is needed in order to tell the hub's TT that the transaction has been cancelled. Second, why issue a ClearTTBuffer request in the rare cases when the transaction does complete? I don't know exactly because you haven't supplied enough details, but it sounds like there's a race: The transaction completes at about the same time as it is cancelled. Because of the cancellation, halt processing is applied. 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
