USB-C port cannot be used as host
Created by: mvduin
For some time now I've heard of people who need USB 3 strugging to use the USB-C port, which is the BBAI's only USB 3 port, in host mode (using a charging hub). Recently I finally got around to digging into it, and my conclusion is: it cannot work, at least not if either the BBAI or the hub complies with the USB standard (if both violate USB standard then those violations might perhaps in some cases fortuitously interact to yield a working result, but that's obviously terrible to rely on).
Here's why:
When connecting devices via USB-C, initially one side has to become sourcing host (i.e. host data-role and source power-role) and one side has to become sinking device (i.e. device data-role and sink power-role), or no connection will be established. Becoming initial-host requires being able to supply VBUS power, hence a VBUS-powered device like the BBAI will always initially negotiate device role on connect. Even if the BBAI is powered via P9, it lacks the ability the provide VBUS to the USB-C connector, hence it still cannot negotiate initial host role.
After these initial roles are established it is possible for the devices to subsequently swap data role (i.e. which side is host and which side is device) and/or power role (i.e. which side is source (i.e. supplies VBUS power) and which is sink), which is the only way you can become a sinking host or sourcing device. However, these role swaps can only be done using USB Power Delivery (PD) signalling. Unfortunately the USB-C controller on the BBAI (TUSB322I) does not support PD signalling, nor does its replacement on rev A2 (HD3SS3220), hence it cannot perform a data role swap.
Since the BBAI can neither be initial-host nor perform a data role swap, there is no way for it to ever have host role on its USB-C port. Forcing the usb subsystem into host mode via sysfs will merely cause the BBAI to violate the usb specification and may result in a drive conflict. It does not change the negotiated role, hence it will not result in successful connection (unless the other side also violates the usb specification).
The only real fix is to use a USB-C controller with support for PD communication, specifically data role swap. (Or, in retrospect, another option would have been to use a dedicated USB3 host (instead of the USB2 host port) and limit the Type-C port to USB2 instead of doing it the other way around, since it seems more likely people would want the beaglebone to be USB3 host than to be USB3 device.)