1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
* Documentation
- README.md
- Literally every trait and method.
* Do not require `core::fmt::Debug` on drivers.
This is a temporary measure so I can show which driver had an issue
when something goes wrong, but it's much more expansive than needed.
* Driver API.
** More thorough errors.
*** TransferError
`TransferError` breaks everything down into `Retry`/`Permanent`, which
isn't detailed enough. Depending on what's going on, we need to know
at least `Stall` and `NAK`, and possibly more.
*** DriverError
The `Retry`/`Permanent` distinction is probably fine here, but there
needs to be a better way of querying which device had the
problem. Right now we early-abort on a problem so we can stuff the
address into the error, but that means the rest of the devices don't
get a chance to run.
** Device addition and removal.
Device addition and removal is in both the top-level USB host driver
and the individual drivers, so there are at least two lists of
addresses floating around and it's not entirely clear who's
authoritative for which devices are attached.
The USB host driver should be the only source of this information. The
`remove_device` call should be considered informative for the driver
(as in: this device is already gone).
** Interface-level drivers.
Most uses of the USB are done at the interface level, with devices
just an agglomeration of interfaces. In particular, this is how HID
works. However, to accomodate this, the USB host driver needs to,
minimally, fetch a variable-length configuration from the device which
can be passed to the driver layer so it can accept the interface and
its associated data (e.g., endpoints and HID descriptors).
I'd rather not invoke an allocator here, but there seems to be little
choice. It would be possible to have a static buffer that gets used
(and possibly zero-copied into various borrowed descriptors), but
that's going to put an arbitrary limit on the length of the
ConfigurationDescriptor we accept.
|
