On 11/13/24 21:18, Johannes Berg wrote:
On Wed, 2024-11-13 at 20:13 +0530, Aditya Kumar Singh wrote:
On 11/13/24 14:59, Johannes Berg wrote:
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index a5eb92d93074e6ce1e08fcc2790b80cf04ff08f8..2a932a036225a3e0587cf5c18a4e80e91552313b 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -1112,10 +1112,6 @@ void cfg80211_cac_event(struct net_device *netdev,
struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy);
unsigned long timeout;
- if (WARN_ON(wdev->valid_links &&
- !(wdev->valid_links & BIT(link_id))))
- return;
-
trace_cfg80211_cac_event(netdev, event, link_id);
if (WARN_ON(!wdev->links[link_id].cac_started &&
This really doesn't seem right.
Perhaps the order in teardown should be changed?
I thought about it but couldn't really come down to a convincing approach.
The thing is when CAC in ongoing and hostapd process is killed, there is
no specific event apart from link delete which hostapd sends.
so we do have link removal, why doesn't that work?
Because link ID is cleared from the bitmap well before link stop is
called. As mentioned in commit message, this is the flow -
nl80211_remove_link
> cfg80211_remove_link -> link ID gets updated here
> ieee80211_del_intf_link
> ieee80211_vif_set_links
> ieee80211_vif_update_links
> ieee80211_link_stop -> this ultimately tries to stop
CAC if it is ongoing.
Will it be
okay to add a new NL command to stop radar detection? Something opposite
of what start_radar_detection command does?
No, obviously not.
johannes
--
Aditya
