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

[Jack Pham <jackp@codeaurora.org>]

On Tue, Aug 13, 2013 at 10:32:57AM -0500, Felipe Balbi wrote:
> On Mon, Aug 12, 2013 at 02:52:33PM -0400, Alan Stern wrote:
> > On Mon, 12 Aug 2013, Felipe Balbi wrote:
> > > 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?
> 
> I haven't looked at USB??CV spec for a while, maybe Jack knows better ?

I've been going off of
http://www.usb.org/developers/onthego/EHSET_v1.01.pdf which is specific
to OTG and Embedded hosts, but I think it overlaps pretty close with
with what USB20CV/HSET is trying to cover.

So far the SINGLE_STEP_GET_DEVICE_DESCRIPTOR and SINGLE_STEP_SET_FEATURE
tests are the only ones we've had to implement in software for, and
obviously with the latter requiring further modification in the HCD
itself for that 15-second delay insertion.

The other test modes that the USB20CV/HSETT tool appears to invoke (TEST_J,
TEST_K, etc.) are actually defined in USB 2.0 Section 7.1.20 and also
reserved in EHCI's PORTSC bits [19:16], so whatever invokes these tests
modes--unlike SINGLE_STEP--simply issue a SET_FEATURE(PORT_FEAT_TEST)
and can expect the hardware to handle it.
 
> > 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.

Already submitted a follow-on patch for that.

> > 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.

+1. I am open to suggestions on how best to achieve this.  I have a
another patch in the for doing the same 15-second delay in xHCI but am
hesitant to submit it just yet, pending ideas on a better way to do it
in the common HCD core.

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