[CC1] RTL8821CU fails USB enumeration with -EPROTO after warm reboot

[pdscomp]

Summary

clogged_nozzl3 reproduced a remaining CC1 Wi-Fi failure on the PR-261-80a
image. This is an earlier failure phase than the rtw88 control-transfer issue
addressed by PR #261.

Related: #261

Evidence

Two read-only diagnostic bundles were collected from the same printer:

• wifi-failure-192.168.1.99-20260721T122030Z.tar.gz
• wifi-failure-192.168.1.99-20260721T122901Z.tar.gz

Both report:

• swu_version=PR-261-80a
• Linux 6.6.85
• different boot IDs (564e99c0-... and 9116f6ca-...), proving separate boots
• the same QinHeng 1a86:8091 hub on physical port 2
• no old_scheme_first or use_both_schemes boot parameter

The USB bus number changes from 1-1.2 to 2-1.2, so the physical port—not a
hard-coded bus path—must be used for any fix.

In both boots the sequence is effectively identical:

hub ready                         ~1.57 s
port 2 device appears             ~2.5 s
GET_DESCRIPTOR(64)                error -71 (-EPROTO), twice
kernel requests port power-cycle ~4.0 s
SET_ADDRESS attempts              error -71 (-EPROTO), twice
port 2 unable to enumerate       ~5.95 s

The camera (05a3:9230) on port 1 and direct Realtek Ethernet (0bda:8156)
on port 3 enumerate normally. The expected RTL8821CU (0bda:c811) is absent
from lsusb; iw dev, rfkill list, and wlan0 are empty, and there are no
rtw_8821cu messages. The driver never gets a chance to run.

The first bundle was captured after 35 minutes of uptime, with no later retry;
the second was captured after one minute on the following warm boot. This is
one failure state persisting across a warm reboot, not yet two independent
healthy-to-failed intervals.

Kernel/config details

The captured config includes the platform EHCI/OHCI drivers,
CONFIG_USB_DEFAULT_PERSIST=y, and CONFIG_USB_AUTOSUSPEND_DELAY=2. No
CONFIG_USB_FEW_INIT_RETRIES setting is present, so the normal four USB port
initialization attempts apply. The stock 6.6 USB core therefore tries the new
scheme first (64-byte descriptor read), power-cycles once, then tries the old
scheme as fallback. The logs match that exact sequence.

USB_QUIRK_HUB_SLOW_RESET is present in the PR build, but it only adds 100 ms
after a successful port reset. It does not provide a long VBUS-off interval or
retry after USB core gives up.

Suspected root cause

The high-confidence fault is USB endpoint-zero enumeration on hub port 2, before
VID/PID discovery and before rtw88. -EPROTO indicates a malformed or missing
USB response, not a Wi-Fi association, firmware-file, or network-service error.

The likely underlying cause is a retained or marginal RTL8821CU/port-2 state
across warm reset: module firmware state, VBUS settling, hub switching, signal
integrity, or board-to-board tolerance. The exact physical component is not
proven. The healthy camera and Ethernet narrow the problem to the Wi-Fi device
or its dedicated port path, but do not distinguish module from motherboard.

Initial mitigation and test plan

1. Keep all PR cc1: harden RTL8821CU Wi-Fi across warm reboots #261 fixes. They address the separate post-bind failure and are
   not involved in this pre-driver failure.
2. Test usbcore.old_scheme_first=1 with the default
   usbcore.use_both_schemes=1. This reverses the order so the address-first
   legacy sequence runs before the failing 64-byte descriptor-first sequence,
   while retaining the new scheme as fallback. This is implemented in the PR
   branch as commit 085eb29.
3. If ordering helps, narrow it from a global parameter to a port-specific
   USB_PORT_QUIRK_OLD_SCHEME for hub 1a86:8091, physical port 2.
4. The follow-up diagnostic disables the fallback entirely with
   usbcore.old_scheme_first=1 usbcore.use_both_schemes=0, matching the old
   enumeration behavior more closely. This is implemented as commit 9073ece
   and is under CI/test now. It is global to USB 2.0 and must be validated with
   the camera, Ethernet, bed MCU, flashing, and both A/B slots.
5. If ordering does not help, test a failure-only, dynamically located port-2
   recovery with increasing off/settle intervals. The hub reports ganged power,
   so sibling peripherals may briefly drop; do this early in boot and never
   while USB storage is mounted.
6. In parallel, compare warm reboot with cold power removal and, if practical,
   swap the RTL8821CU module with a stable CC1 to determine whether the fault
   follows the module or motherboard/port.

The target acceptance criterion is at least 500 consecutive warm reboots (or
five times the reproducer's measured healthy-to-failure interval) with USB,
camera, Ethernet, and bed MCU functionality intact.