On Mon, 12 Aug 2013, Felipe Balbi wrote: > > > 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. That's not what I meant. Yes, the test-device driver knows what test it wants to run, based on the VID/PID. I was asking how it would communicate this knowledge to the HCD. For example, it doesn't make sense to have a callback that means "Insert a 15-second delay into the next URB that I submit", because the HCD doesn't know where URBs come from. > > 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. That's what I'm trying to find out. What are the special features that we would need to implement in order to support the entire test suite? > > 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. Therefore we both agree the $SUBJECT patch should not be accepted in its current form. At the very least, the new code in ehci-hcd should be conditional on a CONFIG_USB_HCD_TEST_MODE option. In addition, we may want some of the work (though at this point I'm not still clear on exactly what parts) to be moved into usbcore. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
