| 1 | USB OTG ports can act as either a host (normal, what you'd expect from a USB |
| 2 | port on a computer) or a client (the port instead acts as if the computer it's |
| 3 | attached to is a peripheral). whether the port acts as a host or a client is a |
| 4 | decision we make via device driver logic, which can go one of two ways: |
| 5 | |
| 6 | * sysctl state switch (bad, cumbersome, prone to error) |
| 7 | |
| 8 | * automatic determination: |
| 9 | |
| 10 | - if a USB peripheral is attached, act as a host (obvious) |
| 11 | |
| 12 | - if another USB host is attached, defer to it and act as client |
| 13 | |
| 14 | - if another USB OTG port is attached, then ??? (edge case) |
| 15 | |
| 16 | ------------------------------------------------------------------------------- |
| 17 | |
| 18 | the BBB's USB port, while in client mode, acts as a ethernet-over-USB port. |
| 19 | however, the OTG specification might state that any OTG port, while in client |
| 20 | mode, should present a more generic MI midlayer before a specific MI driver |
| 21 | attaches (in our case, it'll be whatever the ethernet-over-USB driver is |
| 22 | called). that midlayer is absent in openbsd and just jerry-rigging the |
| 23 | ethernet-over-USB driver to load immediately off the USB device driver might |
| 24 | upset the more fussy devs since it's wrong to assume that all am335x/omap |
| 25 | devices with OTG USB ports only support ethernet-over-USB in client mode, even |
| 26 | though that is the case at this time. |
| 27 | |
| 28 | |