Hi Sergey,
>Hi Orr,
>
>> In case a radar event of CAC_FINISHED or RADAR_DETECTED happens during
>> another phy is during CAC we might need to cancel that CAC.
>> If we got a radar in a channel that another phy is now doing CAC on
>> then the CAC should be canceled.
>> If, for example, 2 phys doing CAC on the same channels, or on
>> comptable channels, once on of them will finish his CAC the other
>> might need to cancel his CAC, since it is no longer relevant.
>>
>> To fix that the commit adds an callback and implement it in mac80211
>> to end CAC.
>> This commit also adds a call to said callback if after a radar event
>> we see the cac is no longer relevant
>
>> net/mac80211/cfg.c | 23 +++++++++++++++++++++++
>> net/wireless/rdev-ops.h | 10 ++++++++++
>> net/wireless/reg.c | 24 +++++++++++++++++++++++-
>> net/wireless/trace.h | 5 +++++
>> 5 files changed, 66 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index
>> 4ab2c49423dc..68782ba8b6e8 100644
>> --- a/include/net/cfg80211.h
>> +++ b/include/net/cfg80211.h
>> @@ -3537,6 +3537,9 @@ struct cfg80211_update_owe_info {
>> *
>> * @start_radar_detection: Start radar detection in the driver.
>> *
>> + * @end_cac: End running CAC, probably because a related CAC
>> + * was finished on another phy.
>> + *
>
>Maybe it makes sense to follow existing naming convention here and to use
>something like 'stop_radar_detection' ?
I think 'stop_radar_detection' might be misleading as we don’t stop radar_detection,
we only end cac, normal radar detection will continue.
>
>> * @update_ft_ies: Provide updated Fast BSS Transition information to the
>> * driver. If the SME is in the driver/firmware, this information can be
>> * used in building Authentication and Reassociation Request frames.
>> @@ -3863,6 +3866,8 @@ struct cfg80211_ops {
>> struct net_device *dev,
>> struct cfg80211_chan_def *chandef,
>> u32 cac_time_ms);
>> + void (*end_cac)(struct wiphy *wiphy,
>> + struct net_device *dev);
>
>...
>
>> +static void cfg80211_check_and_end_cac(struct
>> +cfg80211_registered_device *rdev) {
>> + struct wireless_dev *wdev;
>> + /* If we finished CAC or received radar, we should end any
>> + * CAC running on the same channels.
>> + * the check !cfg80211_chandef_dfs_usable contain 2 options:
>> + * either all channels are available - those the CAC_FINISHED
>> + * event has effected another wdev state, or there is a channel
>> + * in unavailable state in wdev chandef - those the RADAR_DETECTED
>> + * event has effected another wdev state.
>> + * In both cases we should end the CAC on the wdev.
>> + *
>> + */
>> + list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
>> + if (wdev->cac_started &&
>> + !cfg80211_chandef_dfs_usable(&rdev->wiphy, &wdev-
>>chandef))
>> + rdev_end_cac(rdev, wdev->netdev);
>> + }
>> +}
>> +
>
>IIUC, this code does not match your commit message. You are stopping CAC
>on all the virtual wireless interfaces on the same PHY, but not CACs on
>different PHYs. Meanwhile CAC does not need to be started on multiple
>virtual interfaces. For instance, in multiple BSSID configuration, hostapd
>performs CAC only on primary interface.
>
regulatory_propagate_dfs_state will call cfg80211_check_and_end_cac
only on phys != current phy.
So for each phy != current we will call mac80211 end_cac (if needed)
which in turn will end the cac on all that phys’ interfaces.
>Could you please clarify the use-case which requires this functionality ?
>
I will explain more on the use-case:
Let say we have 2 phys on 5ghz: phy0, phy1
And 2 interfaces accordingly: wlan0, wlan1
We start hostapd with wlan0 in channel 60,
5 seconds later we start hostapd with wlan1 on channel 60.
What will happen is that when phy0 finishes CAC,
It will propagate it to phy1 and to the other hostapd,
which causes it to start the ap fully.
However the CAC timer on wlan1 is still running,
The propagate did not stop it.
When wlan1 CAC is finished we will get the following:
WARNING: CPU: 0 PID: 4406 at net/mac80211/chan.c:1753 ieee80211_vif_release_channel+0x21/0x60 [mac80211]
From
[ +0.000002] Call Trace:
[ +0.000044] ieee80211_dfs_cac_timer_work+0x74/0xc0 [mac80211]
Since we are trying to release the channel when the interface is active.
Also, from that point on, we will be unable to do channel switch on wlan1,
probably because we released the channel.
A few minutes later this also shows up:
WARNING: CPU: 2 PID: 6017 at net/mac80211/ieee80211_i.h:1435 ieee80211_change_bss+0x1a6/0x1c0 [mac80211]
The idea behind this patch is to improve the regulatory_propagate_dfs_state,
so it will also consider cases in which the radar event effects other phys CAC,
and won’t get that warnings and issues in that case.
>Regards,
>Sergey
>
>
>This email, including its contents and any attachment(s), may contain
>confidential information of ON Semiconductor and is solely for the intended
>recipient(s). If you may have received this in error, please contact the sender
>and permanently delete this email, its contents and any attachment(s).
Regards,
Orr
