1d36719c |
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 | |
d544e109 |
28 | ------------------------------------------------------------------------------- |
1d36719c |
29 | |
d544e109 |
30 | remember to pass sc_ih irq handler to bus_space_map |