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.