WUSB gadget API proposal

[ilya moskovko <ilya@xxxxxxxxxxxxx>]

hello david,

i think it's time i officially introduce myself. my name is ilya moskovko,
i am a software engineer for LucidPort Technologies Inc.
<http://www.lucidport.com>, which is a successor to NetChip and is
made up of pretty much the same people. we have developed a
wireless USB controller, L800, and are interested in extending the gadget
API to WUSB to work with our chip along with other WUSB controllers.

as promised, i have made up a proposal of what would need to change
in the API in order to make it work with wireless USB. i also have a
preliminary driver for our controller along with modified g_file_storage
and a cable association gadget [g_cbaf] that work with wireless USB.
i can release this code to you as an example. majority of WUSB
specifics are handled in the controller driver, i only had to modify the
g_file_storage to handle EP companions and turn off the page boundary
math.

looking forward to hearing from you.

-- ilya

DESCRIPTORS & CONTROL REQUESTS:

Out of all new descriptors introduced in WUSB the one that
has to make it into the gadget side is the ep companion
[usb_wireless_ep_comp_descriptor structure in ch9.h] So
maybe a few fields can be added to the struct usb_ep
[maxburst, maxsequence, etc.] to allow the gadget to build
these descriptors. The gadget itself will probably ignore
these parameters but these descriptors need to be sent out
along with the endpoint descriptors so it would be a pain
to do in the controller driver.

The rest of the descriptors are a little more hardware
specific but it would still be useful to have them on the
gadget side. These descriptors, and other control request
that require info from the controller, can be filled out
on demand by corresponding functions specified in some
structure. For example: GET_SECURITY_DESCRIPTOR can call
something like wusb_get_security passing a pointer on the
security descriptor, which the controller can fill out.
Similar with SET_WUSB_DATA, gadget can call a function
that will pass ten bytes of the DRP allocation information
to the controller.


ENDPOINTS:

First off, EP0's maxpacket is now 512 instead of 64. Bulk
endpoints can have different maxpacket sizes, from 512 to 3584,
so the gadget should adjust all its buffers and requests
accordingly. And as of today no host supports isochronous
transfers; whether or not ISO is going to be supported in
the future is unknown, it is in the spec but as far as I
know it has not been tried yet.


ASSOCIATION MODELS:

These are standard methods of "assigning" a device to a host(s).
Before the device is associated with the host it will not
be able to connect and enumerate.

Cable Association [CBAF]:

This is fairly straightforward, a device that supports it
will present a separate interface descriptor of CBAF class 
on the wired side. A CBAF device does not need any endpoints
other than ep0. It needs to support three new control
requests: GET_ASSOCIATION_INFORMATION, SET_ASSOCIATION_RESPONSE,
and GET_ASSOCIATION_REQUEST. The only thing that the CBAF
gadget would need from the controller driver is what
bandgroups it supports; maybe this can be a new field in
usb_gadget structure. Once associated, the CBAF gadget would
need to pass something to the controller driver. It can be
only the connection context, which is a host id, device id,
and a connection key, 16 bytes each; or it can be the whole
structure that the host sends to the device upon completion,
which includes a few more details on top of the connection
context. The CBAF gadget can also pass the response to
RETRIEVE_HOST_INFO request, which is another structure
that has more details about the host. At a minimum,
the controller driver needs to have the connection context.

I have a sample CBAF gadget that uses an exported function
from the controller driver to pass 48 bytes of connection context.

The CBAF most likely does not need to be a full-blown gadget
but, as was suggested, a small module that will plug into the
gadget side and that would handle the three requests. This
can be a compile time option or a module parameter for each gadget.


Numeric Association:

The whole mechanism only requires two control requests
GET_SECURITY_DATA and SET_SECURITY_DATA. The procedure is
based on Diffie-Hellman key exchange and requires a number
of large calculations. At the end the host and the device spit
out a number and if they match the user can confirm the
association. My main concern is with the performance, I am
sure that some WUSB controllers will provide special logic
to perform these calculations and whatever platform the gadget
is running on might be too slow. So, this can be a module that
is similar to CBAF; it will handle the two requests and do
all the calculations and then simply pass the connection
context to the controller driver using the same method as CBAF.
Or, the module has access to a set of functions that it can use
to get the controller driver to do all the math for it; this
can be done via some structure that is passed to this numeric
association module and that has pointers to functions for each
type of calculation. If we leave nummeric associaiton to the
controller driver then it would need to be aware of the gadget's
friendly name and language id.

For connection context itself, my idea is to implement a
separate connection context API that would manage the CCs,
write/read them from disk, search through them, delete/add
new ones, etc. This would allow for the controller drivers
to load the CC on the fly, not worrying about reads/writes
to disk from kernel space, and here one can implement the
encryption, although it should not be necessary for the end
product.


MISCELLANEOUS:

It would be very useful if each gadget could have a module
parameter that can switch it between wireless and wired modes.
That way if the controller supports both types of USB it can
simply reload the module rather than recompiling the whole
thing. We can go even further by switching between two modes
on the fly, say during usb_gadget_register_driver, by having
a switch inside usb_gadget structure that specifies whether
the gadget is wireless or wired.

I think all of this would be much easier to implement if
the Gadget API had some kind of mid-layer between the
actual client gadget and the controller driver. There, one
could implement all the standard control request for wired
and wireless and then pass the requests it doesn't know how
to handle to the actual gadget. This would make the API
expandable for future USB implementations.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel