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

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

[Stephen Rothwell]

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

Hi John,

Today's linux-next merge of the wireless-next tree got a conflict in
net/mac80211/sta_info.c between commit 27a737ff7cb0 ("mac80211: always
synchronize_net() during station removal") from the wireless tree and
commits 3b8d9c290364 ("mac80211: remove underscores from some key
functions") and 6d10e46be5ac ("mac80211: batch key free synchronize_net()")
from the wireless-next tree.

The latter seems to supercede the former, so I just used the latter and
can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Johannes Berg]

Hi Stephen,

Thanks for the heads-up.

> between commit:
> 
>   5f4040050553 ("wifi: iwlwifi: mvm: disable MLO for the time being")
> 
> from the wireless tree and commit:
> 
>   bbd6d0f8bc51 ("wifi: iwlwifi: mvm: advertise IEEE80211_HW_HANDLES_QUIET_CSA")
> 
> from the wireless-next tree.

I kind of knew this was going to happen (given how the patches applied
or rather didn't), but nothing to prevent it yet. I think we'll get it
fixed in due time, before all the -next stuff goes anywhere.

Thanks,
johannes

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c

between commit:

  5f4040050553 ("wifi: iwlwifi: mvm: disable MLO for the time being")

from the wireless tree and commit:

  bbd6d0f8bc51 ("wifi: iwlwifi: mvm: advertise IEEE80211_HW_HANDLES_QUIET_CSA")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 8f4b063d6243,6b8f18b3e280..000000000000
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@@ -359,8 -359,11 +359,11 @@@ int iwl_mvm_mac_setup_register(struct i
  	/* Set this early since we need to have it for the check below */
  	if (mvm->mld_api_is_used && mvm->nvm_data->sku_cap_11be_enable &&
  	    !iwlwifi_mod_params.disable_11ax &&
- 	    !iwlwifi_mod_params.disable_11be)
+ 	    !iwlwifi_mod_params.disable_11be) {
 -		hw->wiphy->flags |= WIPHY_FLAG_SUPPORTS_MLO;
 +		hw->wiphy->flags |= WIPHY_FLAG_DISABLE_WEXT;
+ 		/* we handle this already earlier, but need it for MLO */
+ 		ieee80211_hw_set(hw, HANDLES_QUIET_CSA);
+ 	}
  
  	/* With MLD FW API, it tracks timing by itself,
  	 * no need for any timing from the host

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

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

[Johannes Berg]

Hi,

Thanks for the heads-up!

On Fri, 2024-02-09 at 10:56 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the wireless-next tree got a conflict in:
> 
>   drivers/net/wireless/intel/iwlwifi/mvm/tx.c
> 
> between commit:
> 
>   2e57b77583ca ("wifi: iwlwifi: mvm: use correct address 3 in A-MSDU")
> 
> from the wireless tree and commit:
> 
>   3d869feacb74 ("wifi: iwlwifi: mvm: use FW rate for non-data only on new devices")

I had a different (potential) conflict on my radar and pulled wireless
into wireless-next to avoid it, but this one wasn't on my radar at all.
Sorry about that.

> I fixed it up (see below)

That obviously looks fine, thanks!

johannes

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/net/wireless/intel/iwlwifi/mvm/tx.c

between commit:

  2e57b77583ca ("wifi: iwlwifi: mvm: use correct address 3 in A-MSDU")

from the wireless tree and commit:

  3d869feacb74 ("wifi: iwlwifi: mvm: use FW rate for non-data only on new devices")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index 461f26d9214e,4981bb1f0251..000000000000
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@@ -520,16 -520,31 +520,41 @@@ static void iwl_mvm_set_tx_cmd_crypto(s
  	}
  }
  
 +static void iwl_mvm_copy_hdr(void *cmd, const void *hdr, int hdrlen,
 +			     const u8 *addr3_override)
 +{
 +	struct ieee80211_hdr *out_hdr = cmd;
 +
 +	memcpy(cmd, hdr, hdrlen);
 +	if (addr3_override)
 +		memcpy(out_hdr->addr3, addr3_override, ETH_ALEN);
 +}
 +
+ static bool iwl_mvm_use_host_rate(struct iwl_mvm *mvm,
+ 				  struct iwl_mvm_sta *mvmsta,
+ 				  struct ieee80211_hdr *hdr,
+ 				  struct ieee80211_tx_info *info)
+ {
+ 	if (unlikely(!mvmsta))
+ 		return true;
+ 
+ 	if (unlikely(info->control.flags & IEEE80211_TX_CTRL_RATE_INJECT))
+ 		return true;
+ 
+ 	if (likely(ieee80211_is_data(hdr->frame_control) &&
+ 		   mvmsta->sta_state >= IEEE80211_STA_AUTHORIZED))
+ 		return false;
+ 
+ 	/*
+ 	 * Not a data frame, use host rate if on an old device that
+ 	 * can't possibly be doing MLO (firmware may be selecting a
+ 	 * bad rate), if we might be doing MLO we need to let FW pick
+ 	 * (since we don't necesarily know the link), but FW rate
+ 	 * selection was fixed.
+ 	 */
+ 	return mvm->trans->trans_cfg->device_family < IWL_DEVICE_FAMILY_BZ;
+ }
+ 
  /*
   * Allocates and sets the Tx cmd the driver data pointers in the skb
   */

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

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

[Johannes Berg]

On Tue, 2023-09-26 at 12:41 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Tue, 26 Sep 2023 12:02:53 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > Today's linux-next merge of the wireless-next tree got conflicts in:
> > 
> >   net/mac80211/cfg.c
> > 
> > between commit:
> > 
> >   31db78a4923e ("wifi: mac80211: fix potential key use-after-free")
> > 
> > from the wireless tree and commit:
> > 
> >   4d3acf4311a0 ("wifi: mac80211: remove sta_mtx")
> > 
> > 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.
> 
> That wasn't quite right.  The final resolution is below.

Thanks Stephen, also for the other one!

I knew about the new ones as well but forgot to give you a heads-up, my
bad, I'm sorry.

I'm planning to submit a wireless pull request today or tomorrow, and
then merge back into wireless-next once it settles in, so this should
hopefully be resolved by the end of the week or so.

Thanks,
johannes

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

[Stephen Rothwell]

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

Hi all,

On Tue, 26 Sep 2023 12:02:53 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the wireless-next tree got conflicts in:
> 
>   net/mac80211/cfg.c
> 
> between commit:
> 
>   31db78a4923e ("wifi: mac80211: fix potential key use-after-free")
> 
> from the wireless tree and commit:
> 
>   4d3acf4311a0 ("wifi: mac80211: remove sta_mtx")
> 
> 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.

That wasn't quite right.  The final resolution is below.
-- 
Cheers,
Stephen Rothwell

diff --cc net/mac80211/cfg.c
index 0e3a1753a51c,5bc6b1329465..3e7bb883137c
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@@ -472,8 -470,9 +470,10 @@@ static int ieee80211_add_key(struct wip
  	struct ieee80211_local *local = sdata->local;
  	struct sta_info *sta = NULL;
  	struct ieee80211_key *key;
 +	int err;
  
+ 	lockdep_assert_wiphy(local->hw.wiphy);
+ 
  	if (!ieee80211_sdata_running(sdata))
  		return -ENETDOWN;
  
@@@ -565,15 -561,7 +562,11 @@@
  		break;
  	}
  
 -	return ieee80211_key_link(key, link, sta);
 +	err = ieee80211_key_link(key, link, sta);
 +	/* KRACK protection, shouldn't happen but just silently accept key */
 +	if (err == -EALREADY)
 +		err = 0;
- 
-  out_unlock:
- 	mutex_unlock(&local->sta_mtx);
- 
 +	return err;
  }
  
  static struct ieee80211_key *

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/mac80211/key.c

