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

[Mark Brown]

On Wed, Jul 22, 2026 at 03:53:59PM -0500, Enderaoe Lyther wrote:

> Thanks for carrying the conflict resolution.
> 
> I noticed one semantic conflict later in ieee80211_rx_mgmt_assoc_resp().
> 
> Commit 035ed430ce6a2 ("wifi: mac80211: avoid non-S1G AID fallback for S1G
> assoc") added:
> 
> 	else if (status_code == WLAN_STATUS_SUCCESS)
> 		goto abandon_assoc;
> 
> where abandon_assoc destroyed the association data with ASSOC_ABANDON and
> notified the driver.
> 
> After f13e573ab3f12 ("wifi: mac80211: notify driver before destroying
> assoc link") folds the driver notification into
> ieee80211_destroy_assoc_data(), the equivalent target is
> destroy_assoc_data, since assoc_status is initialized to ASSOC_ABANDON.
> 
> next-20260722 instead has:
> 
> 	else if (status_code == WLAN_STATUS_SUCCESS)
> 		goto notify_driver;
> 
> which bypasses ieee80211_destroy_assoc_data(). I believe this should
> instead be:
> 
> 	else if (status_code == WLAN_STATUS_SUCCESS)
> 		goto destroy_assoc_data;

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;

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.

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

Attachment: signature.asc
Description: PGP signature