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

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

[broonie]

Hi all,

Today's linux-next merge of the wireless-next tree got a conflict in:

  net/mac80211/mlme.c

between commit:

  a72c01a94f1d2 ("mac80211: mlme: check for null after calling kmemdup")

from the origin tree and commit:

  820acc810fb6e ("mac80211: Add EHT capabilities to association/probe request")

from the wireless-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc net/mac80211/mlme.c
index 20b57ddf149c4,197cad4a2768a..0000000000000
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@@ -671,7 -692,49 +692,49 @@@ static void ieee80211_add_he_ie(struct 
  	ieee80211_ie_build_he_6ghz_cap(sdata, skb);
  }
  
+ static void ieee80211_add_eht_ie(struct ieee80211_sub_if_data *sdata,
+ 				 struct sk_buff *skb,
+ 				 struct ieee80211_supported_band *sband)
+ {
+ 	u8 *pos;
+ 	const struct ieee80211_sta_he_cap *he_cap;
+ 	const struct ieee80211_sta_eht_cap *eht_cap;
+ 	struct ieee80211_chanctx_conf *chanctx_conf;
+ 	u8 eht_cap_size;
+ 	bool reg_cap = false;
+ 
+ 	rcu_read_lock();
+ 	chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
+ 	if (!WARN_ON_ONCE(!chanctx_conf))
+ 		reg_cap = cfg80211_chandef_usable(sdata->wdev.wiphy,
+ 						  &chanctx_conf->def,
+ 						  IEEE80211_CHAN_NO_HE |
+ 						  IEEE80211_CHAN_NO_EHT);
+ 	rcu_read_unlock();
+ 
+ 	he_cap = ieee80211_get_he_iftype_cap(sband,
+ 					     ieee80211_vif_type_p2p(&sdata->vif));
+ 	eht_cap = ieee80211_get_eht_iftype_cap(sband,
+ 					       ieee80211_vif_type_p2p(&sdata->vif));
+ 
+ 	/*
+ 	 * EHT capabilities element is only added if the HE capabilities element
+ 	 * was added so assume that 'he_cap' is valid and don't check it.
+ 	 */
+ 	if (WARN_ON(!he_cap || !eht_cap || !reg_cap))
+ 		return;
+ 
+ 	eht_cap_size =
+ 		2 + 1 + sizeof(eht_cap->eht_cap_elem) +
+ 		ieee80211_eht_mcs_nss_size(&he_cap->he_cap_elem,
+ 					   &eht_cap->eht_cap_elem) +
+ 		ieee80211_eht_ppe_size(eht_cap->eht_ppe_thres[0],
+ 				       eht_cap->eht_cap_elem.phy_cap_info);
+ 	pos = skb_put(skb, eht_cap_size);
+ 	ieee80211_ie_build_eht_cap(pos, he_cap, eht_cap, pos + eht_cap_size);
+ }
+ 
 -static void ieee80211_send_assoc(struct ieee80211_sub_if_data *sdata)
 +static int ieee80211_send_assoc(struct ieee80211_sub_if_data *sdata)
  {
  	struct ieee80211_local *local = sdata->local;
  	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;

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

[Johannes Berg]

Hi,

> Today's linux-next merge of the wireless-next tree got a conflict in:
> 
>   net/mac80211/mlme.c
> 
> between commit:
> 
>   a72c01a94f1d2 ("mac80211: mlme: check for null after calling kmemdup")
> 
> from the origin tree and commit:
> 
>   820acc810fb6e ("mac80211: Add EHT capabilities to association/probe request")
> 
> from the wireless-next tree.

Thanks. I think Stephen had also noticed this before.

Maybe I'll just move the new code around so it doesn't conflict anymore
;)

johannes

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

Hi all,

Today's linux-next merge of the wireless-next tree got a conflict in:

  drivers/net/wireless/intel/ipw2x00/libipw_crypto_tkip.c

between commit:

  1842442007cd ("wifi: lib80211: Constify struct lib80211_crypto_ops")

from the origin tree and commit:

  02f220b52670 ("wifi: ipw2x00/lib80211: move remaining lib80211 into libipw")

from the wireless-next tree.

I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Johannes Berg]

On Wed, 2024-10-09 at 11:35 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the wireless-next tree got a conflict in:
> 
>   drivers/net/wireless/intel/ipw2x00/libipw_crypto_tkip.c

This one's weird. These can't conflict:

> between commit:
> 
>   1842442007cd ("wifi: lib80211: Constify struct lib80211_crypto_ops")
> 
> from the origin tree and commit:
> 
>   02f220b52670 ("wifi: ipw2x00/lib80211: move remaining lib80211 into libipw")

because 1842442007cd is an ancestor of 02f220b52670:

$ git merge-base 1842442007cd 02f220b52670
1842442007cd...


When I tried to redo the merge I did get a conflict in this area, but
git was showed it between comments in a deleted staging file and the now
moved lib80211/libipw code.

So I think that git just got confused because I moved a file around in
the tree, and deleted another copy of the same file in staging.

Anyway ... I need to sync with Kalle, but I think I'll pull net-next
into wireless-next and that should resolve this and the other two
conflicts.

johannes

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

Hi all,

Today's linux-next merge of the wireless-next tree got a conflict in:

  net/mac80211/mlme.c

between commit:

  035ed430ce6a2 ("wifi: mac80211: avoid non-S1G AID fallback for S1G assoc")

from the origin tree and commit:

  f13e573ab3f12 ("wifi: mac80211: notify driver before destroying assoc link")

from the wireless-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc net/mac80211/mlme.c
index fa773f3b0541a,d577252dbb9f1..0000000000000
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@@ -7140,7 -7191,8 +7193,8 @@@ static void ieee80211_rx_mgmt_assoc_res
  {
  	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
  	struct ieee80211_mgd_assoc_data *assoc_data = ifmgd->assoc_data;
+ 	enum assoc_status assoc_status = ASSOC_ABANDON;
 -	u16 capab_info, status_code, aid;
 +	u16 capab_info, status_code, aid = 0;
  	struct ieee80211_elems_parse_params parse_params = {
  		.bss = NULL,
  		.link_id = -1,

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Enderaoe Lyther]

Hi Mark,

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;

Regards,
Zhao

On Wed, 22 Jul 2026 16:57:59 +0100, Mark Brown <broonie@kernel.org> wrote:
> Hi all,
>
> Today's linux-next merge of the wireless-next tree got a conflict in:
>
> net/mac80211/mlme.c
>
> between commit:
>
> 035ed430ce6a2 ("wifi: mac80211: avoid non-S1G AID fallback for S1G assoc")
>
> from the origin tree and commit:
>
> f13e573ab3f12 ("wifi: mac80211: notify driver before destroying assoc link")
>
> from the wireless-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc net/mac80211/mlme.c
> index fa773f3b0541a,d577252dbb9f1..0000000000000
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@@ -7140,7 -7191,8 +7193,8 @@@ static void ieee80211_rx_mgmt_assoc_res
> {
> struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
> struct ieee80211_mgd_assoc_data *assoc_data = ifmgd->assoc_data;
> + enum assoc_status assoc_status = ASSOC_ABANDON;
> - u16 capab_info, status_code, aid;
> + u16 capab_info, status_code, aid = 0;
> struct ieee80211_elems_parse_params parse_params = {
> .bss = NULL,
> .link_id = -1,

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

[Zhao Li]

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