Re: [RFC/PATCH 2/2] usb: ehci: Add support for SINGLE_STEP_SET_FEATURE test of EHSET

[Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]