Hi, On Fri, Aug 09, 2013 at 11:04:48AM -0400, Alan Stern wrote: > > > > heh, it doesn't need to be entirely in the core. Core could have the > > > > generic calls and HCDs could implement some callbacks, but I think quite > > > > a bit of the code will be similar if we implement the same thing on all > > > > HCDs. > > > > > > What generic calls and callbacks would you suggest? I assume you want > > > enough to cover not just this one test but the entire USB-CV suite. > > > > maybe a single callback for supporting 'testmodes' ? which receives the > > test mode as argument ? > > I don't have a clear picture of how you would apply such an approach to > this case. There would have to be a way to tell the HCD to insert a > 15-second delay between the Setup and Data stages of a particular > control URB. How would you do that? Whatever method you choose, each test is started after enumerating a known Vid/Pid pair. Based on that, you *know* which test to run. > implementing it in every HCD would be a huge amount of work. sure, we can support different HCDs with time, but once SINGLE_STEP is implemented in e.g. EHCI, it should be simple to port it to OHCI/xHCI/MUSB/etc. > What other test modes would you want to support? anything that USB[23]0CV supports today. There are even link layer tests for USB3 and a bunch of others. This SINGLE_STEP_SET_FEATURE is but one of a large(-ish) test suite which needs to be supported. > Is it worth adding this support to the standard host controller > drivers, or should there be a special version (a Kconfig option like > CONFIG_RCU_TORTURE_TEST) to enable it? Putting a lot of testing code > in distribution kernels where it will never be used seems like a big > waste. right, I think it should be hidden by Kconfig, not arguing against that. -- balbi
Attachment:
signature.asc
Description: Digital signature
