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.
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
ssusbcomplia...@usb.org),
and call its driver (say lvstestdev). (Is there a way to call use
driver on the basis of name only?)
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?
Regards
Pratyush
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
