Fishwaldo opened a new pull request, #19745:
URL: https://github.com/apache/nuttx/pull/19745
## Summary
The xHCI driver does not work on a conforming controller. On the one in-tree
configuration that has one, `qemu-intel64:jumbo` with `qemu-xhci`, the
controller fails to come up at all:
```
pci_xhci_probe: failed to initialize HW!
```
No root ports, no devices, nothing on the bus. This series makes it work,
separates the driver from the PCI bus so that any hardware carrying an xHCI
controller can use it rather than only PCI-attached ones, and adds hub support.
Fifteen commits, in four groups.
**Making it work at all** (1-8): register access widths that a conforming
controller ignores when narrowed; an interrupt path that assumed a
level-triggered wire and so never re-armed behind a message-signalled one;
cache maintenance around DMA and transfer-length limits; device and endpoint
context fields the specification requires and the driver left zero; TRB
chaining across the ring wrap; endpoint allocation for interrupt endpoints; and
asynchronous transfers that set up correctly but delivered no data.
Commit 2 is the separation from PCI. The controller is the same part
wherever it is fitted, but the driver was written as a PCI device, so an SoC
that wires one directly could not use it. The bus-specific work moves behind a
small `struct xhci_bus_ops_s` (probe, interrupt attach, DMA address
translation), leaving the controller logic bus-agnostic. It is a move rather
than a rewrite, which is why it is kept as its own commit and why the diff is
large.
**Resource handling** (9-11): a per-endpoint lock, because the controller
lock is released across a transfer and two threads on one endpoint corrupted
each other's completion state; releasing the device slot when enumeration
fails, which otherwise leaks one per attempt until the controller has none
left; and bounding the retries, since a device that cannot enumerate is
otherwise retried for as long as it stays plugged in.
**Preparing for hubs** (12-14): stop using the root port as a device's
identity, describe a device to the controller from the device rather than from
the port, and fill in the route string and transaction translator that a device
behind a hub needs.
**Hub support** (15): `CONFIG_USBHOST_HUB` was refused outright by an
`#error`. It now works.
## Impact
- **User visible:** xHCI works. Before this, mass storage, keyboards and
hubs on an xHCI controller do not enumerate.
- **Reusability:** an SoC with an integrated xHCI controller can now use
this driver by supplying a handful of bus operations, instead of the driver
being usable only over PCI.
- **Configurations affected:** `qemu-intel64:jumbo` is the one in-tree
configuration that selects xHCI (`CONFIG_USBHOST_XHCI_PCI=y`, with MSC, HIDKBD,
HIDMOUSE and COMPOSITE). **Its behaviour changes**: the controller initialises
where it previously did not, and USB devices enumerate where previously none
did. That is the purpose of the series, but it is a behaviour change and not
merely an addition. Both that configuration and the EIC7700X port were used to
test it, and no other in-tree configuration selects xHCI.
- **New option:** `CONFIG_USBHOST_XHCI_ENUM_RETRIES`, default 3, bounding
enumeration attempts per port.
- **Interface change:** `xhci_initialize()` takes a bus number so an SoC
driver can identify its controller. The PCI caller passes 0.
- **Documentation, security:** unaffected.
## Testing
**Host:** macOS 15.5 (Apple Silicon). **qemu:** 10.1.5 with KVM on Fedora 43
x86_64. **Board:** ESWIN EIC7700X (RISC-V, 4 cores SMP), whose port will be
upstreamed later.
### qemu - reproducible in tree
```
tools/configure.sh -E qemu-intel64:jumbo && make
qemu-system-x86_64 -enable-kvm -m 4G -smp 4 -kernel nuttx -nographic \
-device qemu-xhci,id=xhci \
-drive if=none,id=stick,format=raw,file=disk.img \
-device usb-storage,bus=xhci.0,drive=stick
```
**Before:** `pci_xhci_probe: failed to initialize HW!`, and `/dev` holds no
`sda`.
**After:** the controller initialises and the drive enumerates:
```
pci_xhci_probe: Enabled bus mastering
pci_xhci_probe: Enabled memory resources
/dev:
sda
```
With a hub in the topology, three devices enumerate together and the data
path works through it:
```
usb 0-5: hub, driver attached QEMU USB Hub
usb 0-5.2: mass storage, driver attached QEMU USB HARDDRIVE
usb 0-5.3: keyboard, driver attached QEMU USB Keyboard
mount -t vfat /dev/sda /mnt -> cat /mnt/HELLO.TXT ->
qemu-xhci-regression-ok
```
### Hardware - the non-PCI path
The EIC7700X attaches its xHCI controllers directly, not over PCI, so it
exercises the separation in commit 2. Both controllers drive real devices
concurrently: a low-speed keyboard on one, and on the other a hub carrying a 59
GB mass storage device (mounted, directory listed, file read back correctly), a
composite CDC device presenting four `ttyACM` nodes, and a Realtek Ethernet
adapter with no driver in this tree, which is enumerated and reported as
unclaimed rather than wedging the bus.
Every commit builds and links individually against `qemu-intel64:jumbo`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
