diff options
| author | Benjamin Li <[email protected]> | 2021-10-27 10:03:04 -0700 |
|---|---|---|
| committer | Kalle Valo <[email protected]> | 2021-11-01 16:18:37 +0200 |
| commit | f02e1cc2a84693a649d94a7584291d88f31fd5fa (patch) | |
| tree | eec8ea6c6237d2477237aff7c3d4a3542f6ff8d3 /tools/perf/scripts/python/Perf-Trace-Util/Context.c | |
| parent | df008741dd62bd3bc8733fe568415fb01b3e65c5 (diff) | |
wcn36xx: implement flush op to speed up connected scan
Without ieee80211_ops->flush implemented to empty HW queues, mac80211 will
do a 100ms dead wait after stopping SW queues, before leaving the operating
channel to resume a software connected scan[1].
(see ieee80211_scan_state_resume)
This wait is correctly included in the calculation for whether or not
we've exceeded max off-channel time, as it occurs after sending the null
frame with PS bit set. Thus, with 125 ms max off-channel time we only
have 25 ms of scan time, which technically isn't even enough to scan one
channel (although mac80211 always scans at least one channel per off-
channel window).
Moreover, for passive probes we end up spending at least 100 ms + 111 ms
(IEEE80211_PASSIVE_CHANNEL_TIME) "off-channel"[2], which exceeds the listen
interval of 200 ms that we provide in our association request frame. That's
technically out-of-spec.
[1]: Until recently, wcn36xx performed software (rather than FW-offloaded)
scanning when 5GHz channels are requested. This apparent limitation is now
resolved -- see commit 1395f8a6a4d5 ("wcn36xx: Enable hardware scan offload
for 5Ghz band").
[2]: in quotes because about 100 ms of it is still on-channel but with PS
set
Signed-off-by: Benjamin Li <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Diffstat (limited to 'tools/perf/scripts/python/Perf-Trace-Util/Context.c')
0 files changed, 0 insertions, 0 deletions