Hi Am Samstag, 29. Juni 2013, 15:39:52 schrieb Alan Stern: > 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=073c9409b9cf4 > > 11552314d4fa887ebc8c23942a1 > > > > 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! This is great news :-). > > > 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? In our case that is definetly not the case but we are missing the testmode driver. The testing functionality is triggered mainly by the "magic" usb id's reserved for the testing device. > > 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. Well Linux is big nowadays in embedded devices and the less time is needed to bring up the hardware the more time is available for creating good hardware. So having a good testing infrastructure helps in new HW development and quality assurance for these devices. Having a sound hardware is paramount for a good user experience. Or the other way round: making testing the hardware harder is a receipe for crappy hardware in the end. > > 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. According to our electrical engineer escpecially these single step mode matter for analyzing the hardware. Especially when the other testmodes can also be triggered by an ioctl as Alan kindly pointed out. Best regards Tim -- 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
