[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <383a616d-50c7-4538-9e94-fc8526405c94@quicinc.com>
Date: Wed, 13 Nov 2024 20:13:29 +0530
From: Aditya Kumar Singh <quic_adisi@...cinc.com>
To: Johannes Berg <johannes@...solutions.net>
CC: <linux-wireless@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] wifi: cfg80211: fix WARN_ON during CAC cancelling
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. Will it be
okay to add a new NL command to stop radar detection? Something opposite
of what start_radar_detection command does?
--
Aditya
Powered by blists - more mailing lists