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

[Zhao Li <enderaoelyther@gmail.com>]

On Thu, Jul 23, 2026 at 7:51 PM Mark Brown <broonie@kernel.org> wrote:
> On Wed, Jul 22, 2026 at 03:53:59PM -0500, Enderaoe Lyther wrote:
>
> > I noticed one semantic conflict later in ieee80211_rx_mgmt_assoc_resp().
>
> I can't tell which bit of code you are talking about here.  I see there
> is a block at line 7274 of -next:
>
>         if (elems->aid_resp)
>                 aid = le16_to_cpu(elems->aid_resp->aid);
>         else if (!assoc_data->s1g)
>                 aid = le16_to_cpu(mgmt->u.assoc_resp.aid);
>         else if (status_code == WLAN_STATUS_SUCCESS)
>                 goto notify_driver;

Sorry about the formatting in my earlier message. I should have quoted the
code inline instead of top-posting.

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.

> Please don't top post, reply in line with needed context.

Understood. Sorry for the unclear top-posted reply.

Zhao