[BUG] xhci: Acer ANV16S-41 internal USB camera never attaches on AMD 1022:15ba

The internal USB camera on an Acer Nitro ANV16S-41 works under Windows but
does not enumerate under Linux. This is before uvcvideo can bind, not a UVC
probe-control failure.

Hardware and tested software:

- Acer ANV16S-41, board BRZ_SKF, BIOS V1.14 dated 2026-04-02.
- Ryzen 7 260; Arch Linux 7.2.2-arch1-1.
- xHCI PCI 0000:65:00.4, 1022:15ba rev 00, subsystem 1025:1969.
- Camera USB 0408:4035 rev 0004, using Microsoft usbvideo on Windows.
- Controller path \_SB.PCI0.GP17.XHC1; camera under RHUB.PRT1.CAM0.
- Linux USB2 port usb3-port1 is hardwired; companion usb4-port1 is not used.
- Windows USBXHCI version 10.0.26100.8972.

On 2026-09-08, a read-only check also finds no camera USB device or video node
on 7.2.3-arch1-3, with BIOS V1.14 and the same controller IDs. The detailed
controlled boot traces below were recorded on 7.2.2-arch1-1, not 7.2.3.

Linux results:

1. No camera USB device or video node.
2. Resuming the controller/root hub to D0/active does not reveal the camera.
3. Cycling only the empty camera port changes PORTSC from 0x000002a0 to
   0x00000080 and back, with no attachment.
4. Unbinding/rebinding the empty xHCI controller recreates the root hubs but
   does not reveal the camera. Original policies were restored.
5. A separate boot with usbcore.autosuspend=-1 keeps this controller and both
   root hubs continuously active throughout a 42.9-second trace. The camera
   is still absent. The capture contains 121,343 events with no reported
   drops across 16 CPU buffers.

In the no-autosuspend boot, the first camera-port write is PORTSC 0x000002a0
at 0.737260 seconds, followed by the same status at 0.757631 seconds.
No later attachment or enumeration is recorded. PP is set, CCS is clear;
this is not a physical measurement of module voltage.

Successful Windows cold and warm boot traces show standard root-hub
SET_FEATURE(PORT_POWER) for USB2 port 1, approximately 100 ms later a hub
status of 0x0101/change 0x0001, then normal port reset and enumeration.
The unused SuperSpeed port is also powered/disconnected (hub status 0x02a0).
No proprietary USB request enabling the camera before attachment was found.
Raw xHCI PORTSC and USB hub status use different bit layouts.

The Windows ETLs retain USBXHCI/USBHUB3/UCX and ACPI events with embedded
build-specific schemas. Local decoding recovered 13,249 cold-boot and
14,015 warm-boot UCX records. All 5,185 XHCI/HUB3 records match the native
Windows exports on comparable fields and timestamps within 2 microseconds.
Opaque structure fields and UCX/ACPI payload semantics were not independently
validated against native field exports; decoding limits are documented.

ACPI SSDT31 supplies XHC1 power methods, despite their absence from the
DSDT device body. Its platform hooks call M000, whose only definition in the
captured SSDT17 is empty. SSDT9 XHC1 _DSM advertises functions 3/4 and returns
constant buffers. Windows logs method names but not the _DSM arguments or
underlying register operations. No verified camera-enable method was found.

Matching Microsoft public symbols decode the target controller's recorded
flags as 0x00040060000000a4 / 0x0000000044050000. The three
RestoreRyzenFeatureBitsPostControllerReset flags and Needs180msDelayPostHcReset
are not set in any of the ten saved controller snapshots. This is an observed
flag state, not proof of every operation performed before those snapshots.

The unresolved stage is controller/platform initialization before electrical
USB attachment. Maintainer guidance on a targeted xHCI/PCI/ACPI instrumentation
point or a known AMD/board-specific initialization requirement would help
identify a justified patch. There is currently no proposed fix or known-good
Linux version, so this is not being presented as a bisected regression.

A separate same-model/BIOS report describes the same symptom:
https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg6302306.html
Its claim that no XHC1 power methods exist does not match this laptop's SSDT31.