The four patches that follow this message are the (untested but
compilable) code to add support for USB 3.0 bulk endpoint streams.
Streams are basically a way of queueing multiple transfers to one
endpoint, which allows the device to complete them out of order.
I'd appreciate it if people reviewed the documentation and new
interfaces included the last patch. UASP drivers (the new mass storage
device class) will probably use these interfaces first. If you are
developing a UASP driver, I would appreciate if you could test these
patches (and post your code).
I also need a bit of advice on how to deal with the USB core.
First, is anything going to break in the USB core when URBs for an
endpoint are completed out of order? There's no blindly taking the head
of a list of queued URBs, is there?
My second question involves resetting devices when a driver has enabled
streams for an endpoint. Here's how I understand usb_reset_device() works:
1. Call the pre_reset driver method for all interface drivers, or it call
their unbind method.
2. Reset the port and get the descriptors.
3. Reinstall the old configuration and alt settings.
4. Call the interface driver's post_reset or bind methods.
I have yet to support resetting configured devices under the xHCI driver
because I have to add a new hook after the reset port in step two. That
hook will issue (and wait) on a Reset Device command, and tear down all
the internal structures that relate to endpoints other than control
endpoint zero. That means that any structures relating to streams will
also be lost.
To enable streams, the driver must call usb_alloc_streams(). When the
driver is done using streams, it should call usb_free_streams(). Would
it be appropriate to ask drivers to call usb_free_streams() in their
pre_reset and then call usb_alloc_streams() in their post_reset method?
I'm also not quite sure what happens when a driver is unbound from a
device. Is their close method called? If so, drives would need to call
usb_free_streams() in their close method.
Another approach would be to have the USB core keep track of how many
stream IDs are enabled for an endpoint and reinstate them after the
reset. It would need to stash the number of streams in some structure,
perhaps usb_host_endpoint?
I'm leaning towards letting drivers re-allocate streams after a reset,
what are your thoughts?
Sarah
--
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
