Re: [PATCH wireless-next v3 3/4] wifi: mac80211: implement STA-mode peer probing

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2026-05-07 at 22:46 +0530, Priyansha Tiwari wrote:


> +	guard(rcu)();

You're rewriting the whole thing anyway - we have wiphy lock here, so we
don't really need RCU at all. Can just use wiphy_dereference() or
similar below, no?


> +	case NL80211_IFTYPE_STATION:
> +	case NL80211_IFTYPE_P2P_CLIENT:
> +		if (ieee80211_vif_is_mld(&sdata->vif)) {
> +			link_id = IEEE80211_LINK_UNSPECIFIED;
> +			peer_addr = sdata->vif.cfg.ap_addr;
> +			src_addr = sdata->vif.addr;
> +			band = 0;
> +			sta = sta_info_get(sdata, sdata->vif.cfg.ap_addr);
> +		} else {
> +			link_id = 0;
> +			conf = rcu_dereference(sdata->vif.link_conf[0]);
> +			if (!conf)
> +				return -ENOLINK;
> +			band = conf->chanreq.oper.chan->band;
> +			peer_addr = conf->bssid;
> +			src_addr = conf->addr;
> +			sta = sta_info_get_bss(sdata, peer_addr);
>  		}

This whole logic seems too much - the non-MLO case really should be a
subset of the MLO case anyway, because e.g. conf->bssid will definitely
be the same as sdata->vif.cfg.ap_addr, so you shouldn't really need
(most of?) this distinction.

Equally I don't think we need link_id=0 in the non-MLO case, fully non-
MLO drivers won't be looking at it anyway, and MLO drivers should be
able to deal with the UNSPECIFIED.

That leaves only really the band to be potentially set differently.
Ideally some unification with the AP side is possible there.

> -		band = chanctx_conf->def.chan->band;
> -		link_id = 0;
> +		qos = sta ? sta->sta.wme : false;
> +		fromds = false;
> +		break;

I see the check in cfg80211, but it just feels completely wrong to have
to do "sta ? ..." here when it should be connected.

Better to just refuse the operation when there's no 'sta' for the AP
found.

johannes