diff options
author | Brian Cully <bjc@kublai.com> | 2019-08-04 15:28:37 -0400 |
---|---|---|
committer | Brian Cully <bjc@kublai.com> | 2019-08-04 16:01:04 -0400 |
commit | 54e051b7dfbfde9083ce4becd80718ea642114fd (patch) | |
tree | b8353bebc8270e87bd9443dd3f6f07b2ab0cef2c /TODO.org | |
download | usb-host-54e051b7dfbfde9083ce4becd80718ea642114fd.tar.gz usb-host-54e051b7dfbfde9083ce4becd80718ea642114fd.zip |
Initial commit.v0.1.0
Diffstat (limited to 'TODO.org')
-rw-r--r-- | TODO.org | 44 |
1 files changed, 44 insertions, 0 deletions
diff --git a/TODO.org b/TODO.org new file mode 100644 index 0000000..8d22b40 --- /dev/null +++ b/TODO.org @@ -0,0 +1,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. |