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

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

[Stephen Rothwell]

Hi all,

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

  drivers/net/wireless/ath/ath10k/mac.c

between commit:

  f3fe4e93dd63 ("mac80211: add a HW flag for supporting HW TX fragmentation")

from the net-next tree and commit:

  ff32eeb86aa1 ("ath10k: advertize hardware packet loss mechanism")

from the wireless-drivers-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/ath/ath10k/mac.c
index 717b2fad9a8a,db6ddf974d1d..000000000000
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@@ -8005,7 -7993,7 +7993,8 @@@ int ath10k_mac_register(struct ath10k *
  	ieee80211_hw_set(ar->hw, WANT_MONITOR_VIF);
  	ieee80211_hw_set(ar->hw, CHANCTX_STA_CSA);
  	ieee80211_hw_set(ar->hw, QUEUE_CONTROL);
 +	ieee80211_hw_set(ar->hw, SUPPORTS_TX_FRAG);
+ 	ieee80211_hw_set(ar->hw, REPORTS_LOW_ACK);
  
  	if (!test_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags))
  		ieee80211_hw_set(ar->hw, SW_CRYPTO_CONTROL);

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

[Kalle Valo]

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

> Hi all,
>
> Today's linux-next merge of the wireless-drivers-next tree got a
> conflict in:
>
>   drivers/net/wireless/ath/ath10k/mac.c
>
> between commit:
>
>   f3fe4e93dd63 ("mac80211: add a HW flag for supporting HW TX fragmentation")
>
> from the net-next tree and commit:
>
>   ff32eeb86aa1 ("ath10k: advertize hardware packet loss mechanism")
>
> from the wireless-drivers-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.

The fix looks good, thanks. I sent a pull request to Dave yesteday which
should fix this.

-- 
Kalle Valo

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

[Kalle Valo]

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

> Today's linux-next merge of the wireless-drivers-next tree got a
> conflict in:
>
>   drivers/net/wireless/intel/iwlwifi/mvm/scan.c
>
> between commit:
>
>   7947d3e075cd ("mac80211: Add support for beacon report radio measurement")
>
> from the net-next tree and commit:
>
>   69e046423ad7 ("iwlwifi: mvm: change scan timeout to a delayed work")
>
> from the wireless-drivers-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.

Thanks. I'm planning to submit a pull request to Dave tomorrow and I'll
include instruction how to solve these mac80211 API conflicts.

-- 
Kalle Valo

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

[Stephen Rothwell]

Hi all,

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

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

between commit:

  7947d3e075cd ("mac80211: Add support for beacon report radio measurement")

from the net-next tree and commit:

  69e046423ad7 ("iwlwifi: mvm: change scan timeout to a delayed work")

from the wireless-drivers-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/scan.c
index 1cac10c5d818,fb25d9e41912..000000000000
--- a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
@@@ -400,9 -396,10 +400,9 @@@ void iwl_mvm_rx_lmac_scan_complete_noti
  			       iwl_mvm_ebs_status_str(scan_notif->ebs_status));
  
  		mvm->scan_status &= ~IWL_MVM_SCAN_REGULAR;
 -		ieee80211_scan_completed(mvm->hw,
 -				scan_notif->status == IWL_SCAN_OFFLOAD_ABORTED);
 +		ieee80211_scan_completed(mvm->hw, &info);
  		iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
- 		del_timer(&mvm->scan_timer);
+ 		cancel_delayed_work(&mvm->scan_timeout_dwork);
  	} else {
  		IWL_ERR(mvm,
  			"got scan complete notification but no scan is running\n");
@@@ -1433,13 -1432,9 +1435,13 @@@ void iwl_mvm_rx_umac_scan_complete_noti
  
  	/* if the scan is already stopping, we don't need to notify mac80211 */
  	if (mvm->scan_uid_status[uid] == IWL_MVM_SCAN_REGULAR) {
 -		ieee80211_scan_completed(mvm->hw, aborted);
 +		struct cfg80211_scan_info info = {
 +			.aborted = aborted,
 +		};
 +
 +		ieee80211_scan_completed(mvm->hw, &info);
  		iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
- 		del_timer(&mvm->scan_timer);
+ 		cancel_delayed_work(&mvm->scan_timeout_dwork);
  	} else if (mvm->scan_uid_status[uid] == IWL_MVM_SCAN_SCHED) {
  		ieee80211_sched_scan_stopped(mvm->hw);
  		mvm->sched_scan_pass_all = SCHED_SCAN_PASS_ALL_DISABLED;
@@@ -1644,14 -1630,9 +1646,14 @@@ out
  		 * to release the scan reference here.
  		 */
  		iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
- 		del_timer(&mvm->scan_timer);
+ 		cancel_delayed_work(&mvm->scan_timeout_dwork);
 -		if (notify)
 -			ieee80211_scan_completed(mvm->hw, true);
 +		if (notify) {
 +			struct cfg80211_scan_info info = {
 +				.aborted = true,
 +			};
 +
 +			ieee80211_scan_completed(mvm->hw, &info);
 +		}
  	} else if (notify) {
  		ieee80211_sched_scan_stopped(mvm->hw);
  		mvm->sched_scan_pass_all = SCHED_SCAN_PASS_ALL_DISABLED;

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

[David Miller]

From: Kalle Valo <kvalo@codeaurora.org>
Date: Mon, 16 May 2016 16:10:27 +0300

> I wasn't expecting that skb_info variable is removed. Do we now have
> merge damage somewhere? Luca, what do you think?

It's possible I got the net --> net-next merge wrong the other day, feel
free to send me an appropriate fixup.

Thanks.

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

[Kalle Valo]

"Coelho, Luciano" <luciano.coelho@intel.com> writes:

(dropping damaged diffs etc, adding Emmanuel as the author of
5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the AMSDU
len"))

>> I wasn't expecting that skb_info variable is removed. Do we now have
>> merge damage somewhere? Luca, what do you think?
>
> As we discussed on IRC, it seems to me that there was a merge damage
> when Dave merged net.git into net-next.git (as you mostly found out ;).
>
> I'm not sure how to solve that, but I'm sure you and Dave can figure
> something out. :) Please let me know if you need any help with it.

Yeah, I guess in net-next.git Dave assumed that 'info == skb_info' is
always valid in iwl_mvm_set_tx_cmd(), but I don't that's the case. So I
think the end case, after a merge, should look like this:

void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff *skb,
			struct iwl_tx_cmd *tx_cmd,
			struct ieee80211_tx_info *info, u8 sta_id)
{
	struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
	struct ieee80211_hdr *hdr = (void *)skb->data;
	__le16 fc = hdr->frame_control;
	u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
	u32 len = skb->len + FCS_LEN;
	u8 ac;

[...]

	tx_cmd->tx_flags = cpu_to_le32(tx_flags);
	/* Total # bytes to be transmitted */
	tx_cmd->len = cpu_to_le16((u16)skb->len +
		(uintptr_t)skb_info->driver_data[0]);
	tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
	tx_cmd->sta_id = sta_id;

I'm going to propose this to Dave in my pending pull request[1]. But I
would appreciate if someone else would double check this.

[1] https://patchwork.ozlabs.org/patch/621953/

-- 
Kalle Valo

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

[Coelho, Luciano]

Hi Kalle,

On Mon, 2016-05-16 at 16:10 +0300, Kalle Valo wrote:
> (Adding Luca and linux-wireless)
> 
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
> 
> > 
> > Today's linux-next merge of the wireless-drivers-next tree got a
> > conflict in:
> > 
> >   drivers/net/wireless/intel/iwlwifi/mvm/tx.c
> > 
> > between commit:
> > 
> >   909b27f70643 ("Merge
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
> > 
> > from the net-next tree and commit:
> > 
> >   a525d0eab17d ("Merge tag 'iwlwifi-for-kalle-2016-05-04' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-
> > fixes")
> > 
> > from the wireless-drivers-next tree.
> > 
> > I fixed it up (I think that the net-next tree merge lost the
> > changes
> > to iwl_mvm_set_tx_cmd() associated with commit 5c08b0f5026f
> > ("iwlwifi:
> > mvm: don't override the rate with the AMSDU len")) and can carry
> > the
> > fix as necessary.
> Hmm, I'm starting to suspect something is wrong. I did a test merge
> of
> net-next and wireless-drivers-next and got this as a diff after the
> merge:
> 
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
> @@ -211,7 +211,6 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm,
> struct sk_buff *skb,
>                         struct iwl_tx_cmd *tx_cmd,
>                         struct ieee80211_tx_info *info, u8 sta_id)
>  {
> -       struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
>         struct ieee80211_hdr *hdr = (void *)skb->data;
>         __le16 fc = hdr->frame_control;
>         u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
> @@ -295,7 +294,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm,
> struct sk_buff *skb,
>         tx_cmd->tx_flags = cpu_to_le32(tx_flags);
>         /* Total # bytes to be transmitted */
>         tx_cmd->len = cpu_to_le16((u16)skb->len +
> -               (uintptr_t)skb_info->driver_data[0]);
> +               (uintptr_t)info->driver_data[0]);
>         tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
>         tx_cmd->sta_id = sta_id;
> 
> But commit 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with
> the
> AMSDU len") specifically added skb_info variable to that function:
> 
> @@ -105,6 +105,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm,
> struct sk_buff *skb,
>                         struct iwl_tx_cmd *tx_cmd,
>                         struct ieee80211_tx_info *info, u8 sta_id)
>  {
> +       struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
>         struct ieee80211_hdr *hdr = (void *)skb->data;
>         __le16 fc = hdr->frame_control;
>         u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
> @@ -185,7 +186,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm,
> struct sk_buff *skb,
>         tx_cmd->tx_flags = cpu_to_le32(tx_flags);
>         /* Total # bytes to be transmitted */
>         tx_cmd->len = cpu_to_le16((u16)skb->len +
> -               (uintptr_t)info->driver_data[0]);
> +               (uintptr_t)skb_info->driver_data[0]);
>         tx_cmd->next_frame_len = 0;
>         tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
>         tx_cmd->sta_id = sta_id;
> 
> I wasn't expecting that skb_info variable is removed. Do we now have
> merge damage somewhere? Luca, what do you think?

As we discussed on IRC, it seems to me that there was a merge damage
when Dave merged net.git into net-next.git (as you mostly found out ;).

I'm not sure how to solve that, but I'm sure you and Dave can figure
something out. :) Please let me know if you need any help with it.

--
Cheers,
Luca.

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

[Kalle Valo]

(Adding Luca and linux-wireless)

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

> Today's linux-next merge of the wireless-drivers-next tree got a
> conflict in:
>
>   drivers/net/wireless/intel/iwlwifi/mvm/tx.c
>
> between commit:
>
>   909b27f70643 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
>
> from the net-next tree and commit:
>
>   a525d0eab17d ("Merge tag 'iwlwifi-for-kalle-2016-05-04' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes")
>
> from the wireless-drivers-next tree.
>
> I fixed it up (I think that the net-next tree merge lost the changes
> to iwl_mvm_set_tx_cmd() associated with commit 5c08b0f5026f ("iwlwifi:
> mvm: don't override the rate with the AMSDU len")) and can carry the
> fix as necessary.

Hmm, I'm starting to suspect something is wrong. I did a test merge of
net-next and wireless-drivers-next and got this as a diff after the
merge:

--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -211,7 +211,6 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff *skb,
                        struct iwl_tx_cmd *tx_cmd,
                        struct ieee80211_tx_info *info, u8 sta_id)
 {
-       struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
        struct ieee80211_hdr *hdr = (void *)skb->data;
        __le16 fc = hdr->frame_control;
        u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
@@ -295,7 +294,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff *skb,
        tx_cmd->tx_flags = cpu_to_le32(tx_flags);
        /* Total # bytes to be transmitted */
        tx_cmd->len = cpu_to_le16((u16)skb->len +
-               (uintptr_t)skb_info->driver_data[0]);
+               (uintptr_t)info->driver_data[0]);
        tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
        tx_cmd->sta_id = sta_id;

But commit 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the
AMSDU len") specifically added skb_info variable to that function:

@@ -105,6 +105,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff *skb,
                        struct iwl_tx_cmd *tx_cmd,
                        struct ieee80211_tx_info *info, u8 sta_id)
 {
+       struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
        struct ieee80211_hdr *hdr = (void *)skb->data;
        __le16 fc = hdr->frame_control;
        u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
@@ -185,7 +186,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff *skb,
        tx_cmd->tx_flags = cpu_to_le32(tx_flags);
        /* Total # bytes to be transmitted */
        tx_cmd->len = cpu_to_le16((u16)skb->len +
-               (uintptr_t)info->driver_data[0]);
+               (uintptr_t)skb_info->driver_data[0]);
        tx_cmd->next_frame_len = 0;
        tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
        tx_cmd->sta_id = sta_id;

I wasn't expecting that skb_info variable is removed. Do we now have
merge damage somewhere? Luca, what do you think?

-- 
Kalle Valo

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

[Stephen Rothwell]

Hi Kalle,

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

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

between commit:

  909b27f70643 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")

from the net-next tree and commit:

  a525d0eab17d ("Merge tag 'iwlwifi-for-kalle-2016-05-04' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes")

from the wireless-drivers-next tree.

I fixed it up (I think that the net-next tree merge lost the changes
to iwl_mvm_set_tx_cmd() associated with commit 5c08b0f5026f ("iwlwifi:
mvm: don't override the rate with the AMSDU len")) 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

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

[Stephen Rothwell]

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

Hi Kalle,

Today's linux-next merge of the wireless-drivers-next tree got a
conflict in drivers/net/wireless/ath/ath10k/mac.c between commits
41fbf6e4f317 ("ath10k: enable IEEE80211_HW_SUPPORT_FAST_XMIT") and
df1404650ccb ("mac80211: remove support for IFF_PROMISC") from the
net-next tree and commits 548462133d98 ("ath10k: fix interrupt storm"),
cc9904e694fa ("ath10k: add hw connection monitor support") and
500ff9f9389d ("ath10k: implement chanctx API") (and a few others) from
the wireless-drivers-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 drivers/net/wireless/ath/ath10k/mac.c
index fcd08b2f8d26,eaa0182e001d..000000000000
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@@ -766,9 -1031,68 +1031,48 @@@ static int ath10k_monitor_stop(struct a
  	return 0;
  }
  
 -static bool ath10k_mac_should_disable_promisc(struct ath10k *ar)
 -{
 -	struct ath10k_vif *arvif;
 -
 -	if (!(ar->filter_flags & FIF_PROMISC_IN_BSS))
 -		return true;
 -
 -	if (!ar->num_started_vdevs)
 -		return false;
 -
 -	list_for_each_entry(arvif, &ar->arvifs, list)
 -		if (arvif->vdev_type != WMI_VDEV_TYPE_AP)
 -			return false;
 -
 -	ath10k_dbg(ar, ATH10K_DBG_MAC,
 -		   "mac disabling promiscuous mode because vdev is started\n");
 -	return true;
 -}
 -
+ static bool ath10k_mac_monitor_vdev_is_needed(struct ath10k *ar)
+ {
+ 	int num_ctx;
+ 
+ 	/* At least one chanctx is required to derive a channel to start
+ 	 * monitor vdev on.
+ 	 */
+ 	num_ctx = ath10k_mac_num_chanctxs(ar);
+ 	if (num_ctx == 0)
+ 		return false;
+ 
+ 	/* If there's already an existing special monitor interface then don't
+ 	 * bother creating another monitor vdev.
+ 	 */
+ 	if (ar->monitor_arvif)
+ 		return false;
+ 
+ 	return ar->monitor ||
 -	       !ath10k_mac_should_disable_promisc(ar) ||
+ 	       test_bit(ATH10K_CAC_RUNNING, &ar->dev_flags);
+ }
+ 
+ static bool ath10k_mac_monitor_vdev_is_allowed(struct ath10k *ar)
+ {
+ 	int num_ctx;
+ 
+ 	num_ctx = ath10k_mac_num_chanctxs(ar);
+ 
+ 	/* FIXME: Current interface combinations and cfg80211/mac80211 code
+ 	 * shouldn't allow this but make sure to prevent handling the following
+ 	 * case anyway since multi-channel DFS hasn't been tested at all.
+ 	 */
+ 	if (test_bit(ATH10K_CAC_RUNNING, &ar->dev_flags) && num_ctx > 1)
+ 		return false;
+ 
+ 	return true;
+ }
+ 
  static int ath10k_monitor_recalc(struct ath10k *ar)
  {
- 	bool should_start;
+ 	bool needed;
+ 	bool allowed;
+ 	int ret;
  
  	lockdep_assert_held(&ar->conf_mutex);
  
@@@ -5499,9 -6915,14 +6894,15 @@@ int ath10k_mac_register(struct ath10k *
  			IEEE80211_HW_AP_LINK_PS |
  			IEEE80211_HW_SPECTRUM_MGMT |
  			IEEE80211_HW_SW_CRYPTO_CONTROL |
- 			IEEE80211_HW_SUPPORT_FAST_XMIT;
++			IEEE80211_HW_SUPPORT_FAST_XMIT |
+ 			IEEE80211_HW_CONNECTION_MONITOR |
+ 			IEEE80211_HW_SUPPORTS_PER_STA_GTK |
+ 			IEEE80211_HW_WANT_MONITOR_VIF |
+ 			IEEE80211_HW_CHANCTX_STA_CSA |
+ 			IEEE80211_HW_QUEUE_CONTROL;
  
  	ar->hw->wiphy->features |= NL80211_FEATURE_STATIC_SMPS;
+ 	ar->hw->wiphy->flags |= WIPHY_FLAG_IBSS_RSN;
  
  	if (ar->ht_cap_info & WMI_HT_CAP_DYNAMIC_SMPS)
  		ar->hw->wiphy->features |= NL80211_FEATURE_DYNAMIC_SMPS;

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