Hi Alan, On Tue, Apr 1, 2014 at 4:19 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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? > Yes, same mechanism for the test that do not require a packet. In fact, for those tests nothing to be done in the driver. Once core has been stopped for enumeration and link is in U0, it is sufficient. All the link layer packets are responded by hardware without any software intervention. >> > 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. > Only problem is that unlike "Embedded Host High Speed Electrical Test Procedure Specs V1.01" "USB 3.0 Link Layer Test Specs" not defines VID, PIDs yet. May be this specs need a bit more maturity for embedded hosts. Anyway, at the moment let me go with the implementation. I will float RFCs when my host will be passing all tests. >> > 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. > misc/ehset.c... EH Electrical Tests allows host to enumerate device till "Set Configuration". Therefore , no change in core layer required. > Does the test device respond to Get-Device-Descriptor requests? Yes, Lecroy Compliance Suite device prompts like "Send Get Device Descriptor" from host. For, sure it would be responding to that. Regards Pratyush > > 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 -- 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
