Re: Fixing full name in patchwork

[Sudip Mukherjee]

On Tue, Dec 08, 2015 at 09:54:41AM +0200, Kalle Valo wrote:
> Sudip Mukherjee  writes:
> 
> > On Mon, Dec 07, 2015 at 08:03:54PM +0200, Kalle Valo wrote:
> >> Hi Sudip,
> >> 
> >> Sudip Mukherjee  writes:
> >> 

> >
> > I have also noticed the patch. Anyway, I have created a profile in
> > patchwork and given full name. Hopefully that should solve the problem.
> 
> At least now your name in the patchwork link above looks correct:

Yes, but I am still surprised why this happened for only this patch.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fixing full name in patchwork

[Kalle Valo]

Sudip Mukherjee  writes:

> On Tue, Dec 08, 2015 at 09:54:41AM +0200, Kalle Valo wrote:
>> Sudip Mukherjee  writes:
>> 
>> > On Mon, Dec 07, 2015 at 08:03:54PM +0200, Kalle Valo wrote:
>> >> Hi Sudip,
>> >> 
>> >> Sudip Mukherjee  writes:
>> >> 
> 
>> >
>> > I have also noticed the patch. Anyway, I have created a profile in
>> > patchwork and given full name. Hopefully that should solve the problem.
>> 
>> At least now your name in the patchwork link above looks correct:
>
> Yes, but I am still surprised why this happened for only this patch.

I don't know what other patches you are referring to, but I download the
patches I apply directly from patchwork. If other maintainers take the
patch from a mail folder this issue would not happen.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless-testing rebased, new HEAD commit f5feec4244464225c03ccc9ddad615cb43a044cc

[Bob Copeland]

On Mon, Dec 07, 2015 at 02:39:11PM -0500, John W. Linville wrote:
> All,
> 
> An earlier pull got a version of mac80211.git that was later reverted.
> Unfortunately, the intervening merges got things so screwed-up I
> couldn't reasonably unravel them.  So, I have taken the somewhat
> unusual step of rebasing wireless-testing here in the middle of the
> 4.4 stream.

For this reason, we are considering making the new wireless-testing
rebase the feeder trees for each build instead of once per cycle,
similarly to how linux-next is built.  For most users, the main
difference will behaving to remember to 'git pull --rebase' instead of
just 'git pull'.

If there are users that rely on the merging-type workflow, could you
weigh in on whether that is a strong requirement?

I'm running this in test-pilot mode now at its eventual home; comments
welcome:

https://git.kernel.org/cgit/linux/kernel/git/wireless/wireless-testing.git

-- 
Bob Copeland %% http://bobcopeland.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/9] mac80211: pass aggregation window size to lower level

[Emmanuel Grumbach]

From: Sara Sharon 

Currently mac80211 does not inform the driver of the window
size when starting a rx aggregation session.
Following patches will enable managing the reorder buffer in
the driver or hardware, and the window size is needed.

Signed-off-by: Sara Sharon 
Signed-off-by: Emmanuel Grumbach 
---
 include/net/mac80211.h | 8 +---
 net/mac80211/agg-rx.c  | 2 +-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index f4cbad4..dca010a 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -3061,9 +3061,11 @@ enum ieee80211_reconfig_type {
  * ieee80211_ampdu_mlme_action. Starting sequence number (@ssn)
  * is the first frame we expect to perform the action on. Notice
  * that TX/RX_STOP can pass NULL for this parameter.
- * The @buf_size parameter is only valid when the action is set to
- * %IEEE80211_AMPDU_TX_OPERATIONAL and indicates the peer's reorder
- * buffer size (number of subframes) for this session -- the driver
+ * The @buf_size parameter is valid only when the action is set to
+ * %IEEE80211_AMPDU_RX_START or %IEEE80211_AMPDU_TX_OPERATIONAL and
+ * indicates the reorder buffer size (number of subframes) for this
+ * session.
+ * When the action is set to %IEEE80211_AMPDU_TX_OPERATIONAL the driver
  * may neither send aggregates containing more subframes than this
  * nor send aggregates in a way that lost frames would exceed the
  * buffer size. If just limiting the aggregate size, this would be
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 10ad4ac..7867273 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -323,7 +323,7 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
__skb_queue_head_init(_agg_rx->reorder_buf[i]);
 
ret = drv_ampdu_action(local, sta->sdata, IEEE80211_AMPDU_RX_START,
-  >sta, tid, _seq_num, 0, false);
+  >sta, tid, _seq_num, buf_size, false);
ht_dbg(sta->sdata, "Rx A-MPDU request on %pM tid %d result %d\n",
   sta->sta.addr, tid, ret);
if (ret) {
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 9/9] mac80211: reprogram in interface order

[Emmanuel Grumbach]

From: Johannes Berg 

During reprogramming, mac80211 currently first adds all the channel
contexts, then binds them to the vifs and then goes to reconfigure
all the interfaces. Drivers might, perhaps implicitly, rely on the
operation order for certain things that typically happen within a
single function elsewhere in mac80211. To avoid problems with that,
reorder the code in mac80211's restart/reprogramming to work fully
within the interface loop so that the order of operations is like
in normal operation.

For iwlwifi, this fixes a firmware crash when reprogramming with an
AP/GO interface active.

Reported-by: David Spinadel 
Signed-off-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
---
 net/mac80211/util.c | 76 ++---
 1 file changed, 37 insertions(+), 39 deletions(-)

diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 1a26ebd..f4b2c04 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1726,6 +1726,27 @@ static void ieee80211_assign_chanctx(struct 
ieee80211_local *local,
mutex_unlock(>chanctx_mtx);
 }
 
+static void ieee80211_reconfig_stations(struct ieee80211_sub_if_data *sdata)
+{
+   struct ieee80211_local *local = sdata->local;
+   struct sta_info *sta;
+
+   /* add STAs back */
+   mutex_lock(>sta_mtx);
+   list_for_each_entry(sta, >sta_list, list) {
+   enum ieee80211_sta_state state;
+
+   if (!sta->uploaded || sta->sdata != sdata)
+   continue;
+
+   for (state = IEEE80211_STA_NOTEXIST;
+state < sta->sta_state; state++)
+   WARN_ON(drv_sta_state(local, sta->sdata, sta, state,
+ state + 1));
+   }
+   mutex_unlock(>sta_mtx);
+}
+
 int ieee80211_reconfig(struct ieee80211_local *local)
 {
struct ieee80211_hw *hw = >hw;
@@ -1861,50 +1882,11 @@ int ieee80211_reconfig(struct ieee80211_local *local)
WARN_ON(drv_add_chanctx(local, ctx));
mutex_unlock(>chanctx_mtx);
 
-   list_for_each_entry(sdata, >interfaces, list) {
-   if (!ieee80211_sdata_running(sdata))
-   continue;
-   ieee80211_assign_chanctx(local, sdata);
-   }
-
sdata = rtnl_dereference(local->monitor_sdata);
if (sdata && ieee80211_sdata_running(sdata))
ieee80211_assign_chanctx(local, sdata);
}
 
-   /* add STAs back */
-   mutex_lock(>sta_mtx);
-   list_for_each_entry(sta, >sta_list, list) {
-   enum ieee80211_sta_state state;
-
-   if (!sta->uploaded)
-   continue;
-
-   /* AP-mode stations will be added later */
-   if (sta->sdata->vif.type == NL80211_IFTYPE_AP)
-   continue;
-
-   for (state = IEEE80211_STA_NOTEXIST;
-state < sta->sta_state; state++)
-   WARN_ON(drv_sta_state(local, sta->sdata, sta, state,
- state + 1));
-   }
-   mutex_unlock(>sta_mtx);
-
-   /* reconfigure tx conf */
-   if (hw->queues >= IEEE80211_NUM_ACS) {
-   list_for_each_entry(sdata, >interfaces, list) {
-   if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
-   sdata->vif.type == NL80211_IFTYPE_MONITOR ||
-   !ieee80211_sdata_running(sdata))
-   continue;
-
-   for (i = 0; i < IEEE80211_NUM_ACS; i++)
-   drv_conf_tx(local, sdata, i,
-   >tx_conf[i]);
-   }
-   }
-
/* reconfigure hardware */
ieee80211_hw_config(local, ~0);
 
@@ -1917,6 +1899,22 @@ int ieee80211_reconfig(struct ieee80211_local *local)
if (!ieee80211_sdata_running(sdata))
continue;
 
+   ieee80211_assign_chanctx(local, sdata);
+
+   switch (sdata->vif.type) {
+   case NL80211_IFTYPE_AP_VLAN:
+   case NL80211_IFTYPE_MONITOR:
+   break;
+   default:
+   ieee80211_reconfig_stations(sdata);
+   /* fall through */
+   case NL80211_IFTYPE_AP: /* AP stations are handled later */
+   for (i = 0; i < IEEE80211_NUM_ACS; i++)
+   drv_conf_tx(local, sdata, i,
+   >tx_conf[i]);
+   break;
+   }
+
/* common change flags for all interface types */
changed = BSS_CHANGED_ERP_CTS_PROT |
  

[PATCH 2/9] mac80211: limit the A-MSDU Tx based on peer's capabilities

[Emmanuel Grumbach]

In VHT, the specification allows to limit the number of
MSDUs in an A-MSDU in the Extended Capabilities IE. There
is also a limitation on the byte size in the VHT IE.
In HT, the only limitation is on the byte size.
Parse the capabilities from the peer and make them
available to the driver.

In HT, there is another limitation when a BA agreement
is active: the byte size can't be greater than 4095.
This is not enforced here.

Signed-off-by: Emmanuel Grumbach 
---
 include/linux/ieee80211.h | 19 +++
 include/net/mac80211.h| 14 ++
 net/mac80211/cfg.c| 29 +
 net/mac80211/ht.c |  5 +
 net/mac80211/vht.c| 18 ++
 5 files changed, 85 insertions(+)

diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index d9ddb89..3b1f6ce 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -163,6 +163,14 @@ static inline u16 ieee80211_sn_sub(u16 sn1, u16 sn2)
 /* 30 byte 4 addr hdr, 2 byte QoS, 2304 byte MSDU, 12 byte crypt, 4 byte FCS */
 #define IEEE80211_MAX_FRAME_LEN2352
 
+/* Maximal size of an A-MSDU */
+#define IEEE80211_MAX_MPDU_LEN_HT_3839 3839
+#define IEEE80211_MAX_MPDU_LEN_HT_7935 7935
+
+#define IEEE80211_MAX_MPDU_LEN_VHT_38953895
+#define IEEE80211_MAX_MPDU_LEN_VHT_79917991
+#define IEEE80211_MAX_MPDU_LEN_VHT_11454   11454
+
 #define IEEE80211_MAX_SSID_LEN 32
 
 #define IEEE80211_MAX_MESH_ID_LEN  32
@@ -1505,6 +1513,7 @@ struct ieee80211_vht_operation {
 #define IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895 0x
 #define IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991 0x0001
 #define IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454
0x0002
+#define IEEE80211_VHT_CAP_MAX_MPDU_MASK
0x0003
 #define IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ   0x0004
 #define IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ  0x0008
 #define IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK 0x000C
@@ -2086,6 +2095,16 @@ enum ieee80211_tdls_actioncode {
 #define WLAN_EXT_CAPA8_TDLS_WIDE_BW_ENABLEDBIT(5)
 #define WLAN_EXT_CAPA8_OPMODE_NOTIFBIT(6)
 
+/* Defines the maximal number of MSDUs in an A-MSDU. */
+#define WLAN_EXT_CAPA8_MAX_MSDU_IN_AMSDU_LSB   BIT(7)
+#define WLAN_EXT_CAPA9_MAX_MSDU_IN_AMSDU_MSB   BIT(0)
+
+/*
+ * Fine Timing Measurement Initiator - bit 71 of @WLAN_EID_EXT_CAPABILITY
+ * information element
+ */
+#define WLAN_EXT_CAPA9_FTM_INITIATOR   BIT(7)
+
 /* TDLS specific payload type in the LLC/SNAP header */
 #define WLAN_TDLS_SNAP_RFTYPE  0x2
 
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 8da483b..71be30d 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1701,6 +1701,18 @@ struct ieee80211_sta_rates {
  * @tdls_initiator: indicates the STA is an initiator of the TDLS link. Only
  * valid if the STA is a TDLS peer in the first place.
  * @mfp: indicates whether the STA uses management frame protection or not.
+ * @max_amsdu_subframes: indicates the maximal number of MSDUs in a single
+ * A-MSDU. Taken from the Extended Capabilities element. 0 means
+ * unlimited.
+ * @max_amsdu_len: indicates the maximal length of an A-MSDU in bytes. This
+ * field is always valid for packets with a VHT preamble. For packets
+ * with a HT preamble, additional limits apply:
+ * + If the skb is transmitted as part of a BA agreement, the
+ *   A-MSDU maximal size is min(max_amsdu_len, 4065) bytes.
+ * + If the skb is not part of a BA aggreement, the A-MSDU maximal
+ *   size is min(max_amsdu_len, 7935) bytes.
+ * Both additional HT limits must be enforced by the low level driver.
+ * This is defined by the spec (IEEE 802.11-2012 section 8.3.2.2 NOTE 2).
  * @txq: per-TID data TX queues (if driver uses the TXQ abstraction)
  */
 struct ieee80211_sta {
@@ -1719,6 +1731,8 @@ struct ieee80211_sta {
bool tdls;
bool tdls_initiator;
bool mfp;
+   u8 max_amsdu_subframes;
+   u16 max_amsdu_len;
 
struct ieee80211_txq *txq[IEEE80211_NUM_TIDS];
 
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 2d1c4c3..b9e2c2f 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1131,6 +1131,34 @@ static int sta_apply_parameters(struct ieee80211_local 
*local,
sta->sta.max_sp = params->max_sp;
}
 
+   /* The sender might not have sent the last bit, consider it to be 0 */
+   if (params->ext_capab_len >= 8) {
+   u8 val = (params->ext_capab[7] &
+ WLAN_EXT_CAPA8_MAX_MSDU_IN_AMSDU_LSB) >> 7;
+
+   /* we did get all the bits, take the MSB as well */
+   if (params->ext_capab_len >= 9) {
+   u8 val_msb = params->ext_capab[8] &
+   

ATH10K VLAN firmware issue

[Cedric VONCKEN]

I'm testing to transmit frame with 802.1q tag (VLAN).

My client is set in STA + WDS and the netdev is bridged with
eth0.
I have a computer with vlan configuration set connected to the
STA eth0.

If I try to transmit frames with 802.1q tag, the frames are not
sent.
I checked with wireless sniffer, and I don't see the frame with
VLAN tag (the frames without VLAN tag are sent).

I tested with firmware 10.2.4.70.14-2 from kale github,
10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2 from openwrt,
and in all cases I have the same issue.

Thanks for your help.


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 7/9] mac80211: suppress unchanged "limiting TX power" messages

[Emmanuel Grumbach]

From: Johannes Berg 

When the AP is advertising limited TX power, the message can be
printed over and over again. Suppress it when the power level
isn't changing.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=106011

Signed-off-by: Johannes Berg 
---
 net/mac80211/mlme.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 62c8e4f..31d5881 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1379,21 +1379,26 @@ static u32 ieee80211_handle_pwr_constr(struct 
ieee80211_sub_if_data *sdata,
 */
if (has_80211h_pwr &&
(!has_cisco_pwr || pwr_level_80211h <= pwr_level_cisco)) {
+   new_ap_level = pwr_level_80211h;
+
+   if (sdata->ap_power_level == new_ap_level)
+   return 0;
+
sdata_dbg(sdata,
  "Limiting TX power to %d (%d - %d) dBm as advertised 
by %pM\n",
  pwr_level_80211h, chan_pwr, pwr_reduction_80211h,
  sdata->u.mgd.bssid);
-   new_ap_level = pwr_level_80211h;
} else {  /* has_cisco_pwr is always true here. */
+   new_ap_level = pwr_level_cisco;
+
+   if (sdata->ap_power_level == new_ap_level)
+   return 0;
+
sdata_dbg(sdata,
  "Limiting TX power to %d dBm as advertised by %pM\n",
  pwr_level_cisco, sdata->u.mgd.bssid);
-   new_ap_level = pwr_level_cisco;
}
 
-   if (sdata->ap_power_level == new_ap_level)
-   return 0;
-
sdata->ap_power_level = new_ap_level;
if (__ieee80211_recalc_txpower(sdata))
return BSS_CHANGED_TXPOWER;
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/9] mac80211: process and save VHT MU-MIMO group frame

[Emmanuel Grumbach]

From: Sara Sharon 

The Group ID Management frame is an Action frame of
category VHT. It is transmitted by the AP to assign
or change the user position of a STA for one or more
group IDs.
Process and save the group membership data. Notify
underlying driver of changes.

Signed-off-by: Sara Sharon 
Signed-off-by: Emmanuel Grumbach 
---
 include/linux/ieee80211.h  |  7 +++
 include/net/mac80211.h | 17 +
 net/mac80211/ieee80211_i.h |  2 ++
 net/mac80211/iface.c   | 10 ++
 net/mac80211/mlme.c|  7 +++
 net/mac80211/rx.c  |  5 +
 net/mac80211/util.c|  3 +++
 net/mac80211/vht.c | 25 +
 8 files changed, 76 insertions(+)

diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 452c0b0..d9ddb89 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -843,6 +843,8 @@ enum ieee80211_vht_opmode_bits {
 };
 
 #define WLAN_SA_QUERY_TR_ID_LEN 2
+#define WLAN_MEMBERSHIP_LEN 8
+#define WLAN_USER_POSITION_LEN 16
 
 /**
  * struct ieee80211_tpc_report_ie
@@ -991,6 +993,11 @@ struct ieee80211_mgmt {
} __packed vht_opmode_notif;
struct {
u8 action_code;
+   u8 membership[WLAN_MEMBERSHIP_LEN];
+   u8 position[WLAN_USER_POSITION_LEN];
+   } __packed vht_group_notif;
+   struct {
+   u8 action_code;
u8 dialog_token;
u8 tpc_elem_id;
u8 tpc_elem_length;
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 7c30faf..8da483b 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -298,6 +298,7 @@ struct ieee80211_vif_chanctx_switch {
  * note that this is only called when it changes after the channel
  * context had been assigned.
  * @BSS_CHANGED_OCB: OCB join status changed
+ * @BSS_CHANGED_MU_GROUPS: VHT MU-MIMO group id or user position changed
  */
 enum ieee80211_bss_change {
BSS_CHANGED_ASSOC   = 1<<0,
@@ -323,6 +324,7 @@ enum ieee80211_bss_change {
BSS_CHANGED_BEACON_INFO = 1<<20,
BSS_CHANGED_BANDWIDTH   = 1<<21,
BSS_CHANGED_OCB = 1<<22,
+   BSS_CHANGED_MU_GROUPS   = 1<<23,
 
/* when adding here, make sure to change ieee80211_reconfig */
 };
@@ -436,6 +438,19 @@ struct ieee80211_event {
 };
 
 /**
+ * struct ieee80211_mu_group_data - STA's VHT MU-MIMO group data
+ *
+ * This structure describes the group id data of VHT MU-MIMO
+ *
+ * @membership: 64 bits array - a bit is set if station is member of the group
+ * @position: 2 bits per group id indicating the position in the group
+ */
+struct ieee80211_mu_group_data {
+   u8 membership[WLAN_MEMBERSHIP_LEN];
+   u8 position[WLAN_USER_POSITION_LEN];
+};
+
+/**
  * struct ieee80211_bss_conf - holds the BSS's changing parameters
  *
  * This structure keeps information about a BSS (and an association
@@ -477,6 +492,7 @@ struct ieee80211_event {
  * @enable_beacon: whether beaconing should be enabled or not
  * @chandef: Channel definition for this BSS -- the hardware might be
  * configured a higher bandwidth than this BSS uses, for example.
+ * @mu_group: VHT MU-MIMO group membership data
  * @ht_operation_mode: HT operation mode like in  
ieee80211_ht_operation.
  * This field is only valid when the channel is a wide HT/VHT channel.
  * Note that with TDLS this can be the case (channel is HT, protection must
@@ -535,6 +551,7 @@ struct ieee80211_bss_conf {
s32 cqm_rssi_thold;
u32 cqm_rssi_hyst;
struct cfg80211_chan_def chandef;
+   struct ieee80211_mu_group_data mu_group;
__be32 arp_addr_list[IEEE80211_BSS_ARP_ADDR_LIST_LEN];
int arp_addr_cnt;
bool qos;
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c30b684..582ea86 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1714,6 +1714,8 @@ ieee80211_vht_cap_ie_to_sta_vht_cap(struct 
ieee80211_sub_if_data *sdata,
 enum ieee80211_sta_rx_bandwidth ieee80211_sta_cap_rx_bw(struct sta_info *sta);
 enum ieee80211_sta_rx_bandwidth ieee80211_sta_cur_vht_bw(struct sta_info *sta);
 void ieee80211_sta_set_rx_nss(struct sta_info *sta);
+void ieee80211_process_mu_groups(struct ieee80211_sub_if_data *sdata,
+struct ieee80211_mgmt *mgmt);
 u32 __ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
   struct sta_info *sta, u8 opmode,
   enum ieee80211_band band, bool nss_only);
diff --git 

[PATCH 0/9] various mac80211 / cfg80211 patches

[Emmanuel Grumbach]

Hi Johannes,

This is a mix of a few random things. A few of things seem
to deserved to be merge in mac80211.git, but all this is
based on mac80211-next.git.

Emmanuel Grumbach (1):
  mac80211: limit the A-MSDU Tx based on peer's capabilities

Eyal Shapira (1):
  mac80211: handle width changes from opmode notification IE in beacon

Johannes Berg (4):
  mac80211: document status.freq restrictions
  mac80211: suppress unchanged "limiting TX power" messages
  mac80211: run scan completed work on reconfig failure
  mac80211: reprogram in interface order

Sara Sharon (3):
  mac80211: process and save VHT MU-MIMO group frame
  mac80211: add flag for duplication check
  mac80211: pass aggregation window size to lower level

 include/linux/ieee80211.h  |  26 ++
 include/net/mac80211.h |  43 +++--
 net/mac80211/agg-rx.c  |   2 +-
 net/mac80211/cfg.c |  32 -
 net/mac80211/ht.c  |   5 ++
 net/mac80211/ieee80211_i.h |   6 ++-
 net/mac80211/iface.c   |  10 
 net/mac80211/mlme.c|  24 +++---
 net/mac80211/rx.c  |  11 -
 net/mac80211/util.c| 116 ++---
 net/mac80211/vht.c |  53 ++---
 11 files changed, 254 insertions(+), 74 deletions(-)

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/9] mac80211: handle width changes from opmode notification IE in beacon

[Emmanuel Grumbach]

From: Eyal Shapira 

An AP can send an operating channel width change in a beacon
opmode notification IE as long as there's a change in the nss as
well (See 802.11ac-2013 section 10.41).
So don't limit updating to nss only from an opmode notification IE.

Signed-off-by: Eyal Shapira 
Signed-off-by: Emmanuel Grumbach 
---
 net/mac80211/cfg.c |  3 +--
 net/mac80211/ieee80211_i.h |  4 ++--
 net/mac80211/mlme.c|  2 +-
 net/mac80211/rx.c  |  3 +--
 net/mac80211/vht.c | 10 +++---
 5 files changed, 8 insertions(+), 14 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index b9e2c2f..a90d875 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1198,8 +1198,7 @@ static int sta_apply_parameters(struct ieee80211_local 
*local,
 * rc isn't initialized here yet, so ignore it
 */
__ieee80211_vht_handle_opmode(sdata, sta,
- params->opmode_notif,
- band, false);
+ params->opmode_notif, band);
}
 
if (ieee80211_vif_is_mesh(>vif))
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 582ea86..747402d 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1718,10 +1718,10 @@ void ieee80211_process_mu_groups(struct 
ieee80211_sub_if_data *sdata,
 struct ieee80211_mgmt *mgmt);
 u32 __ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
   struct sta_info *sta, u8 opmode,
-  enum ieee80211_band band, bool nss_only);
+ enum ieee80211_band band);
 void ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
 struct sta_info *sta, u8 opmode,
-enum ieee80211_band band, bool nss_only);
+enum ieee80211_band band);
 void ieee80211_apply_vhtcap_overrides(struct ieee80211_sub_if_data *sdata,
  struct ieee80211_sta_vht_cap *vht_cap);
 void ieee80211_get_vht_mask_from_cap(__le16 vht_cap,
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 1e6b337..62c8e4f 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3584,7 +3584,7 @@ static void ieee80211_rx_mgmt_beacon(struct 
ieee80211_sub_if_data *sdata,
 
if (sta && elems.opmode_notif)
ieee80211_vht_handle_opmode(sdata, sta, *elems.opmode_notif,
-   rx_status->band, true);
+   rx_status->band);
mutex_unlock(>sta_mtx);
 
changed |= ieee80211_handle_pwr_constr(sdata, chan, mgmt,
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 901c72b..fe675d7 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2738,8 +2738,7 @@ ieee80211_rx_h_action(struct ieee80211_rx_data *rx)
opmode = 
mgmt->u.action.u.vht_opmode_notif.operating_mode;
 
ieee80211_vht_handle_opmode(rx->sdata, rx->sta,
-   opmode, status->band,
-   false);
+   opmode, status->band);
goto handled;
}
case WLAN_VHT_ACTION_GROUPID_MGMT: {
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index d2f2ff6..a02525a 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -399,7 +399,7 @@ void ieee80211_sta_set_rx_nss(struct sta_info *sta)
 
 u32 __ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
  struct sta_info *sta, u8 opmode,
- enum ieee80211_band band, bool nss_only)
+ enum ieee80211_band band)
 {
struct ieee80211_local *local = sdata->local;
struct ieee80211_supported_band *sband;
@@ -422,9 +422,6 @@ u32 __ieee80211_vht_handle_opmode(struct 
ieee80211_sub_if_data *sdata,
changed |= IEEE80211_RC_NSS_CHANGED;
}
 
-   if (nss_only)
-   return changed;
-
switch (opmode & IEEE80211_OPMODE_NOTIF_CHANWIDTH_MASK) {
case IEEE80211_OPMODE_NOTIF_CHANWIDTH_20MHZ:
sta->cur_max_bandwidth = IEEE80211_STA_RX_BW_20;
@@ -473,13 +470,12 @@ void ieee80211_process_mu_groups(struct 
ieee80211_sub_if_data *sdata,
 
 void ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
 struct sta_info *sta, u8 opmode,
-enum ieee80211_band band, bool nss_only)
+enum ieee80211_band band)
 {
struct ieee80211_local *local = 

[PATCH 3/9] mac80211: add flag for duplication check

[Emmanuel Grumbach]

From: Sara Sharon 

Add an option for driver to check for packet duplication
by itself.
This is needed for example by the iwlwifi driver which
parallelizes the RX path and does the duplcation check
per queue.

Signed-off-by: Sara Sharon 
Signed-off-by: Emmanuel Grumbach 
---
 include/net/mac80211.h | 2 +-
 net/mac80211/rx.c  | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 71be30d..f4cbad4 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1063,7 +1063,7 @@ enum mac80211_rx_flags {
RX_FLAG_HT_GF   = BIT(13),
RX_FLAG_AMPDU_DETAILS   = BIT(14),
RX_FLAG_PN_VALIDATED= BIT(15),
-   /* bit 16 free */
+   RX_FLAG_DUP_VALIDATED   = BIT(16),
RX_FLAG_AMPDU_LAST_KNOWN= BIT(17),
RX_FLAG_AMPDU_IS_LAST   = BIT(18),
RX_FLAG_AMPDU_DELIM_CRC_ERROR   = BIT(19),
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index c4198d48..901c72b 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1099,6 +1099,9 @@ ieee80211_rx_h_check_dup(struct ieee80211_rx_data *rx)
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)rx->skb->data;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(rx->skb);
 
+   if (status->flag & RX_FLAG_DUP_VALIDATED)
+   return RX_CONTINUE;
+
/*
 * Drop duplicate 802.11 retransmissions
 * (IEEE 802.11-2012: 9.3.2.10 "Duplicate detection and recovery")
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 8/9] mac80211: run scan completed work on reconfig failure

[Emmanuel Grumbach]

From: Johannes Berg 

When reconfiguration during resume fails while a scan is pending
for completion work, that work will never run, and the scan will
be stuck forever. Factor out the code to recover this and call it
also in ieee80211_handle_reconfig_failure().

Signed-off-by: Johannes Berg 
---
 net/mac80211/util.c | 37 ++---
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 4d6130b..1a26ebd 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1644,6 +1644,29 @@ void ieee80211_stop_device(struct ieee80211_local *local)
drv_stop(local);
 }
 
+static void ieee80211_flush_completed_scan(struct ieee80211_local *local,
+  bool aborted)
+{
+   /* It's possible that we don't handle the scan completion in
+* time during suspend, so if it's still marked as completed
+* here, queue the work and flush it to clean things up.
+* Instead of calling the worker function directly here, we
+* really queue it to avoid potential races with other flows
+* scheduling the same work.
+*/
+   if (test_bit(SCAN_COMPLETED, >scanning)) {
+   /* If coming from reconfiguration failure, abort the scan so
+* we don't attempt to continue a partial HW scan - which is
+* possible otherwise if (e.g.) the 2.4 GHz portion was the
+* completed scan, and a 5 GHz portion is still pending.
+*/
+   if (aborted)
+   set_bit(SCAN_ABORTED, >scanning);
+   ieee80211_queue_delayed_work(>hw, >scan_work, 0);
+   flush_delayed_work(>scan_work);
+   }
+}
+
 static void ieee80211_handle_reconfig_failure(struct ieee80211_local *local)
 {
struct ieee80211_sub_if_data *sdata;
@@ -1663,6 +1686,8 @@ static void ieee80211_handle_reconfig_failure(struct 
ieee80211_local *local)
local->suspended = false;
local->in_reconfig = false;
 
+   ieee80211_flush_completed_scan(local, true);
+
/* scheduled scan clearly can't be running any more, but tell
 * cfg80211 and clear local state
 */
@@ -2080,17 +2105,7 @@ int ieee80211_reconfig(struct ieee80211_local *local)
mb();
local->resuming = false;
 
-   /* It's possible that we don't handle the scan completion in
-* time during suspend, so if it's still marked as completed
-* here, queue the work and flush it to clean things up.
-* Instead of calling the worker function directly here, we
-* really queue it to avoid potential races with other flows
-* scheduling the same work.
-*/
-   if (test_bit(SCAN_COMPLETED, >scanning)) {
-   ieee80211_queue_delayed_work(>hw, >scan_work, 0);
-   flush_delayed_work(>scan_work);
-   }
+   ieee80211_flush_completed_scan(local, false);
 
if (local->open_count && !reconfig_due_to_wowlan)
drv_reconfig_complete(local, IEEE80211_RECONFIG_TYPE_SUSPEND);
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ath10k: do not use coherent memory for allocated device memory chunks

[Kalle Valo]

Felix Fietkau  writes:

> Coherent memory is more expensive to allocate (and constrained on some
> architectures where it has to be pre-allocated). It is also completely
> unnecessary, since the host has no reason to even access these allocated
> memory spaces
>
> Signed-off-by: Felix Fietkau 

Applied, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/13] ath9k: add debug messages to aggr/chanctx funcs

[Kalle Valo]

Janusz Dziedzic  writes:

> Add/extend debug messages when chanctx used.
>
> Signed-off-by: Janusz Dziedzic 

Manually applied these patches to ath.git:

05a85a6c42b5 ath9k: remove ath9k_mod_tsf64_tu
02edab5b5f82 ath9k: MCC, print time elapsed between events
a64d876ef7dc ath9k: MCC, add NOA also in case of an AP
b10b7fb31a21 ath9k: P2P_CLIENT, get/set NOA correctly
3edbf0ba0494 ath9k: MCC enable Opportunistic Power Save
c1b7bea038f0 ath9k: setup correct skb priority for nullfunc
631c45f41957 ath9k: use u32 when calculate tsf
b77b59ae8acd ath9k: P2P_CLIENT, send frames after 1ms AP/GO will aprear
60337ed86306 ath9k: queue null frames in case of MCC
2f985539b98b ath9k: print real timer value
58bb9ca84c20 ath9k: add debug messages to aggr/chanctx funcs

These patches are still pending:

[v2,09/13] ath9k: request NOA update when chanctx active
[v2,11/13] ath9k: MCC add sta_ap_ratio module param

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2] ath9k: Simplify and fix eeprom endianness swapping

[Kalle Valo]

Martin Blumenstingl  writes:

> The three eeprom implementations had quite some duplicate code when it
> came to endianness swapping.
> Additionally there was a bug in eeprom_4k and eeprom_9287 which
> prevented the endianness swapping from working correctly, because the
> swapping code was guarded within an "if (!ath9k_hw_use_flash(ah))". In
> eeprom_def this check did not exist, so it seems that eeprom_def was the
> only implementation where endianness swapping worked.
>
> This patch takes the duplicate code and moves it from eeprom_* to
> eeprom.c. The new code is derived from eeprom_def, while taking into
> account the specifics from the other implementations.
>
> Signed-off-by: Martin Blumenstingl 

Applied to ath.git, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ath6kl: Don't print error message when recv is canceled

[Kalle Valo]

Steve deRosier  writes:

> An error message ath6kl_htc_rxmsg_pending_handler isn't appropate for when
> the error is ECANCELED. This could be the result of a perfectly appropriate
> RX cancel due to shutdown or suspend. This allows the right cleanup to
> continue, but without an alarming error message in this particular case.
>
> Signed-off-by: Steve deRosier 

Applied, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ath5k: fix RTS/CTS by using proper rate flags

[Kalle Valo]

Bob Copeland  writes:

> The rates in the tx control rateset do not have the protection
> flags applied, so RTS/CTS would never get enabled if requested.
>
> Fix by using the rate flags in the rates returned by
> ieee80211_get_tx_rates().
>
> Signed-off-by: Bob Copeland 

Applied, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] wil6210: prevent external wmi commands during suspend flow

[Kalle Valo]

Maya Erez  writes:

> In __wmi_send we check if fw is ready at the beginning of the function.
> While we wait for the completion of the previous command, system suspend
> can be invoked and reset the HW, causing __wmi_send to read from HW
> registers while it is not ready.
> Taking the wmi_mutex in the reset flow when setting the FW ready bit
> to zero will prevent the above race condition.
>
> Signed-off-by: Maya Erez 

Applied, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/9] mac80211: handle width changes from opmode notification IE in beacon

[Johannes Berg]

On Tue, 2015-12-08 at 21:08 +0530, Krishna Chaitanya wrote:
> 
> >  void ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data
> > *sdata,
> >  struct sta_info *sta, u8 opmode,
> > -enum ieee80211_band band, bool
> > nss_only)
> > +enum ieee80211_band band)
> >  {
> > struct ieee80211_local *local = sdata->local;
> > struct ieee80211_supported_band *sband = local->hw.wiphy-
> > >bands[band];
> > 
> > -   u32 changed = __ieee80211_vht_handle_opmode(sdata, sta,
> > opmode,
> > -   band,
> > nss_only);
> > +   u32 changed = __ieee80211_vht_handle_opmode(sdata, sta,
> > opmode, band);
> > 
> > if (changed > 0)
> > rate_control_rate_update(local, sband, sta,
> > changed);
> 
> Not related to current change.
> 
> I was looking at this code a while ago and found that
> rate_control_rate_update
> doesn't update the rates from rx_nss, rather it updates from HT/VHT
> capabilities.
> 
> So how does the NSS update from OP MODE IE work?
> 

Huh? You just quoted the code that does this?

If the rate control algorithm doesn't look at sta->sta.rx_nss then
that's their bug.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/9] mac80211: handle width changes from opmode notification IE in beacon

[Johannes Berg]

On Tue, 2015-12-08 at 21:25 +0530, Krishna Chaitanya wrote:
> On Tue, Dec 8, 2015 at 9:23 PM, Johannes Berg  net> wrote:
> > On Tue, 2015-12-08 at 21:17 +0530, Krishna Chaitanya wrote:
> > > 
> > > > If the rate control algorithm doesn't look at sta->sta.rx_nss
> > > > then
> > > > that's their bug.
> > > 
> > > Yes, it looks like it. Only BW is handled, not the NSS change,
> > > and
> > > without this patch OP MODE IE in beacon updates neither NSS nor
> > > BW.
> > > 
> > > For Action frame OP MODE IE, NSS will be updated.
> Typo BW will be updated.

Ok.

> > I don't see how that would happen - they end up in exactly the same
> > code path.
> 
> As nss_only is false, BW will be update in case of action frame.

Well, this patch removes that since the whole concept of nss_only was
wrong.

So basically you're just saying that minstrel should be fixed to look
at rx_nss (and the relevant change bit, perhaps)...

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/9] mac80211: handle width changes from opmode notification IE in beacon

[Johannes Berg]

On Tue, 2015-12-08 at 21:17 +0530, Krishna Chaitanya wrote:
> 
> > If the rate control algorithm doesn't look at sta->sta.rx_nss then
> > that's their bug.
> 
> Yes, it looks like it. Only BW is handled, not the NSS change, and
> without this patch OP MODE IE in beacon updates neither NSS nor BW.
> 
> For Action frame OP MODE IE, NSS will be updated.
> 

I don't see how that would happen - they end up in exactly the same
code path.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] mac80211: pass block ack session timeout to to driver

[Emmanuel Grumbach]

From: Sara Sharon 

Currently mac80211 does not inform the driver of the session
block ack timeout when starting a rx aggregation session.
Drivers that manage the reorder buffer need to know this
parameter.
Seeing that there are now too many arguments for the
drv_ampdu_action() function, wrap them inside a structure.

Signed-off-by: Sara Sharon 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/dvm/mac80211.c |  9 +++--
 drivers/net/wireless/iwlwifi/mvm/mac80211.c | 10 --
 drivers/net/wireless/mac80211_hwsim.c   |  8 +++--
 include/net/mac80211.h  | 44 
 net/mac80211/agg-rx.c   | 25 +++---
 net/mac80211/agg-tx.c   | 53 +++--
 net/mac80211/driver-ops.c   | 10 ++
 net/mac80211/driver-ops.h   |  4 +--
 net/mac80211/trace.h| 41 +++---
 9 files changed, 129 insertions(+), 75 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/dvm/mac80211.c 
b/drivers/net/wireless/iwlwifi/dvm/mac80211.c
index b3ad34e..1eb1a82 100644
--- a/drivers/net/wireless/iwlwifi/dvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/dvm/mac80211.c
@@ -729,12 +729,15 @@ static inline bool iwl_enable_tx_ampdu(const struct 
iwl_cfg *cfg)
 
 static int iwlagn_mac_ampdu_action(struct ieee80211_hw *hw,
   struct ieee80211_vif *vif,
-  enum ieee80211_ampdu_mlme_action action,
-  struct ieee80211_sta *sta, u16 tid, u16 *ssn,
-  u8 buf_size, bool amsdu)
+  struct ieee80211_ampdu_params *params)
 {
struct iwl_priv *priv = IWL_MAC80211_GET_DVM(hw);
int ret = -EINVAL;
+   struct ieee80211_sta *sta = params->sta;
+   enum ieee80211_ampdu_mlme_action action = params->action;
+   u16 tid = params->tid;
+   u16 *ssn = >ssn;
+   u8 buf_size = params->buf_size;
struct iwl_station_priv *sta_priv = (void *) sta->drv_priv;
 
IWL_DEBUG_HT(priv, "A-MPDU action on addr %pM tid %d\n",
diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c 
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index 1fb6846..3b124cf 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -826,13 +826,17 @@ iwl_mvm_ampdu_check_trigger(struct iwl_mvm *mvm, struct 
ieee80211_vif *vif,
 
 static int iwl_mvm_mac_ampdu_action(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
-   enum ieee80211_ampdu_mlme_action action,
-   struct ieee80211_sta *sta, u16 tid,
-   u16 *ssn, u8 buf_size, bool amsdu)
+   struct ieee80211_ampdu_params *params)
 {
struct iwl_mvm *mvm = IWL_MAC80211_GET_MVM(hw);
int ret;
bool tx_agg_ref = false;
+   struct ieee80211_sta *sta = params->sta;
+   enum ieee80211_ampdu_mlme_action action = params->action;
+   u16 tid = params->tid;
+   u16 *ssn = >ssn;
+   u8 buf_size = params->buf_size;
+   bool amsdu = params->amsdu;
 
IWL_DEBUG_HT(mvm, "A-MPDU action on addr %pM tid %d: action %d\n",
 sta->addr, tid, action);
diff --git a/drivers/net/wireless/mac80211_hwsim.c 
b/drivers/net/wireless/mac80211_hwsim.c
index c32889a..e31a94f 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -1845,10 +1845,12 @@ static int mac80211_hwsim_testmode_cmd(struct 
ieee80211_hw *hw,
 
 static int mac80211_hwsim_ampdu_action(struct ieee80211_hw *hw,
   struct ieee80211_vif *vif,
-  enum ieee80211_ampdu_mlme_action action,
-  struct ieee80211_sta *sta, u16 tid, u16 
*ssn,
-  u8 buf_size, bool amsdu)
+  struct ieee80211_ampdu_params *params)
 {
+   struct ieee80211_sta *sta = params->sta;
+   enum ieee80211_ampdu_mlme_action action = params->action;
+   u16 tid = params->tid;
+
switch (action) {
case IEEE80211_AMPDU_TX_START:
ieee80211_start_tx_ba_cb_irqsafe(vif, sta->addr, tid);
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 54af948..0fad29c 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2717,6 +2717,33 @@ enum ieee80211_ampdu_mlme_action {
 };
 
 /**
+ * struct ieee80211_ampdu_params - AMPDU action parameters
+ *
+ * @action: the ampdu action, value from %ieee80211_ampdu_mlme_action.
+ * @sta: peer of this AMPDU session
+ * @tid: tid of the BA session
+ * @ssn: start sequence number of the session. 

[PATCH 2/2] mac80211: support hw managing reorder logic

[Emmanuel Grumbach]

From: Sara Sharon 

Enable driver to manage the reordering logic itself.
This is needed for example for the iwlwifi driver that
supports hardware based reordering.

type=feature

Signed-off-by: Sara Sharon 
Signed-off-by: Emmanuel Grumbach 
---
 include/net/mac80211.h  |  6 ++
 net/mac80211/agg-rx.c   | 24 ++--
 net/mac80211/debugfs.c  |  1 +
 net/mac80211/sta_info.h | 21 -
 4 files changed, 41 insertions(+), 11 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 0fad29c..916c29c 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1943,6 +1943,11 @@ struct ieee80211_txq {
  * by just its MAC address; this prevents, for example, the same station
  * from connecting to two virtual AP interfaces at the same time.
  *
+ * @IEEE80211_HW_SUPPORTS_REORDERING_BUFFER: Hardware (or driver) manages the
+ * reordering buffer internally, guaranteeing mac80211 receives frames in
+ * order and does not need to manage its own reorder buffer or BA session
+ * timeout.
+ *
  * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
  */
 enum ieee80211_hw_flags {
@@ -1979,6 +1984,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_SUPPORTS_AMSDU_IN_AMPDU,
IEEE80211_HW_BEACON_TX_STATUS,
IEEE80211_HW_NEEDS_UNIQUE_STA_ADDR,
+   IEEE80211_HW_SUPPORTS_REORDERING_BUFFER,
 
/* keep last, obviously */
NUM_IEEE80211_HW_FLAGS
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index ec80db7..2ab5479 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -76,10 +76,11 @@ void ___ieee80211_stop_rx_ba_session(struct sta_info *sta, 
u16 tid,
tid_rx = rcu_dereference_protected(sta->ampdu_mlme.tid_rx[tid],
lockdep_is_held(>ampdu_mlme.mtx));
 
-   if (!tid_rx)
+   if (!test_bit(tid, sta->ampdu_mlme.agg_session_valid))
return;
 
RCU_INIT_POINTER(sta->ampdu_mlme.tid_rx[tid], NULL);
+   __clear_bit(tid, sta->ampdu_mlme.agg_session_valid);
 
ht_dbg(sta->sdata,
   "Rx BA session stop requested for %pM tid %u %s reason: %d\n",
@@ -97,6 +98,13 @@ void ___ieee80211_stop_rx_ba_session(struct sta_info *sta, 
u16 tid,
ieee80211_send_delba(sta->sdata, sta->sta.addr,
 tid, WLAN_BACK_RECIPIENT, reason);
 
+   /*
+* return here in case tid_rx is not assigned - which will happen if
+* IEEE80211_HW_SUPPORTS_REORDERING_BUFFER is set.
+*/
+   if (!tid_rx)
+   return;
+
del_timer_sync(_rx->session_timer);
 
/* make sure ieee80211_sta_reorder_release() doesn't re-arm the timer */
@@ -297,7 +305,7 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
/* examine state machine */
mutex_lock(>ampdu_mlme.mtx);
 
-   if (sta->ampdu_mlme.tid_rx[tid]) {
+   if (test_bit(tid, sta->ampdu_mlme.agg_session_valid)) {
ht_dbg_ratelimited(sta->sdata,
   "unexpected AddBA Req from %pM on tid %u\n",
   sta->sta.addr, tid);
@@ -308,6 +316,16 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
false);
}
 
+   if (ieee80211_hw_check(>hw, SUPPORTS_REORDERING_BUFFER)) {
+   ret = drv_ampdu_action(local, sta->sdata, );
+   ht_dbg(sta->sdata,
+  "Rx A-MPDU request on %pM tid %d result %d\n",
+  sta->sta.addr, tid, ret);
+   if (!ret)
+   status = WLAN_STATUS_SUCCESS;
+   goto end;
+   }
+
/* prepare A-MPDU MLME for Rx aggregation */
tid_agg_rx = kmalloc(sizeof(struct tid_ampdu_rx), GFP_KERNEL);
if (!tid_agg_rx)
@@ -369,6 +387,8 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
}
 
 end:
+   if (status == WLAN_STATUS_SUCCESS)
+   __set_bit(tid, sta->ampdu_mlme.agg_session_valid);
mutex_unlock(>ampdu_mlme.mtx);
 
 end_no_lock:
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index abbdff0..e433d0c 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -126,6 +126,7 @@ static const char *hw_flag_names[NUM_IEEE80211_HW_FLAGS + 
1] = {
FLAG(SUPPORTS_AMSDU_IN_AMPDU),
FLAG(BEACON_TX_STATUS),
FLAG(NEEDS_UNIQUE_STA_ADDR),
+   FLAG(SUPPORTS_REORDERING_BUFFER),
 
/* keep last for the build bug below */
(void *)0x1
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index d605162..f4d3899 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -1,6 +1,7 @@
 /*
  * Copyright 2002-2005, Devicescape Software, Inc.
  * Copyright 2013-2014  Intel Mobile Communications GmbH
+ * Copyright(c) 

Re: [PATCH 6/9] mac80211: handle width changes from opmode notification IE in beacon

[Krishna Chaitanya]

On Tue, Dec 8, 2015 at 7:34 PM, Emmanuel Grumbach
 wrote:
>
> From: Eyal Shapira 
>
> An AP can send an operating channel width change in a beacon
> opmode notification IE as long as there's a change in the nss as
> well (See 802.11ac-2013 section 10.41).
> So don't limit updating to nss only from an opmode notification IE.
>
> Signed-off-by: Eyal Shapira 
> Signed-off-by: Emmanuel Grumbach 
> ---
>  net/mac80211/cfg.c |  3 +--
>  net/mac80211/ieee80211_i.h |  4 ++--
>  net/mac80211/mlme.c|  2 +-
>  net/mac80211/rx.c  |  3 +--
>  net/mac80211/vht.c | 10 +++---
>  5 files changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index b9e2c2f..a90d875 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -1198,8 +1198,7 @@ static int sta_apply_parameters(struct ieee80211_local 
> *local,
>  * rc isn't initialized here yet, so ignore it
>  */
> __ieee80211_vht_handle_opmode(sdata, sta,
> - params->opmode_notif,
> - band, false);
> + params->opmode_notif, band);
> }
>
> if (ieee80211_vif_is_mesh(>vif))
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index 582ea86..747402d 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -1718,10 +1718,10 @@ void ieee80211_process_mu_groups(struct 
> ieee80211_sub_if_data *sdata,
>  struct ieee80211_mgmt *mgmt);
>  u32 __ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
>struct sta_info *sta, u8 opmode,
> -  enum ieee80211_band band, bool nss_only);
> + enum ieee80211_band band);
>  void ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
>  struct sta_info *sta, u8 opmode,
> -enum ieee80211_band band, bool nss_only);
> +enum ieee80211_band band);
>  void ieee80211_apply_vhtcap_overrides(struct ieee80211_sub_if_data *sdata,
>   struct ieee80211_sta_vht_cap *vht_cap);
>  void ieee80211_get_vht_mask_from_cap(__le16 vht_cap,
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 1e6b337..62c8e4f 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -3584,7 +3584,7 @@ static void ieee80211_rx_mgmt_beacon(struct 
> ieee80211_sub_if_data *sdata,
>
> if (sta && elems.opmode_notif)
> ieee80211_vht_handle_opmode(sdata, sta, *elems.opmode_notif,
> -   rx_status->band, true);
> +   rx_status->band);
> mutex_unlock(>sta_mtx);
>
> changed |= ieee80211_handle_pwr_constr(sdata, chan, mgmt,
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index 901c72b..fe675d7 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -2738,8 +2738,7 @@ ieee80211_rx_h_action(struct ieee80211_rx_data *rx)
> opmode = 
> mgmt->u.action.u.vht_opmode_notif.operating_mode;
>
> ieee80211_vht_handle_opmode(rx->sdata, rx->sta,
> -   opmode, status->band,
> -   false);
> +   opmode, status->band);
> goto handled;
> }
> case WLAN_VHT_ACTION_GROUPID_MGMT: {
> diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
> index d2f2ff6..a02525a 100644
> --- a/net/mac80211/vht.c
> +++ b/net/mac80211/vht.c
> @@ -399,7 +399,7 @@ void ieee80211_sta_set_rx_nss(struct sta_info *sta)
>
>  u32 __ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
>   struct sta_info *sta, u8 opmode,
> - enum ieee80211_band band, bool nss_only)
> + enum ieee80211_band band)
>  {
> struct ieee80211_local *local = sdata->local;
> struct ieee80211_supported_band *sband;
> @@ -422,9 +422,6 @@ u32 __ieee80211_vht_handle_opmode(struct 
> ieee80211_sub_if_data *sdata,
> changed |= IEEE80211_RC_NSS_CHANGED;
> }
>
> -   if (nss_only)
> -   return changed;
> -
> switch (opmode & IEEE80211_OPMODE_NOTIF_CHANWIDTH_MASK) {
> case IEEE80211_OPMODE_NOTIF_CHANWIDTH_20MHZ:
> sta->cur_max_bandwidth = IEEE80211_STA_RX_BW_20;
> @@ -473,13 +470,12 @@ void ieee80211_process_mu_groups(struct 
> ieee80211_sub_if_data *sdata,
>
>  void 

Re: [PATCH 6/9] mac80211: handle width changes from opmode notification IE in beacon

[Krishna Chaitanya]

On Tue, Dec 8, 2015 at 9:23 PM, Johannes Berg  wrote:
> On Tue, 2015-12-08 at 21:17 +0530, Krishna Chaitanya wrote:
>>
>> > If the rate control algorithm doesn't look at sta->sta.rx_nss then
>> > that's their bug.
>>
>> Yes, it looks like it. Only BW is handled, not the NSS change, and
>> without this patch OP MODE IE in beacon updates neither NSS nor BW.
>>
>> For Action frame OP MODE IE, NSS will be updated.
Typo BW will be updated.
>
> I don't see how that would happen - they end up in exactly the same
> code path.

As nss_only is false, BW will be update in case of action frame.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] mac80211: limit the A-MSDU Tx based on peer's capabilities

[Krishna Chaitanya]

On Tue, Dec 8, 2015 at 7:34 PM, Emmanuel Grumbach
 wrote:
> index 7a76ce6..f4a5287 100644
> --- a/net/mac80211/ht.c
> +++ b/net/mac80211/ht.c
> @@ -230,6 +230,11 @@ bool ieee80211_ht_cap_ie_to_sta_ht_cap(struct 
> ieee80211_sub_if_data *sdata,
> /* set Rx highest rate */
> ht_cap.mcs.rx_highest = ht_cap_ie->mcs.rx_highest;
>
> +   if (ht_cap.cap & IEEE80211_HT_CAP_MAX_AMSDU)
> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_HT_7935;
> +   else
> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_HT_3839;
> +
>   apply:
> changed = memcmp(>sta.ht_cap, _cap, sizeof(ht_cap));
>
> diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
> index 92c9843..d2f2ff6 100644
> --- a/net/mac80211/vht.c
> +++ b/net/mac80211/vht.c
> @@ -281,6 +281,24 @@ ieee80211_vht_cap_ie_to_sta_vht_cap(struct 
> ieee80211_sub_if_data *sdata,
> }
>
> sta->sta.bandwidth = ieee80211_sta_cur_vht_bw(sta);
> +
> +   /* If HT IE reported 3839 bytes only, stay with that size. */
> +   if (sta->sta.max_amsdu_len == IEEE80211_MAX_MPDU_LEN_HT_3839)
> +   return;
> +
> +   switch (vht_cap->cap & IEEE80211_VHT_CAP_MAX_MPDU_MASK) {
> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454:
> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_11454;
> +   break;
> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991:
> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_7991;
> +   break;
> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895:
> +   default:
> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_3895;
> +   break;
> +   }
Ideally speaking shouldn't we use different variables for HT and VHT
and depending on
rate HT/VHT we should aggregate accordingly? of course that will be
tricky as we dont
have the rate control info at the time of aggregation. Standard is
clear about usage of
independent lengths depending on whether its an VHT/HT PPDU.

If we use the same variable to arrive at max_amsdu_len for both VHT
and HT, we might
end up sending 11454 sized MSDU in a HT rate.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/9] mac80211: handle width changes from opmode notification IE in beacon

[Krishna Chaitanya]

On Tue, Dec 8, 2015 at 9:28 PM, Johannes Berg  wrote:
> On Tue, 2015-12-08 at 21:25 +0530, Krishna Chaitanya wrote:
>> On Tue, Dec 8, 2015 at 9:23 PM, Johannes Berg > net> wrote:
>> > On Tue, 2015-12-08 at 21:17 +0530, Krishna Chaitanya wrote:
>> > >
>> > > > If the rate control algorithm doesn't look at sta->sta.rx_nss
>> > > > then
>> > > > that's their bug.
>> > >
>> > > Yes, it looks like it. Only BW is handled, not the NSS change,
>> > > and
>> > > without this patch OP MODE IE in beacon updates neither NSS nor
>> > > BW.
>> > >
>> > > For Action frame OP MODE IE, NSS will be updated.
>> Typo BW will be updated.
>
> Ok.
>
>> > I don't see how that would happen - they end up in exactly the same
>> > code path.
>>
>> As nss_only is false, BW will be update in case of action frame.
>
> Well, this patch removes that since the whole concept of nss_only was
> wrong.
>
> So basically you're just saying that minstrel should be fixed to look
> at rx_nss (and the relevant change bit, perhaps)...
>
Exactly :-).
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] mac80211: limit the A-MSDU Tx based on peer's capabilities

[Grumbach, Emmanuel]

On 12/08/2015 06:03 PM, Krishna Chaitanya wrote:
> On Tue, Dec 8, 2015 at 7:34 PM, Emmanuel Grumbach
>  wrote:
>> index 7a76ce6..f4a5287 100644
>> --- a/net/mac80211/ht.c
>> +++ b/net/mac80211/ht.c
>> @@ -230,6 +230,11 @@ bool ieee80211_ht_cap_ie_to_sta_ht_cap(struct 
>> ieee80211_sub_if_data *sdata,
>> /* set Rx highest rate */
>> ht_cap.mcs.rx_highest = ht_cap_ie->mcs.rx_highest;
>>
>> +   if (ht_cap.cap & IEEE80211_HT_CAP_MAX_AMSDU)
>> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_HT_7935;
>> +   else
>> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_HT_3839;
>> +
>>   apply:
>> changed = memcmp(>sta.ht_cap, _cap, sizeof(ht_cap));
>>
>> diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
>> index 92c9843..d2f2ff6 100644
>> --- a/net/mac80211/vht.c
>> +++ b/net/mac80211/vht.c
>> @@ -281,6 +281,24 @@ ieee80211_vht_cap_ie_to_sta_vht_cap(struct 
>> ieee80211_sub_if_data *sdata,
>> }
>>
>> sta->sta.bandwidth = ieee80211_sta_cur_vht_bw(sta);
>> +
>> +   /* If HT IE reported 3839 bytes only, stay with that size. */
>> +   if (sta->sta.max_amsdu_len == IEEE80211_MAX_MPDU_LEN_HT_3839)
>> +   return;
>> +
>> +   switch (vht_cap->cap & IEEE80211_VHT_CAP_MAX_MPDU_MASK) {
>> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454:
>> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_11454;
>> +   break;
>> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991:
>> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_7991;
>> +   break;
>> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895:
>> +   default:
>> +   sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_3895;
>> +   break;
>> +   }
> Ideally speaking shouldn't we use different variables for HT and VHT
> and depending on
> rate HT/VHT we should aggregate accordingly? of course that will be
> tricky as we dont
> have the rate control info at the time of aggregation. Standard is
> clear about usage of
> independent lengths depending on whether its an VHT/HT PPDU.

Yes - but since it is tricky, I preferred to be on the safe side and
limit VHT amsdus for the very peculiar AP that would decide to have
large A-MSDUs in VHT and small ones in HT (?!).

> If we use the same variable to arrive at max_amsdu_len for both VHT
> and HT, we might
> end up sending 11454 sized MSDU in a HT rate.
>
And since that can't be handled at the time of the A-MSDU building,
leave that to another entity :)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] mac80211: limit the A-MSDU Tx based on peer's capabilities

[Grumbach, Emmanuel]

On 12/08/2015 06:35 PM, Krishna Chaitanya wrote:
>
>
> On Dec 8, 2015 10:01 PM, "Grumbach, Emmanuel"
> > wrote:
> >
> >
> >
> > On 12/08/2015 06:03 PM, Krishna Chaitanya wrote:
> > > On Tue, Dec 8, 2015 at 7:34 PM, Emmanuel Grumbach
> > > >
> wrote:
> > >> index 7a76ce6..f4a5287 100644
> > >> --- a/net/mac80211/ht.c
> > >> +++ b/net/mac80211/ht.c
> > >> @@ -230,6 +230,11 @@ bool
> ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_sub_if_data *sdata,
> > >> /* set Rx highest rate */
> > >> ht_cap.mcs.rx_highest = ht_cap_ie->mcs.rx_highest;
> > >>
> > >> +   if (ht_cap.cap & IEEE80211_HT_CAP_MAX_AMSDU)
> > >> +   sta->sta.max_amsdu_len =
> IEEE80211_MAX_MPDU_LEN_HT_7935;
> > >> +   else
> > >> +   sta->sta.max_amsdu_len =
> IEEE80211_MAX_MPDU_LEN_HT_3839;
> > >> +
> > >>   apply:
> > >> changed = memcmp(>sta.ht_cap, _cap, sizeof(ht_cap));
> > >>
> > >> diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
> > >> index 92c9843..d2f2ff6 100644
> > >> --- a/net/mac80211/vht.c
> > >> +++ b/net/mac80211/vht.c
> > >> @@ -281,6 +281,24 @@ ieee80211_vht_cap_ie_to_sta_vht_cap(struct
> ieee80211_sub_if_data *sdata,
> > >> }
> > >>
> > >> sta->sta.bandwidth = ieee80211_sta_cur_vht_bw(sta);
> > >> +
> > >> +   /* If HT IE reported 3839 bytes only, stay with that size. */
> > >> +   if (sta->sta.max_amsdu_len == IEEE80211_MAX_MPDU_LEN_HT_3839)
> > >> +   return;
> > >> +
> > >> +   switch (vht_cap->cap & IEEE80211_VHT_CAP_MAX_MPDU_MASK) {
> > >> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454:
> > >> +   sta->sta.max_amsdu_len =
> IEEE80211_MAX_MPDU_LEN_VHT_11454;
> > >> +   break;
> > >> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991:
> > >> +   sta->sta.max_amsdu_len =
> IEEE80211_MAX_MPDU_LEN_VHT_7991;
> > >> +   break;
> > >> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895:
> > >> +   default:
> > >> +   sta->sta.max_amsdu_len =
> IEEE80211_MAX_MPDU_LEN_VHT_3895;
> > >> +   break;
> > >> +   }
> > > Ideally speaking shouldn't we use different variables for HT and VHT
> > > and depending on
> > > rate HT/VHT we should aggregate accordingly? of course that will be
> > > tricky as we dont
> > > have the rate control info at the time of aggregation. Standard is
> > > clear about usage of
> > > independent lengths depending on whether its an VHT/HT PPDU.
> >
> > Yes - but since it is tricky, I preferred to be on the safe side and
> > limit VHT amsdus for the very peculiar AP that would decide to have
> > large A-MSDUs in VHT and small ones in HT (?!).
> Yes but wouldn't it be safer to just use min(ht , vht)? For a good AP
> it shouldn't matter and bad AP it will still work.
>
This is the de-facto what this code does I think.
If the HT limit is 4K, then don't even take the VHT limit into account
and the VHT limit can't be smaller than the HT one in that case.
If the HT limit is 8K, then we can limit it further to 4K in case VHT
has a limit of 4K (which is another weird case), but we can also make it
larger for VHT frames?

So I don't really see the bug here, am I missing something?

> > > If we use the same variable to arrive at max_amsdu_len for both VHT
> > > and HT, we might
> > > end up sending 11454 sized MSDU in a HT rate.
> > >
> > And since that can't be handled at the time of the A-MSDU building,
> > leave that to another entity :)
>

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/9] mac80211: handle width changes from opmode notification IE in beacon

