From: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
To: Orr Mazor <orr.mazor@tandemg.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] subsystem: Fix radar event during another phy CAC
Date: Mon, 23 Dec 2019 13:52:35 +0300 [thread overview]
Message-ID: <20191223105234.lgsupxfapbmxuvc5@bars> (raw)
In-Reply-To: <20191222145449.15792-1-Orr.Mazor@tandemg.com>
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' ?
> * @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.
Could you please clarify the use-case which requires this functionality ?
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).
next prev parent reply other threads:[~2019-12-23 10:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-22 14:55 [PATCH] subsystem: Fix radar event during another phy CAC Orr Mazor
2019-12-23 10:52 ` Sergey Matyukevich [this message]
2019-12-24 8:29 ` Orr Mazor
2019-12-24 11:42 ` Sergey Matyukevich
2019-12-24 13:18 ` Orr Mazor
2019-12-24 15:37 ` Sergey Matyukevich
2020-01-15 7:40 ` Kalle Valo
2020-01-15 10:28 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191223105234.lgsupxfapbmxuvc5@bars \
--to=sergey.matyukevich.os@quantenna.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=orr.mazor@tandemg.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox