Hi Alan and Tim, On Fri, Jun 28, 2013 at 10:58:56AM -0400, Alan Stern wrote: > On Fri, 28 Jun 2013, Tim Sander wrote: > > But i am talking about this driver over here: > > http://code.google.com/p/bricked/source/browse/drivers/usb/misc/ehset.c > > > > There is a special usb debug device which can be switched to different "magic" usb id's which > > are supposed to set the driver into a testing mode. So the idea is that you just plug in this special > > and overpriced hardware and have your port in the configured testing mode on the device. The > > detailed procedure is detailed over here: > > http://www.usb.org/developers/onthego/EHSET_v1.01.pdf > > > > So this is official functionality defined by the USB-IF. Keep in mind that an embedded linux device > > has no possibility to install the Intel USB Windows test suite and this is not needed with > > a *working* ehset driver in kernel. Also this enables testing the ports without access to the > > commandline. As i said this is a hardware driver which should IMHO live inside > > the kernel and should be implemented to fullfill the test procedures laid out by the USB-IF. <snip> > I also looked at the ehset driver on code.google.com. It seems quite > reasonable. If you or anyone else wants to submit that driver for > inclusion in the mainline kernel, go right ahead (but get permission > from the author first, of course). There's no reason not to merge it. 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. > 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. 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. 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. 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. > Presumably the test device isn't meant to be used with a host > controller that doesn't support test mode 6 (which, BTW, seems to be > different from the test mode 6 description in your patch). I believe we chose 6 because it was the first reserved value for the selector field of the set port feature request. It's simply passed from the ehset.c driver to the code in ehci-hub.c that eventually handles this request. Thanks, Jack -- Employee of Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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
