Please use Reply-To-All so that your response gets sent to the mailing list as well as to me. And please don't top-post. On Fri, 28 Jun 2013, William Gulland wrote: > Yes, two ClearTTBuffer requests seem to be necessary with Intel's CaveCreek > integrated rate-matching hub - I've got it into the state where control > requests to a USB 1.1 device were failing, How did you manage to do that? > but recovered when I sent the > hub a ClearTTBuffer for endpoint 0 - but only if I set the IN bit in the > request. This sounds like a bug in the Intel hub hardware, or at least, unintentional behavior. Sarah, is this the sort of thing the Intel engineers would want to know about? > William > > > On Fri, Jun 28, 2013 at 8:56 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>wrote: > > > On Thu, 27 Jun 2013, William Gulland wrote: > > > > > Control transfers have both IN and OUT (or SETUP) packets, so when > > > clearing TT buffers for a control transfer it's necessary to send > > > two HUB_CLEAR_TT_BUFFER requests to the hub. > > > > What makes you think this is necessary? Have you found any hardware > > that requires this? > > > > Although the USB spec doesn't say much about Clear-TT-Buffer requests, > > the text in section 11.17.1 and Figure 11-47 seems to indicate that a > > second Clear-TT-Buffer shouldn't be needed. The spec says that TT > > buffers are matched based on the device address, endpoint number, and > > endpoint direction -- but the direction is used only for bulk > > endpoints, not for control endpoints. > > > > In particular, a control endpoint uses only one TT buffer for both the > > IN and OUT directions. So I don't think two Clear-TT-Buffers are > > needed. > > > > 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
