RE: [PATCH v2] wifi: rtw89: phy: increase RF calibration timeouts for USB transport

Ping-Ke Shih
2026-04-16T01:15:33Z

Louis Kotze <loukot@gmail.com> wrote:
> USB transport adds significant latency to H2C/C2H round-trips used
> by RF calibration. The existing timeout values were designed for PCIe
> and are too tight for USB, causing "failed to wait RF DACK",
> "failed to wait RF TSSI" and similar errors on USB adapters.
>
> Apply a 4x timeout multiplier when the device uses USB transport.
> The multiplier is applied in rtw89_phy_rfk_report_wait() so all
> calibrations benefit without changing any call sites or PCIe
> timeout values.
>
> The 4x multiplier was chosen based on measured data from two
> independent testers (RTL8922AU, 6GHz MLO and 2.4/5GHz):
>
> Calibration PCIe timeout Max measured (USB) 4x timeout
> PRE_NTFY 5ms 1ms 20ms
> DACK 58ms 72ms 232ms
> RX_DCK 128ms 374ms 512ms
> TSSI normal 20ms 24ms 80ms
> TSSI scan 6ms 14ms 24ms
> TXGAPK 54ms 18ms 216ms
> IQK 84ms 53ms 336ms
> DPK 34ms 30ms 136ms
>
> Tested with RTL8922AU on 6GHz MLO (5GHz + 6GHz simultaneous):
> 25 connect/disconnect cycles with zero failures.
>
> In response to review feedback on v1,

Can we remove this phrase? No need to mention v1 in commit message.

> the 4x multiplier was also
> re-verified under adverse host conditions on 5GHz. 5 cycles per
> scenario, stress-ng as the load generator, max observed time per
> calibration:
>
> Calibration PCIe 4x Baseline CPU stress Mem stress Combined
> PRE_NTFY 5 20 0 0 0 1
> DACK 58 232 71 (!) 71 (!) 71 (!) 71 (!)
> RX_DCK 128 512 23 22 22 23
> IQK 84 336 53 53 53 53
> DPK 34 136 23 23 26 23
> TSSI 20 80 6 9 14 9
> TXGAPK 54 216 16 16 16 16
>
> Legend: (!) = exceeds PCIe budget but within 4x budget.
>
> Two observations from that matrix:
>
> 1. DACK exceeds the stock PCIe budget (58ms) in baseline on 5GHz
> on this hardware. Without the 4x multiplier, DACK fails
> -ETIMEDOUT deterministically on every connect, no stress
> needed. This is the specific bug the patch fixes.

I'm not sure this should be called "bug", as Bitterblue has not adjusted
these timeout time by earlier version.

>
> 2. Calibration times are I/O bound (USB H2C/C2H round-trip
> latency),

I'm also not sure if this is correct. The calibration time of DACK might
rely on WiFi hardware and external components, not only I/O speed.

> not CPU or memory bound. DACK stays at 71ms across
> all four scenarios. Host-side stress has essentially zero
> effect on observed calibration duration. Bumping the
> multiplier above 4x would not address a failure mode that
> this stress matrix produces.
>
> Signed-off-by: Louis Kotze <loukot@gmail.com>

Otherwise, patch content looks good to me.

Acked-by: Ping-Ke Shih <pkshih@realtek.com>