between commits:

  31db78a4923e ("wifi: mac80211: fix potential key use-after-free")
  d097ae01ebd4 ("wifi: mac80211: fix potential key leak")

from the wireless tree and commit:

  2a8b665e6bcc ("wifi: mac80211: remove key_mtx")

from the wireless-next tree.

I fixed it up (I think - 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.

-- 
Cheers,
Stephen Rothwell

diff --cc net/mac80211/key.c
index 0665ff5e456e,ac410f6632b5..000000000000
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@@ -881,21 -875,20 +880,22 @@@ int ieee80211_key_link(struct ieee80211
  
  		if (link_id >= 0) {
  			link_sta = rcu_dereference_protected(sta->link[link_id],
- 							     lockdep_is_held(&sta->local->sta_mtx));
+ 							     lockdep_is_held(&sta->local->hw.wiphy->mtx));
 -			if (!link_sta)
 -				return -ENOLINK;
 +			if (!link_sta) {
 +				ret = -ENOLINK;
 +				goto out;
 +			}
  		}
  
- 		old_key = key_mtx_dereference(sdata->local, link_sta->gtk[idx]);
+ 		old_key = wiphy_dereference(sdata->local->hw.wiphy,
+ 					    link_sta->gtk[idx]);
  	} else {
  		if (idx < NUM_DEFAULT_KEYS)
- 			old_key = key_mtx_dereference(sdata->local,
- 						      sdata->keys[idx]);
+ 			old_key = wiphy_dereference(sdata->local->hw.wiphy,
+ 						    sdata->keys[idx]);
  		if (!old_key)
- 			old_key = key_mtx_dereference(sdata->local,
- 						      link->gtk[idx]);
+ 			old_key = wiphy_dereference(sdata->local->hw.wiphy,
+ 						    link->gtk[idx]);
  	}
  
  	/* Non-pairwise keys must also not switch the cipher on rekey */
@@@ -910,10 -901,10 +910,8 @@@
  	 * Silently accept key re-installation without really installing the
  	 * new version of the key to avoid nonce reuse or replay issues.
  	 */
--	if (ieee80211_key_identical(sdata, old_key, key)) {
- 		ret = -EALREADY;
- 		goto unlock;
 -		ieee80211_key_free_unused(key);
 -		return 0;
--	}
++	if (ieee80211_key_identical(sdata, old_key, key))
++		return -EALREADY;
  
  	key->local = sdata->local;
  	key->sdata = sdata;
@@@ -936,13 -927,6 +934,10 @@@
  		ieee80211_key_free(key, delay_tailroom);
  	}
  
 +	key = NULL;
 +
 + out:
 +	ieee80211_key_free_unused(key);
-  unlock:
- 	mutex_unlock(&sdata->local->key_mtx);
- 
  	return ret;
  }
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/mac80211/cfg.c

between commit:

  31db78a4923e ("wifi: mac80211: fix potential key use-after-free")

from the wireless tree and commit:

  4d3acf4311a0 ("wifi: mac80211: remove sta_mtx")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc net/mac80211/cfg.c
index 0e3a1753a51c,5bc6b1329465..000000000000
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@@ -565,15 -561,7 +561,11 @@@ static int ieee80211_add_key(struct wip
  		break;
  	}
  
 -	return ieee80211_key_link(key, link, sta);
 +	err = ieee80211_key_link(key, link, sta);
 +	/* KRACK protection, shouldn't happen but just silently accept key */
 +	if (err == -EALREADY)
 +		err = 0;
- 
-  out_unlock:
- 	mutex_unlock(&local->sta_mtx);
- 
 +	return err;
  }
  
  static struct ieee80211_key *

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

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

[Stephen Rothwell]

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

Hi all,

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

  net/wireless/nl80211.c

between commit:

  37c20b2effe9 ("wifi: cfg80211: fix cqm_config access race")

from the wireless tree and commit:

  076fc8775daf ("wifi: cfg80211: remove wdev mutex")

from the wireless-next tree.

