Re: [PATCH wireless-next v4 13/21] wifi: mac80211: apply SMD BSS Transition STA sub-states

[Pooventhiran G]

On 11/11/2026 01:59 am, Johannes Berg wrote:
> On Fri, 2026-11-06 at 13:28 +0530, Pooventhiran G wrote:
>>
>> +static int sta_apply_smd_state_flags(struct sta_info *sta,
>> +				     u32 mask, u32 set)
>> +{
>> +	bool smd_prep_target, smd_exec_current, smd_dl_drain;
>> +	u32 expected_mask = BIT(NL80211_STA_FLAG_SMD_PREP_TARGET) |
>> +			    BIT(NL80211_STA_FLAG_SMD_EXEC_CURRENT) |
>> +			    BIT(NL80211_STA_FLAG_SMD_DL_DRAIN);
>> +	u32 smd_flags;
>> +
>> +	if (!(mask & expected_mask))
>> +		return 0;
> 
> Not sure I'd call that "expected", it's more like "relevant" (for this
> function)?

I will rename this.

> 
>> +	smd_flags = mask & expected_mask & set;
>> +	if (WARN_ON(hweight32(smd_flags) > 1))
>> +		return -EINVAL;
> 
> WARN? Isn't that potentially reachable from userspace?
> 

I will remove WARN_ON, there is only one call stack.

>> +	smd_prep_target =
>> +		!!(smd_flags & BIT(NL80211_STA_FLAG_SMD_PREP_TARGET));
>> +	smd_exec_current =
>> +		!!(smd_flags & BIT(NL80211_STA_FLAG_SMD_EXEC_CURRENT));
>> +	smd_dl_drain =
>> +		!!(smd_flags & BIT(NL80211_STA_FLAG_SMD_DL_DRAIN));
> 
> bool, so you don't need the !!
> 

I will clean this up.

>> +
>> +	if (!test_sta_flag(sta, WLAN_STA_AUTHORIZED) &&
>> +	    (smd_exec_current || smd_dl_drain))
>> +		return -EINVAL;
>> +
>> +	if (smd_prep_target) {
>> +		clear_sta_flag(sta, WLAN_STA_SMD_EXEC_CURRENT);
>> +		clear_sta_flag(sta, WLAN_STA_SMD_DL_DRAIN);
>> +		set_sta_flag(sta, WLAN_STA_SMD_PREP_TARGET);
> 
> might be better to set then clear?
> 

Sure, will change it.

>> +	/*
>> +	 * SMD BSS Transition sub-states (IEEE P802.11bn/D2.0, Aug 2026,
>> +	 * subclause 11.3.1).
>> +	 * Only meaningful for SMD-capable stations (WLAN_STA_SMD set).
>> +	 */
>> +	if (test_sta_flag(sta, WLAN_STA_SMD)) {
>> +		ret = sta_apply_smd_state_flags(sta, mask, set);
> 
> Sounds more like an LLM invention than a useful comment ...
> 

Sorry about this redundant comment. I will remove it.

> It'd be good to know why any of this was needed I guess.
> 

ath12k driver and firmware needs notification for these states to handle data
continuity and filtering such as to stop DL, etc.,

> johannes