From 3183430df4018b6976a286a1103356e77ce5c037 Mon Sep 17 00:00:00 2001 From: Hauke Mehrtens Date: Thu, 28 Mar 2019 16:00:43 +0100 Subject: 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 Tested-by: Daniel Engberg --- ...ath9k-only-mask-use_eeprom-on-of-noeeprom.patch | 73 ---------------------- 1 file changed, 73 deletions(-) delete mode 100644 package/kernel/mac80211/patches/ath/558-ath9k-only-mask-use_eeprom-on-of-noeeprom.patch (limited to 'package/kernel/mac80211/patches/ath/558-ath9k-only-mask-use_eeprom-on-of-noeeprom.patch') 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 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 ---- 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; - } - -- cgit v1.2.3