On Wed, 2025-06-25 at 18:31 +0530, Aditya Kumar Singh wrote:
>
> - if (ieee80211_num_beaconing_links(sdata) &&
> - (!(wiphy->features & NL80211_FEATURE_AP_SCAN) ||
> - !(req->flags & NL80211_SCAN_FLAG_AP)))
> - return -EOPNOTSUPP;
> + for (link_id = 0; link_id < IEEE80211_MLD_MAX_NUM_LINKS;
> + link_id++) {
> + link = sdata_dereference(sdata->link[link_id], sdata);
> + if (!link)
> + continue;
for_each_link_data()
> +
> + /* if the link is not beaconing, ignore it */
> + if (!sdata_dereference(link->u.ap.beacon, sdata))
> + continue;
> +
> + /* If we are here then at least one of the link is
> + * beaconing and since radio level information is
> + * not present or single underlying radio is present,
> + * no point in checking further and hence return if
> + * flag requirements are not met.
> + */
> + if (wiphy->n_radio < 2) {
> + if (!(wiphy->features & NL80211_FEATURE_AP_SCAN) ||
> + !(req->flags & NL80211_SCAN_FLAG_AP))
> + return -EOPNOTSUPP;
> +
> + continue;
> + }
Is that _really_ worth special-casing in the scan control path? It's not
like this is a performance question here.
Maybe ieee80211_is_radio_idx_in_scan_req() shouldn't WARN_ON() then or
something, so we can reuse it. Or maybe (better?) just reorder the
checks there, if the chan_radio_idx==-1 and radio_idx==-1 would return
first, and WARN only if we found a scan channel that isn't covered by a
radio?
And <2 seems really strange anyway, ==1 should basically never happen,
it's equivalent to ==0, as in no list of radios?
johannes
