kernel/linux.git/drivers/net/wireless, branch linux-4.20.y

ath9k: Avoid OF no-EEPROM quirks without qca,no-eeprom

2019-03-13T21:04:20+00:00

commit ce938231bd3b1d7af3cbd8836f084801090470e1 upstream. 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) has some kind of default - not unique mac address - set and requires to set the correct MAC address via mac-address devicetree property, however: "some cards come with a physical EEPROM chip [or OTP] 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]. Thanks to Christian Lamparter for all his help on troubleshooting this issue and the basis for this patch. [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/ Fixes: 138b41253d9c ("ath9k: parse the device configuration from an OF node") Reviewed-by: Martin Blumenstingl Tested-by: Martin Blumenstingl Signed-off-by: Daniel F. Dickinson Signed-off-by: Kalle Valo Cc: Christian Lamparter Signed-off-by: Greg Kroah-Hartman

ath10k: correct bus type for WCN3990

2019-03-13T21:04:13+00:00

[ Upstream commit 2c2008a63e482654ab137c84d3c61c03b75e7df6 ] WCN3990 is SNOC, not PCI. This prevents probing WCN3990. Fixes: 367c899f622c ("ath10k: add bus type check in ath10k_init_hw_params") Signed-off-by: Brian Norris Reviewed-by: Bjorn Andersson Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin

wlcore: sdio: Fixup power on/off sequence

2019-03-13T21:04:10+00:00

[ Upstream commit 13e62626c578d9889ebbda7c521be5adff9bef8e ] During "wlan-up", we are programming the FW into the WiFi-chip. However, re-programming the FW doesn't work, unless a power cycle of the WiFi-chip is made in-between the programmings. To conform to this requirement and to fix the regression in a simple way, let's start by allowing that the SDIO card (WiFi-chip) may stay powered on (runtime resumed) when wl12xx_sdio_power_off() returns. The intent with the current code is to treat this scenario as an error, but unfortunate this doesn't work as expected, so let's fix this. The other part is to guarantee that a power cycle of the SDIO card has been completed when wl12xx_sdio_power_on() returns, as to allow the FW programming to succeed. However, relying solely on runtime PM to deal with this isn't sufficient. For example, userspace may prevent runtime suspend via sysfs for the device that represents the SDIO card, leading to that the mmc core also keeps it powered on. For this reason, let's instead do a brute force power cycle in wl12xx_sdio_power_on(). Fixes: 728a9dc61f13 ("wlcore: sdio: Fix flakey SDIO runtime PM handling") Signed-off-by: Ulf Hansson Tested-by: Tony Lindgren Tested-by: Anders Roxell Signed-off-by: Ulf Hansson Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin

mt76x0u: fix suspend/resume

2019-02-27T09:09:40+00:00

commit d04ca383860bef90a0dab4eb397907f7f05e839e upstream. We need to reset MCU and do other initializations on resume otherwise MT7610U device will fail to initialize, what cause system hung due to USB requests timeouts. Patch fixes 4.19 -> 4.20 regression. Cc: stable@vger.kernel.org # 4.20+ Signed-off-by: Stanislaw Gruszka Acked-by: Lorenzo Bianconi Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

ath9k: dynack: check da->enabled first in sampling routines

2019-02-12T19:02:39+00:00

commit 9d3d65a91f027b8a9af5e63752d9b78cb10eb92d upstream. Check da->enabled flag first in ath_dynack_sample_tx_ts and ath_dynack_sample_ack_ts routines in order to avoid useless processing Tested-by: Koen Vandeputte Signed-off-by: Lorenzo Bianconi Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

ath9k: dynack: make ewma estimation faster

2019-02-12T19:02:39+00:00

commit 0c60c490830a1a756c80f8de8d33d9c6359d4a36 upstream. In order to make propagation time estimation faster, use current sample as ewma output value during 'late ack' tracking Tested-by: Koen Vandeputte Signed-off-by: Lorenzo Bianconi Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

ath10k: fix tx_stats memory leak

2019-02-12T19:02:25+00:00

[ Upstream commit 386f97e3b201d18578abb0e7037b85a1ae50c0a3 ] Memory of tx_stats was allocated when a STA was added. But it's not freed if the STA failed to be added to driver. This issue could be seen in MDK3 attack case when STA number reached the limit. Tested: QCA9984 with firmware ver 10.4-3.9.0.1-00005 Signed-off-by: Zhi Chen Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin

ath10k: fix kernel panic due to use after free

2019-02-12T19:02:25+00:00

