summaryrefslogtreecommitdiff
path: root/include/linux/livepatch_external.h
diff options
context:
space:
mode:
authorAmith A <amith.a@oss.qualcomm.com>2026-01-30 09:25:11 +0530
committerJohannes Berg <johannes.berg@intel.com>2026-02-02 10:06:14 +0100
commitba90a7af74a56326f4ff774674ff4f510dcddee1 (patch)
tree2d1a2e2cc91ac0e6f83183578075bd2ffa3d89be /include/linux/livepatch_external.h
parentc3e92c7868fd1cade43a6fbc7e1d839ec1e9f264 (diff)
wifi: mac80211: use wiphy_hrtimer_work for CAC timeout
Prior initiating communication in a DFS channel, there should be a monitoring of RADAR in that channel for a minimum of 600 seconds if it is a Weather RADAR channel and 60 seconds for other DFS channels. This Channel Availability Check(CAC) is currently implemented by scheduling a work item for execution with a delay equal to an appropriate timeout. But this work item is observed to take more delay than specified (4-5 seconds in regular DFS channels and 25-30 seconds in Weather RADAR channels). Even though this delay is expected in case of delayed work queue as there is no guarantee that the work will be scheduled exactly after the specified delay, a delay of more than 20 seconds is too much for the AP to be in non-operational state. Recently commit 7ceba45a6658 ("wifi: cfg80211: add an hrtimer based delayed work item") added an infrastructure to overcome this issue by supporting high resolution timers for mac80211 delayed work, which do not have this timeout latency. Switch the CAC timeout to use this infrastructure, so the CAC completion handling is triggered with tighter timing and reduced latency. Signed-off-by: Amith A <amith.a@oss.qualcomm.com> Link: https://patch.msgid.link/20260130035511.2328713-1-amith.a@oss.qualcomm.com [fix delay handling] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'include/linux/livepatch_external.h')
0 files changed, 0 insertions, 0 deletions