tests: libusb_wrap_sys_device hotplug smoke test

[josephnef]

Adds tests/in_process_hotplug_wrap.cpp — an in-process hotplug binary that constructs the libusb handle via libusb_wrap_sys_device(fd) instead of libusb_open_device_with_vid_pid. Mirrors the construction path Android takes when an app obtains a fd from UsbDeviceConnection.getFileDescriptor().

Follow-up to the kaeru episode 8821au-inprocess-hotplug-cant-repro-2026-05-25 which noted we lacked a Linux test exercising the wrap_sys_device codepath.

How it works

1. Walks /sys/bus/usb/devices/ (NO libusb enumeration) to find a device matching VID:PID — default 2357:0120 / T2U Plus
2. Reads busnum + devnum, opens /dev/bus/usb/BBB/DDD directly via open(2)
3. libusb_wrap_sys_device(ctx, fd, &handle) → that's the construction path Android uses
4. CreateRtlDevice + Init, count RX hits for RX_SECONDS
5. Trigger sysfs unbind+rebind of the same port (full USB reset cycle)
6. Repeats steps 1-4 — new fd, new wrap_sys_device handle in the same libusb context as session 1
7. Prints per-session hit counts + verdict

g++ -std=c++20 -O2 tests/in_process_hotplug_wrap.cpp \
    -o /tmp/in_process_hotplug_wrap \
    -I src -I hal build/libWiFiDriver.a \
    $(pkg-config --cflags --libs libusb-1.0) -pthread

sudo /tmp/in_process_hotplug_wrap            # default 2357:0120
sudo /tmp/in_process_hotplug_wrap 0bda 8812  # explicit chipset

Honest scope note

This test does NOT reproduce the original Android hotplug bug on Linux. Validated 2026-05-26:

Built against	iter1 hits	iter2 hits	Verdict
master 01cad75 (post-#42)	246	192	both RX ✓
master 8c87cd5 (pre-#42)	243	241	both RX ✓

Same outcome on both. So the Android gap evidently involves more than just libusb_wrap_sys_device construction — likely fd lifetime, USB reset semantics, or Android-stack-specific teardown behavior we don't replicate with sysfs unbind/rebind alone.

Treat this as a smoke check for the wrap_sys_device construction path, not a regression test for the specific hotplug bug.

Why land it anyway

• Catches future breakage of the wrap_sys_device construction path itself (e.g. if some HAL change broke fd-wrap init, this would catch it).
• Scaffolding for future experiments — find_usb_device, open_usbfs, and wrap helpers are reusable. Anyone trying to narrow the Android gap can iterate on closure timing, USBFS reset ioctls, etc., from this base.
• Documents that "we tested wrap_sys_device on Linux master and it works" — useful when triaging future hotplug reports that may or may not be the same bug.

Build is opt-in (not added to CMakeLists). Header comment carries the compile + run instructions; no CI integration.

Test plan

• Builds against current master
• Runs end-to-end on the rig (T2U Plus, 8814 + 8821 hardware available)
• Validated identical outcome on pre-RTL8821AU: 8821-specific init flow (replaces trace-derived parity) #42 (8c87cd5) and post-RTL8821AU: 8821-specific init flow (replaces trace-derived parity) #42 (01cad75) — confirms the test does not depend on PR RTL8821AU: 8821-specific init flow (replaces trace-derived parity) #42's changes
• CI matrix builds (no effect since file isn't compiled by default)

🤖 Generated with Claude Code