Artemis Milestone 2e: PORTSC connect/disconnect detection, verified live

xhci_poll_events()'s Port Status Change branch now decodes the Port ID
from the event TRB (XHCI_PSC_EVT_PORT_ID, new in xhci.h), reads that
port's PORTSC.CCS via a new xhci_port_regs() helper, and logs connect vs.
disconnect. Acknowledges by writing back only PP (preserved) and CSC (the
bit being cleared) -- PED/PR/other _C bits written 0 so nothing is
accidentally disabled, reset, or silently cleared, matching the RW1C
discipline already used for ERDP.EHB in 2d.

Verified with the real target scenario via QMP hotplug on all three
architectures: boot with the xHCI controller present but no USB device
attached (confirmed zero port activity at ok>), then live
attach/detach/re-attach of a virtual USB thumb drive
(disk/usb-thumbdrive-test.img via usb-storage on xhci0.0). Full
connect->disconnect->connect cycle confirmed clean (no port wedge) on
amd64; single connect confirmed on aarch64 and riscv64.

Still open: correlating Command Completion Events back to their issuing
command, driving Enable Slot/Address Device from this connect path
(currently only a boot-time smoke test), and the callback surface into
Section U's higher-level code.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HZ8kNoTuP63pbQtro4qvrm

FABRIC-2.md

@@ -3205,8 +3205,8 @@ Final three-arch acceptance (probe-free, `clean qemu`): all three boot to `ok>`
 `logs/20260822-091923/amd64/`, `logs/20260822-092035/aarch64/`, `logs/20260822-092229/riscv64/`.
 
 **2e. Hotplug detection (the actual trigger for everything in Section U)**
-- [ ] On a Port Status Change event, read the corresponding Port Register to determine
-      connect vs. disconnect
+- [x] On a Port Status Change event, read the corresponding Port Register to determine
+      connect vs. disconnect — **done 2026-08-22**, see writeup below
 - [ ] On connect: allocate a Device Slot (Enable Slot command via the Command Ring), address
       the device (Address Device command), read its device descriptor
 - [ ] On disconnect: tear down the corresponding device slot and signal to whatever higher-
@@ -3233,12 +3233,29 @@ Closed that gap first as its own discriminating step:
   starts running from `ok>`'s idle loop — proof the controller actually consumed a
   software-written TRB via doorbell 0, not just that software believes it did.
   `logs/20260822-093311/amd64/`, `logs/20260822-093412/aarch64/`, `logs/20260822-093549/riscv64/`.
-- Still open, unchanged from the checklist above: reading PORTSC to distinguish connect from
-  disconnect, correlating the Command Completion Event back to its issuing command (currently
-  only logged, slot ID/context bookkeeping not read from the event TRB), Address Device, and
-  the callback surface into Section U's higher-level code. The Enable Slot call above is a
-  speculative smoke test, not yet triggered by a real connect event — that wiring is the next
-  increment.
+**PORTSC connect/disconnect read, done 2026-08-22.** Port Status Change Event TRBs carry the
+1-based Port ID in `parameter[31:24]` (`XHCI_PSC_EVT_PORT_ID()`, new in `xhci.h`); a new
+`xhci_port_regs()` helper computes the Port Register Set address (Operational base + 0x400 +
+0x10*port_index) and `xhci_poll_events()`'s PSC branch now reads `PORTSC.CCS` to log
+`device connected` or `device disconnected`, then acknowledges by writing back only `PP`
+(preserved) and `CSC` (the one RW1CS bit being cleared) — `PED`/`PR`/every other `_C` bit
+written as 0 so nothing is accidentally disabled, reset, or silently cleared, matching the
+same RW1C discipline already applied to `ERDP.EHB` in 2d.
+
+Verified live via QMP hotplug, all three architectures, using the real scenario: boot with the
+xHCI controller present but **no USB device attached** (confirmed zero port activity at
+`ok>`), then `device_add usb-storage,bus=xhci0.0` → immediate `device connected`, then
+`device_del` → immediate `device disconnected`, then a second `device_add` → immediate
+`device connected` again with no wedge (proves the CSC acknowledgment doesn't stick the port).
+Full connect→disconnect→connect cycle confirmed on amd64
+(`logs/20260822-100654/amd64/`); single connect confirmed on aarch64
+(`logs/20260822-100814/aarch64/`) and riscv64 (`logs/20260822-100940/riscv64/`).
+
+Still open: correlating the Command Completion Event back to its issuing command (currently
+only logged, slot ID/context bookkeeping not read from the event TRB), actually calling Enable
+Slot / Address Device from the connect path above (today's Enable Slot call remains the
+boot-time smoke test from the previous increment, not yet triggered by a real connect event),
+and the callback surface into Section U's higher-level code.
 
 **2f. USB device enumeration (post-connect, before it's usable as storage)**
 - [ ] Request and parse the device descriptor (confirm vendor/product IDs are even needed,