--- /dev/null
+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.
+
+