From 4346de8d34b541bb6b2eb7025119aeb150e4dab8 Mon Sep 17 00:00:00 2001
From: Daniel Golle <daniel@makrotopia.org>
Date: Fri, 23 Aug 2019 18:09:04 +0200
Subject: [PATCH] mac80211: rt2x00: import pending patches

https://patchwork.kernel.org/patch/11111605/
https://patchwork.kernel.org/patch/11110703/

Fixes: 91c84e87c249 ("mac80211: rt2x00: clear IV's on start to fix AP mode regression")
Fixes: 0b2c42ced21a ("mac80211: Update to version 5.2-rc7")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
 ...-rt2x00-clear-up-IV-s-on-key-removal.patch | 57 +++++++++++++++++++
 ...1_TX_STAT_AMPDU_NO_BACK-on-tx-status.patch | 52 +++++++++++++++++
 2 files changed, 109 insertions(+)
 create mode 100644 package/kernel/mac80211/patches/rt2x00/011-rt2x00-clear-up-IV-s-on-key-removal.patch
 create mode 100644 package/kernel/mac80211/patches/rt2x00/015-rt2x00-do-not-set-IEEE80211_TX_STAT_AMPDU_NO_BACK-on-tx-status.patch

diff --git a/package/kernel/mac80211/patches/rt2x00/011-rt2x00-clear-up-IV-s-on-key-removal.patch b/package/kernel/mac80211/patches/rt2x00/011-rt2x00-clear-up-IV-s-on-key-removal.patch
new file mode 100644
index 000000000000..06430b0ec977
--- /dev/null
+++ b/package/kernel/mac80211/patches/rt2x00/011-rt2x00-clear-up-IV-s-on-key-removal.patch
@@ -0,0 +1,57 @@
+From patchwork Fri Aug 23 12:48:03 2019
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+X-Patchwork-Submitter: Stanislaw Gruszka <sgruszka@redhat.com>
+X-Patchwork-Id: 11111605
+X-Patchwork-Delegate: kvalo@adurom.com
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+To: linux-wireless@vger.kernel.org
+Subject: [PATCH 5.3] rt2x00: clear up IV's on key removal
+Date: Fri, 23 Aug 2019 14:48:03 +0200
+Message-Id: <1566564483-31088-1-git-send-email-sgruszka@redhat.com>
+Sender: linux-wireless-owner@vger.kernel.org
+List-ID: <linux-wireless.vger.kernel.org>
+X-Mailing-List: linux-wireless@vger.kernel.org
+
+After looking at code I realized that my previous fix
+95844124385e ("rt2x00: clear IV's on start to fix AP mode regression")
+was incomplete. We can still have wrong IV's after re-keyring.
+To fix that, clear up IV's also on key removal.
+
+Fixes: 710e6cc1595e ("rt2800: do not nullify initialization vector data")
+Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
+---
+ drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 19 ++++++++++++-------
+ 1 file changed, 12 insertions(+), 7 deletions(-)
+
+diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+index ecbe78b8027b..28e2de04834e 100644
+--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
++++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+@@ -1654,13 +1654,18 @@ static void rt2800_config_wcid_attr_cipher(struct rt2x00_dev *rt2x00dev,
+ 
+ 	offset = MAC_IVEIV_ENTRY(key->hw_key_idx);
+ 
+-	rt2800_register_multiread(rt2x00dev, offset,
+-				  &iveiv_entry, sizeof(iveiv_entry));
+-	if ((crypto->cipher == CIPHER_TKIP) ||
+-	    (crypto->cipher == CIPHER_TKIP_NO_MIC) ||
+-	    (crypto->cipher == CIPHER_AES))
+-		iveiv_entry.iv[3] |= 0x20;
+-	iveiv_entry.iv[3] |= key->keyidx << 6;
++	if (crypto->cmd == SET_KEY) {
++		rt2800_register_multiread(rt2x00dev, offset,
++					  &iveiv_entry, sizeof(iveiv_entry));
++		if ((crypto->cipher == CIPHER_TKIP) ||
++		    (crypto->cipher == CIPHER_TKIP_NO_MIC) ||
++		    (crypto->cipher == CIPHER_AES))
++			iveiv_entry.iv[3] |= 0x20;
++		iveiv_entry.iv[3] |= key->keyidx << 6;
++	} else {
++		memset(&iveiv_entry, 0, sizeof(iveiv_entry));
++	}
++
+ 	rt2800_register_multiwrite(rt2x00dev, offset,
+ 				   &iveiv_entry, sizeof(iveiv_entry));
+ }
diff --git a/package/kernel/mac80211/patches/rt2x00/015-rt2x00-do-not-set-IEEE80211_TX_STAT_AMPDU_NO_BACK-on-tx-status.patch b/package/kernel/mac80211/patches/rt2x00/015-rt2x00-do-not-set-IEEE80211_TX_STAT_AMPDU_NO_BACK-on-tx-status.patch
new file mode 100644
index 000000000000..9ac115fd9772
--- /dev/null
+++ b/package/kernel/mac80211/patches/rt2x00/015-rt2x00-do-not-set-IEEE80211_TX_STAT_AMPDU_NO_BACK-on-tx-status.patch
@@ -0,0 +1,52 @@
+From patchwork Fri Aug 23 07:09:56 2019
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+X-Patchwork-Submitter: Stanislaw Gruszka <sgruszka@redhat.com>
+X-Patchwork-Id: 11110703
+X-Patchwork-Delegate: kvalo@adurom.com
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+To: linux-wireless@vger.kernel.org
+Subject: [PATCH] rt2x00: do not set IEEE80211_TX_STAT_AMPDU_NO_BACK on tx
+ status
+Date: Fri, 23 Aug 2019 09:09:56 +0200
+Message-Id: <1566544196-20371-1-git-send-email-sgruszka@redhat.com>
+Sender: linux-wireless-owner@vger.kernel.org
+List-ID: <linux-wireless.vger.kernel.org>
+X-Mailing-List: linux-wireless@vger.kernel.org
+
+According to documentation IEEE80211_TX_STAT_AMPDU_NO_BACK is suppose
+to be used when we do not recive BA (BlockAck). However on rt2x00 we
+use it when remote station fail to decode one or more subframes within
+AMPDU (some bits are not set in BlockAck bitmap). Setting the flag result
+in sent of BAR (BlockAck Request) frame and this might result of abuse
+of BA session, since remote station can sent BA with incorrect
+sequence numbers after receiving BAR. This problem is visible especially
+when connecting two rt2800 devices.
+
+Previously I observed some performance benefits when using the flag
+when connecting with iwlwifi devices. But currently possibly due
+to reacent changes in rt2x00 removing the flag has no effect on
+those test cases.
+
+So remove the IEEE80211_TX_STAT_AMPDU_NO_BACK.
+
+Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
+---
+ drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 3 ---
+ 1 file changed, 3 deletions(-)
+
+diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
+index 9d158237ac67..c3eab767bc21 100644
+--- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
++++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
+@@ -371,9 +371,6 @@ static void rt2x00lib_fill_tx_status(struct rt2x00_dev *rt2x00dev,
+ 				  IEEE80211_TX_CTL_AMPDU;
+ 		tx_info->status.ampdu_len = 1;
+ 		tx_info->status.ampdu_ack_len = success ? 1 : 0;
+-
+-		if (!success)
+-			tx_info->flags |= IEEE80211_TX_STAT_AMPDU_NO_BACK;
+ 	}
+ 
+ 	if (rate_flags & IEEE80211_TX_RC_USE_RTS_CTS) {
-- 
2.30.2