add barely-comprehensible TODO + questions file
authorkremlin <ian@kremlin.cc>
Sat, 11 Feb 2017 06:20:13 +0000 (00:20 -0600)
committerkremlin <ian@kremlin.cc>
Sat, 11 Feb 2017 06:20:13 +0000 (00:20 -0600)
TODO_and_friends [new file with mode: 0644]

diff --git a/TODO_and_friends b/TODO_and_friends
new file mode 100644 (file)
index 0000000..0db6fb3
--- /dev/null
@@ -0,0 +1,28 @@
+USB OTG ports can act as either a host (normal, what you'd expect from a USB
+port on a computer) or a client (the port instead acts as if the computer it's
+attached to is a peripheral). whether the port acts as a host or a client is a
+decision we make via device driver logic, which can go one of two ways:
+
+       * sysctl state switch (bad, cumbersome, prone to error)
+
+       * automatic determination:
+
+               - if a USB peripheral is attached, act as a host (obvious)
+
+               - if another USB host is attached, defer to it and act as client
+
+               - if another USB OTG port is attached, then ??? (edge case)
+
+-------------------------------------------------------------------------------
+
+the BBB's USB port, while in client mode, acts as a ethernet-over-USB port.
+however, the OTG specification might state that any OTG port, while in client
+mode, should present a more generic MI midlayer before a specific MI driver
+attaches (in our case, it'll be whatever the ethernet-over-USB driver is
+called). that midlayer is absent in openbsd and just jerry-rigging the
+ethernet-over-USB driver to load immediately off the USB device driver might
+upset the more fussy devs since it's wrong to assume that all am335x/omap
+devices with OTG USB ports only support ethernet-over-USB in client mode, even
+though that is the case at this time.
+
+