I fixed it up (I used a supplied resolution from Johannes - 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.

-- 
Cheers,
Stephen Rothwell

diff --cc net/wireless/nl80211.c
index 7a88361b3414,ab0aea7dca7d..fe06c238d4ef
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@@ -6191,12 -6135,8 +6150,12 @@@ static int nl80211_start_ap(struct sk_b
  
  	err = nl80211_calculate_ap_params(params);
  	if (err)
- 		goto out_unlock;
+ 		goto out;
  
 +	err = nl80211_validate_ap_phy_operation(params);
 +	if (err)
- 		goto out_unlock;
++		goto out;
 +
  	if (info->attrs[NL80211_ATTR_AP_SETTINGS_FLAGS])
  		params->flags = nla_get_u32(
  			info->attrs[NL80211_ATTR_AP_SETTINGS_FLAGS]);
@@@ -12884,11 -12747,10 +12767,11 @@@ static int nl80211_set_cqm_rssi(struct 
  				u32 hysteresis)
  {
  	struct cfg80211_registered_device *rdev = info->user_ptr[0];
 +	struct cfg80211_cqm_config *cqm_config = NULL, *old;
  	struct net_device *dev = info->user_ptr[1];
  	struct wireless_dev *wdev = dev->ieee80211_ptr;
- 	int i, err;
  	s32 prev = S32_MIN;
 -	int i;
++	int i, err;
  
  	/* Check all values negative and sorted */
  	for (i = 0; i < n_thresholds; i++) {
@@@ -12917,11 -12781,9 +12800,9 @@@
  	if (n_thresholds == 1 && thresholds[0] == 0) /* Disabling */
  		n_thresholds = 0;
  
- 	wdev_lock(wdev);
- 	old = rcu_dereference_protected(wdev->cqm_config,
- 					lockdep_is_held(&wdev->mtx));
 -	if (n_thresholds) {
 -		struct cfg80211_cqm_config *cqm_config;
++	old = wiphy_dereference(wdev->wiphy, wdev->cqm_config);
  
 +	if (n_thresholds) {
  		cqm_config = kzalloc(struct_size(cqm_config, rssi_thresholds,
  						 n_thresholds),
  				     GFP_KERNEL);
@@@ -12936,22 -12796,10 +12815,20 @@@
  		       flex_array_size(cqm_config, rssi_thresholds,
  				       n_thresholds));
  
 -		wdev->cqm_config = cqm_config;
 +		rcu_assign_pointer(wdev->cqm_config, cqm_config);
 +	} else {
 +		RCU_INIT_POINTER(wdev->cqm_config, NULL);
  	}
  
 -	return cfg80211_cqm_rssi_update(rdev, dev);
 +	err = cfg80211_cqm_rssi_update(rdev, dev, cqm_config);
 +	if (err) {
 +		rcu_assign_pointer(wdev->cqm_config, old);
 +		kfree_rcu(cqm_config, rcu_head);
 +	} else {
 +		kfree_rcu(old, rcu_head);
 +	}
- unlock:
- 	wdev_unlock(wdev);
 +
 +	return err;
  }
  
  static int nl80211_set_cqm(struct sk_buff *skb, struct genl_info *info)
@@@ -19107,41 -18879,18 +18907,39 @@@ void cfg80211_cqm_rssi_notify(struct ne
  		    rssi_event != NL80211_CQM_RSSI_THRESHOLD_EVENT_HIGH))
  		return;
  
 -	if (wdev->cqm_config) {
 -		wdev->cqm_config->last_rssi_event_value = rssi_level;
 +	rcu_read_lock();
 +	cqm_config = rcu_dereference(wdev->cqm_config);
 +	if (cqm_config) {
 +		cqm_config->last_rssi_event_value = rssi_level;
 +		cqm_config->last_rssi_event_type = rssi_event;
 +		wiphy_work_queue(wdev->wiphy, &wdev->cqm_rssi_work);
 +	}
 +	rcu_read_unlock();
 +}
 +EXPORT_SYMBOL(cfg80211_cqm_rssi_notify);
 +
 +void cfg80211_cqm_rssi_notify_work(struct wiphy *wiphy, struct wiphy_work *work)
 +{
 +	struct wireless_dev *wdev = container_of(work, struct wireless_dev,
 +						 cqm_rssi_work);
 +	struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy);
 +	enum nl80211_cqm_rssi_threshold_event rssi_event;
 +	struct cfg80211_cqm_config *cqm_config;
 +	struct sk_buff *msg;
 +	s32 rssi_level;
 +
- 	wdev_lock(wdev);
- 	cqm_config = rcu_dereference_protected(wdev->cqm_config,
- 					       lockdep_is_held(&wdev->mtx));
++	cqm_config = wiphy_dereference(wdev->wiphy, wdev->cqm_config);
 +	if (!wdev->cqm_config)
- 		goto unlock;
++		return;
  
 -		cfg80211_cqm_rssi_update(rdev, dev);
 +	cfg80211_cqm_rssi_update(rdev, wdev->netdev, cqm_config);
  
 -		if (rssi_level == 0)
 -			rssi_level = wdev->cqm_config->last_rssi_event_value;
 -	}
 +	rssi_level = cqm_config->last_rssi_event_value;
 +	rssi_event = cqm_config->last_rssi_event_type;
  
 -	msg = cfg80211_prepare_cqm(dev, NULL, gfp);
 +	msg = cfg80211_prepare_cqm(wdev->netdev, NULL, GFP_KERNEL);
  	if (!msg)
- 		goto unlock;
+ 		return;
  
  	if (nla_put_u32(msg, NL80211_ATTR_CQM_RSSI_THRESHOLD_EVENT,
  			rssi_event))
@@@ -19151,15 -18900,14 +18949,13 @@@
  				      rssi_level))
  		goto nla_put_failure;
  
 -	cfg80211_send_cqm(msg, gfp);
 +	cfg80211_send_cqm(msg, GFP_KERNEL);
  
- 	goto unlock;
+ 	return;
  
   nla_put_failure:
  	nlmsg_free(msg);
-  unlock:
- 	wdev_unlock(wdev);
  }
 -EXPORT_SYMBOL(cfg80211_cqm_rssi_notify);
  
  void cfg80211_cqm_txe_notify(struct net_device *dev,
  			     const u8 *peer, u32 num_packets,

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

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

[Kalle Valo]

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> Hi all,
>
> On Fri, 31 Mar 2023 10:49:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the wireless-next tree got a conflict in:
>> 
>>   net/mac80211/rx.c
>> 
>> between commit:
>> 
>>   a16fc38315f2 ("wifi: mac80211: fix potential null pointer dereference")
>> 
>> from the wireless tree and commit:
>> 
>>   fe4a6d2db3ba ("wifi: mac80211: implement support for yet another mesh A-MSDU format")
>> 
>> 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.

[...]

> This is now a conflict between the net-next and net trees.

My plan is to submit wireless-next pull request to net-next by
Wednesday, that should fix the conflict.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

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

[Stephen Rothwell]

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

Hi all,

On Fri, 31 Mar 2023 10:49:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the wireless-next tree got a conflict in:
> 
>   net/mac80211/rx.c
> 
> between commit:
> 
>   a16fc38315f2 ("wifi: mac80211: fix potential null pointer dereference")
> 
> from the wireless tree and commit:
> 
>   fe4a6d2db3ba ("wifi: mac80211: implement support for yet another mesh A-MSDU format")
> 
> 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.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc net/mac80211/rx.c
> index 3e2176a730e6,1c957194554b..000000000000
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@@ -2776,27 -2862,12 +2843,31 @@@ ieee80211_rx_mesh_data(struct ieee80211
>   		rcu_read_unlock();
>   	}
>   
>  +	/* Frame has reached destination.  Don't forward */
>  +	if (ether_addr_equal(sdata->vif.addr, eth->h_dest))
>  +		goto rx_accept;
>  +
>  +	if (!--mesh_hdr->ttl) {
>  +		if (multicast)
>  +			goto rx_accept;
>  +
>  +		IEEE80211_IFSTA_MESH_CTR_INC(ifmsh, dropped_frames_ttl);
>  +		return RX_DROP_MONITOR;
>  +	}
>  +
>  +	if (!ifmsh->mshcfg.dot11MeshForwarding) {
>  +		if (is_multicast_ether_addr(eth->h_dest))
>  +			goto rx_accept;
>  +
>  +		return RX_DROP_MONITOR;
>  +	}
>  +
>   	skb_set_queue_mapping(skb, ieee802_1d_to_ac[skb->priority]);
>   
> + 	if (!multicast &&
> + 	    ieee80211_rx_mesh_fast_forward(sdata, skb, mesh_hdrlen))
> + 		return RX_QUEUED;
> + 
>   	ieee80211_fill_mesh_addresses(&hdr, &hdr.frame_control,
>   				      eth->h_dest, eth->h_source);
>   	hdrlen = ieee80211_hdrlen(hdr.frame_control);
> @@@ -2914,14 -2982,24 +2985,24 @@@ __ieee80211_rx_h_amsdu(struct ieee80211
>   					  data_offset, true))
>   		return RX_DROP_UNUSABLE;
>   
>  -	if (rx->sta && rx->sta->amsdu_mesh_control < 0) {
>  +	if (rx->sta->amsdu_mesh_control < 0) {
> - 		bool valid_std = ieee80211_is_valid_amsdu(skb, true);
> - 		bool valid_nonstd = ieee80211_is_valid_amsdu(skb, false);
> + 		s8 valid = -1;
> + 		int i;
> + 
> + 		for (i = 0; i <= 2; i++) {
> + 			if (!ieee80211_is_valid_amsdu(skb, i))
> + 				continue;
> + 
> + 			if (valid >= 0) {
> + 				/* ambiguous */
> + 				valid = -1;
> + 				break;
> + 			}
>   
> - 		if (valid_std && !valid_nonstd)
> - 			rx->sta->amsdu_mesh_control = 1;
> - 		else if (valid_nonstd && !valid_std)
> - 			rx->sta->amsdu_mesh_control = 0;
> + 			valid = i;
> + 		}
> + 
> + 		rx->sta->amsdu_mesh_control = valid;
>   	}
>   
>   	ieee80211_amsdu_to_8023s(skb, &frame_list, dev->dev_addr,

This is now a conflict between the net-next and net trees.

-- 
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 wireless tree

[Johannes Berg]

On Fri, 2023-03-31 at 10:49 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the wireless-next tree got a conflict in:
> 
>   net/mac80211/rx.c
> 
> between commit:
> 
>   a16fc38315f2 ("wifi: mac80211: fix potential null pointer dereference")
> 
> from the wireless tree and commit:
> 
>   fe4a6d2db3ba ("wifi: mac80211: implement support for yet another mesh A-MSDU format")
> 
> from the wireless-next tree.

Thanks for the heads-up. I sort of expected this, but didn't want to do
a merge or wireless into wireless-next before it was pulled, maybe I
should've staggered the pull requests, but you would've seen the merge
issue anyway.

Anyway, I've now pulled wireless into wireless-next, so you might
continue seeing this issue (*) if you merge net/net-next before merging
wireless-next, but it'll be completely resolved when we send the next
pull request to net-next (next week).

Thanks!

(*) and another one in nl80211 policy, I think?

joahnnes

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

[Stephen Rothwell]

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

Hi all,

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

  net/mac80211/rx.c

between commit:

  a16fc38315f2 ("wifi: mac80211: fix potential null pointer dereference")

from the wireless tree and commit:

  fe4a6d2db3ba ("wifi: mac80211: implement support for yet another mesh A-MSDU format")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc net/mac80211/rx.c
index 3e2176a730e6,1c957194554b..000000000000
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@@ -2776,27 -2862,12 +2843,31 @@@ ieee80211_rx_mesh_data(struct ieee80211
  		rcu_read_unlock();
  	}
  
 +	/* Frame has reached destination.  Don't forward */
 +	if (ether_addr_equal(sdata->vif.addr, eth->h_dest))
 +		goto rx_accept;
 +
 +	if (!--mesh_hdr->ttl) {
 +		if (multicast)
 +			goto rx_accept;
 +
 +		IEEE80211_IFSTA_MESH_CTR_INC(ifmsh, dropped_frames_ttl);
 +		return RX_DROP_MONITOR;
 +	}
 +
 +	if (!ifmsh->mshcfg.dot11MeshForwarding) {
 +		if (is_multicast_ether_addr(eth->h_dest))
 +			goto rx_accept;
 +
 +		return RX_DROP_MONITOR;
 +	}
 +
  	skb_set_queue_mapping(skb, ieee802_1d_to_ac[skb->priority]);
  
+ 	if (!multicast &&
+ 	    ieee80211_rx_mesh_fast_forward(sdata, skb, mesh_hdrlen))
+ 		return RX_QUEUED;
+ 
  	ieee80211_fill_mesh_addresses(&hdr, &hdr.frame_control,
  				      eth->h_dest, eth->h_source);
  	hdrlen = ieee80211_hdrlen(hdr.frame_control);
@@@ -2914,14 -2982,24 +2985,24 @@@ __ieee80211_rx_h_amsdu(struct ieee80211
  					  data_offset, true))
  		return RX_DROP_UNUSABLE;
  
 -	if (rx->sta && rx->sta->amsdu_mesh_control < 0) {
 +	if (rx->sta->amsdu_mesh_control < 0) {
- 		bool valid_std = ieee80211_is_valid_amsdu(skb, true);
- 		bool valid_nonstd = ieee80211_is_valid_amsdu(skb, false);
+ 		s8 valid = -1;
+ 		int i;
+ 
+ 		for (i = 0; i <= 2; i++) {
+ 			if (!ieee80211_is_valid_amsdu(skb, i))
+ 				continue;
+ 
+ 			if (valid >= 0) {
+ 				/* ambiguous */
+ 				valid = -1;
+ 				break;
+ 			}
  
- 		if (valid_std && !valid_nonstd)
- 			rx->sta->amsdu_mesh_control = 1;
- 		else if (valid_nonstd && !valid_std)
- 			rx->sta->amsdu_mesh_control = 0;
+ 			valid = i;
+ 		}
+ 
+ 		rx->sta->amsdu_mesh_control = valid;
  	}
  
  	ieee80211_amsdu_to_8023s(skb, &frame_list, dev->dev_addr,

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

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

[Stephen Rothwell]

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

Hi John,

Today's linux-next merge of the wireless-next tree got a conflict in
drivers/net/wireless/iwlwifi/iwl-fw.h between commit 5ac6c72e5944
("iwlwifi: mvm: check TLV flag before trying to use hotspot firmware
commands") from the wireless tree and commit 77c5d7eff790 ("iwlwifi:
mvm: add TDLS channel switch FW APIs") from the wireless-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/net/wireless/iwlwifi/iwl-fw.h
index 649fdae77383,a94d244459d7..000000000000
--- a/drivers/net/wireless/iwlwifi/iwl-fw.h
+++ b/drivers/net/wireless/iwlwifi/iwl-fw.h
@@@ -155,7 -157,7 +157,8 @@@ enum iwl_ucode_tlv_api 
   * @IWL_UCODE_TLV_CAPA_QUIET_PERIOD_SUPPORT: supports Quiet Period requests
   * @IWL_UCODE_TLV_CAPA_DQA_SUPPORT: supports dynamic queue allocation (DQA),
   *	which also implies support for the scheduler configuration command
+  * @IWL_UCODE_TLV_CAPA_TDLS_CHANNEL_SWITCH: supports TDLS channel switching
 + * @IWL_UCODE_TLV_CAPA_HOTSPOT_SUPPORT: supports Hot Spot Command
   */
  enum iwl_ucode_tlv_capa {
  	IWL_UCODE_TLV_CAPA_D0I3_SUPPORT			= BIT(0),
@@@ -164,7 -168,7 +169,8 @@@
  	IWL_UCODE_TLV_CAPA_WFA_TPC_REP_IE_SUPPORT	= BIT(10),
  	IWL_UCODE_TLV_CAPA_QUIET_PERIOD_SUPPORT		= BIT(11),
  	IWL_UCODE_TLV_CAPA_DQA_SUPPORT			= BIT(12),
+ 	IWL_UCODE_TLV_CAPA_TDLS_CHANNEL_SWITCH		= BIT(13),
 +	IWL_UCODE_TLV_CAPA_HOTSPOT_SUPPORT		= BIT(18),
  };
  
  /* The default calibrate table size if not specified by firmware file */

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

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

[Yeoh Chun-Yeow]

>> I think the above is correct, the pre_value assignment with 1/++ and
>> chsw_init moved into another function in Bob's patch. Bob?
>
> The quoted resolution looks right to me.  But, I think the patch
> in question was actually Chun-yeow's so I'm not sure my opinion
> counts :)

Yes, it is correct.

The chsw_init is moved by ""mac80211: fix the mesh channel switch
support" patch.

----
Chun-Yeow

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

[Bob Copeland]

On Tue, Dec 03, 2013 at 05:09:43PM +0100, Johannes Berg wrote:
> > > diff --cc net/mac80211/util.c
> > > index 9f9b9bd3fd44,06265d7f8cc3..000000000000
> > > --- a/net/mac80211/util.c
> > > +++ b/net/mac80211/util.c
> > > @@@ -2457,9 -2481,13 +2479,8 @@@ int ieee80211_send_action_csa(struct ie
> > >                         WLAN_EID_CHAN_SWITCH_PARAM_TX_RESTRICT : 0x00;
> > >               put_unaligned_le16(WLAN_REASON_MESH_CHAN, pos); /* Reason Cd */
> > >               pos += 2;
> > > -             pre_value = cpu_to_le16(ifmsh->pre_value);
> > > -             memcpy(pos, &pre_value, 2);             /* Precedence Value */
> > >  -            if (!ifmsh->pre_value)
> > >  -                    ifmsh->pre_value = 1;
> > >  -            else
> > >  -                    ifmsh->pre_value++;
> > > +             put_unaligned_le16(ifmsh->pre_value, pos);/* Precedence Value */
> > >               pos += 2;
> > >  -            ifmsh->chsw_init = true;
> > >       }
> > >
> > >       ieee80211_tx_skb(sdata, skb);


> I think the above is correct, the pre_value assignment with 1/++ and
> chsw_init moved into another function in Bob's patch. Bob?

The quoted resolution looks right to me.  But, I think the patch
in question was actually Chun-yeow's so I'm not sure my opinion
counts :)

-- 
Bob Copeland %% www.bobcopeland.com

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

[Johannes Berg]

On Tue, 2013-12-03 at 15:52 +0000, John W. Linville wrote:

> > Today's linux-next merge of the wireless-next tree got a conflict in
> > net/mac80211/util.c between commit 3f718fd8401d ("mac80211: fix the mesh
> > channel switch support") from the wireless tree and commit ca91dc97b8a0
> > ("mac80211: use put_unaligned_le16 for precedence value in mesh") from
> > the wireless-next tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
> >
> > --
> > Cheers,
> > Stephen Rothwell                    sfr@canb.auug.org.au
> >
> > diff --cc net/mac80211/util.c
> > index 9f9b9bd3fd44,06265d7f8cc3..000000000000
> > --- a/net/mac80211/util.c
> > +++ b/net/mac80211/util.c
> > @@@ -2457,9 -2481,13 +2479,8 @@@ int ieee80211_send_action_csa(struct ie
> >                         WLAN_EID_CHAN_SWITCH_PARAM_TX_RESTRICT : 0x00;
> >               put_unaligned_le16(WLAN_REASON_MESH_CHAN, pos); /* Reason Cd */
> >               pos += 2;
> > -             pre_value = cpu_to_le16(ifmsh->pre_value);
> > -             memcpy(pos, &pre_value, 2);             /* Precedence Value */
> >  -            if (!ifmsh->pre_value)
> >  -                    ifmsh->pre_value = 1;
> >  -            else
> >  -                    ifmsh->pre_value++;
> > +             put_unaligned_le16(ifmsh->pre_value, pos);/* Precedence Value */
> >               pos += 2;
> >  -            ifmsh->chsw_init = true;
> >       }
> >
> >       ieee80211_tx_skb(sdata, skb);
> 
> This differs from how I resolved the conflict when merging in wireless-testing...
> 
> Johannes, could you comment on which (if either) of these options is correct?

I think the above is correct, the pre_value assignment with 1/++ and
chsw_init moved into another function in Bob's patch. Bob?

johannes

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

[John W. Linville]

On Tue, Dec 03, 2013 at 11:20:32AM +1100, Stephen Rothwell wrote:
> Hi John,
> 
> Today's linux-next merge of the wireless-next tree got a conflict in
> net/mac80211/util.c between commit 3f718fd8401d ("mac80211: fix the mesh
> channel switch support") from the wireless tree and commit ca91dc97b8a0
> ("mac80211: use put_unaligned_le16 for precedence value in mesh") from
> the wireless-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc net/mac80211/util.c
> index 9f9b9bd3fd44,06265d7f8cc3..000000000000
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@@ -2457,9 -2481,13 +2479,8 @@@ int ieee80211_send_action_csa(struct ie
>   			  WLAN_EID_CHAN_SWITCH_PARAM_TX_RESTRICT : 0x00;
>   		put_unaligned_le16(WLAN_REASON_MESH_CHAN, pos); /* Reason Cd */
>   		pos += 2;
> - 		pre_value = cpu_to_le16(ifmsh->pre_value);
> - 		memcpy(pos, &pre_value, 2);		/* Precedence Value */
>  -		if (!ifmsh->pre_value)
>  -			ifmsh->pre_value = 1;
>  -		else
>  -			ifmsh->pre_value++;
> + 		put_unaligned_le16(ifmsh->pre_value, pos);/* Precedence Value */
>   		pos += 2;
>  -		ifmsh->chsw_init = true;
>   	}
>   
>   	ieee80211_tx_skb(sdata, skb);

This differs from how I resolved the conflict when merging in wireless-testing...

Johannes, could you comment on which (if either) of these options is correct?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

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

[Stephen Rothwell]

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

Hi John,

Today's linux-next merge of the wireless-next tree got a conflict in
net/mac80211/util.c between commit 3f718fd8401d ("mac80211: fix the mesh
channel switch support") from the wireless tree and commit ca91dc97b8a0
("mac80211: use put_unaligned_le16 for precedence value in mesh") from
the wireless-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc net/mac80211/util.c
index 9f9b9bd3fd44,06265d7f8cc3..000000000000
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@@ -2457,9 -2481,13 +2479,8 @@@ int ieee80211_send_action_csa(struct ie
  			  WLAN_EID_CHAN_SWITCH_PARAM_TX_RESTRICT : 0x00;
  		put_unaligned_le16(WLAN_REASON_MESH_CHAN, pos); /* Reason Cd */
  		pos += 2;
- 		pre_value = cpu_to_le16(ifmsh->pre_value);
- 		memcpy(pos, &pre_value, 2);		/* Precedence Value */
 -		if (!ifmsh->pre_value)
 -			ifmsh->pre_value = 1;
 -		else
 -			ifmsh->pre_value++;
+ 		put_unaligned_le16(ifmsh->pre_value, pos);/* Precedence Value */
  		pos += 2;
 -		ifmsh->chsw_init = true;
  	}
  
  	ieee80211_tx_skb(sdata, skb);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Stephen Rothwell]

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

Hi John,

Today's linux-next merge of the wireless-next tree got a conflict in drivers/net/wireless/iwlwifi/pcie/trans.c between commit eabc4ac5d760 ("iwlwifi: pcie: disable L1 Active after pci_enable_device") from the wireless tree and commit 6965a3540a4b ("iwlwifi: pcie: don't swallow error codes in iwl_trans_pcie_alloc()") from the wireless-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/net/wireless/iwlwifi/pcie/trans.c
index 8c6c405,bad95d2..0000000
--- a/drivers/net/wireless/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
@@@ -1400,11 -1401,6 +1401,10 @@@ struct iwl_trans *iwl_trans_pcie_alloc(
  	spin_lock_init(&trans_pcie->reg_lock);
  	init_waitqueue_head(&trans_pcie->ucode_write_waitq);
  
- 	if (pci_enable_device(pdev)) {
- 		err = -ENODEV;
++	err = pci_enable_device(pdev);
++	if (err)
 +		goto out_no_pci;
- 	}
 +
  	if (!cfg->base_params->pcie_l1_allowed) {
  		/*
  		 * W/A - seems to solve weird behavior. We need to remove this

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Berg, Johannes]

> I think I have this slightly different in wireless-testing.  Johannes, please
> review and advise...

> > Today's linux-next merge of the wireless-next tree got a conflict in
> > drivers/net/wireless/iwlwifi/pcie/trans.c between commit eabc4ac5d760
> > ("iwlwifi: pcie: disable L1 Active after pci_enable_device") from
> > thewireless tree and commit f2532b04b2ec ("iwlwifi: pcie: don't
> > disable
> > L1 for newest NICs") from the wireless-next tree.
> >
> > I fixed it up (maybe - see below) and can carry the fix as necessary
> > (no action is required).


> > diff --cc drivers/net/wireless/iwlwifi/pcie/trans.c
> > index 390e2f0,e52d1ce..0000000
> > --- a/drivers/net/wireless/iwlwifi/pcie/trans.c
> > +++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
> > @@@ -1502,16 -1400,22 +1400,22 @@@ struct iwl_trans
> *iwl_trans_pcie_alloc(
> >   	spin_lock_init(&trans_pcie->reg_lock);
> >   	init_waitqueue_head(&trans_pcie->ucode_write_waitq);
> >
> >  +	if (pci_enable_device(pdev)) {
> >  +		err = -ENODEV;
> >  +		goto out_no_pci;
> >  +	}
> >  +
> > - 	/* W/A - seems to solve weird behavior. We need to remove this if
> we
> > - 	 * don't want to stay in L1 all the time. This wastes a lot of power */
> > - 	pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S |
> PCIE_LINK_STATE_L1 |
> > - 			       PCIE_LINK_STATE_CLKPM);
> > + 	if (!cfg->base_params->pcie_l1_allowed) {
> > + 		/*
> > + 		 * W/A - seems to solve weird behavior. We need to remove
> this
> > + 		 * if we don't want to stay in L1 all the time. This wastes a
> > + 		 * lot of power.
> > + 		 */
> > + 		pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S |
> > + 				       PCIE_LINK_STATE_L1 |
> > + 				       PCIE_LINK_STATE_CLKPM);
> > + 	}
> >
> >  -	if (pci_enable_device(pdev)) {
> >  -		err = -ENODEV;
> >  -		goto out_no_pci;
> >  -	}
> >  -
> >   	pci_set_master(pdev);
> >
> >   	err = pci_set_dma_mask(pdev, DMA_BIT_MASK(36));

This looks fine, and it seems to be exactly what you have in wireless-testing/master. I have yet another change pending to this which removes the err= in favour of taking it from pci_enable_device() though.

johannes
(sorry for the outlook mess - might want to use johannes@sipsolutions.net)
-- 

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

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

[John W. Linville]

I think I have this slightly different in wireless-testing.  Johannes,
please review and advise...

John

On Mon, Aug 12, 2013 at 11:53:27AM +1000, Stephen Rothwell wrote:
> Hi John,
> 
> Today's linux-next merge of the wireless-next tree got a conflict in
> drivers/net/wireless/iwlwifi/pcie/trans.c between commit eabc4ac5d760
> ("iwlwifi: pcie: disable L1 Active after pci_enable_device") from
> thewireless tree and commit f2532b04b2ec ("iwlwifi: pcie: don't disable
> L1 for newest NICs") from the wireless-next tree.
> 
> I fixed it up (maybe - see below) and can carry the fix as necessary (no
> action is required).
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc drivers/net/wireless/iwlwifi/pcie/trans.c
> index 390e2f0,e52d1ce..0000000
> --- a/drivers/net/wireless/iwlwifi/pcie/trans.c
> +++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
> @@@ -1502,16 -1400,22 +1400,22 @@@ struct iwl_trans *iwl_trans_pcie_alloc(
>   	spin_lock_init(&trans_pcie->reg_lock);
>   	init_waitqueue_head(&trans_pcie->ucode_write_waitq);
>   
>  +	if (pci_enable_device(pdev)) {
>  +		err = -ENODEV;
>  +		goto out_no_pci;
>  +	}
>  +
> - 	/* W/A - seems to solve weird behavior. We need to remove this if we
> - 	 * don't want to stay in L1 all the time. This wastes a lot of power */
> - 	pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
> - 			       PCIE_LINK_STATE_CLKPM);
> + 	if (!cfg->base_params->pcie_l1_allowed) {
> + 		/*
> + 		 * W/A - seems to solve weird behavior. We need to remove this
> + 		 * if we don't want to stay in L1 all the time. This wastes a
> + 		 * lot of power.
> + 		 */
> + 		pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S |
> + 				       PCIE_LINK_STATE_L1 |
> + 				       PCIE_LINK_STATE_CLKPM);
> + 	}
>   
>  -	if (pci_enable_device(pdev)) {
>  -		err = -ENODEV;
>  -		goto out_no_pci;
>  -	}
>  -
>   	pci_set_master(pdev);
>   
>   	err = pci_set_dma_mask(pdev, DMA_BIT_MASK(36));



-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

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

[Stephen Rothwell]

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

Hi John,

Today's linux-next merge of the wireless-next tree got a conflict in
drivers/net/wireless/iwlwifi/pcie/trans.c between commit eabc4ac5d760
("iwlwifi: pcie: disable L1 Active after pci_enable_device") from
thewireless tree and commit f2532b04b2ec ("iwlwifi: pcie: don't disable
L1 for newest NICs") from the wireless-next tree.

I fixed it up (maybe - see below) and can carry the fix as necessary (no
action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/net/wireless/iwlwifi/pcie/trans.c
index 390e2f0,e52d1ce..0000000
--- a/drivers/net/wireless/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
@@@ -1502,16 -1400,22 +1400,22 @@@ struct iwl_trans *iwl_trans_pcie_alloc(
  	spin_lock_init(&trans_pcie->reg_lock);
  	init_waitqueue_head(&trans_pcie->ucode_write_waitq);
  
 +	if (pci_enable_device(pdev)) {
 +		err = -ENODEV;
 +		goto out_no_pci;
 +	}
 +
- 	/* W/A - seems to solve weird behavior. We need to remove this if we
- 	 * don't want to stay in L1 all the time. This wastes a lot of power */
- 	pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
- 			       PCIE_LINK_STATE_CLKPM);
+ 	if (!cfg->base_params->pcie_l1_allowed) {
+ 		/*
+ 		 * W/A - seems to solve weird behavior. We need to remove this
+ 		 * if we don't want to stay in L1 all the time. This wastes a
+ 		 * lot of power.
+ 		 */
+ 		pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S |
+ 				       PCIE_LINK_STATE_L1 |
+ 				       PCIE_LINK_STATE_CLKPM);
+ 	}
  
 -	if (pci_enable_device(pdev)) {
 -		err = -ENODEV;
 -		goto out_no_pci;
 -	}
 -
  	pci_set_master(pdev);
  
  	err = pci_set_dma_mask(pdev, DMA_BIT_MASK(36));

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Sujith Manoharan]

Stephen Rothwell wrote:
> Today's linux-next merge of the wireless-next tree got a conflict in
> drivers/net/wireless/ath/ath9k/Kconfig between commit 8bb7f167a12a
> ("ath9k: Use minstrel rate control by default") from the wireless tree
> and commit cf657a2bc50d ("ath9k: Remove MAC_DEBUG") from the
> wireless-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks !

Sujith

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

[Stephen Rothwell]

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

Hi John,

Today's linux-next merge of the wireless-next tree got a conflict in
drivers/net/wireless/ath/ath9k/Kconfig between commit 8bb7f167a12a
("ath9k: Use minstrel rate control by default") from the wireless tree
and commit cf657a2bc50d ("ath9k: Remove MAC_DEBUG") from the
wireless-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/net/wireless/ath/ath9k/Kconfig
index 3c2cbc9,ec33c80..0000000
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@@ -84,25 -84,13 +84,17 @@@ config ATH9K_DFS_CERTIFIE
  	  developed. At this point enabling this option won't do anything
  	  except increase code size.
  
- config ATH9K_MAC_DEBUG
- 	bool "Atheros MAC statistics"
- 	depends on ATH9K_DEBUGFS
- 	default y
- 	---help---
- 	  This option enables collection of statistics for Rx/Tx status
- 	  data and some other MAC related statistics
- 
 -config ATH9K_RATE_CONTROL
 +config ATH9K_LEGACY_RATE_CONTROL
  	bool "Atheros ath9k rate control"
  	depends on ATH9K
 -	default y
 +	default n
  	---help---
  	  Say Y, if you want to use the ath9k specific rate control
 -	  module instead of minstrel_ht.
 +	  module instead of minstrel_ht. Be warned that there are various
 +	  issues with the ath9k RC and minstrel is a more robust algorithm.
 +	  Note that even if this option is selected, "ath9k_rate_control"
 +	  has to be passed to mac80211 using the module parameter,
 +	  ieee80211_default_rc_algo.
  
  config ATH9K_HTC
         tristate "Atheros HTC based wireless cards support"

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Stephen Rothwell]

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

Hi John,

Today's linux-next merge of the wireless-next tree got a conflict in
net/nfc/llcp/llcp.c between commit 3536da06db0b ("NFC: llcp: Clean local
timers and works when removing a device") from the wireless tree and
commits d9b8d8e19b07 ("NFC: llcp: Service Name Lookup netlink interface")
and 40213fa8513c ("NFC: llcp: Add cleanup support for unreplied SNL
requests") from the wireless-next tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc net/nfc/llcp/llcp.c
index b530afa,3361170..0000000
--- a/net/nfc/llcp/llcp.c
+++ b/net/nfc/llcp/llcp.c
@@@ -188,16 -156,9 +188,19 @@@ static void local_cleanup(struct nfc_ll
  	cancel_work_sync(&local->rx_work);
  	cancel_work_sync(&local->timeout_work);
  	kfree_skb(local->rx_pending);
 +}
 +
 +static void local_release(struct kref *ref)
 +{
 +	struct nfc_llcp_local *local;
 +
 +	local = container_of(ref, struct nfc_llcp_local, ref);
 +
 +	list_del(&local->list);
 +	local_cleanup(local, false);
+ 	del_timer_sync(&local->sdreq_timer);
+ 	cancel_work_sync(&local->sdreq_timeout_work);
+ 	nfc_llcp_free_sdp_tlv_list(&local->pending_sdreqs);
  	kfree(local);
  }
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Arend van Spriel]

On 11/15/2012 03:17 AM, Stephen Rothwell wrote:
> Hi John,
>
> Today's linux-next merge of the wireless-next tree got a conflict in
> drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c between commit
> d61f978b8f26 ("brcmfmac: fix typo in CONFIG_BRCMISCAN") from the  tree
> and commit f07998959d57 ("brcmfmac: remove obsolete i-scan and clean up
> related code") from the wireless-next tree.
>
> I used the latter (which removed the line that was fixed in the former)
> and can carry the fix as necessary (no action is required).
>

Agreed. The typo fix is only needed for v3.7.

Gr. AvS

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

[Stephen Rothwell]

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

Hi John,

Today's linux-next merge of the wireless-next tree got a conflict in
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c between commit
d61f978b8f26 ("brcmfmac: fix typo in CONFIG_BRCMISCAN") from the  tree
and commit f07998959d57 ("brcmfmac: remove obsolete i-scan and clean up
related code") from the wireless-next tree.

I used the latter (which removed the line that was fixed in the former)
and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Stephen Rothwell]

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

Hi John,

Today's linux-next merge of the wireless-next tree got a conflict in
net/mac80211/mlme.c between commit 3a40414f826a ("mac80211: connect with
HT20 if HT40 is not permitted") from the wireless tree and commit
04ecd2578e71 ("mac80211: track needed RX chains for channel contexts")
from the wireless-next tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc net/mac80211/mlme.c
index 1b7eed2,469d864..0000000
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@@ -3104,44 -3181,43 +3183,51 @@@ static int ieee80211_prep_channel(struc
  		}
  	}
  
 -	if (ht_oper) {
 +	if (ht_oper && sband->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40) {
+ 		const u8 *ht_cap_ie;
+ 		const struct ieee80211_ht_cap *ht_cap;
+ 		u8 chains = 1;
+ 
 -		channel_type = NL80211_CHAN_HT20;
 +		/*
 +		 * cfg80211 already verified that the channel itself can
 +		 * be used, but it didn't check that we can do the right
 +		 * HT type, so do that here as well. If HT40 isn't allowed
 +		 * on this channel, disable 40 MHz operation.
 +		 */
  
 -		if (sband->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40) {
 -			switch (ht_oper->ht_param &
 -					IEEE80211_HT_PARAM_CHA_SEC_OFFSET) {
 -			case IEEE80211_HT_PARAM_CHA_SEC_ABOVE:
 +		switch (ht_oper->ht_param & IEEE80211_HT_PARAM_CHA_SEC_OFFSET) {
 +		case IEEE80211_HT_PARAM_CHA_SEC_ABOVE:
 +			if (cbss->channel->flags & IEEE80211_CHAN_NO_HT40PLUS)
 +				ifmgd->flags |= IEEE80211_STA_DISABLE_40MHZ;
 +			else
  				channel_type = NL80211_CHAN_HT40PLUS;
 -				break;
 -			case IEEE80211_HT_PARAM_CHA_SEC_BELOW:
 +			break;
 +		case IEEE80211_HT_PARAM_CHA_SEC_BELOW:
 +			if (cbss->channel->flags & IEEE80211_CHAN_NO_HT40MINUS)
 +				ifmgd->flags |= IEEE80211_STA_DISABLE_40MHZ;
 +			else
  				channel_type = NL80211_CHAN_HT40MINUS;
 -				break;
 -			}
 +			break;
  		}
- 	}
  
- 	if (!ieee80211_set_channel_type(local, sdata, channel_type)) {
- 		/* can only fail due to HT40+/- mismatch */
- 		channel_type = NL80211_CHAN_HT20;
- 		sdata_info(sdata,
- 			   "disabling 40 MHz due to multi-vif mismatch\n");
- 		ifmgd->flags |= IEEE80211_STA_DISABLE_40MHZ;
- 		WARN_ON(!ieee80211_set_channel_type(local, sdata,
- 						    channel_type));
+ 		ht_cap_ie = cfg80211_find_ie(WLAN_EID_HT_CAPABILITY,
+ 					     cbss->information_elements,
+ 					     cbss->len_information_elements);
+ 		if (ht_cap_ie && ht_cap_ie[1] >= sizeof(*ht_cap)) {
+ 			ht_cap = (void *)(ht_cap_ie + 2);
+ 			chains = ieee80211_mcs_to_chains(&ht_cap->mcs);
+ 		}
+ 		sdata->needed_rx_chains = min(chains, local->rx_chains);
+ 	} else {
+ 		sdata->needed_rx_chains = 1;
  	}
  
- 	local->oper_channel = cbss->channel;
- 	ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
+ 	/* will change later if needed */
+ 	sdata->smps_mode = IEEE80211_SMPS_OFF;
  
- 	return 0;
+ 	ieee80211_vif_release_channel(sdata);
+ 	return ieee80211_vif_use_channel(sdata, cbss->channel, channel_type,
+ 					 IEEE80211_CHANCTX_SHARED);
  }
  
  static int ieee80211_prep_connection(struct ieee80211_sub_if_data *sdata,

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Stephen Rothwell]

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

Hi John,

Today's linux-next merge of the wireless-next tree got a conflict in
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c between commit
3e4f319dacc6 ("brcmfmac: fix end of loop check (signedness bug)") from
the wireless tree and commit 81118d165811 ("brcmfmac: Using zero instead
of NULL") from the wireless-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index 411dfe7,b27e245..0000000
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@@ -3972,8 -3972,8 +3972,8 @@@ brcmf_set_management_ie(struct brcmf_cf
  	u8  *iovar_ie_buf;
  	u8  *curr_ie_buf;
  	u8  *mgmt_ie_buf = NULL;
 -	u32 mgmt_ie_buf_len;
 +	int mgmt_ie_buf_len;
- 	u32 *mgmt_ie_len = 0;
+ 	u32 *mgmt_ie_len;
  	u32 del_add_ie_buf_len = 0;
  	u32 total_ie_buf_len = 0;
  	u32 parsed_ie_buf_len = 0;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Stephen Rothwell]

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

Hi John,

Today's linux-next merge of the wireless-next tree got a conflict in
drivers/net/wireless/libertas/cfg.c between commit d929bbc63069
("wireless: libertas: fix unaligned le64 accesses") from the wireless
tree and commit 731f8e1c41a4 ("libertas: release bss references and avoid
warning from cfg80211_inform_bss") from the wireless-next tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/net/wireless/libertas/cfg.c
index a7f1ab2,89f34ad..0000000
--- a/drivers/net/wireless/libertas/cfg.c
+++ b/drivers/net/wireless/libertas/cfg.c
@@@ -632,9 -633,9 +633,9 @@@ static int lbs_ret_scan(struct lbs_priv
  				     LBS_SCAN_RSSI_TO_MBM(rssi)/100);
  
  			if (channel &&
- 			    !(channel->flags & IEEE80211_CHAN_DISABLED))
- 				cfg80211_inform_bss(wiphy, channel,
+ 			    !(channel->flags & IEEE80211_CHAN_DISABLED)) {
+ 				bss = cfg80211_inform_bss(wiphy, channel,
 -					bssid, le64_to_cpu(*(__le64 *)tsfdesc),
 +					bssid, get_unaligned_le64(tsfdesc),
  					capa, intvl, ie, ielen,
  					LBS_SCAN_RSSI_TO_MBM(rssi),
  					GFP_KERNEL);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]