12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273 |
- 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 <[email protected]> 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 <[email protected]>
- --- 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;
- }
-
|