aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/Perf-Trace-Util/Context.c
diff options
context:
space:
mode:
authorBenjamin Li <[email protected]>2021-10-27 10:03:04 -0700
committerKalle Valo <[email protected]>2021-11-01 16:18:37 +0200
commitf02e1cc2a84693a649d94a7584291d88f31fd5fa (patch)
treeeec8ea6c6237d2477237aff7c3d4a3542f6ff8d3 /tools/perf/scripts/python/Perf-Trace-Util/Context.c
parentdf008741dd62bd3bc8733fe568415fb01b3e65c5 (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