aboutsummaryrefslogtreecommitdiffstats
path: root/TODO.org
diff options
context:
space:
mode:
authorBrian Cully <bjc@kublai.com>2019-08-04 15:28:37 -0400
committerBrian Cully <bjc@kublai.com>2019-08-04 16:01:04 -0400
commit54e051b7dfbfde9083ce4becd80718ea642114fd (patch)
treeb8353bebc8270e87bd9443dd3f6f07b2ab0cef2c /TODO.org
downloadusb-host-54e051b7dfbfde9083ce4becd80718ea642114fd.tar.gz
usb-host-54e051b7dfbfde9083ce4becd80718ea642114fd.zip
Initial commit.v0.1.0
Diffstat (limited to 'TODO.org')
-rw-r--r--TODO.org44
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.