+++ /dev/null
-From 2fef681a4cf7994c882190fd2417b95f30510afb Mon Sep 17 00:00:00 2001
-From: Jia-Shyr Chuang <saint.chuang@cypress.com>
-Date: Wed, 15 Aug 2018 04:23:09 -0500
-Subject: [PATCH] brcmfmac: add CYW89342 mini-PCIe device
-
-CYW89342 is a 2x2 MIMO, 802.11a/b/g/n/ac for WLAN. It is a member of
-4355/4359 family.
-
-Signed-off-by: Jia-Shyr Chuang <saint.chuang@cypress.com>
-Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
-Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
----
- drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 1 +
- 1 file changed, 1 insertion(+)
-
---- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
-+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
-@@ -2017,6 +2017,7 @@ static const struct dev_pm_ops brcmf_pci
-
- static const struct pci_device_id brcmf_pcie_devid_table[] = {
- BRCMF_PCIE_DEVICE(BRCM_PCIE_4350_DEVICE_ID),
-+ BRCMF_PCIE_DEVICE_SUB(0x4355, BRCM_PCIE_VENDOR_ID_BROADCOM, 0x4355),
- BRCMF_PCIE_DEVICE(BRCM_PCIE_4356_DEVICE_ID),
- BRCMF_PCIE_DEVICE(BRCM_PCIE_43567_DEVICE_ID),
- BRCMF_PCIE_DEVICE(BRCM_PCIE_43570_DEVICE_ID),
+++ /dev/null
-From cb18e2e9ec71d42409a51b83546686c609780dde Mon Sep 17 00:00:00 2001
-From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
-Date: Wed, 22 Aug 2018 15:22:15 +0200
-Subject: [PATCH] brcmfmac: fix wrong strnchr usage
-
-strnchr takes arguments in the order of its name: string, max bytes to
-read, character to search for. Here we're passing '\n' aka 10 as the
-buffer size, and searching for sizeof(buf) aka BRCMF_DCMD_SMLEN aka
-256 (aka '\0', since it's implicitly converted to char) within those 10
-bytes.
-
-Just interchanging the last two arguments would still leave a bug,
-because if we've been successful once, there are not sizeof(buf)
-characters left after the new value of p.
-
-Since clmver is immediately afterwards passed as a %s argument, I assume
-that it is actually a properly nul-terminated string. For that case, we
-have strreplace().
-
-Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
-Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
----
- drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 4 +---
- 1 file changed, 1 insertion(+), 3 deletions(-)
-
---- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
-+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
-@@ -296,9 +296,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_i
- /* Replace all newline/linefeed characters with space
- * character
- */
-- ptr = clmver;
-- while ((ptr = strnchr(ptr, '\n', sizeof(buf))) != NULL)
-- *ptr = ' ';
-+ strreplace(clmver, '\n', ' ');
-
- brcmf_dbg(INFO, "CLM version = %s\n", clmver);
- }
+++ /dev/null
-From: Arend van Spriel <arend.vanspriel@broadcom.com>
-Date: Wed, 5 Sep 2018 09:48:58 +0200
-Subject: [PATCH] brcmfmac: fix for proper support of 160MHz bandwidth
-
-Decoding of firmware channel information was not complete for 160MHz
-support. This resulted in the following warning:
-
- WARNING: CPU: 2 PID: 2222 at .../broadcom/brcm80211/brcmutil/d11.c:196
- brcmu_d11ac_decchspec+0x2e/0x100 [brcmutil]
- Modules linked in: brcmfmac(O) brcmutil(O) sha256_generic cfg80211 ...
- CPU: 2 PID: 2222 Comm: kworker/2:0 Tainted: G O
- 4.17.0-wt-testing-x64-00002-gf1bed50 #1
- Hardware name: Dell Inc. Latitude E6410/07XJP9, BIOS A07 02/15/2011
- Workqueue: events request_firmware_work_func
- RIP: 0010:brcmu_d11ac_decchspec+0x2e/0x100 [brcmutil]
- RSP: 0018:ffffc90000047bd0 EFLAGS: 00010206
- RAX: 000000000000e832 RBX: ffff8801146fe910 RCX: ffff8801146fd3c0
- RDX: 0000000000002800 RSI: 0000000000000070 RDI: ffffc90000047c30
- RBP: ffffc90000047bd0 R08: 0000000000000000 R09: ffffffffa0798c80
- R10: ffff88012bca55e0 R11: ffff880110a4ea00 R12: ffff8801146f8000
- R13: ffffc90000047c30 R14: ffff8801146fe930 R15: ffff8801138e02e0
- FS: 0000000000000000(0000) GS:ffff88012bc80000(0000) knlGS:0000000000000000
- CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
- CR2: 00007f18ce8b8070 CR3: 000000000200a003 CR4: 00000000000206e0
- Call Trace:
- brcmf_setup_wiphybands+0x212/0x780 [brcmfmac]
- brcmf_cfg80211_attach+0xae2/0x11a0 [brcmfmac]
- brcmf_attach+0x1fc/0x4b0 [brcmfmac]
- ? __kmalloc+0x13c/0x1c0
- brcmf_pcie_setup+0x99b/0xe00 [brcmfmac]
- brcmf_fw_request_done+0x16a/0x1f0 [brcmfmac]
- request_firmware_work_func+0x36/0x60
- process_one_work+0x146/0x350
- worker_thread+0x4a/0x3b0
- kthread+0x102/0x140
- ? process_one_work+0x350/0x350
- ? kthread_bind+0x20/0x20
- ret_from_fork+0x35/0x40
- Code: 66 90 0f b7 07 55 48 89 e5 89 c2 88 47 02 88 47 03 66 81 e2 00 38
- 66 81 fa 00 18 74 6e 66 81 fa 00 20 74 39 66 81 fa 00 10 74 14 <0f>
- 0b 66 25 00 c0 74 20 66 3d 00 c0 75 20 c6 47 04 01 5d c3 66
- ---[ end trace 550c46682415b26d ]---
- brcmfmac: brcmf_construct_chaninfo: Ignoring unexpected firmware channel 50
-
-This patch adds the missing stuff to properly handle this.
-
-Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
-Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
-Reviewed-by: Franky Lin <franky.lin@broadcom.com>
-Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
----
- .../net/wireless/broadcom/brcm80211/brcmutil/d11.c | 34 +++++++++++++++++++++-
- .../broadcom/brcm80211/include/brcmu_wifi.h | 2 ++
- 2 files changed, 35 insertions(+), 1 deletion(-)
-
---- a/drivers/net/wireless/broadcom/brcm80211/brcmutil/d11.c
-+++ b/drivers/net/wireless/broadcom/brcm80211/brcmutil/d11.c
-@@ -77,6 +77,8 @@ static u16 d11ac_bw(enum brcmu_chan_bw b
- return BRCMU_CHSPEC_D11AC_BW_40;
- case BRCMU_CHAN_BW_80:
- return BRCMU_CHSPEC_D11AC_BW_80;
-+ case BRCMU_CHAN_BW_160:
-+ return BRCMU_CHSPEC_D11AC_BW_160;
- default:
- WARN_ON(1);
- }
-@@ -190,8 +192,38 @@ static void brcmu_d11ac_decchspec(struct
- break;
- }
- break;
-- case BRCMU_CHSPEC_D11AC_BW_8080:
- case BRCMU_CHSPEC_D11AC_BW_160:
-+ switch (ch->sb) {
-+ case BRCMU_CHAN_SB_LLL:
-+ ch->control_ch_num -= CH_70MHZ_APART;
-+ break;
-+ case BRCMU_CHAN_SB_LLU:
-+ ch->control_ch_num -= CH_50MHZ_APART;
-+ break;
-+ case BRCMU_CHAN_SB_LUL:
-+ ch->control_ch_num -= CH_30MHZ_APART;
-+ break;
-+ case BRCMU_CHAN_SB_LUU:
-+ ch->control_ch_num -= CH_10MHZ_APART;
-+ break;
-+ case BRCMU_CHAN_SB_ULL:
-+ ch->control_ch_num += CH_10MHZ_APART;
-+ break;
-+ case BRCMU_CHAN_SB_ULU:
-+ ch->control_ch_num += CH_30MHZ_APART;
-+ break;
-+ case BRCMU_CHAN_SB_UUL:
-+ ch->control_ch_num += CH_50MHZ_APART;
-+ break;
-+ case BRCMU_CHAN_SB_UUU:
-+ ch->control_ch_num += CH_70MHZ_APART;
-+ break;
-+ default:
-+ WARN_ON_ONCE(1);
-+ break;
-+ }
-+ break;
-+ case BRCMU_CHSPEC_D11AC_BW_8080:
- default:
- WARN_ON_ONCE(1);
- break;
---- a/drivers/net/wireless/broadcom/brcm80211/include/brcmu_wifi.h
-+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcmu_wifi.h
-@@ -29,6 +29,8 @@
- #define CH_UPPER_SB 0x01
- #define CH_LOWER_SB 0x02
- #define CH_EWA_VALID 0x04
-+#define CH_70MHZ_APART 14
-+#define CH_50MHZ_APART 10
- #define CH_30MHZ_APART 6
- #define CH_20MHZ_APART 4
- #define CH_10MHZ_APART 2
+++ /dev/null
-From: Arend van Spriel <arend.vanspriel@broadcom.com>
-Date: Wed, 5 Sep 2018 09:48:59 +0200
-Subject: [PATCH] brcmfmac: increase buffer for obtaining firmware capabilities
-
-When obtaining the firmware capability a buffer is provided of 512
-bytes. However, if all features in firmware are supported the buffer
-needs to be 565 bytes as otherwise truncated information is retrieved
-from firmware. Increasing the buffer to 768 bytes on stack.
-
-Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
-Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
-Reviewed-by: Franky Lin <franky.lin@broadcom.com>
-Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
----
- drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
---- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
-+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
-@@ -178,7 +178,7 @@ static void brcmf_feat_iovar_data_set(st
- ifp->fwil_fwerr = false;
- }
-
--#define MAX_CAPS_BUFFER_SIZE 512
-+#define MAX_CAPS_BUFFER_SIZE 768
- static void brcmf_feat_firmware_capabilities(struct brcmf_if *ifp)
- {
- char caps[MAX_CAPS_BUFFER_SIZE];
+++ /dev/null
-From: =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
-Date: Mon, 13 Aug 2018 14:16:25 +0200
-Subject: [PATCH] mac80211: Run TXQ teardown code before de-registering
- interfaces
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-The TXQ teardown code can reference the vif data structures that are
-stored in the netdev private memory area if there are still packets on
-the queue when it is being freed. Since the TXQ teardown code is run
-after the netdevs are freed, this can lead to a use-after-free. Fix this
-by moving the TXQ teardown code to earlier in ieee80211_unregister_hw().
-
-Reported-by: Ben Greear <greearb@candelatech.com>
-Tested-by: Ben Greear <greearb@candelatech.com>
-Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
-Signed-off-by: Johannes Berg <johannes.berg@intel.com>
----
-
---- a/net/mac80211/main.c
-+++ b/net/mac80211/main.c
-@@ -1172,6 +1172,7 @@ void ieee80211_unregister_hw(struct ieee
- #if IS_ENABLED(__disabled__CONFIG_IPV6)
- unregister_inet6addr_notifier(&local->ifa6_notifier);
- #endif
-+ ieee80211_txq_teardown_flows(local);
-
- rtnl_lock();
-
-@@ -1200,7 +1201,6 @@ void ieee80211_unregister_hw(struct ieee
- skb_queue_purge(&local->skb_queue);
- skb_queue_purge(&local->skb_queue_unreliable);
- skb_queue_purge(&local->skb_queue_tdls_chsw);
-- ieee80211_txq_teardown_flows(local);
-
- destroy_workqueue(local->workqueue);
- wiphy_unregister(local->hw.wiphy);
+++ /dev/null
-From: Yuan-Chi Pang <fu3mo6goo@gmail.com>
-Date: Wed, 29 Aug 2018 09:30:08 +0800
-Subject: [PATCH] mac80211: mesh: fix HWMP sequence numbering to follow
- standard
-
-IEEE 802.11-2016 14.10.8.3 HWMP sequence numbering says:
-If it is a target mesh STA, it shall update its own HWMP SN to
-maximum (current HWMP SN, target HWMP SN in the PREQ element) + 1
-immediately before it generates a PREP element in response to a
-PREQ element.
-
-Signed-off-by: Yuan-Chi Pang <fu3mo6goo@gmail.com>
-Signed-off-by: Johannes Berg <johannes.berg@intel.com>
----
-
---- a/net/mac80211/mesh_hwmp.c
-+++ b/net/mac80211/mesh_hwmp.c
-@@ -572,6 +572,10 @@ static void hwmp_preq_frame_process(stru
- forward = false;
- reply = true;
- target_metric = 0;
-+
-+ if (SN_GT(target_sn, ifmsh->sn))
-+ ifmsh->sn = target_sn;
-+
- if (time_after(jiffies, ifmsh->last_sn_update +
- net_traversal_jiffies(sdata)) ||
- time_before(jiffies, ifmsh->last_sn_update)) {
+++ /dev/null
-From: Sara Sharon <sara.sharon@intel.com>
-Date: Wed, 29 Aug 2018 08:57:02 +0200
-Subject: [PATCH] mac80211: avoid kernel panic when building AMSDU from
- non-linear SKB
-
-When building building AMSDU from non-linear SKB, we hit a
-kernel panic when trying to push the padding to the tail.
-Instead, put the padding at the head of the next subframe.
-This also fixes the A-MSDU subframes to not have the padding
-accounted in the length field and not have pad at all for
-the last subframe, both required by the spec.
-
-Fixes: 6e0456b54545 ("mac80211: add A-MSDU tx support")
-Signed-off-by: Sara Sharon <sara.sharon@intel.com>
-Reviewed-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
-Signed-off-by: Johannes Berg <johannes.berg@intel.com>
----
-
---- a/net/mac80211/tx.c
-+++ b/net/mac80211/tx.c
-@@ -3064,27 +3064,18 @@ void ieee80211_clear_fast_xmit(struct st
- }
-
- static bool ieee80211_amsdu_realloc_pad(struct ieee80211_local *local,
-- struct sk_buff *skb, int headroom,
-- int *subframe_len)
-+ struct sk_buff *skb, int headroom)
- {
-- int amsdu_len = *subframe_len + sizeof(struct ethhdr);
-- int padding = (4 - amsdu_len) & 3;
--
-- if (skb_headroom(skb) < headroom || skb_tailroom(skb) < padding) {
-+ if (skb_headroom(skb) < headroom) {
- I802_DEBUG_INC(local->tx_expand_skb_head);
-
-- if (pskb_expand_head(skb, headroom, padding, GFP_ATOMIC)) {
-+ if (pskb_expand_head(skb, headroom, 0, GFP_ATOMIC)) {
- wiphy_debug(local->hw.wiphy,
- "failed to reallocate TX buffer\n");
- return false;
- }
- }
-
-- if (padding) {
-- *subframe_len += padding;
-- skb_put_zero(skb, padding);
-- }
--
- return true;
- }
-
-@@ -3108,8 +3099,7 @@ static bool ieee80211_amsdu_prepare_head
- if (info->control.flags & IEEE80211_TX_CTRL_AMSDU)
- return true;
-
-- if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(*amsdu_hdr),
-- &subframe_len))
-+ if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(*amsdu_hdr)))
- return false;
-
- data = skb_push(skb, sizeof(*amsdu_hdr));
-@@ -3176,7 +3166,8 @@ static bool ieee80211_amsdu_aggregate(st
- void *data;
- bool ret = false;
- unsigned int orig_len;
-- int n = 1, nfrags;
-+ int n = 1, nfrags, pad = 0;
-+ u16 hdrlen;
-
- if (!ieee80211_hw_check(&local->hw, TX_AMSDU))
- return false;
-@@ -3228,8 +3219,19 @@ static bool ieee80211_amsdu_aggregate(st
- if (max_frags && nfrags > max_frags)
- goto out;
-
-- if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(rfc1042_header) + 2,
-- &subframe_len))
-+ /*
-+ * Pad out the previous subframe to a multiple of 4 by adding the
-+ * padding to the next one, that's being added. Note that head->len
-+ * is the length of the full A-MSDU, but that works since each time
-+ * we add a new subframe we pad out the previous one to a multiple
-+ * of 4 and thus it no longer matters in the next round.
-+ */
-+ hdrlen = fast_tx->hdr_len - sizeof(rfc1042_header);
-+ if ((head->len - hdrlen) & 3)
-+ pad = 4 - ((head->len - hdrlen) & 3);
-+
-+ if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(rfc1042_header) +
-+ 2 + pad))
- goto out;
-
- ret = true;
-@@ -3241,6 +3243,8 @@ static bool ieee80211_amsdu_aggregate(st
- memcpy(data, &len, 2);
- memcpy(data + 2, rfc1042_header, sizeof(rfc1042_header));
-
-+ memset(skb_push(skb, pad), 0, pad);
-+
- head->len += skb->len;
- head->data_len += skb->len;
- *frag_tail = skb;
+++ /dev/null
-From: Arunk Khandavalli <akhandav@codeaurora.org>
-Date: Thu, 30 Aug 2018 00:40:16 +0300
-Subject: [PATCH] cfg80211: nl80211_update_ft_ies() to validate
- NL80211_ATTR_IE
-
-nl80211_update_ft_ies() tried to validate NL80211_ATTR_IE with
-is_valid_ie_attr() before dereferencing it, but that helper function
-returns true in case of NULL pointer (i.e., attribute not included).
-This can result to dereferencing a NULL pointer. Fix that by explicitly
-checking that NL80211_ATTR_IE is included.
-
-Fixes: 355199e02b83 ("cfg80211: Extend support for IEEE 802.11r Fast BSS Transition")
-Signed-off-by: Arunk Khandavalli <akhandav@codeaurora.org>
-Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
-Signed-off-by: Johannes Berg <johannes.berg@intel.com>
----
-
---- a/net/wireless/nl80211.c
-+++ b/net/wireless/nl80211.c
-@@ -11763,6 +11763,7 @@ static int nl80211_update_ft_ies(struct
- return -EOPNOTSUPP;
-
- if (!info->attrs[NL80211_ATTR_MDID] ||
-+ !info->attrs[NL80211_ATTR_IE] ||
- !is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
- return -EINVAL;
-
+++ /dev/null
-From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
-Date: Wed, 29 Aug 2018 21:03:25 +0200
-Subject: [PATCH] mac80211: do not convert to A-MSDU if frag/subframe
- limited
-
-Do not start to aggregate packets in a A-MSDU frame (converting the
-first subframe to A-MSDU, adding the header) if max_tx_fragments or
-max_amsdu_subframes limits are already exceeded by it. In particular,
-this happens when drivers set the limit to 1 to avoid A-MSDUs at all.
-
-Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
-[reword commit message to be more precise]
-Signed-off-by: Johannes Berg <johannes.berg@intel.com>
----
-
---- a/net/mac80211/tx.c
-+++ b/net/mac80211/tx.c
-@@ -3201,9 +3201,6 @@ static bool ieee80211_amsdu_aggregate(st
- if (skb->len + head->len > max_amsdu_len)
- goto unlock;
-
-- if (!ieee80211_amsdu_prepare_head(sdata, fast_tx, head))
-- goto out;
--
- nfrags = 1 + skb_shinfo(skb)->nr_frags;
- nfrags += 1 + skb_shinfo(head)->nr_frags;
- frag_tail = &skb_shinfo(head)->frag_list;
-@@ -3219,6 +3216,9 @@ static bool ieee80211_amsdu_aggregate(st
- if (max_frags && nfrags > max_frags)
- goto out;
-
-+ if (!ieee80211_amsdu_prepare_head(sdata, fast_tx, head))
-+ goto out;
-+
- /*
- * Pad out the previous subframe to a multiple of 4 by adding the
- * padding to the next one, that's being added. Note that head->len
+++ /dev/null
-From: Johannes Berg <johannes.berg@intel.com>
-Date: Thu, 30 Aug 2018 10:55:49 +0200
-Subject: [PATCH] mac80211: always account for A-MSDU header changes
-
-In the error path of changing the SKB headroom of the second
-A-MSDU subframe, we would not account for the already-changed
-length of the first frame that just got converted to be in
-A-MSDU format and thus is a bit longer now.
-
-Fix this by doing the necessary accounting.
-
-It would be possible to reorder the operations, but that would
-make the code more complex (to calculate the necessary pad),
-and the headroom expansion should not fail frequently enough
-to make that worthwhile.
-
-Fixes: 6e0456b54545 ("mac80211: add A-MSDU tx support")
-Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
-Signed-off-by: Johannes Berg <johannes.berg@intel.com>
----
-
---- a/net/mac80211/tx.c
-+++ b/net/mac80211/tx.c
-@@ -3232,7 +3232,7 @@ static bool ieee80211_amsdu_aggregate(st
-
- if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(rfc1042_header) +
- 2 + pad))
-- goto out;
-+ goto out_recalc;
-
- ret = true;
- data = skb_push(skb, ETH_ALEN + 2);
-@@ -3249,11 +3249,13 @@ static bool ieee80211_amsdu_aggregate(st
- head->data_len += skb->len;
- *frag_tail = skb;
-
-- flow->backlog += head->len - orig_len;
-- tin->backlog_bytes += head->len - orig_len;
--
-- fq_recalc_backlog(fq, tin, flow);
-+out_recalc:
-+ if (head->len != orig_len) {
-+ flow->backlog += head->len - orig_len;
-+ tin->backlog_bytes += head->len - orig_len;
-
-+ fq_recalc_backlog(fq, tin, flow);
-+ }
- out:
- fq->memory_usage += head->truesize - orig_truesize;
-
+++ /dev/null
-From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
-Date: Fri, 31 Aug 2018 01:04:13 +0200
-Subject: [PATCH] mac80211: fix an off-by-one issue in A-MSDU
- max_subframe computation
-
-Initialize 'n' to 2 in order to take into account also the first
-packet in the estimation of max_subframe limit for a given A-MSDU
-since frag_tail pointer is NULL when ieee80211_amsdu_aggregate
-routine analyzes the second frame.
-
-Fixes: 6e0456b54545 ("mac80211: add A-MSDU tx support")
-Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
-Signed-off-by: Johannes Berg <johannes.berg@intel.com>
----
-
---- a/net/mac80211/tx.c
-+++ b/net/mac80211/tx.c
-@@ -3166,7 +3166,7 @@ static bool ieee80211_amsdu_aggregate(st
- void *data;
- bool ret = false;
- unsigned int orig_len;
-- int n = 1, nfrags, pad = 0;
-+ int n = 2, nfrags, pad = 0;
- u16 hdrlen;
-
- if (!ieee80211_hw_check(&local->hw, TX_AMSDU))
+++ /dev/null
-From: Dan Carpenter <dan.carpenter@oracle.com>
-Date: Fri, 31 Aug 2018 11:10:55 +0300
-Subject: [PATCH] cfg80211: fix a type issue in
- ieee80211_chandef_to_operating_class()
-
-The "chandef->center_freq1" variable is a u32 but "freq" is a u16 so we
-are truncating away the high bits. I noticed this bug because in commit
-9cf0a0b4b64a ("cfg80211: Add support for 60GHz band channels 5 and 6")
-we made "freq <= 56160 + 2160 * 6" a valid requency when before it was
-only "freq <= 56160 + 2160 * 4" that was valid. It introduces a static
-checker warning:
-
- net/wireless/util.c:1571 ieee80211_chandef_to_operating_class()
- warn: always true condition '(freq <= 56160 + 2160 * 6) => (0-u16max <= 69120)'
-
-But really we probably shouldn't have been truncating the high bits
-away to begin with.
-
-Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
-Signed-off-by: Johannes Berg <johannes.berg@intel.com>
----
-
---- a/net/wireless/util.c
-+++ b/net/wireless/util.c
-@@ -1377,7 +1377,7 @@ bool ieee80211_chandef_to_operating_clas
- u8 *op_class)
- {
- u8 vht_opclass;
-- u16 freq = chandef->center_freq1;
-+ u32 freq = chandef->center_freq1;
-
- if (freq >= 2412 && freq <= 2472) {
- if (chandef->width > NL80211_CHAN_WIDTH_40)
+++ /dev/null
-From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-Date: Fri, 31 Aug 2018 11:31:06 +0300
-Subject: [PATCH] mac80211: fix a race between restart and CSA flows
-
-We hit a problem with iwlwifi that was caused by a bug in
-mac80211. A bug in iwlwifi caused the firwmare to crash in
-certain cases in channel switch. Because of that bug,
-drv_pre_channel_switch would fail and trigger the restart
-flow.
-Now we had the hw restart worker which runs on the system's
-workqueue and the csa_connection_drop_work worker that runs
-on mac80211's workqueue that can run together. This is
-obviously problematic since the restart work wants to
-reconfigure the connection, while the csa_connection_drop_work
-worker does the exact opposite: it tries to disconnect.
-
-Fix this by cancelling the csa_connection_drop_work worker
-in the restart worker.
-
-Note that this can sound racy: we could have:
-
-driver iface_work CSA_work restart_work
-+++++++++++++++++++++++++++++++++++++++++++++
- |
- <--drv_cs ---|
-<FW CRASH!>
--CS FAILED-->
- | |
- | cancel_work(CSA)
- schedule |
- CSA work |
- | |
- Race between those 2
-
-But this is not possible because we flush the workqueue
-in the restart worker before we cancel the CSA worker.
-That would be bullet proof if we could guarantee that
-we schedule the CSA worker only from the iface_work
-which runs on the workqueue (and not on the system's
-workqueue), but unfortunately we do have an instance
-in which we schedule the CSA work outside the context
-of the workqueue (ieee80211_chswitch_done).
-
-Note also that we should probably cancel other workers
-like beacon_connection_loss_work and possibly others
-for different types of interfaces, at the very least,
-IBSS should suffer from the exact same problem, but for
-now, do the minimum to fix the actual bug that was actually
-experienced and reproduced.
-
-Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-Signed-off-by: Johannes Berg <johannes.berg@intel.com>
----
-
---- a/net/mac80211/main.c
-+++ b/net/mac80211/main.c
-@@ -255,8 +255,27 @@ static void ieee80211_restart_work(struc
-
- flush_work(&local->radar_detected_work);
- rtnl_lock();
-- list_for_each_entry(sdata, &local->interfaces, list)
-+ list_for_each_entry(sdata, &local->interfaces, list) {
-+ /*
-+ * XXX: there may be more work for other vif types and even
-+ * for station mode: a good thing would be to run most of
-+ * the iface type's dependent _stop (ieee80211_mg_stop,
-+ * ieee80211_ibss_stop) etc...
-+ * For now, fix only the specific bug that was seen: race
-+ * between csa_connection_drop_work and us.
-+ */
-+ if (sdata->vif.type == NL80211_IFTYPE_STATION) {
-+ /*
-+ * This worker is scheduled from the iface worker that
-+ * runs on mac80211's workqueue, so we can't be
-+ * scheduling this worker after the cancel right here.
-+ * The exception is ieee80211_chswitch_done.
-+ * Then we can have a race...
-+ */
-+ cancel_work_sync(&sdata->u.mgd.csa_connection_drop_work);
-+ }
- flush_delayed_work(&sdata->dec_tailroom_needed_wk);
-+ }
- ieee80211_scan_cancel(local);
-
- /* make sure any new ROC will consider local->in_reconfig */
+++ /dev/null
-From: Ilan Peer <ilan.peer@intel.com>
-Date: Fri, 31 Aug 2018 11:31:10 +0300
-Subject: [PATCH] mac80211: Fix station bandwidth setting after channel
- switch
-
-When performing a channel switch flow for a managed interface, the
-flow did not update the bandwidth of the AP station and the rate
-scale algorithm. In case of a channel width downgrade, this would
-result with the rate scale algorithm using a bandwidth that does not
-match the interface channel configuration.
-
-Fix this by updating the AP station bandwidth and rate scaling algorithm
-before the actual channel change in case of a bandwidth downgrade, or
-after the actual channel change in case of a bandwidth upgrade.
-
-Signed-off-by: Ilan Peer <ilan.peer@intel.com>
-Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-Signed-off-by: Johannes Berg <johannes.berg@intel.com>
----
-
---- a/net/mac80211/mlme.c
-+++ b/net/mac80211/mlme.c
-@@ -975,6 +975,10 @@ static void ieee80211_chswitch_work(stru
- */
-
- if (sdata->reserved_chanctx) {
-+ struct ieee80211_supported_band *sband = NULL;
-+ struct sta_info *mgd_sta = NULL;
-+ enum ieee80211_sta_rx_bandwidth bw = IEEE80211_STA_RX_BW_20;
-+
- /*
- * with multi-vif csa driver may call ieee80211_csa_finish()
- * many times while waiting for other interfaces to use their
-@@ -983,6 +987,48 @@ static void ieee80211_chswitch_work(stru
- if (sdata->reserved_ready)
- goto out;
-
-+ if (sdata->vif.bss_conf.chandef.width !=
-+ sdata->csa_chandef.width) {
-+ /*
-+ * For managed interface, we need to also update the AP
-+ * station bandwidth and align the rate scale algorithm
-+ * on the bandwidth change. Here we only consider the
-+ * bandwidth of the new channel definition (as channel
-+ * switch flow does not have the full HT/VHT/HE
-+ * information), assuming that if additional changes are
-+ * required they would be done as part of the processing
-+ * of the next beacon from the AP.
-+ */
-+ switch (sdata->csa_chandef.width) {
-+ case NL80211_CHAN_WIDTH_20_NOHT:
-+ case NL80211_CHAN_WIDTH_20:
-+ default:
-+ bw = IEEE80211_STA_RX_BW_20;
-+ break;
-+ case NL80211_CHAN_WIDTH_40:
-+ bw = IEEE80211_STA_RX_BW_40;
-+ break;
-+ case NL80211_CHAN_WIDTH_80:
-+ bw = IEEE80211_STA_RX_BW_80;
-+ break;
-+ case NL80211_CHAN_WIDTH_80P80:
-+ case NL80211_CHAN_WIDTH_160:
-+ bw = IEEE80211_STA_RX_BW_160;
-+ break;
-+ }
-+
-+ mgd_sta = sta_info_get(sdata, ifmgd->bssid);
-+ sband =
-+ local->hw.wiphy->bands[sdata->csa_chandef.chan->band];
-+ }
-+
-+ if (sdata->vif.bss_conf.chandef.width >
-+ sdata->csa_chandef.width) {
-+ mgd_sta->sta.bandwidth = bw;
-+ rate_control_rate_update(local, sband, mgd_sta,
-+ IEEE80211_RC_BW_CHANGED);
-+ }
-+
- ret = ieee80211_vif_use_reserved_context(sdata);
- if (ret) {
- sdata_info(sdata,
-@@ -993,6 +1039,13 @@ static void ieee80211_chswitch_work(stru
- goto out;
- }
-
-+ if (sdata->vif.bss_conf.chandef.width <
-+ sdata->csa_chandef.width) {
-+ mgd_sta->sta.bandwidth = bw;
-+ rate_control_rate_update(local, sband, mgd_sta,
-+ IEEE80211_RC_BW_CHANGED);
-+ }
-+
- goto out;
- }
-
+++ /dev/null
-From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-Date: Fri, 31 Aug 2018 11:31:12 +0300
-Subject: [PATCH] mac80211: don't Tx a deauth frame if the AP forbade Tx
-
-If the driver fails to properly prepare for the channel
-switch, mac80211 will disconnect. If the CSA IE had mode
-set to 1, it means that the clients are not allowed to send
-any Tx on the current channel, and that includes the
-deauthentication frame.
-
-Make sure that we don't send the deauthentication frame in
-this case.
-
-In iwlwifi, this caused a failure to flush queues since the
-firmware already closed the queues after having parsed the
-CSA IE. Then mac80211 would wait until the deauthentication
-frame would go out (drv_flush(drop=false)) and that would
-never happen.
-
-Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-Signed-off-by: Johannes Berg <johannes.berg@intel.com>
----
-
---- a/net/mac80211/mlme.c
-+++ b/net/mac80211/mlme.c
-@@ -1267,6 +1267,16 @@ ieee80211_sta_process_chanswitch(struct
- cbss->beacon_interval));
- return;
- drop_connection:
-+ /*
-+ * This is just so that the disconnect flow will know that
-+ * we were trying to switch channel and failed. In case the
-+ * mode is 1 (we are not allowed to Tx), we will know not to
-+ * send a deauthentication frame. Those two fields will be
-+ * reset when the disconnection worker runs.
-+ */
-+ sdata->vif.csa_active = true;
-+ sdata->csa_block_tx = csa_ie.mode;
-+
- ieee80211_queue_work(&local->hw, &ifmgd->csa_connection_drop_work);
- mutex_unlock(&local->chanctx_mtx);
- mutex_unlock(&local->mtx);
-@@ -2437,6 +2447,7 @@ static void __ieee80211_disconnect(struc
- struct ieee80211_local *local = sdata->local;
- struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
- u8 frame_buf[IEEE80211_DEAUTH_FRAME_LEN];
-+ bool tx;
-
- sdata_lock(sdata);
- if (!ifmgd->associated) {
-@@ -2444,6 +2455,8 @@ static void __ieee80211_disconnect(struc
- return;
- }
-
-+ tx = !sdata->csa_block_tx;
-+
- /* AP is probably out of range (or not reachable for another reason) so
- * remove the bss struct for that AP.
- */
-@@ -2451,7 +2464,7 @@ static void __ieee80211_disconnect(struc
-
- ieee80211_set_disassoc(sdata, IEEE80211_STYPE_DEAUTH,
- WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY,
-- true, frame_buf);
-+ tx, frame_buf);
- mutex_lock(&local->mtx);
- sdata->vif.csa_active = false;
- ifmgd->csa_waiting_bcn = false;
-@@ -2462,7 +2475,7 @@ static void __ieee80211_disconnect(struc
- }
- mutex_unlock(&local->mtx);
-
-- ieee80211_report_disconnect(sdata, frame_buf, sizeof(frame_buf), true,
-+ ieee80211_report_disconnect(sdata, frame_buf, sizeof(frame_buf), tx,
- WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY);
-
- sdata_unlock(sdata);
+++ /dev/null
-From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-Date: Fri, 31 Aug 2018 11:31:13 +0300
-Subject: [PATCH] mac80211: shorten the IBSS debug messages
-
-When tracing is enabled, all the debug messages are recorded and must
-not exceed MAX_MSG_LEN (100) columns. Longer debug messages grant the
-user with:
-
-WARNING: CPU: 3 PID: 32642 at /tmp/wifi-core-20180806094828/src/iwlwifi-stack-dev/net/mac80211/./trace_msg.h:32 trace_event_raw_event_mac80211_msg_event+0xab/0xc0 [mac80211]
-Workqueue: phy1 ieee80211_iface_work [mac80211]
- RIP: 0010:trace_event_raw_event_mac80211_msg_event+0xab/0xc0 [mac80211]
- Call Trace:
- __sdata_dbg+0xbd/0x120 [mac80211]
- ieee80211_ibss_rx_queued_mgmt+0x15f/0x510 [mac80211]
- ieee80211_iface_work+0x21d/0x320 [mac80211]
-
-Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-Signed-off-by: Johannes Berg <johannes.berg@intel.com>
----
-
---- a/net/mac80211/ibss.c
-+++ b/net/mac80211/ibss.c
-@@ -947,8 +947,8 @@ static void ieee80211_rx_mgmt_deauth_ibs
- if (len < IEEE80211_DEAUTH_FRAME_LEN)
- return;
-
-- ibss_dbg(sdata, "RX DeAuth SA=%pM DA=%pM BSSID=%pM (reason: %d)\n",
-- mgmt->sa, mgmt->da, mgmt->bssid, reason);
-+ ibss_dbg(sdata, "RX DeAuth SA=%pM DA=%pM\n", mgmt->sa, mgmt->da);
-+ ibss_dbg(sdata, "\tBSSID=%pM (reason: %d)\n", mgmt->bssid, reason);
- sta_info_destroy_addr(sdata, mgmt->sa);
- }
-
-@@ -966,9 +966,9 @@ static void ieee80211_rx_mgmt_auth_ibss(
- auth_alg = le16_to_cpu(mgmt->u.auth.auth_alg);
- auth_transaction = le16_to_cpu(mgmt->u.auth.auth_transaction);
-
-- ibss_dbg(sdata,
-- "RX Auth SA=%pM DA=%pM BSSID=%pM (auth_transaction=%d)\n",
-- mgmt->sa, mgmt->da, mgmt->bssid, auth_transaction);
-+ ibss_dbg(sdata, "RX Auth SA=%pM DA=%pM\n", mgmt->sa, mgmt->da);
-+ ibss_dbg(sdata, "\tBSSID=%pM (auth_transaction=%d)\n",
-+ mgmt->bssid, auth_transaction);
-
- if (auth_alg != WLAN_AUTH_OPEN || auth_transaction != 1)
- return;
-@@ -1175,10 +1175,10 @@ static void ieee80211_rx_bss_info(struct
- rx_timestamp = drv_get_tsf(local, sdata);
- }
-
-- ibss_dbg(sdata,
-- "RX beacon SA=%pM BSSID=%pM TSF=0x%llx BCN=0x%llx diff=%lld @%lu\n",
-+ ibss_dbg(sdata, "RX beacon SA=%pM BSSID=%pM TSF=0x%llx\n",
- mgmt->sa, mgmt->bssid,
-- (unsigned long long)rx_timestamp,
-+ (unsigned long long)rx_timestamp);
-+ ibss_dbg(sdata, "\tBCN=0x%llx diff=%lld @%lu\n",
- (unsigned long long)beacon_timestamp,
- (unsigned long long)(rx_timestamp - beacon_timestamp),
- jiffies);
-@@ -1537,9 +1537,9 @@ static void ieee80211_rx_mgmt_probe_req(
-
- tx_last_beacon = drv_tx_last_beacon(local);
-
-- ibss_dbg(sdata,
-- "RX ProbeReq SA=%pM DA=%pM BSSID=%pM (tx_last_beacon=%d)\n",
-- mgmt->sa, mgmt->da, mgmt->bssid, tx_last_beacon);
-+ ibss_dbg(sdata, "RX ProbeReq SA=%pM DA=%pM\n", mgmt->sa, mgmt->da);
-+ ibss_dbg(sdata, "\tBSSID=%pM (tx_last_beacon=%d)\n",
-+ mgmt->bssid, tx_last_beacon);
-
- if (!tx_last_beacon && is_multicast_ether_addr(mgmt->da))
- return;
+++ /dev/null
-From: Felix Fietkau <nbd@nbd.name>
-Date: Sat, 22 Sep 2018 15:05:59 +0200
-Subject: [PATCH] mac80211: allocate TXQs for active monitor interfaces
-
-Monitor mode interfaces with the active flag are passed down to the driver.
-Drivers using TXQ expect that all interfaces have allocated TXQs before
-they get added.
-
-Fixes: 79af1f866193d ("mac80211: avoid allocating TXQs that won't be used")
-Cc: stable@vger.kernel.org
-Reported-by: Catrinel Catrinescu <cc@80211.de>
-Signed-off-by: Felix Fietkau <nbd@nbd.name>
----
-
---- a/net/mac80211/iface.c
-+++ b/net/mac80211/iface.c
-@@ -1816,7 +1816,8 @@ int ieee80211_if_add(struct ieee80211_lo
-
- if (local->ops->wake_tx_queue &&
- type != NL80211_IFTYPE_AP_VLAN &&
-- type != NL80211_IFTYPE_MONITOR)
-+ (type != NL80211_IFTYPE_MONITOR ||
-+ (params->flags & MONITOR_FLAG_ACTIVE)))
- txq_size += sizeof(struct txq_info) +
- local->hw.txq_data_size;
-
+++ /dev/null
-From: Felix Fietkau <nbd@nbd.name>
-Date: Sat, 22 Sep 2018 15:20:50 +0200
-Subject: [PATCH] ath9k: add back support for using active monitor interfaces
- for tx99
-
-Various documented examples on how to set up tx99 with ath9k rely
-on setting up a regular monitor interface for setting the channel.
-My previous patch "ath9k: fix tx99 with monitor mode interface" made
-it possible to set it up this way again. However, it was removing support
-for using an active monitor interface, which is required for controlling
-the bitrate as well, since the bitrate is not passed down with a regular
-monitor interface.
-
-This patch partially reverts the previous one, but keeps support for using
-a regular monitor interface to keep documented steps working in cases
-where the bitrate does not matter
-
-Fixes: d9c52fd17cb48 ("ath9k: fix tx99 with monitor mode interface")
-Signed-off-by: Felix Fietkau <nbd@nbd.name>
----
-
---- a/drivers/net/wireless/ath/ath9k/ath9k.h
-+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
-@@ -1074,6 +1074,7 @@ struct ath_softc {
-
- struct ath_spec_scan_priv spec_priv;
-
-+ struct ieee80211_vif *tx99_vif;
- struct sk_buff *tx99_skb;
- bool tx99_state;
- s16 tx99_power;
---- a/drivers/net/wireless/ath/ath9k/main.c
-+++ b/drivers/net/wireless/ath/ath9k/main.c
-@@ -1251,8 +1251,13 @@ static int ath9k_add_interface(struct ie
- struct ath_vif *avp = (void *)vif->drv_priv;
- struct ath_node *an = &avp->mcast_node;
-
-- if (IS_ENABLED(CPTCFG_ATH9K_TX99))
-- return -EOPNOTSUPP;
-+ if (IS_ENABLED(CPTCFG_ATH9K_TX99)) {
-+ if (sc->cur_chan->nvifs >= 1) {
-+ mutex_unlock(&sc->mutex);
-+ return -EOPNOTSUPP;
-+ }
-+ sc->tx99_vif = vif;
-+ }
-
- mutex_lock(&sc->mutex);
-
-@@ -1337,6 +1342,7 @@ static void ath9k_remove_interface(struc
- ath9k_p2p_remove_vif(sc, vif);
-
- sc->cur_chan->nvifs--;
-+ sc->tx99_vif = NULL;
- if (!ath9k_is_chanctx_enabled())
- list_del(&avp->list);
-
---- a/drivers/net/wireless/ath/ath9k/tx99.c
-+++ b/drivers/net/wireless/ath/ath9k/tx99.c
-@@ -54,6 +54,7 @@ static struct sk_buff *ath9k_build_tx99_
- struct ieee80211_hdr *hdr;
- struct ieee80211_tx_info *tx_info;
- struct sk_buff *skb;
-+ struct ath_vif *avp;
-
- skb = alloc_skb(len, GFP_KERNEL);
- if (!skb)
-@@ -71,11 +72,17 @@ static struct sk_buff *ath9k_build_tx99_
- memcpy(hdr->addr2, hw->wiphy->perm_addr, ETH_ALEN);
- memcpy(hdr->addr3, hw->wiphy->perm_addr, ETH_ALEN);
-
-+ if (sc->tx99_vif) {
-+ avp = (struct ath_vif *) sc->tx99_vif->drv_priv;
-+ hdr->seq_ctrl |= cpu_to_le16(avp->seq_no);
-+ }
-+
- tx_info = IEEE80211_SKB_CB(skb);
- memset(tx_info, 0, sizeof(*tx_info));
- rate = &tx_info->control.rates[0];
- tx_info->band = sc->cur_chan->chandef.chan->band;
- tx_info->flags = IEEE80211_TX_CTL_NO_ACK;
-+ tx_info->control.vif = sc->tx99_vif;
- rate->count = 1;
- if (ah->curchan && IS_CHAN_HT(ah->curchan)) {
- rate->flags |= IEEE80211_TX_RC_MCS;
---- a/drivers/net/wireless/ath/ath9k/xmit.c
-+++ b/drivers/net/wireless/ath/ath9k/xmit.c
-@@ -2973,7 +2973,7 @@ int ath9k_tx99_send(struct ath_softc *sc
- return -EINVAL;
- }
-
-- ath_set_rates(NULL, NULL, bf);
-+ ath_set_rates(sc->tx99_vif, NULL, bf);
-
- ath9k_hw_set_desc_link(sc->sc_ah, bf->bf_desc, bf->bf_daddr);
- ath9k_hw_tx99_start(sc->sc_ah, txctl->txq->axq_qnum);
--- /dev/null
+From: Felix Fietkau <nbd@nbd.name>
+Date: Sat, 22 Sep 2018 15:20:50 +0200
+Subject: [PATCH] ath9k: add back support for using active monitor interfaces
+ for tx99
+
+Various documented examples on how to set up tx99 with ath9k rely
+on setting up a regular monitor interface for setting the channel.
+My previous patch "ath9k: fix tx99 with monitor mode interface" made
+it possible to set it up this way again. However, it was removing support
+for using an active monitor interface, which is required for controlling
+the bitrate as well, since the bitrate is not passed down with a regular
+monitor interface.
+
+This patch partially reverts the previous one, but keeps support for using
+a regular monitor interface to keep documented steps working in cases
+where the bitrate does not matter
+
+Fixes: d9c52fd17cb48 ("ath9k: fix tx99 with monitor mode interface")
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+---
+
+--- a/drivers/net/wireless/ath/ath9k/ath9k.h
++++ b/drivers/net/wireless/ath/ath9k/ath9k.h
+@@ -1074,6 +1074,7 @@ struct ath_softc {
+
+ struct ath_spec_scan_priv spec_priv;
+
++ struct ieee80211_vif *tx99_vif;
+ struct sk_buff *tx99_skb;
+ bool tx99_state;
+ s16 tx99_power;
+--- a/drivers/net/wireless/ath/ath9k/main.c
++++ b/drivers/net/wireless/ath/ath9k/main.c
+@@ -1251,8 +1251,13 @@ static int ath9k_add_interface(struct ie
+ struct ath_vif *avp = (void *)vif->drv_priv;
+ struct ath_node *an = &avp->mcast_node;
+
+- if (IS_ENABLED(CPTCFG_ATH9K_TX99))
+- return -EOPNOTSUPP;
++ if (IS_ENABLED(CPTCFG_ATH9K_TX99)) {
++ if (sc->cur_chan->nvifs >= 1) {
++ mutex_unlock(&sc->mutex);
++ return -EOPNOTSUPP;
++ }
++ sc->tx99_vif = vif;
++ }
+
+ mutex_lock(&sc->mutex);
+
+@@ -1337,6 +1342,7 @@ static void ath9k_remove_interface(struc
+ ath9k_p2p_remove_vif(sc, vif);
+
+ sc->cur_chan->nvifs--;
++ sc->tx99_vif = NULL;
+ if (!ath9k_is_chanctx_enabled())
+ list_del(&avp->list);
+
+--- a/drivers/net/wireless/ath/ath9k/tx99.c
++++ b/drivers/net/wireless/ath/ath9k/tx99.c
+@@ -54,6 +54,7 @@ static struct sk_buff *ath9k_build_tx99_
+ struct ieee80211_hdr *hdr;
+ struct ieee80211_tx_info *tx_info;
+ struct sk_buff *skb;
++ struct ath_vif *avp;
+
+ skb = alloc_skb(len, GFP_KERNEL);
+ if (!skb)
+@@ -71,11 +72,17 @@ static struct sk_buff *ath9k_build_tx99_
+ memcpy(hdr->addr2, hw->wiphy->perm_addr, ETH_ALEN);
+ memcpy(hdr->addr3, hw->wiphy->perm_addr, ETH_ALEN);
+
++ if (sc->tx99_vif) {
++ avp = (struct ath_vif *) sc->tx99_vif->drv_priv;
++ hdr->seq_ctrl |= cpu_to_le16(avp->seq_no);
++ }
++
+ tx_info = IEEE80211_SKB_CB(skb);
+ memset(tx_info, 0, sizeof(*tx_info));
+ rate = &tx_info->control.rates[0];
+ tx_info->band = sc->cur_chan->chandef.chan->band;
+ tx_info->flags = IEEE80211_TX_CTL_NO_ACK;
++ tx_info->control.vif = sc->tx99_vif;
+ rate->count = 1;
+ if (ah->curchan && IS_CHAN_HT(ah->curchan)) {
+ rate->flags |= IEEE80211_TX_RC_MCS;
+--- a/drivers/net/wireless/ath/ath9k/xmit.c
++++ b/drivers/net/wireless/ath/ath9k/xmit.c
+@@ -2973,7 +2973,7 @@ int ath9k_tx99_send(struct ath_softc *sc
+ return -EINVAL;
+ }
+
+- ath_set_rates(NULL, NULL, bf);
++ ath_set_rates(sc->tx99_vif, NULL, bf);
+
+ ath9k_hw_set_desc_link(sc->sc_ah, bf->bf_desc, bf->bf_daddr);
+ ath9k_hw_tx99_start(sc->sc_ah, txctl->txq->axq_qnum);
--- /dev/null
+From 2fef681a4cf7994c882190fd2417b95f30510afb Mon Sep 17 00:00:00 2001
+From: Jia-Shyr Chuang <saint.chuang@cypress.com>
+Date: Wed, 15 Aug 2018 04:23:09 -0500
+Subject: [PATCH] brcmfmac: add CYW89342 mini-PCIe device
+
+CYW89342 is a 2x2 MIMO, 802.11a/b/g/n/ac for WLAN. It is a member of
+4355/4359 family.
+
+Signed-off-by: Jia-Shyr Chuang <saint.chuang@cypress.com>
+Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+---
+ drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+@@ -2017,6 +2017,7 @@ static const struct dev_pm_ops brcmf_pci
+
+ static const struct pci_device_id brcmf_pcie_devid_table[] = {
+ BRCMF_PCIE_DEVICE(BRCM_PCIE_4350_DEVICE_ID),
++ BRCMF_PCIE_DEVICE_SUB(0x4355, BRCM_PCIE_VENDOR_ID_BROADCOM, 0x4355),
+ BRCMF_PCIE_DEVICE(BRCM_PCIE_4356_DEVICE_ID),
+ BRCMF_PCIE_DEVICE(BRCM_PCIE_43567_DEVICE_ID),
+ BRCMF_PCIE_DEVICE(BRCM_PCIE_43570_DEVICE_ID),
--- /dev/null
+From cb18e2e9ec71d42409a51b83546686c609780dde Mon Sep 17 00:00:00 2001
+From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
+Date: Wed, 22 Aug 2018 15:22:15 +0200
+Subject: [PATCH] brcmfmac: fix wrong strnchr usage
+
+strnchr takes arguments in the order of its name: string, max bytes to
+read, character to search for. Here we're passing '\n' aka 10 as the
+buffer size, and searching for sizeof(buf) aka BRCMF_DCMD_SMLEN aka
+256 (aka '\0', since it's implicitly converted to char) within those 10
+bytes.
+
+Just interchanging the last two arguments would still leave a bug,
+because if we've been successful once, there are not sizeof(buf)
+characters left after the new value of p.
+
+Since clmver is immediately afterwards passed as a %s argument, I assume
+that it is actually a properly nul-terminated string. For that case, we
+have strreplace().
+
+Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+---
+ drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+@@ -296,9 +296,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_i
+ /* Replace all newline/linefeed characters with space
+ * character
+ */
+- ptr = clmver;
+- while ((ptr = strnchr(ptr, '\n', sizeof(buf))) != NULL)
+- *ptr = ' ';
++ strreplace(clmver, '\n', ' ');
+
+ brcmf_dbg(INFO, "CLM version = %s\n", clmver);
+ }
--- /dev/null
+From: Arend van Spriel <arend.vanspriel@broadcom.com>
+Date: Wed, 5 Sep 2018 09:48:58 +0200
+Subject: [PATCH] brcmfmac: fix for proper support of 160MHz bandwidth
+
+Decoding of firmware channel information was not complete for 160MHz
+support. This resulted in the following warning:
+
+ WARNING: CPU: 2 PID: 2222 at .../broadcom/brcm80211/brcmutil/d11.c:196
+ brcmu_d11ac_decchspec+0x2e/0x100 [brcmutil]
+ Modules linked in: brcmfmac(O) brcmutil(O) sha256_generic cfg80211 ...
+ CPU: 2 PID: 2222 Comm: kworker/2:0 Tainted: G O
+ 4.17.0-wt-testing-x64-00002-gf1bed50 #1
+ Hardware name: Dell Inc. Latitude E6410/07XJP9, BIOS A07 02/15/2011
+ Workqueue: events request_firmware_work_func
+ RIP: 0010:brcmu_d11ac_decchspec+0x2e/0x100 [brcmutil]
+ RSP: 0018:ffffc90000047bd0 EFLAGS: 00010206
+ RAX: 000000000000e832 RBX: ffff8801146fe910 RCX: ffff8801146fd3c0
+ RDX: 0000000000002800 RSI: 0000000000000070 RDI: ffffc90000047c30
+ RBP: ffffc90000047bd0 R08: 0000000000000000 R09: ffffffffa0798c80
+ R10: ffff88012bca55e0 R11: ffff880110a4ea00 R12: ffff8801146f8000
+ R13: ffffc90000047c30 R14: ffff8801146fe930 R15: ffff8801138e02e0
+ FS: 0000000000000000(0000) GS:ffff88012bc80000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 00007f18ce8b8070 CR3: 000000000200a003 CR4: 00000000000206e0
+ Call Trace:
+ brcmf_setup_wiphybands+0x212/0x780 [brcmfmac]
+ brcmf_cfg80211_attach+0xae2/0x11a0 [brcmfmac]
+ brcmf_attach+0x1fc/0x4b0 [brcmfmac]
+ ? __kmalloc+0x13c/0x1c0
+ brcmf_pcie_setup+0x99b/0xe00 [brcmfmac]
+ brcmf_fw_request_done+0x16a/0x1f0 [brcmfmac]
+ request_firmware_work_func+0x36/0x60
+ process_one_work+0x146/0x350
+ worker_thread+0x4a/0x3b0
+ kthread+0x102/0x140
+ ? process_one_work+0x350/0x350
+ ? kthread_bind+0x20/0x20
+ ret_from_fork+0x35/0x40
+ Code: 66 90 0f b7 07 55 48 89 e5 89 c2 88 47 02 88 47 03 66 81 e2 00 38
+ 66 81 fa 00 18 74 6e 66 81 fa 00 20 74 39 66 81 fa 00 10 74 14 <0f>
+ 0b 66 25 00 c0 74 20 66 3d 00 c0 75 20 c6 47 04 01 5d c3 66
+ ---[ end trace 550c46682415b26d ]---
+ brcmfmac: brcmf_construct_chaninfo: Ignoring unexpected firmware channel 50
+
+This patch adds the missing stuff to properly handle this.
+
+Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
+Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
+Reviewed-by: Franky Lin <franky.lin@broadcom.com>
+Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
+---
+ .../net/wireless/broadcom/brcm80211/brcmutil/d11.c | 34 +++++++++++++++++++++-
+ .../broadcom/brcm80211/include/brcmu_wifi.h | 2 ++
+ 2 files changed, 35 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/broadcom/brcm80211/brcmutil/d11.c
++++ b/drivers/net/wireless/broadcom/brcm80211/brcmutil/d11.c
+@@ -77,6 +77,8 @@ static u16 d11ac_bw(enum brcmu_chan_bw b
+ return BRCMU_CHSPEC_D11AC_BW_40;
+ case BRCMU_CHAN_BW_80:
+ return BRCMU_CHSPEC_D11AC_BW_80;
++ case BRCMU_CHAN_BW_160:
++ return BRCMU_CHSPEC_D11AC_BW_160;
+ default:
+ WARN_ON(1);
+ }
+@@ -190,8 +192,38 @@ static void brcmu_d11ac_decchspec(struct
+ break;
+ }
+ break;
+- case BRCMU_CHSPEC_D11AC_BW_8080:
+ case BRCMU_CHSPEC_D11AC_BW_160:
++ switch (ch->sb) {
++ case BRCMU_CHAN_SB_LLL:
++ ch->control_ch_num -= CH_70MHZ_APART;
++ break;
++ case BRCMU_CHAN_SB_LLU:
++ ch->control_ch_num -= CH_50MHZ_APART;
++ break;
++ case BRCMU_CHAN_SB_LUL:
++ ch->control_ch_num -= CH_30MHZ_APART;
++ break;
++ case BRCMU_CHAN_SB_LUU:
++ ch->control_ch_num -= CH_10MHZ_APART;
++ break;
++ case BRCMU_CHAN_SB_ULL:
++ ch->control_ch_num += CH_10MHZ_APART;
++ break;
++ case BRCMU_CHAN_SB_ULU:
++ ch->control_ch_num += CH_30MHZ_APART;
++ break;
++ case BRCMU_CHAN_SB_UUL:
++ ch->control_ch_num += CH_50MHZ_APART;
++ break;
++ case BRCMU_CHAN_SB_UUU:
++ ch->control_ch_num += CH_70MHZ_APART;
++ break;
++ default:
++ WARN_ON_ONCE(1);
++ break;
++ }
++ break;
++ case BRCMU_CHSPEC_D11AC_BW_8080:
+ default:
+ WARN_ON_ONCE(1);
+ break;
+--- a/drivers/net/wireless/broadcom/brcm80211/include/brcmu_wifi.h
++++ b/drivers/net/wireless/broadcom/brcm80211/include/brcmu_wifi.h
+@@ -29,6 +29,8 @@
+ #define CH_UPPER_SB 0x01
+ #define CH_LOWER_SB 0x02
+ #define CH_EWA_VALID 0x04
++#define CH_70MHZ_APART 14
++#define CH_50MHZ_APART 10
+ #define CH_30MHZ_APART 6
+ #define CH_20MHZ_APART 4
+ #define CH_10MHZ_APART 2
--- /dev/null
+From: Arend van Spriel <arend.vanspriel@broadcom.com>
+Date: Wed, 5 Sep 2018 09:48:59 +0200
+Subject: [PATCH] brcmfmac: increase buffer for obtaining firmware capabilities
+
+When obtaining the firmware capability a buffer is provided of 512
+bytes. However, if all features in firmware are supported the buffer
+needs to be 565 bytes as otherwise truncated information is retrieved
+from firmware. Increasing the buffer to 768 bytes on stack.
+
+Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
+Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
+Reviewed-by: Franky Lin <franky.lin@broadcom.com>
+Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
+---
+ drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
+@@ -178,7 +178,7 @@ static void brcmf_feat_iovar_data_set(st
+ ifp->fwil_fwerr = false;
+ }
+
+-#define MAX_CAPS_BUFFER_SIZE 512
++#define MAX_CAPS_BUFFER_SIZE 768
+ static void brcmf_feat_firmware_capabilities(struct brcmf_if *ifp)
+ {
+ char caps[MAX_CAPS_BUFFER_SIZE];
--- /dev/null
+From: Felix Fietkau <nbd@nbd.name>
+Date: Sat, 22 Sep 2018 15:05:59 +0200
+Subject: [PATCH] mac80211: allocate TXQs for active monitor interfaces
+
+Monitor mode interfaces with the active flag are passed down to the driver.
+Drivers using TXQ expect that all interfaces have allocated TXQs before
+they get added.
+
+Fixes: 79af1f866193d ("mac80211: avoid allocating TXQs that won't be used")
+Cc: stable@vger.kernel.org
+Reported-by: Catrinel Catrinescu <cc@80211.de>
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+---
+
+--- a/net/mac80211/iface.c
++++ b/net/mac80211/iface.c
+@@ -1834,7 +1834,8 @@ int ieee80211_if_add(struct ieee80211_lo
+
+ if (local->ops->wake_tx_queue &&
+ type != NL80211_IFTYPE_AP_VLAN &&
+- type != NL80211_IFTYPE_MONITOR)
++ (type != NL80211_IFTYPE_MONITOR ||
++ (params->flags & MONITOR_FLAG_ACTIVE)))
+ txq_size += sizeof(struct txq_info) +
+ local->hw.txq_data_size;
+
projects / openwrt / staging / blogic.git / commitdiff