[Krishna Chaitanya]

On Tue, Dec 8, 2015 at 9:12 PM, Johannes Berg  wrote:
> On Tue, 2015-12-08 at 21:08 +0530, Krishna Chaitanya wrote:
>>
>> >  void ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data
>> > *sdata,
>> >  struct sta_info *sta, u8 opmode,
>> > -enum ieee80211_band band, bool
>> > nss_only)
>> > +enum ieee80211_band band)
>> >  {
>> > struct ieee80211_local *local = sdata->local;
>> > struct ieee80211_supported_band *sband = local->hw.wiphy-
>> > >bands[band];
>> >
>> > -   u32 changed = __ieee80211_vht_handle_opmode(sdata, sta,
>> > opmode,
>> > -   band,
>> > nss_only);
>> > +   u32 changed = __ieee80211_vht_handle_opmode(sdata, sta,
>> > opmode, band);
>> >
>> > if (changed > 0)
>> > rate_control_rate_update(local, sband, sta,
>> > changed);
>>
>> Not related to current change.
>>
>> I was looking at this code a while ago and found that
>> rate_control_rate_update
>> doesn't update the rates from rx_nss, rather it updates from HT/VHT
>> capabilities.
>>
>> So how does the NSS update from OP MODE IE work?
>>
>
> Huh? You just quoted the code that does this?
MLME is updating the rx_nss.

> If the rate control algorithm doesn't look at sta->sta.rx_nss then
> that's their bug.

Yes, it looks like it. Only BW is handled, not the NSS change, and
without this patch OP MODE IE in beacon updates neither NSS nor BW.

For Action frame OP MODE IE, NSS will be updated.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] mac80211: support hw managing reorder logic

