From: Johannes Berg <johannes@sipsolutions.net>
To: Raj Kumar Bhagat <quic_rajkbhag@quicinc.com>
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH wireless-next 2/3] wifi: mac80211: Allow scan on a radio while operating on DFS on another radio
Date: Fri, 16 May 2025 10:01:11 +0200 [thread overview]
Message-ID: <d23e55879c6d8b6cabcc8357f153ae0622a4c53a.camel@sipsolutions.net> (raw)
In-Reply-To: <20250514-mlo-dfs-acs-v1-2-74e42a5583c6@quicinc.com>
On Wed, 2025-05-14 at 16:58 +0530, Raj Kumar Bhagat wrote:
> Currently, in multi-radio wiphy cases, if one radio is operating on a DFS
> channel, -EBUSY is returned even when a scan is requested on a different
> radio. Because of this, an MLD AP with one radio (link) on a DFS channel
> and Automatic Channel Selection (ACS) on another radio (link) cannot be
> brought up.
>
> In multi-radio wiphy cases, multiple radios are grouped under a single
> wiphy. Hence, if a radio is operating on a DFS channel and a scan is
> requested on a different radio of the same wiphy, the scan can be allowed
> simultaneously without impacting the DFS operations.
>
> Add logic to check the underlying radio used for the requested scan. If the
> radio on which DFS is already running is not being used, allow the scan
> operation; otherwise, return -EBUSY.
So while I agree in principle, I think this needs to be more carefully
constructed because it relies on an unstated (?) assumption that each
radio is going to ever be used for scanning on a certain band. That
seems to make sense, and a radio will certainly only ever be able to
_operate_ on the frequencies listed for it (due to chanctx etc.), but is
it really true that it will never be able to operate at all on other
frequencies?
I'm not sure I find the notion of e.g. having a 5 and 6 GHz radio that
are used for operating on those bands, but being able to scan 5 GHz
channels using the 6 GHz radio completely unimaginable? Maybe it is
though and I'm just overly paranoid?
We could also just leave that up to the drivers, of course, but then I
think we should _state_ this assumption somewhere in the docs/header
file(s)?
> +bool ieee80211_is_radio_idx_in_scan_req(struct wiphy *wiphy,
> + struct cfg80211_scan_request *scan_req,
> + int radio_idx)
> +{
> + struct ieee80211_channel *chan;
> + int i, chan_radio_idx;
> +
> + if (!scan_req)
> + return false;
That seems overly paranoid, or maybe it should be WARN_ON()? I mean,
asking something about a scan request and then not giving one is just
the wrong thing to do in the first place, no?
And if you're going to be paranoid then this probably shouldn't be
called with an invalid/negative radio_idx either :)
> + for (i = 0; i < scan_req->n_channels; i++) {
> + chan = scan_req->channels[i];
> + chan_radio_idx = cfg80211_get_radio_idx_by_chan(wiphy, chan);
> + /*
> + * Skip channels with an invalid radio index and continue
> + * checking. If any channel in the scan request matches the
> + * given radio index, return true.
> + */
> + if (chan_radio_idx < 0)
> + continue;
This seems ... wrong? If there's a channel in the scan request that
didn't map to _any_ radio then how are we even scanning there? And the
comment seems even stranger, why would we _want_ to ignore it (which it
conveniently doesn't answer)?
johannes
next prev parent reply other threads:[~2025-05-16 8:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-14 11:28 [PATCH wireless-next 0/3] wifi: cfg80211/mac80211: Handle simultaneous scan and DFS operations on different radios Raj Kumar Bhagat
2025-05-14 11:28 ` [PATCH wireless-next 1/3] wifi: cfg80211: Add utility API to get radio index from channel Raj Kumar Bhagat
2025-05-16 7:51 ` Johannes Berg
2025-05-16 7:52 ` Johannes Berg
2025-05-22 9:20 ` Raj Kumar Bhagat
2025-05-14 11:28 ` [PATCH wireless-next 2/3] wifi: mac80211: Allow scan on a radio while operating on DFS on another radio Raj Kumar Bhagat
2025-05-16 8:01 ` Johannes Berg [this message]
2025-05-22 10:40 ` Raj Kumar Bhagat
2025-05-22 11:23 ` Johannes Berg
2025-05-27 6:49 ` Raj Kumar Bhagat
2025-05-14 11:28 ` [PATCH wireless-next 3/3] wifi: mac80211: Allow DFS/CSA on a radio if scan is ongoing " Raj Kumar Bhagat
2025-05-16 8:05 ` Johannes Berg
2025-05-22 9:21 ` Raj Kumar Bhagat
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=d23e55879c6d8b6cabcc8357f153ae0622a4c53a.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=quic_rajkbhag@quicinc.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
all inboxes | Powered by JetHome®