Re: linux-next: manual merge of the wireless-next tree with the origin tree

[Johannes Berg]

On Fri, 2026-07-24 at 04:21 +0800, Zhao Li wrote:
> 
> That last branch was introduced by 035ed430ce6a ("wifi: mac80211: avoid
> non-S1G AID fallback for S1G assoc") as:
> 
> 	else if (status_code == WLAN_STATUS_SUCCESS)
> 		goto abandon_assoc;
> 
> f13e573ab3f12 ("wifi: mac80211: notify driver before destroying assoc
> link") consolidated terminal association cleanup at destroy_assoc_data
> and removed abandon_assoc. The conflict resolution retargeted this branch
> to notify_driver, but notify_driver only calls drv_mgd_complete_tx()
> without destroying the association data.
> 
> Since assoc_status is initialized to ASSOC_ABANDON at function entry, the
> equivalent target is destroy_assoc_data. A successful S1G association
> response with no AID Response element otherwise leaves assoc_data live
> instead of abandoning it.
> 
> > but that is immediately after another goto notify_driver, there's
> > further notify_driver error handling afterwards and all the earlier
> > error handling is return statements so it looks at least unclear what's
> > supposed to be going on.
> 
> Other goto notify_driver targets are intentional:
> 
>   - "if (!elems) goto notify_driver" is a pre-existing allocation failure
>     bail-out; so association timeout handles cleanup.
> 
>   - The comeback path WLAN_STATUS_ASSOC_REJECTED_TEMPORARILY keeps
>     assoc_data live deliberately for retry.
> 
> A successful S1G response without an AID Response element is terminal.
> It needs to abandon association immediately, so the target should be
> destroy_assoc_data rather than notify_driver.

Actually, looking at this again because I was going to send a PR for
wireless-next, I disagree.

>From userspace perspective, you're right, we could and perhaps should
abandon the assoc attempt entirely and send a "something went wrong" to
userspace.

However, from the driver's perspective, we're going to need the
notify_driver part, because we're done with the transmit/receive cycle.
Just abandoning it there would introduce a bug around this area.

But because I don't think (a) we should fix that in the merge, and (b)
it's actually very important, I'm just going to leave it as
"notify_driver". Sure, this means that for a bogus association response
we're going to try again (and who knows what the AP will do then), but
that only risks confusing the AP and potentially wasting some time
against a broken AP, rather than confusing the driver.

If we actually observe this in practice and want to get rid of the time
wasting, I guess we could add a path out that does both, but I'm not
sure it's worth it.

johannes