Re: [PATCH 1/1] wifi: mac80211: don't coalesce a new ROC onto an expired one

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2026-11-04 at 17:20 +0800, JB Tsai wrote:
> From: james-ly huang <james-ly.huang@mediatek.com>
> 
> ieee80211_coalesce_hw_started_roc() computed the remaining time of the
> running ROC as
> 
> 	remaining = cur_roc->start_time +
> 		    msecs_to_jiffies(cur_roc->duration) - now;
> 
> and merged the new request into it when the new duration fits. When the
> running ROC is already over, that subtraction wraps around (unsigned),
> the "fits" check passes, and the new request gets added behind a ROC
> that will never produce another on_channel or expired event.
> 
> The expired-but-still-listed state is not rare at all: the driver's
> ieee80211_remain_on_channel_expired() only queues the hw_roc_done work,
> so until that work runs - the driver's UNI_ROC_ABORT round trip can
> take tens of ms - every ROC on the list whose time is up stays listed
> with started=true. A remain-on-channel / mgmt-TX request arriving in
> that window hits exactly this path.
> 
> Check the ROC's end time explicitly with time_after_eq() and refuse to
> coalesce once it has passed; compute the (now guaranteed positive)
> remaining window from the same end time.

Please rewrite this with a useful commit message and comment.

johannes