[Grumbach, Emmanuel]

On 12/08/2015 07:09 PM, Grumbach, Emmanuel wrote:
> From: Sara Sharon 
>
> Enable driver to manage the reordering logic itself.
> This is needed for example for the iwlwifi driver that
> supports hardware based reordering.
>
> type=feature

Ouch - sorry for that. I guess you'll edit? Or you want me to resend?

> Signed-off-by: Sara Sharon 
> Signed-off-by: Emmanuel Grumbach 
> ---
>  include/net/mac80211.h  |  6 ++
>  net/mac80211/agg-rx.c   | 24 ++--
>  net/mac80211/debugfs.c  |  1 +
>  net/mac80211/sta_info.h | 21 -
>  4 files changed, 41 insertions(+), 11 deletions(-)
>
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index 0fad29c..916c29c 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -1943,6 +1943,11 @@ struct ieee80211_txq {
>   *   by just its MAC address; this prevents, for example, the same station
>   *   from connecting to two virtual AP interfaces at the same time.
>   *
> + * @IEEE80211_HW_SUPPORTS_REORDERING_BUFFER: Hardware (or driver) manages the
> + *   reordering buffer internally, guaranteeing mac80211 receives frames in
> + *   order and does not need to manage its own reorder buffer or BA session
> + *   timeout.
> + *
>   * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
>   */
>  enum ieee80211_hw_flags {
> @@ -1979,6 +1984,7 @@ enum ieee80211_hw_flags {
>   IEEE80211_HW_SUPPORTS_AMSDU_IN_AMPDU,
>   IEEE80211_HW_BEACON_TX_STATUS,
>   IEEE80211_HW_NEEDS_UNIQUE_STA_ADDR,
> + IEEE80211_HW_SUPPORTS_REORDERING_BUFFER,
>  
>   /* keep last, obviously */
>   NUM_IEEE80211_HW_FLAGS
> diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
> index ec80db7..2ab5479 100644
> --- a/net/mac80211/agg-rx.c
> +++ b/net/mac80211/agg-rx.c
> @@ -76,10 +76,11 @@ void ___ieee80211_stop_rx_ba_session(struct sta_info 
> *sta, u16 tid,
>   tid_rx = rcu_dereference_protected(sta->ampdu_mlme.tid_rx[tid],
>   lockdep_is_held(>ampdu_mlme.mtx));
>  
> - if (!tid_rx)
> + if (!test_bit(tid, sta->ampdu_mlme.agg_session_valid))
>   return;
>  
>   RCU_INIT_POINTER(sta->ampdu_mlme.tid_rx[tid], NULL);
> + __clear_bit(tid, sta->ampdu_mlme.agg_session_valid);
>  
>   ht_dbg(sta->sdata,
>  "Rx BA session stop requested for %pM tid %u %s reason: %d\n",
> @@ -97,6 +98,13 @@ void ___ieee80211_stop_rx_ba_session(struct sta_info *sta, 
> u16 tid,
>   ieee80211_send_delba(sta->sdata, sta->sta.addr,
>tid, WLAN_BACK_RECIPIENT, reason);
>  
> + /*
> +  * return here in case tid_rx is not assigned - which will happen if
> +  * IEEE80211_HW_SUPPORTS_REORDERING_BUFFER is set.
> +  */
> + if (!tid_rx)
> + return;
> +
>   del_timer_sync(_rx->session_timer);
>  
>   /* make sure ieee80211_sta_reorder_release() doesn't re-arm the timer */
> @@ -297,7 +305,7 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
>   /* examine state machine */
>   mutex_lock(>ampdu_mlme.mtx);
>  
> - if (sta->ampdu_mlme.tid_rx[tid]) {
> + if (test_bit(tid, sta->ampdu_mlme.agg_session_valid)) {
>   ht_dbg_ratelimited(sta->sdata,
>  "unexpected AddBA Req from %pM on tid %u\n",
>  sta->sta.addr, tid);
> @@ -308,6 +316,16 @@ void __ieee80211_start_rx_ba_session(struct sta_info 
> *sta,
>   false);
>   }
>  
> + if (ieee80211_hw_check(>hw, SUPPORTS_REORDERING_BUFFER)) {
> + ret = drv_ampdu_action(local, sta->sdata, );
> + ht_dbg(sta->sdata,
> +"Rx A-MPDU request on %pM tid %d result %d\n",
> +sta->sta.addr, tid, ret);
> + if (!ret)
> + status = WLAN_STATUS_SUCCESS;
> + goto end;
> + }
> +
>   /* prepare A-MPDU MLME for Rx aggregation */
>   tid_agg_rx = kmalloc(sizeof(struct tid_ampdu_rx), GFP_KERNEL);
>   if (!tid_agg_rx)
> @@ -369,6 +387,8 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
>   }
>  
>  end:
> + if (status == WLAN_STATUS_SUCCESS)
> + __set_bit(tid, sta->ampdu_mlme.agg_session_valid);
>   mutex_unlock(>ampdu_mlme.mtx);
>  
>  end_no_lock:
> diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
> index abbdff0..e433d0c 100644
> --- a/net/mac80211/debugfs.c
> +++ b/net/mac80211/debugfs.c
> @@ -126,6 +126,7 @@ static const char *hw_flag_names[NUM_IEEE80211_HW_FLAGS + 
> 1] = {
>   FLAG(SUPPORTS_AMSDU_IN_AMPDU),
>   FLAG(BEACON_TX_STATUS),
>   FLAG(NEEDS_UNIQUE_STA_ADDR),
> + FLAG(SUPPORTS_REORDERING_BUFFER),
>  
>   /* keep last for the build bug below */
>   (void *)0x1
> diff --git a/net/mac80211/sta_info.h 

Re: pull-request: wireless-drivers-next 2015-12-07

[David Miller]

From: Kalle Valo 
Date: Mon, 07 Dec 2015 19:46:45 +0200

> here's the first "real" pull request after the wireless directory
> reorganisation. Nothing really out ordinary, new features and bugfixes
> as usual. This time there's a regression in ath10k because of a bugfix
> in wireless-drivers.git which conflicted with a patch in
> wireless-drivers-next.git. But it should be easy to fix, just follow
> what Stephen did in in linux-next:
> 
> http://article.gmane.org/gmane.linux.kernel.next/37391
> 
> Please let me know if you have any problems.

Pulled, thanks for the heads-up about the conflicts.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] mac80211: limit the A-MSDU Tx based on peer's capabilities

[Grumbach, Emmanuel]

On 12/08/2015 09:11 PM, Krishna Chaitanya wrote:
>
>
> On Dec 9, 2015 12:37 AM, "Grumbach, Emmanuel"
> > wrote:
> >
> >
> >
> > On 12/08/2015 07:49 PM, Krishna Chaitanya wrote:
> > >
> > >
> > > On Dec 8, 2015 10:13 PM, "Grumbach, Emmanuel"
> > > 
>  >> wrote:
> > > >
> > > >
> > > >
> > > > On 12/08/2015 06:35 PM, Krishna Chaitanya wrote:
> > > > >
> > > > >
> > > > > On Dec 8, 2015 10:01 PM, "Grumbach, Emmanuel"
> > > > >  
> >
> > >  
> > >   > > > > >
> > > > > >
> > > > > >
> > > > > > On 12/08/2015 06:03 PM, Krishna Chaitanya wrote:
> > > > > > > On Tue, Dec 8, 2015 at 7:34 PM, Emmanuel Grumbach
> > > > > > >  
> > >  >
> > >  
>   > > > > wrote:
> > > > > > >> index 7a76ce6..f4a5287 100644
> > > > > > >> --- a/net/mac80211/ht.c
> > > > > > >> +++ b/net/mac80211/ht.c
> > > > > > >> @@ -230,6 +230,11 @@ bool
> > > > > ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_sub_if_data
> *sdata,
> > > > > > >> /* set Rx highest rate */
> > > > > > >> ht_cap.mcs.rx_highest = ht_cap_ie->mcs.rx_highest;
> > > > > > >>
> > > > > > >> +   if (ht_cap.cap & IEEE80211_HT_CAP_MAX_AMSDU)
> > > > > > >> +   sta->sta.max_amsdu_len =
> > > > > IEEE80211_MAX_MPDU_LEN_HT_7935;
> > > > > > >> +   else
> > > > > > >> +   sta->sta.max_amsdu_len =
> > > > > IEEE80211_MAX_MPDU_LEN_HT_3839;
> > > > > > >> +
> > > > > > >>   apply:
> > > > > > >> changed = memcmp(>sta.ht_cap, _cap,
> > > sizeof(ht_cap));
> > > > > > >>
> > > > > > >> diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
> > > > > > >> index 92c9843..d2f2ff6 100644
> > > > > > >> --- a/net/mac80211/vht.c
> > > > > > >> +++ b/net/mac80211/vht.c
> > > > > > >> @@ -281,6 +281,24 @@
> ieee80211_vht_cap_ie_to_sta_vht_cap(struct
> > > > > ieee80211_sub_if_data *sdata,
> > > > > > >> }
> > > > > > >>
> > > > > > >> sta->sta.bandwidth = ieee80211_sta_cur_vht_bw(sta);
> > > > > > >> +
> > > > > > >> +   /* If HT IE reported 3839 bytes only, stay with that
> > > size. */
> > > > > > >> +   if (sta->sta.max_amsdu_len ==
> > > IEEE80211_MAX_MPDU_LEN_HT_3839)
> > > > > > >> +   return;
> > > > > > >> +
> > > > > > >> +   switch (vht_cap->cap &
> IEEE80211_VHT_CAP_MAX_MPDU_MASK) {
> > > > > > >> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454:
> > > > > > >> +   sta->sta.max_amsdu_len =
> > > > > IEEE80211_MAX_MPDU_LEN_VHT_11454;
> > > > > > >> +   break;
> > > > > > >> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991:
> > > > > > >> +   sta->sta.max_amsdu_len =
> > > > > IEEE80211_MAX_MPDU_LEN_VHT_7991;
> > > > > > >> +   break;
> > > > > > >> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895:
> > > > > > >> +   default:
> > > > > > >> +   sta->sta.max_amsdu_len =
> > > > > IEEE80211_MAX_MPDU_LEN_VHT_3895;
> > > > > > >> +   break;
> > > > > > >> +   }
> > > > > > > Ideally speaking shouldn't we use different variables for HT
> > > and VHT
> > > > > > > and depending on
> > > > > > > rate HT/VHT we should aggregate accordingly? of course that
> > > will be
> > > > > > > tricky as we dont
> > > > > > > have the rate control info at the time of aggregation.
> Standard is
> > > > > > > clear about usage of
> > > > > > > independent lengths depending on whether its an VHT/HT PPDU.
> > > > > >
> > > > > > Yes - but since it is tricky, I preferred to be on the safe
> side and
> > > > > > limit VHT amsdus for the very peculiar AP that would decide
> to have
> > > > > > large A-MSDUs in VHT and small ones in HT (?!).
> > > > > Yes but wouldn't it be safer to just use min(ht , vht)? For a
> good AP
> > > > > it shouldn't matter and bad AP it will still work.
> > > > >
> > > > This is the de-facto what this code does I think.
> > > > If the HT limit is 4K, then don't even take the VHT limit into
> account
> > > > and the VHT limit can't be smaller than the HT one in that case.
> > > > If the HT limit is 8K, then we can limit it further to 4K in
> case VHT
> > > > has a limit of 4K (which is another weird case), but we can also
> make it
> > > > larger for VHT frames?
> > > >
> > > > So I don't really see the bug here, am I 

[PATCH] ath9k: fix inconsistent indenting on return statement

[Colin King]

From: Colin Ian King 

minor change, indenting is one tab out.

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index 3e3dac3..f796d90 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2894,7 +2894,7 @@ int ath9k_tx99_send(struct ath_softc *sc, struct sk_buff 
*skb,
if (skb_headroom(skb) < padsize) {
ath_dbg(common, XMIT,
"tx99 padding failed\n");
-   return -EINVAL;
+   return -EINVAL;
}
 
skb_push(skb, padsize);
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mtd: bcm47xxnflash: really unregister NAND on device removal

[Brian Norris]

The field bcma_nflash::mtd is never set to be non-zero anywhere, but we
test for it in the removal path. So the MTD is never unregistered.

Also, we should use nand_release(), not mtd_device_unregister().

Finally, we don't need to use the 'platdata' for stashing/retrieving our
*driver* data -- that's what *_{get,set}_drvdata() are for.

So, kill off bcm_nflash::mtd, and stash the struct bcm47xxnflash in
drvdata instead. Also move the forward declaration of mtd_info up a bit,
since struct bcma_sflash should be using it.

Caught while inspecting other changes being made to this driver. Compile
tested only.

Signed-off-by: Brian Norris 
Cc: "Rafał Miłecki" 
Cc: linux-wireless@vger.kernel.org
---
Might have some small conflict with Boris' NAND/MTD refactoring patch set. I
can rebase this small one if his gets in proper shape. Just wanted to get this
out there.

 drivers/mtd/nand/bcm47xxnflash/main.c   | 7 ---
 include/linux/bcma/bcma_driver_chipcommon.h | 6 ++
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/bcm47xxnflash/main.c 
b/drivers/mtd/nand/bcm47xxnflash/main.c
index 9ba0c0f2cd9b..0b3acc439181 100644
--- a/drivers/mtd/nand/bcm47xxnflash/main.c
+++ b/drivers/mtd/nand/bcm47xxnflash/main.c
@@ -49,6 +49,8 @@ static int bcm47xxnflash_probe(struct platform_device *pdev)
return err;
}
 
+   platform_set_drvdata(pdev, b47n);
+
err = mtd_device_parse_register(>mtd, probes, NULL, NULL, 0);
if (err) {
pr_err("Failed to register MTD device: %d\n", err);
@@ -60,10 +62,9 @@ static int bcm47xxnflash_probe(struct platform_device *pdev)
 
 static int bcm47xxnflash_remove(struct platform_device *pdev)
 {
-   struct bcma_nflash *nflash = dev_get_platdata(>dev);
+   struct bcm47xxnflash *nflash = platform_get_drvdata(pdev);
 
-   if (nflash->mtd)
-   mtd_device_unregister(nflash->mtd);
+   nand_release(>mtd);
 
return 0;
 }
diff --git a/include/linux/bcma/bcma_driver_chipcommon.h 
b/include/linux/bcma/bcma_driver_chipcommon.h
index cf038431a5cc..db51a6ffb7d6 100644
--- a/include/linux/bcma/bcma_driver_chipcommon.h
+++ b/include/linux/bcma/bcma_driver_chipcommon.h
@@ -579,6 +579,8 @@ struct bcma_pflash {
 };
 
 #ifdef CONFIG_BCMA_SFLASH
+struct mtd_info;
+
 struct bcma_sflash {
bool present;
u32 window;
@@ -592,13 +594,9 @@ struct bcma_sflash {
 #endif
 
 #ifdef CONFIG_BCMA_NFLASH
-struct mtd_info;
-
 struct bcma_nflash {
bool present;
bool boot;  /* This is the flash the SoC boots from */
-
-   struct mtd_info *mtd;
 };
 #endif
 
-- 
2.6.0.rc2.230.g3dd15c0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] mac80211: limit the A-MSDU Tx based on peer's capabilities

[Krishna Chaitanya]

On Wed, Dec 9, 2015 at 12:52 AM, Grumbach, Emmanuel
 wrote:
>
>
> On 12/08/2015 09:11 PM, Krishna Chaitanya wrote:
>>
>>
>> On Dec 9, 2015 12:37 AM, "Grumbach, Emmanuel"
>> > wrote:
>> >
>> >
>> >
>> > On 12/08/2015 07:49 PM, Krishna Chaitanya wrote:
>> > >
>> > >
>> > > On Dec 8, 2015 10:13 PM, "Grumbach, Emmanuel"
>> > > 
>> > >> wrote:
>> > > >
>> > > >
>> > > >
>> > > > On 12/08/2015 06:35 PM, Krishna Chaitanya wrote:
>> > > > >
>> > > > >
>> > > > > On Dec 8, 2015 10:01 PM, "Grumbach, Emmanuel"
>> > > > > > 
>> >
>> > > > 
>> > > > > > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On 12/08/2015 06:03 PM, Krishna Chaitanya wrote:
>> > > > > > > On Tue, Dec 8, 2015 at 7:34 PM, Emmanuel Grumbach
>> > > > > > > > 
>> > > > >
>> > > > 
>> > > > > > > wrote:
>> > > > > > >> index 7a76ce6..f4a5287 100644
>> > > > > > >> --- a/net/mac80211/ht.c
>> > > > > > >> +++ b/net/mac80211/ht.c
>> > > > > > >> @@ -230,6 +230,11 @@ bool
>> > > > > ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_sub_if_data
>> *sdata,
>> > > > > > >> /* set Rx highest rate */
>> > > > > > >> ht_cap.mcs.rx_highest = ht_cap_ie->mcs.rx_highest;
>> > > > > > >>
>> > > > > > >> +   if (ht_cap.cap & IEEE80211_HT_CAP_MAX_AMSDU)
>> > > > > > >> +   sta->sta.max_amsdu_len =
>> > > > > IEEE80211_MAX_MPDU_LEN_HT_7935;
>> > > > > > >> +   else
>> > > > > > >> +   sta->sta.max_amsdu_len =
>> > > > > IEEE80211_MAX_MPDU_LEN_HT_3839;
>> > > > > > >> +
>> > > > > > >>   apply:
>> > > > > > >> changed = memcmp(>sta.ht_cap, _cap,
>> > > sizeof(ht_cap));
>> > > > > > >>
>> > > > > > >> diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
>> > > > > > >> index 92c9843..d2f2ff6 100644
>> > > > > > >> --- a/net/mac80211/vht.c
>> > > > > > >> +++ b/net/mac80211/vht.c
>> > > > > > >> @@ -281,6 +281,24 @@
>> ieee80211_vht_cap_ie_to_sta_vht_cap(struct
>> > > > > ieee80211_sub_if_data *sdata,
>> > > > > > >> }
>> > > > > > >>
>> > > > > > >> sta->sta.bandwidth = ieee80211_sta_cur_vht_bw(sta);
>> > > > > > >> +
>> > > > > > >> +   /* If HT IE reported 3839 bytes only, stay with that
>> > > size. */
>> > > > > > >> +   if (sta->sta.max_amsdu_len ==
>> > > IEEE80211_MAX_MPDU_LEN_HT_3839)
>> > > > > > >> +   return;
>> > > > > > >> +
>> > > > > > >> +   switch (vht_cap->cap &
>> IEEE80211_VHT_CAP_MAX_MPDU_MASK) {
>> > > > > > >> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454:
>> > > > > > >> +   sta->sta.max_amsdu_len =
>> > > > > IEEE80211_MAX_MPDU_LEN_VHT_11454;
>> > > > > > >> +   break;
>> > > > > > >> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991:
>> > > > > > >> +   sta->sta.max_amsdu_len =
>> > > > > IEEE80211_MAX_MPDU_LEN_VHT_7991;
>> > > > > > >> +   break;
>> > > > > > >> +   case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895:
>> > > > > > >> +   default:
>> > > > > > >> +   sta->sta.max_amsdu_len =
>> > > > > IEEE80211_MAX_MPDU_LEN_VHT_3895;
>> > > > > > >> +   break;
>> > > > > > >> +   }
>> > > > > > > Ideally speaking shouldn't we use different variables for HT
>> > > and VHT
>> > > > > > > and depending on
>> > > > > > > rate HT/VHT we should aggregate accordingly? of course that
>> > > will be
>> > > > > > > tricky as we dont
>> > > > > > > have the rate control info at the time of aggregation.
>> Standard is
>> > > > > > > clear about usage of
>> > > > > > > independent lengths depending on whether its an VHT/HT PPDU.
>> > > > > >
>> > > > > > Yes - but since it is tricky, I preferred to be on the safe
>> side and
>> > > > > > limit VHT amsdus for the very peculiar AP that would decide
>> to have
>> > > > > > large A-MSDUs in VHT and small ones in HT (?!).
>> > > > > Yes but wouldn't it be safer to just use min(ht , vht)? For a
>> good AP
>> > > > > it shouldn't matter and bad AP it will still work.
>> > > > >
>> > > > This is the de-facto what this code does I think.
>> > > > If the HT limit is 4K, then don't even take the VHT limit into
>> account
>> > > > and the VHT limit can't be smaller than the HT one in that case.
>> > > > If the HT limit is 8K, then we can