[CC1] RTL8821CU rtw88 post-bind USB control transfers fail with -EPROTO

[pdscomp]

Summary

Some CC1 boots reach RTL8821CU driver binding and begin firmware initialization,
then lose USB vendor control transfers with -EPROTO (-71). This is the
post-bind failure phase addressed by PR #261,
and is distinct from the pre-driver enumeration failure tracked in
#263.

Related: #261

Observed failure

On a failing PR-261/CC1 boot, the sequence was:

~2.5 s   RTL8821CU USB device enumerates below QinHeng 1a86:8091 hub
~6.0 s   rtw_8821cu binds; firmware 24.11.0, H2C version 12
~9.4 s   register/control transfers begin returning -71 (-EPROTO)
~30.0 s  failed to download firmware / failed to leave idle state
~30.7 s  hub disables port 2 and disconnects the Wi-Fi device
~33-36 s descriptor retries and final unable-to-enumerate result

The original trace emitted approximately 1,051 failed rtw_usb_reg_sec()
messages, while only a handful of ordinary read/write failures were visible
because those paths had separate log limits. The fixed 0x4e0 companion write
used by the RTL8821C register-section workaround also failed. The later hub
disable/disconnect is downstream of the control-transfer failure, not its root
cause.

Root-cause assessment

The failing layer is the USB vendor-control transport after successful
enumeration and driver binding. The likely underlying condition is the same
marginal or retained RTL8821CU/port-2 USB state that can also present earlier
as an endpoint-zero enumeration failure, but the exact physical source remains
unproven: module firmware state, VBUS settling, hub switching, signal margin,
or board-to-board tolerance.

This is not caused by the documented upstream RTL8821CU firmware-upload fix
being absent. The recipe's pinned lwfinger/rtw88 revision already contains
upstream commit
c99acdd
as an ancestor, including the RTL8821C 0x4e0 register-section companion
write. The trace shows that companion transfer failing too.

PR #261 mitigation

PR #261 retains three targeted changes:

1. Add the CC1 QinHeng 1a86:8091 hub to USB_QUIRK_HUB_SLOW_RESET.
2. Serialize rtw88 register, companion, and firmware-page vendor requests with
   a mutex, following the vendor driver's atomic-request principle.
3. Retry only -EPROTO register/control failures with 5, 20, 80, 320, and
   1280 ms backoff. Successful transfers have no added delay. Exhausted
   failures latch the transport broken and suppress the previous storm of
   futile register requests.

The earlier blanket 5 ms delay improved one board's recurrence interval but
added about 17.7 seconds to initialization and still failed after 19 successful
reboots, so it is not retained. The current patches completed 540 consecutive
warm reboot loops on carbon-devu without reproducing this phase, but the
failure remains possible on other hardware and should be tested separately
from the pre-enumeration issue.

Validation and follow-up

• Preserve the full dmesg when a terminal USB control ... failed with -71
  message appears; it identifies the original operation/register address.
• Confirm a recovered transfer logs USB control ... recovered after N retries
  and that wlan0 appears without a material healthy-boot delay.
• Keep the old-scheme enumeration experiments from [CC1] RTL8821CU fails USB enumeration with -EPROTO after warm reboot #263 separate when
  comparing results; they cannot affect a device that has already bound rtw88.
• If bounded retries still exhaust, investigate a failure-only USB reset/reprobe
  or a narrowly scoped preventive interval around the identified operation,
  without restoring blanket control-message pacing.
• Validate at least 500 warm reboots on the reproducing hardware, plus camera,
  Ethernet, bed MCU, flashing, and both A/B slots.