From 1d36719cac9e23201c84846df438bee3fcb5e874 Mon Sep 17 00:00:00 2001 From: kremlin Date: Sat, 11 Feb 2017 00:20:13 -0600 Subject: [PATCH 1/1] add barely-comprehensible TODO + questions file --- TODO_and_friends | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 TODO_and_friends diff --git a/TODO_and_friends b/TODO_and_friends new file mode 100644 index 0000000..0db6fb3 --- /dev/null +++ b/TODO_and_friends @@ -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. + + -- 2.41.0