drivers/usbhost: Separate the xHCI driver from the PCI bus. - #19860
Conversation
github-actions
Bot
added
Size: XL
|
🔗 Cross-repo PR dependenciesThe read-only Build run reported the following dependent PR(s) and fetched head SHA(s): CI run: https://github.com/apache/nuttx/actions/runs/31938194969 |
|
@jerpelea I tried to remove #19745's commits from this branch, and it does not work: this PR splits the file that #19745 fixes, so my commits only exist on top of #19745 - Depends-On: mechanism does not help either. These PR's have to merge in order #19745, 19860, 19861 and 19862. Thats the reason I originally opened as a single PR do avoid these stacked PR... But I was asked to split it up. So... either one large PR doing all the work, or 4 smaller PR's that will have to go through a cycle till we get xhci in a form that can be used on other platforms that Qemu. (i'll rebase each PR as each parent gets merged if needed so any conflicts are resolved) (replying here - but same justification for your comments on the other PR about removing commits) |
Pure rename, so that the history of the driver follows it into the file that keeps the bulk of the code. The PCI attachment is added back as a new usbhost_xhci_pci.c in the commit that follows. Assisted-by: Claude:claude-opus-5 Signed-off-by: Justin Hammond <justin@dynam.ac>
Nothing in the controller driver is PCI-specific beyond finding the registers and the interrupt, so an SoC wiring an xHCI controller directly could not use any of it. usbhost_xhci.c is now the driver; usbhost_xhci_pci.c is the PCI attachment, holding the ID table, the BAR mapping and the MSI-X vector. include/nuttx/usb/xhci.h carries what passes between them: the register base, a way to attach the interrupt, and a name to report the controller by, since a system may have more than one. The interrupt belongs to the bus: the bus attaches and detaches it, and the driver never holds an interrupt number. USBHOST_XHCI is the driver and is not selectable on its own; USBHOST_XHCI_PCI selects it. Another bus adds its own symbol beside it. No functional change intended. Assisted-by: Claude:claude-opus-5 Signed-off-by: Justin Hammond <justin@dynam.ac>
c6bc536 to
c69170f
Compare
|
Rebased after #19745 landed. |
@Fishwaldo you can keep these pr in the draft state until the dependence pr is merged, so the maintainer can know which pr they should review first. |
|
Done. Thanks |
4 participants
Summary
Nothing in the xHCI controller driver is PCI-specific beyond finding the
registers and the interrupt, so an SoC that wires a controller directly could
not use any of it.
Two commits deliberately. The first is a pure
git mvofusbhost_xhci_pci.cto
usbhost_xhci.c, recorded as a rename sogit log --followkeeps reachingthe original driver history, together with the two build-file references so the
commit still builds on its own. The second adds the new
usbhost_xhci_pci.c-the ID table, the BAR mapping and the MSI-X vector - and makes the generic
edits.
include/nuttx/usb/xhci.hcarries what passes between them: the register base,a way to attach the interrupt, and a name to report the controller by, since a
system may have more than one. The interrupt belongs to the bus, which attaches
and detaches it; the driver never holds an interrupt number, so there is
nothing for the two sides to disagree about.
USBHOST_XHCIis the driver and is not selectable on its own;USBHOST_XHCI_PCIselects it. Another bus adds its own symbol beside it.Impact
No functional change intended. Existing configurations keep working through
USBHOST_XHCI_PCI.Testing
Built for
qemu-intel64:nshat both commits with the driver compiled andlinked; the rename commit builds on its own, so the series stays bisectable.
Run at the tip under QEMU with
-device qemu-xhciand ausb-storagedevice,reading back
qemu-xhci-regression-ok- unchanged from #19745, which is thepoint of a move.
History is preserved: