From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felipe Balbi Subject: Re: [RFC/PATCH 2/2] usb: ehci: Add support for SINGLE_STEP_SET_FEATURE test of EHSET Date: Tue, 13 Aug 2013 10:32:57 -0500 Message-ID: <20130813153257.GH27954@radagast> References: <20130812175356.GA27954@radagast> Reply-To: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oeABDT9Upm19aBf" Return-path: Received: from arroyo.ext.ti.com ([192.94.94.40]:50908 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757619Ab3HMPdU (ORCPT ); Tue, 13 Aug 2013 11:33:20 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Alan Stern Cc: Felipe Balbi , Greg KH , Jack Pham , linux-usb@vger.kernel.org, Tim Sander , Manu Gautam , linux-arm-msm@vger.kernel.org --2oeABDT9Upm19aBf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 12, 2013 at 02:52:33PM -0400, Alan Stern wrote: > On Mon, 12 Aug 2013, Felipe Balbi wrote: >=20 > > > > maybe a single callback for supporting 'testmodes' ? which receives= the > > > > test mode as argument ? > > >=20 > > > I don't have a clear picture of how you would apply such an approach = to=20 > > > 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, > >=20 > > each test is started after enumerating a known Vid/Pid pair. Based on > > that, you *know* which test to run. >=20 > 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. >=20 > For example, it doesn't make sense to have a callback that means=20 > "Insert a 15-second delay into the next URB that I submit", because the= =20 > HCD doesn't know where URBs come from. static int ehci_test_mode(struct usb_hcd *hcd, unsigned int test) { struct ehci_hcd *ehci =3D to_ehci(hcd); .... switch (test) { case USB_TEST_SINGLE_STEP_GET_DESC: start_test(); wait_15_seconds(); finish_test(); break; ... default: return -ENOTSUP; } return ret; } =2E.. static struct hc_driver ehci_hcd_driver =3D { .... .test_mode =3D ehci_test_mode, ... }; > > > What other test modes would you want to support? > >=20 > > 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. >=20 > That's what I'm trying to find out. What are the special features that= =20 > 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 ? > > > 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. > >=20 > > right, I think it should be hidden by Kconfig, not arguing against that. >=20 > 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. right --=20 balbi --2oeABDT9Upm19aBf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJSClGpAAoJEIaOsuA1yqREvw4P/1KInefz8t19CSfH7sLRetty JeLvPmM0PwE9rECN8FdKw9lteuQedxMqcLafHTyiAQHON6c3vE3GwcJhPRWSqbs5 6jbaU8A7667E9PzQiT/g9iHyUpfhigdi8dVGwn4Cz5Az6hgC4JjF6Xm2nCCZ5xZW dHHHvFrF/HIm5cks02pcfKiXFTB/84pCWRzc3wHdF5qF/MY0EATBuBLXSTLICE2L mgAEd5KBlqtyWluE37tI2T7NFLcVR/ItmwaQmU6Qd9nUUIXcAhO/FleaYlu/ehUu J4/gSTKizSYmqqoUTvcojbHSK5dja+oixC0YoliwiQDXbij4Nyvss/K9R9O2t8xq oTh7B3ERSk2vyHrKXvxSFt/OrVp9Hf7dRxgbpxbkzL3WazUQEdhMnr+TIa+6wJok i46Nu+VHnw4aL/81X72Y2xzRxVAy6xq1dX7RXu9rXcR7PNRPJ8aDmsxLdM7ZlAL2 JW6GQYR4GVrK7Y/pDR0bXi022d1v6Fy/+R0NJtlSagUnybVH2gIx0Andml7oM8wN LpR4SZPH739mY78a6tZwDaZQoPZ4T4dzZH6NLh98NBNSW8+0C5XdDDzvmui2QPtr uCCa3I0bxEzzisaKyNYiQcpK/e4w0mn6kikqiCTPiBmqG0+Elx6CWPfKpU2ItgsR BVwkEJhzktcbeImrVcpT =XpQf -----END PGP SIGNATURE----- --2oeABDT9Upm19aBf--