[ Upstream commit 553a7cca769d551f1317186760631487c47e23bf ] This issue arise in a race condition between ath10k_sta_state() and ath10k_htt_fetch_peer_stats(), explained in below scenario Steps: 1. In ath10k_sta_state(), arsta->tx_stats get deallocated before peer deletion when the station moves from IEEE80211_STA_NONE to IEEE80211_STA_NOTEXIST state. 2. Meanwhile ath10k receive HTT_T2H_MSG_TYPE_PEER_STATS message. In ath10k_htt_fetch_peer_stats(), arsta->tx_stats get accessed after the peer validation check. Since arsta->tx_stats get freed before the peer deletion [1]. ath10k_htt_fetch_peer_stats() ended up in "use after free" situation. Fixed this issue by moving the arsta->tx_stats free handling after the peer deletion. so that ath10k_htt_fetch_peer_stats() will not end up in "use after free" situation. Kernel Panic: Unable to handle kernel NULL pointer dereference at virtual address 00000286 pgd = d8754000 [00000286] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM ... CPU: 0 PID: 6245 Comm: hostapd Not tainted task: dc44cac0 ti: d4a38000 task.ti: d4a38000 PC is at kmem_cache_alloc+0x7c/0x114 LR is at ath10k_sta_state+0x190/0xd58 [ath10k_core] pc : [] lr : [] psr: 20000013 sp : d4a39b88 ip : 00000000 fp : 00000001 r10: 00000000 r9 : 1d3bc000 r8 : 00000dc0 r7 : 000080d0 r6 : d4a38000 r5 : dd401b00 r4 : 00000286 r3 : 00000000 r2 : d4a39ba0 r1 : 000080d0 r0 : dd401b00 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5787d Table: 5a75406a DAC: 00000015 Process hostapd (pid: 6245, stack limit = 0xd4a38238) Stack: (0xd4a39b88 to 0xd4a3a000) ... [] (kmem_cache_alloc) from [] (ath10k_sta_state+0x190/0xd58 [ath10k_core]) [] (ath10k_sta_state [ath10k_core]) from [] (sta_info_insert_rcu+0x418/0x61c [mac80211]) [] (sta_info_insert_rcu [mac80211]) from [] (ieee80211_add_station+0xf0/0x134 [mac80211]) [] (ieee80211_add_station [mac80211]) from [] (nl80211_new_station+0x330/0x36c [cfg80211]) [] (nl80211_new_station [cfg80211]) from [] (extack_doit+0x2c/0x74 [compat]) [] (extack_doit [compat]) from [] (genl_rcv_msg+0x274/0x30c) [] (genl_rcv_msg) from [] (netlink_rcv_skb+0x58/0xac) [] (netlink_rcv_skb) from [] (genl_rcv+0x20/0x34) [] (genl_rcv) from [] (netlink_unicast+0x11c/0x204) [] (netlink_unicast) from [] (netlink_sendmsg+0x30c/0x370) [] (netlink_sendmsg) from [] (sock_sendmsg+0x70/0x84) [] (sock_sendmsg) from [] (___sys_sendmsg.part.3+0x188/0x228) [] (___sys_sendmsg.part.3) from [] (__sys_sendmsg+0x4c/0x70) [] (__sys_sendmsg) from [] (ret_fast_syscall+0x0/0x44) Code: ebfffec1 e1a04000 ea00001b e5953014 (e7940003) ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped old beacon Hardware tested: QCA9984 Firmware tested: 10.4-3.6.0.1-00004 Fixes: a904417fc ("ath10k: add extended per sta tx statistics support") Signed-off-by: Karthikeyan Periyasamy Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin

iwlwifi: mvm: fix setting HE ppe FW config

2019-02-12T19:02:24+00:00

[ Upstream commit 189b8d441b0f7825f0b4278851c52afaa0515ed2 ] The FW expects to get the ppe value for each NSS-BW pair in the same format as in the he phy capabilities IE, which means that a value of 0 implies ppe should be used for BPSK (mcs 0). If there are no PPE thresholds in the IE, or if for some NSS-RU pair there's no threshold set for it (this could happen because it's a variable-sized field), it means no PPE should not be used for that pair, so the value sent to FW should be 7 which corresponds to "none". Fixes: 514c30696fbc ("iwlwifi: add support for IEEE802.11ax") Signed-off-by: Naftali Goldstein Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin

cw1200: Fix concurrency use-after-free bugs in cw1200_hw_scan()

2019-02-12T19:02:24+00:00

[ Upstream commit 4f68ef64cd7feb1220232bd8f501d8aad340a099 ] The function cw1200_bss_info_changed() and cw1200_hw_scan() can be concurrently executed. The two functions both access a possible shared variable "frame.skb". This shared variable is freed by dev_kfree_skb() in cw1200_upload_beacon(), which is called by cw1200_bss_info_changed(). The free operation is protected by a mutex lock "priv->conf_mutex" in cw1200_bss_info_changed(). In cw1200_hw_scan(), this shared variable is accessed without the protection of the mutex lock "priv->conf_mutex". Thus, concurrency use-after-free bugs may occur. To fix these bugs, the original calls to mutex_lock(&priv->conf_mutex) and mutex_unlock(&priv->conf_mutex) are moved to the places, which can protect the accesses to the shared variable. Signed-off-by: Jia-Ju Bai Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin