On Fri, 28 Jun 2013, Jack Pham wrote: > Sorry to jump into this conversation just now but I saw this thread and > noticed the link to ehset.c. This file was authored by us at Qualcomm, > and had been added to the out-of-tree MSM port of the kernel here: > https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit?id=073c9409b9cf411552314d4fa887ebc8c23942a1 > > Somehow it must have made its way to the tree hosted on code.google.com. > > I agree it should be upstreamed, and good to know you think it looks > reasonable. I will submit a patch after cleaning it up so that it > applies on a recent kernel. Okay, great! > > I just finished looking through the EHSET PDF file from www.usb.org. > > The description of the SINGLE_STEP_SET_FEATURE test appears to depend > > on a hardware feature of the host controller that is not present in the > > EHCI 1.0 spec -- maybe it was added as part of the OTG spec. > > The SINGLE_STEP_SET_FEATURE test is also mentioned in several of the > Host High-speed Electrical Test Procedure (not Embedded Host) PDFs here: > http://www.usb.org/developers/docs/. From what I gather, they require > the HSET tool installed on Windows hosts in order to activate this > feature and it looks like this tool is using a modified proprietary EHCI > driver. Thus it appears that this is a software-controlled test feature, > and hence why it doesn't appear in the EHCI spec as a hardware test > feature. That makes sense -- except for one thing. The EHSET device is intended for testing host controllers in embedded systems, right? Is an embedded system likely to be running a modified proprietary EHCI driver? > As for EHSET we were able to implement SINGLE_STEP_SET_FEATURE in > the kernel by modifying the EHCI driver. This involved adding a hook > function in ehci-q.c that calls submit_async() two separate times: first > qtd_fill() is called for the initial SETUP transaction and submitted on > its own; then a 15-second delay; and finally qtd_fill() is called for > each of the DATA and STATUS stages and submit_async() is called again > for these two to complete the transfer. In essence it is a > deconstruction of ehci_urb_enqueue() for a GetDescriptor control URB, > for the sole purpose of inserting a delay between the SETUP and DATA > stages. I see. > To me that seems to be digging a little too deep into the EHCI HCD > innards, and welcome any better ideas on how to do it. In the meantime I > can send what we did as an RFC. It does sound like a lot of mucking around inside ehci-hcd for a relatively small benefit. But if people want it, I guess it can be added. > By the way, if this is the appropriate approach, then we may have to do > something similar with the xHCI driver also in order to allow USB 3.0 > hosts the SINGLE_STEP_SET_FEATURE test when in high speed mode. That's up to Sarah (the xHCI maintainer). Thanks for enlightening us on this topic. :-) 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
