GMMOS: USB keyboards on xHCI

The third micro driver: xhci.c with everything but finding a keyboard and
reading it taken out. It does not take over the live driver's state --
the kernel may have died inside that driver -- so each controller is
halted, reset and enumerated from nothing. Of the live driver it uses
the register mapping and the scratchpad pages the controller was lent
(DCBAA entry 0, read before the reset).

Root ports, and USB 2 hubs up to two deep (power, reset, route string,
transaction translator for a slow device behind a high-speed hub). A
boot-protocol keyboard interface gets Set Configuration, Set Protocol
boot, Set Idle, one interrupt IN endpoint and a Normal TRB, re-queued
after every report. No interrupts, no hot-plug, nothing that is not a
keyboard or a hub. A static 256 KB pool instead of the DMA allocator.

Checked under QEMU with the PS/2 controller switched off (i8042=off): a
USB keyboard on a root port, and one behind a hub, both type into the
GMMOS terminal. QEMU's hub is full speed, so the transaction-translator
path is not exercised.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S1giNvrHTrPMPw7V6x1kQ4
This commit is contained in:
Nexoniarz 2026-10-25 01:23:14 +02:00
commit f6c4b6377f
5 changed files with 616 additions and 2 deletions

View file

@ -1703,6 +1703,20 @@ xhci_probe(struct pci_dev *d)
return 0;
}
// For GMMOS, after a panic: each controller's registers, as mapped here. Its
// micro driver resets the controller and starts again, so this is all it
// takes -- a BAR above 4 GB has no address of its own without ioremap(),
// which is not a thing to call on a dead kernel.
int
xhci_gmmos_controllers(volatile uchar **caps, int max)
{
int i;
for(i = 0; i < nxhci && i < max; i++)
caps[i] = xhcis[i].cap;
return i;
}
// ---------------------------------------------------------------------------
// Hot-plug
// ---------------------------------------------------------------------------