Re: Discussion: Link Layer Test implementation strategy for Linux Embedded Host

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

best of luck,

greg k-h
--
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux