[PATCH wireless-next] wifi: mac80211: use wiphy_hrtimer_work for CAC timeout

[PATCH wireless-next] wifi: mac80211: use wiphy_hrtimer_work for CAC timeout

[Amith A]

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. The other patches in that series converted some
mac80211 work items to use the new infrastructure.

Unfortunately the CAC timeout work was not addressed as part of that series,
so address it now.

Signed-off-by: Amith A <amith.a@oss.qualcomm.com>
---
 net/mac80211/cfg.c         | 8 ++++----
 net/mac80211/ieee80211_i.h | 2 +-
 net/mac80211/iface.c       | 2 +-
 net/mac80211/link.c        | 4 ++--
 net/mac80211/util.c        | 2 +-
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 964f440e31cd..acec44957040 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1916,7 +1916,7 @@ static int ieee80211_stop_ap(struct wiphy *wiphy, struct net_device *dev,
 
 	if (sdata->wdev.links[link_id].cac_started) {
 		chandef = link_conf->chanreq.oper;
-		wiphy_delayed_work_cancel(wiphy, &link->dfs_cac_timer_work);
+		wiphy_hrtimer_work_cancel(wiphy, &link->dfs_cac_timer_work);
 		cfg80211_cac_event(sdata->dev, &chandef,
 				   NL80211_RADAR_CAC_ABORTED,
 				   GFP_KERNEL, link_id);
@@ -3851,6 +3851,7 @@ static int ieee80211_start_radar_detection(struct wiphy *wiphy,
 					   u32 cac_time_ms, int link_id)
 {
 	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+	ktime_t ktime = ktime_set(0, cac_time_ms * NSEC_PER_MSEC);
 	struct ieee80211_chan_req chanreq = { .oper = *chandef };
 	struct ieee80211_local *local = sdata->local;
 	struct ieee80211_link_data *link_data;
@@ -3874,8 +3875,7 @@ static int ieee80211_start_radar_detection(struct wiphy *wiphy,
 	if (err)
 		return err;
 
-	wiphy_delayed_work_queue(wiphy, &link_data->dfs_cac_timer_work,
-				 msecs_to_jiffies(cac_time_ms));
+	wiphy_hrtimer_work_queue(wiphy, &link_data->dfs_cac_timer_work, ktime);
 
 	return 0;
 }
@@ -3894,7 +3894,7 @@ static void ieee80211_end_cac(struct wiphy *wiphy,
 		if (!link_data)
 			continue;
 
-		wiphy_delayed_work_cancel(wiphy,
+		wiphy_hrtimer_work_cancel(wiphy,
 					  &link_data->dfs_cac_timer_work);
 
 		if (sdata->wdev.links[link_id].cac_started) {
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index dc757cb32974..df5056463388 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1101,7 +1101,7 @@ struct ieee80211_link_data {
 	int ap_power_level; /* in dBm */
 
 	bool radar_required;
-	struct wiphy_delayed_work dfs_cac_timer_work;
+	struct wiphy_hrtimer_work dfs_cac_timer_work;
 
 	union {
 		struct ieee80211_link_data_managed mgd;
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 3ce94b95decd..15583fc7003a 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -561,7 +561,7 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata, bool going_do
 	wiphy_work_cancel(local->hw.wiphy, &sdata->deflink.csa.finalize_work);
 	wiphy_work_cancel(local->hw.wiphy,
 			  &sdata->deflink.color_change_finalize_work);
-	wiphy_delayed_work_cancel(local->hw.wiphy,
+	wiphy_hrtimer_work_cancel(local->hw.wiphy,
 				  &sdata->deflink.dfs_cac_timer_work);
 
 	if (sdata->wdev.links[0].cac_started) {
diff --git a/net/mac80211/link.c b/net/mac80211/link.c
index 1e05845872af..17bf55dabd31 100644
--- a/net/mac80211/link.c
+++ b/net/mac80211/link.c
@@ -116,7 +116,7 @@ void ieee80211_link_init(struct ieee80211_sub_if_data *sdata,
 			ieee80211_color_change_finalize_work);
 	wiphy_delayed_work_init(&link->color_collision_detect_work,
 				ieee80211_color_collision_detection_work);
-	wiphy_delayed_work_init(&link->dfs_cac_timer_work,
+	wiphy_hrtimer_work_init(&link->dfs_cac_timer_work,
 				ieee80211_dfs_cac_timer_work);
 
 	if (!deflink) {
@@ -155,7 +155,7 @@ void ieee80211_link_stop(struct ieee80211_link_data *link)
 			  &link->csa.finalize_work);
 
 	if (link->sdata->wdev.links[link->link_id].cac_started) {
-		wiphy_delayed_work_cancel(link->sdata->local->hw.wiphy,
+		wiphy_hrtimer_work_cancel(link->sdata->local->hw.wiphy,
 					  &link->dfs_cac_timer_work);
 		cfg80211_cac_event(link->sdata->dev,
 				   &link->conf->chanreq.oper,
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 4d5680da7aa0..260893b83df1 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -3597,7 +3597,7 @@ void ieee80211_dfs_cac_cancel(struct ieee80211_local *local,
 			if (ctx && &ctx->conf != chanctx_conf)
 				continue;
 
-			wiphy_delayed_work_cancel(local->hw.wiphy,
+			wiphy_hrtimer_work_cancel(local->hw.wiphy,
 						  &link->dfs_cac_timer_work);
 
 			if (!sdata->wdev.links[link_id].cac_started)

base-commit: c30e188bd2a886258be5facb970a804d8ef549b5
-- 
2.34.1

Re: [PATCH wireless-next] wifi: mac80211: use wiphy_hrtimer_work for CAC timeout

[Johannes Berg]

On Wed, 2026-01-28 at 12:18 +0530, Amith A wrote:
> 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. The other patches in that series converted some
> mac80211 work items to use the new infrastructure.
> 
> Unfortunately the CAC timeout work was not addressed as part of that series,
> so address it now.

This is ... a pretty grossly wrong characterisation. The previous work
fixed a bunch of *correctness* issues. This fixes a performance thing at
best, and you seem to be complaining those are the same and therefore it
should've been fixed before. The other patches also went to wireless for
being fixes, this really wouldn't, I'd argue, those two things really
aren't the same.

Please rewrite this commit message.

johannes

Re: [PATCH wireless-next] wifi: mac80211: use wiphy_hrtimer_work for CAC timeout

[Amith A]

On 1/29/2026 2:02 PM, Johannes Berg wrote:
> On Wed, 2026-01-28 at 12:18 +0530, Amith A wrote:
>> 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. The other patches in that series converted some
>> mac80211 work items to use the new infrastructure.
>>
>> Unfortunately the CAC timeout work was not addressed as part of that series,
>> so address it now.
> This is ... a pretty grossly wrong characterisation. The previous work
> fixed a bunch of *correctness* issues. This fixes a performance thing at
> best, and you seem to be complaining those are the same and therefore it
> should've been fixed before. The other patches also went to wireless for
> being fixes, this really wouldn't, I'd argue, those two things really
> aren't the same.
>
> Please rewrite this commit message.
Will rewrite the commit message and send the next version.
>
> johannes

Re: [PATCH wireless-next] wifi: mac80211: use wiphy_hrtimer_work for CAC timeout

[Johannes Berg]

On Wed, 2026-01-28 at 12:18 +0530, Amith A wrote:
> 
> @@ -3851,6 +3851,7 @@ static int ieee80211_start_radar_detection(struct wiphy *wiphy,
>  					   u32 cac_time_ms, int link_id)
>  {
>  	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> +	ktime_t ktime = ktime_set(0, cac_time_ms * NSEC_PER_MSEC);

ms_to_ktime()

johannes