mac80211: update to version 4.19.32-1

The removed patches are now integrated in the upstream kernel.
Refresh all patches on top of the new backports release.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Tested-by: Daniel Engberg <daniel.engberg.lists@pyret.net>

1 files changed, 0 insertions, 73 deletions

diff --git a/package/kernel/mac80211/patches/ath/558-ath9k-only-mask-use_eeprom-on-of-noeeprom.patch b/package/kernel/mac80211/patches/ath/558-ath9k-only-mask-use_eeprom-on-of-noeeprom.patch
deleted file mode 100644
index f0656de253..0000000000
--- a/package/kernel/mac80211/patches/ath/558-ath9k-only-mask-use_eeprom-on-of-noeeprom.patch
+++ /dev/null
@@ -1,73 +0,0 @@
-ath9k: Avoid OF no-EEPROM quirks without qca,no-eeprom
-
-ath9k_of_init() function[0] was initially written on the assumption that
-if someone had an explicit ath9k OF node that "there must be something
-wrong, why would someone add an OF node if everything is fine"[1]
-(Quoting Martin Blumenstingl)
-
-"it turns out it's not that simple. with your requirements I'm now aware
-of two use-cases where the current code in ath9k_of_init() doesn't work
-without modifications"[1]
-
-The "your requirements" Martin speaks of is the result of the fact that I
-have a device (PowerCloud Systems CR5000) that uses the EEPROM for
-caldata and firmware but for which the MAC address is take from the MTD
-"art" partition[2], or more succinctly:
-
-"some cards come with a physical EEPROM chip so "qca,no-eeprom" should not
-be set (your use-case). in this case AH_USE_EEPROM should be set (which
-is the default when there is no OF node)"[1]
-
-The other use case is:
-
-the firmware on some PowerMac G5 seems to add a OF node for the ath9k
-card automatically. depending on the EEPROM on the card AH_NO_EEP_SWAP
-should be unset (which is the default when there is no OF node). see [3]
-
-After this patch to ath9k_of_init() the new behavior will be:
-
-    if there's no OF node then everything is the same as before
-    if there's an empty OF node then ath9k will use the hardware EEPROM
-      (before ath9k would fail to initialize because no EEPROM data was
-      provided by userspace)
-    if there's an OF node with only a MAC address then ath9k will use
-      the MAC address and the hardware EEPROM (see the case above)
-    with "qca,no-eeprom" EEPROM data from userspace will be requested.
-      the behavior here will not change
-[1]
-
-Martin provides additional background on EEPROM swapping[1] which I have
-included in the patch annotation but not the commit message.
-
-Thanks to Christian Lampartar <chunkeey@gmail.com> for all his help on
-troubleshooting this issue and the basis for this patch.
-
-Fixes: 138b41253d9c ("ath9k: parse the device configuration from an OF node")
-
-[0]https://elixir.bootlin.com/linux/v4.20-rc7/source/drivers/net/wireless/ath/ath9k/init.c#L615
-[1]https://github.com/openwrt/openwrt/pull/1645#issuecomment-448027058
-[2]https://github.com/openwrt/openwrt/pull/1613
-[3]https://patchwork.kernel.org/patch/10241731/
-
-Signed-off-by: Daniel F. Dickinson <cshored@thecshore.com>
---- a/drivers/net/wireless/ath/ath9k/init.c
-+++ b/drivers/net/wireless/ath/ath9k/init.c
-@@ -642,15 +642,15 @@ static int ath9k_of_init(struct ath_soft
- 		ret = ath9k_eeprom_request(sc, eeprom_name);
- 		if (ret)
- 			return ret;
-+
-+		ah->ah_flags &= ~AH_USE_EEPROM;
-+		ah->ah_flags |= AH_NO_EEP_SWAP;
- 	}
- 
- 	mac = of_get_mac_address(np);
- 	if (mac)
- 		ether_addr_copy(common->macaddr, mac);
- 
--	ah->ah_flags &= ~AH_USE_EEPROM;
--	ah->ah_flags |= AH_NO_EEP_SWAP;
--
- 	return 0;
- }
-