Manual

Writing a USB Device Driver
calls like open and read.
min_size
This indicates the smallest transfer size that the hardware can support on this endpoint. Typically this will be
one.
Note: Strictly speaking a minimum size of one is not quite right since it is valid for a USB transfer to involve
zero bytes, in other words a transfer that involves just headers and acknowledgements and an empty data
phase, and that should be tested as well. However current device drivers interpret a transfer size of 0 as
special, so that would have to be resolved first.
max_size
Similarly, this specifies the largest transfer size. For control endpoints the USB protocol uses only two bytes
to hold the transfer length, so there is an upper bound of 65535 bytes. In practice it is very unlikely that
any control transfers would ever need to be this large, and in fact such transfers would take a long time and
probably violate timing constraints. For other types of endpoint any of the protocol, the hardware, or the device
driver may impose size limits. For example a given device driver might be unable to cope with transfers larger
than 65535 bytes. If it should be possible to transfer arbitrary amounts of data then a value of -1 indicates no
upper limit, and transfer sizes will be limited by available memory and by the capabilities of the host machine.
max_in_padding
This field is needed on some hardware where it is impossible to send packets of a certain size. For example the
hardware may be incapable of sending an empty bulk packet to terminate a transfer that is an exact multiple
of the 64-byte bulk packet size. Instead the driver has to do some padding and send an extra byte, and the host
has to be prepared to receive this extra byte. Such a driver should specify a value of 1 for the padding field.
For most drivers this field should be set to 0.
A better solution would be for the device driver to supply a fragment of Tcl code that would adjust the receive
buffer size only when necessary, rather than for every transfer. Forcing receive padding on all transfers when
only certain transfers will actually be padded reduces the accuracy of certain tests.
alignment
On some hardware data transfers may need to be aligned to certain boundaries, for example a word boundary
or a cacheline boundary. Although in theory device drivers could hide such alignment restrictions from higher-
level code by having their own buffers and performing appropriate copying, that would be expensive in terms
of both memory and cpu cycles. Instead the generic testing code will align any buffers passed to the device
driver to the specified boundary. For example, if the driver requires that buffers be aligned to a word boundary
then it should specify an alignment value of 4.
The device driver should provide an array of these structures usbs_testing_endpoints[]. The USB testing
code examines this array and uses the information to perform appropriate tests. Because different USB devices
support different numbers of endpoints the number of entries in the array is not known in advance, so instead the
testing code looks for a special terminator USBS_TESTING_ENDPOINTS_TERMINATOR. An example array, showing
just the control endpoint and the terminator, might look like this:
611