The driver refused CONFIG_USBHOST_HUB outright. Everything needed to
describe a device behind a hub is now in place, so implement the rest.
- xhci_device_init() took a root hub port and read the slot, the control
endpoint and the device out of it, all of which belong to the device.
It now takes the hub port and the control endpoint, and records the
device on the root port only when that is where it sits: once a hub is
plugged in, the device a root port names is the hub. xhci_address_set()
and xhci_device_deinit() likewise work on a device, and
xhci_disconnect() finds the device by the port going away.
- The hub asks for a port's control endpoint before it reports the
connection, so xhci_epalloc() has nothing to attach one to. It returns
an endpoint with no slot, and xhci_connect() gives it one when it
creates the device.
- A hub must be described to the controller as a hub before anything
behind it can be reached, and nothing knows it is one when its slot is
created. xhci_hub_update() corrects the slot context with a Configure
Endpoint command the first time something appears behind it.
- A hub reports each changed port without waiting for the last to be dealt
with, so the connect method queues them; holding one pointer meant the
second report overwrote the first. No more can be outstanding than the
controller has slots.
- Report the root port and slot counts from HCSPARAMS1, and the port count
from a hub's descriptor.
Tested on an EIC7700X board with a hub on one controller and a keyboard on
the other. Behind the hub, a 59 GB mass storage device mounts and reads a
file back, and a composite CDC device gives four ttyACM nodes.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
ba7c7e1f77