On Mon, 31 Mar 2014, Greg KH wrote: > On Mon, Mar 31, 2014 at 05:14:31PM +0530, Pratyush Anand wrote: > > Hi Alan/Greg, > > > > I was starting some work for running "Lecroy USB Compliance Suite Link > > Layer Tests" with embedded xhci host, which runs Linux. I thought, its > > wise to discuss my test strategy before I start implementing it, > > as in long run I would like to push them to mainline. > > > > These tests have been defined in USB 3.0 Link Layer Test > > Specification. > > > > For a xhci host's downstream port under test (PUT), Lecroy excersizer with > > USB Compliance Suite acts as Link Validation System (LVS). > > > > Most of the link layer tests only expects link to be in U0. If a host > > sends a setup packet, it is NAKed by LVS. However, there are some > > tests which ask host to send some control command like Get Descriptor > > etc. How are you planning to support the tests that don't require sending any packets? Can you use that same mechanism for the tests that do require a packet? > > To add support of these tests, I wanted to go as under: > > > > 1. Add a quirk flag for the root hub sysfs device node to prevent enumeration > > of a device. > > 2. Before a lecroy LVS device is connected to the root hub n, do something like > > this. > > echo 1 > /sys/bus/usb/devices/usbn/avoid_enum_quirk > > 3. Now connect LVS device and run Link Layer tests from Lecroy USB > > Compliance Suite. > > 4. To get back into normal working situation (to connect a general usb device > > to root hub n), do following: > > echo 0 > /sys/bus/usb/devices/usbn/avoid_enum_quirk > > 5. Modify hub driver to prevent enumeration when a new device is connected and > > this flag is set. > > Create a new dummy device (VID, PID to be discussed with ssusbcompliance@xxxxxxx), > > and call its driver (say lvstestdev). (Is there a way to call use > > driver on the basis of name only?) It could be done based on the VID PID combination, together with a vendor-specific class and protocol setting. > > This lvstestdev implements further sys nodes/or some other > > method like ioctl etc to allow an application to generate traffic > > for some specific test case. > > 6. When this device is disconnected then the created dummy device is > > destroyed. (Even a single test case may generate multiple > > connection/disconnection from LVS) > > > > Do, you think this flow would be correct, or there could be some > > better approach? > > I don't know, try it out and let us see how it works. There already is a vaguely similar test setup in ehci-hcd. However, it requires the device to be enumerated, so it doesn't involve any changes to the USB core. Does the test device respond to Get-Device-Descriptor requests? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
