summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/ath/ath9k/main.c
AgeCommit message (Collapse)Author
2024-06-26wifi: mac80211: inform the low level if drv_stop() is a suspendEmmanuel Grumbach
This will allow the low level driver to take different actions for different flows. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240618192529.739036208b6e.Ie18a2fe8e02bf2717549d39420b350cfdaf3d317@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-04wifi: ath9k: work around memset overflow warningArnd Bergmann
gcc-9 and some other older versions produce a false-positive warning for zeroing two fields In file included from include/linux/string.h:369, from drivers/net/wireless/ath/ath9k/main.c:18: In function 'fortify_memset_chk', inlined from 'ath9k_ps_wakeup' at drivers/net/wireless/ath/ath9k/main.c:140:3: include/linux/fortify-string.h:462:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 462 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Using a struct_group seems to reliably avoid the warning and not make the code much uglier. The combined memset() should even save a couple of cpu cycles. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://msgid.link/20240328135509.3755090-3-arnd@kernel.org
2024-02-08wifi: mac80211: simplify non-chanctx driversJohannes Berg
There are still surprisingly many non-chanctx drivers, but in mac80211 that code is a bit awkward. Simplify this by having those drivers assign 'emulated' ops, so that the mac80211 code can be more unified between non-chanctx/chanctx drivers. This cuts the number of places caring about it by about 15, which are scattered across - now they're fewer and no longer in the channel context handling. Link: https://msgid.link/20240129194108.6d0ead50f5cf.I60d093b2fc81ca1853925a4d0ac3a2337d5baa5b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-12-13wifi: ath9k: reset survey of current channel after a scan startedHancheng Yang
In the `ath_set_channel()` function, we only reset surveys that are not from the current channel. This leads to the accumulation of survey data for the current channel indefinitely. This may not be the most optimal approach, as we want the ACS to rely on the most recent survey. So reset the survey data for the current channel at the start of each scan. Signed-off-by: Hancheng Yang <hyang@freebox.fr> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20231205170623.3029689-1-hyang@freebox.fr
2023-08-23wifi: ath: remove unused-but-set parameterArnd Bergmann
This has never been used since the driver was merged, but it now causes a W=1 warning in recent clang versions drivers/net/wireless/ath/ath9k/main.c:1566:21: error: parameter 'changed_flags' set but not used [-Werror,-Wunused-but-set-parameter] drivers/net/wireless/ath/ath9k/htc_drv_main.c:1258:25: error: parameter 'changed_flags' set but not used [-Werror,-Wunused-but-set-parameter] drivers/net/wireless/ath/ath5k/mac80211-ops.c:367:62: error: parameter 'changed_flags' set but not used [-Werror,-Wunused-but-set-parameter] Remove the bit manipulation on the otherwise unused parameter. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230814073255.1065242-1-arnd@kernel.org
2023-06-21wifi: ath9k: convert msecs to jiffies where neededDmitry Antipov
Since 'ieee80211_queue_delayed_work()' expects timeout in jiffies and not milliseconds, 'msecs_to_jiffies()' should be used in 'ath_restart_work()' and '__ath9k_flush()'. Fixes: d63ffc45c5d3 ("ath9k: rename tx_complete_work to hw_check_work") Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230613134655.248728-1-dmantipov@yandex.ru
2023-06-13wifi: ath9k: Fix possible stall on ath9k_txq_list_has_key()Remi Pommarel
On EDMA capable hardware, ath9k_txq_list_has_key() can enter infinite loop if it is called while all txq_fifos have packets that use different key that the one we are looking for. Fix it by exiting the loop if all txq_fifos have been checked already. Because this loop is called under spin_lock_bh() (see ath_txq_lock) it causes the following rcu stall: rcu: INFO: rcu_sched self-detected stall on CPU ath10k_pci 0000:01:00.0: failed to read temperature -11 rcu: 1-....: (5254 ticks this GP) idle=189/1/0x4000000000000002 softirq=8442983/8442984 fqs=2579 (t=5257 jiffies g=17983297 q=334) Task dump for CPU 1: task:hostapd state:R running task stack: 0 pid: 297 ppid: 289 flags:0x0000000a Call trace: dump_backtrace+0x0/0x170 show_stack+0x1c/0x24 sched_show_task+0x140/0x170 dump_cpu_task+0x48/0x54 rcu_dump_cpu_stacks+0xf0/0x134 rcu_sched_clock_irq+0x8d8/0x9fc update_process_times+0xa0/0xec tick_sched_timer+0x5c/0xd0 __hrtimer_run_queues+0x154/0x320 hrtimer_interrupt+0x120/0x2f0 arch_timer_handler_virt+0x38/0x44 handle_percpu_devid_irq+0x9c/0x1e0 handle_domain_irq+0x64/0x90 gic_handle_irq+0x78/0xb0 call_on_irq_stack+0x28/0x38 do_interrupt_handler+0x54/0x5c el1_interrupt+0x2c/0x4c el1h_64_irq_handler+0x14/0x1c el1h_64_irq+0x74/0x78 ath9k_txq_has_key+0x1bc/0x250 [ath9k] ath9k_set_key+0x1cc/0x3dc [ath9k] drv_set_key+0x78/0x170 ieee80211_key_replace+0x564/0x6cc ieee80211_key_link+0x174/0x220 ieee80211_add_key+0x11c/0x300 nl80211_new_key+0x12c/0x330 genl_family_rcv_msg_doit+0xbc/0x11c genl_rcv_msg+0xd8/0x1c4 netlink_rcv_skb+0x40/0x100 genl_rcv+0x3c/0x50 netlink_unicast+0x1ec/0x2c0 netlink_sendmsg+0x198/0x3c0 ____sys_sendmsg+0x210/0x250 ___sys_sendmsg+0x78/0xc4 __sys_sendmsg+0x4c/0x90 __arm64_sys_sendmsg+0x28/0x30 invoke_syscall.constprop.0+0x60/0x100 do_el0_svc+0x48/0xd0 el0_svc+0x14/0x50 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x158/0x15c This rcu stall is hard to reproduce as is, but changing ATH_TXFIFO_DEPTH from 8 to 2 makes it reasonably easy to reproduce. Fixes: ca2848022c12 ("ath9k: Postpone key cache entry deletion for TXQ frames reference it") Signed-off-by: Remi Pommarel <repk@triplefau.lt> Tested-by: Nicolas Escande <nico.escande@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230609093744.1985-1-repk@triplefau.lt
2022-07-15wifi: mac80211: replace link_id with link_conf in ↵Gregory Greenman
switch/(un)assign_vif_chanctx() Since mac80211 already has a protected pointer to link_conf, pass it to the driver to avoid additional RCU locking. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-15wifi: mac80211: change QoS settings API to take link into accountJohannes Berg
Take the link into account in the QoS settings (EDCA parameters) APIs. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-06-20wifi: mac80211: make channel context code MLO-awareJohannes Berg
Make the channel context code MLO aware, along with some functions that it uses, so that the chan.c file is now MLD-clean and no longer uses deflink/bss_conf/etc. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-06-20wifi: mac80211: split bss_info_changed methodJohannes Berg
Split the bss_info_changed method to vif_cfg_changed and link_info_changed, with the latter getting a link ID. Also change the 'changed' parameter to u64 already, we know we need that. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-06-20wifi: mac80211: move interface config to new structJohannes Berg
We'll use bss_conf for per-link configuration later, so move out all the non-link-specific data out into a new struct ieee80211_vif_cfg used in the vif. Some adjustments were done with the following spatch: @@ expression sdata; struct ieee80211_vif *vifp; identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator }; @@ ( -sdata->vif.bss_conf.var +sdata->vif.cfg.var | -vifp->bss_conf.var +vifp->cfg.var ) @bss_conf@ struct ieee80211_bss_conf *bss_conf; identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator }; @@ -bss_conf->var +vif_cfg->var (though more manual fixups were needed, e.g. replacing "vif_cfg->" by "vif->cfg." in many files.) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-03Merge tag 'wireless-next-2022-05-03' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v5.19 First set of patches for v5.19 and this is a big one. We have two new drivers, a change in mac80211 STA API affecting most drivers and ath11k getting support for WCN6750. And as usual lots of fixes and cleanups all over. Major changes: new drivers - wfx: silicon labs devices - plfxlc: pureLiFi X, XL, XC devices mac80211 - host based BSS color collision detection - prepare sta handling for IEEE 802.11be Multi-Link Operation (MLO) support rtw88 - support TP-Link T2E devices rtw89 - support firmware crash simulation - preparation for 8852ce hardware support ath11k - Wake-on-WLAN support for QCA6390 and WCN6855 - device recovery (firmware restart) support for QCA6390 and WCN6855 - support setting Specific Absorption Rate (SAR) for WCN6855 - read country code from SMBIOS for WCN6855/QCA6390 - support for WCN6750 wcn36xx - support for transmit rate reporting to user space * tag 'wireless-next-2022-05-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (228 commits) rtw89: 8852c: rfk: add DPK rtw89: 8852c: rfk: add IQK rtw89: 8852c: rfk: add RX DCK rtw89: 8852c: rfk: add RCK rtw89: 8852c: rfk: add TSSI rtw89: 8852c: rfk: add LCK rtw89: 8852c: rfk: add DACK rtw89: 8852c: rfk: add RFK tables plfxlc: fix le16_to_cpu warning for beacon_interval rtw88: remove a copy of the NAPI_POLL_WEIGHT define carl9170: tx: fix an incorrect use of list iterator wil6210: use NAPI_POLL_WEIGHT for napi budget ath10k: remove a copy of the NAPI_POLL_WEIGHT define ath11k: Add support for WCN6750 device ath11k: Datapath changes to support WCN6750 ath11k: HAL changes to support WCN6750 ath11k: Add QMI changes for WCN6750 ath11k: Fetch device information via QMI for WCN6750 ath11k: Add register access logic for WCN6750 ath11k: Add HW params for WCN6750 ... ==================== Link: https://lore.kernel.org/r/20220503153622.C1671C385A4@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-04-11mac80211: prepare sta handling for MLO supportSriram R
Currently in mac80211 each STA object is represented using sta_info datastructure with the associated STA specific information and drivers access ieee80211_sta part of it. With MLO (Multi Link Operation) support being added in 802.11be standard, though the association is logically with a single Multi Link capable STA, at the physical level communication can happen via different advertised links (uniquely identified by Channel, operating class, BSSID) and hence the need to handle multiple link STA parameters within a composite sta_info object called the MLD STA. The different link STA part of MLD STA are identified using the link address which can be same or different as the MLD STA address and unique link id based on the link vif. To support extension of such a model, the sta_info datastructure is modified to hold multiple link STA objects with link specific params currently within sta_info moved to this new structure. Similarly this is done for ieee80211_sta as well which will be accessed within mac80211 as well as by drivers, hence trivial driver changes are expected to support this. For current non MLO supported drivers, only one link STA is present and link information is accessed via 'deflink' member. For MLO drivers, we still need to define the APIs etc. to get the correct link ID and access the correct part of the station info. Currently in mac80211, all link STA info are accessed directly via deflink. These will be updated to access via link pointers indexed by link id with MLO support patches, with link id being 0 for non MLO supported cases. Except for couple of macro related changes, below spatch takes care of updating mac80211 and driver code to access to the link STA info via deflink. @ieee80211_sta@ struct ieee80211_sta *s; struct sta_info *si; identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr}; @@ ( s-> - var + deflink.var | si->sta. - var + deflink.var ) @sta_info@ struct sta_info *si; identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth}; @@ ( si-> - var + deflink.var ) Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com [remove MLO-drivers notes from commit message, not clear yet; run spatch] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-10ath9k: Fix usage of driver-private space in tx_infoToke Høiland-Jørgensen
The ieee80211_tx_info_clear_status() helper also clears the rate counts and the driver-private part of struct ieee80211_tx_info, so using it breaks quite a few other things. So back out of using it, and instead define a ath-internal helper that only clears the area between the status_driver_data and the rates info. Combined with moving the ath_frame_info struct to status_driver_data, this avoids clearing anything we shouldn't be, and so we can keep the existing code for handling the rate information. While fixing this I also noticed that the setting of tx_info->status.rates[tx_rateindex].count on hardware underrun errors was always immediately overridden by the normal setting of the same fields, so rearrange the code so that the underrun detection actually takes effect. The new helper could be generalised to a 'memset_between()' helper, but leave it as a driver-internal helper for now since this needs to go to stable. Cc: stable@vger.kernel.org Reported-by: Peter Seiderer <ps.report@gmx.net> Fixes: 037250f0a45c ("ath9k: Properly clear TX status area before reporting to mac80211") Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Reviewed-by: Peter Seiderer <ps.report@gmx.net> Tested-by: Peter Seiderer <ps.report@gmx.net> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220404204800.2681133-1-toke@toke.dk
2021-10-05ath9k: Fix potential interrupt storm on queue resetLinus Lüssing
In tests with two Lima boards from 8devices (QCA4531 based) on OpenWrt 19.07 we could force a silent restart of a device with no serial output when we were sending a high amount of UDP traffic (iperf3 at 80 MBit/s in both directions from external hosts, saturating the wifi and causing a load of about 4.5 to 6) and were then triggering an ath9k_queue_reset(). Further debugging showed that the restart was caused by the ath79 watchdog. With disabled watchdog we could observe that the device was constantly going into ath_isr() interrupt handler and was returning early after the ATH_OP_HW_RESET flag test, without clearing any interrupts. Even though ath9k_queue_reset() calls ath9k_hw_kill_interrupts(). With JTAG we could observe the following race condition: 1) ath9k_queue_reset() ... -> ath9k_hw_kill_interrupts() -> set_bit(ATH_OP_HW_RESET, &common->op_flags); ... <- returns 2) ath9k_tasklet() ... -> ath9k_hw_resume_interrupts() ... <- returns 3) loops around: ... handle_int() -> ath_isr() ... -> if (test_bit(ATH_OP_HW_RESET, &common->op_flags)) return IRQ_HANDLED; x) ath_reset_internal(): => never reached <= And in ath_isr() we would typically see the following interrupts / interrupt causes: * status: 0x00111030 or 0x00110030 * async_cause: 2 (AR_INTR_MAC_IPQ) * sync_cause: 0 So the ath9k_tasklet() reenables the ath9k interrupts through ath9k_hw_resume_interrupts() which ath9k_queue_reset() had just disabled. And ath_isr() then keeps firing because it returns IRQ_HANDLED without actually clearing the interrupt. To fix this IRQ storm also clear/disable the interrupts again when we are in reset state. Cc: Sven Eckelmann <sven@narfation.org> Cc: Simon Wunderlich <sw@simonwunderlich.de> Cc: Linus Lüssing <linus.luessing@c0d3.blue> Fixes: 872b5d814f99 ("ath9k: do not access hardware on IRQs during reset") Signed-off-by: Linus Lüssing <ll@simonwunderlich.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914192515.9273-3-linus.luessing@c0d3.blue
2021-06-23mac80211: notify driver on mgd TX completionJohannes Berg
We have mgd_prepare_tx(), but sometimes drivers may want/need to take action when the exchange finishes, whether successfully or not. Add a notification to the driver on completion, i.e. call the new method mgd_complete_tx(). To unify the two scenarios, and to add more information, make both of them take a struct that has the duration (prepare only), subtype (both) and success (complete only). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.5d94e78f6230.I6dc979606b6f28701b740d7aab725f7853a5a155@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-12ath9k: Fix kernel NULL pointer dereference during ath_reset_internal()Pali Rohár
I got this crash more times during debugging of PCIe controller and crash happens somehow at the time when PCIe kernel code started link retraining (as part of ASPM code) when at the same time PCIe link went down and ath9k probably executed hw reset procedure. Currently I'm not able to reproduce this issue as it looks like to be some race condition between link training, ASPM, link down and reset path. And as always, race conditions which depends on more input parameters are hard to reproduce as it depends on precise timings. But it is clear that pointers are zero in this case and should be properly filled as same code pattern is used in ath9k_stop() function. Anyway I was able to reproduce this crash by manually triggering ath reset worker prior putting card up. I created simple patch to export reset functionality via debugfs and use it to "simulate" of triggering reset. s proved that NULL-pointer dereference issue is there. Function ath9k_hw_reset() is dereferencing chan structure pointer, so it needs to be non-NULL pointer. Function ath9k_stop() already contains code which sets ah->curchan to valid non-NULL pointer prior calling ath9k_hw_reset() function. Add same code pattern also into ath_reset_internal() function to prevent kernel NULL pointer dereference in ath9k_hw_reset() function. This change fixes kernel NULL pointer dereference in ath9k_hw_reset() which is caused by calling ath9k_hw_reset() from ath_reset_internal() with NULL chan structure. [ 45.334305] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 [ 45.344417] Mem abort info: [ 45.347301] ESR = 0x96000005 [ 45.350448] EC = 0x25: DABT (current EL), IL = 32 bits [ 45.356166] SET = 0, FnV = 0 [ 45.359350] EA = 0, S1PTW = 0 [ 45.362596] Data abort info: [ 45.365756] ISV = 0, ISS = 0x00000005 [ 45.369735] CM = 0, WnR = 0 [ 45.372814] user pgtable: 4k pages, 39-bit VAs, pgdp=000000000685d000 [ 45.379663] [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 45.388856] Internal error: Oops: 96000005 [#1] SMP [ 45.393897] Modules linked in: ath9k ath9k_common ath9k_hw [ 45.399574] CPU: 1 PID: 309 Comm: kworker/u4:2 Not tainted 5.12.0-rc2-dirty #785 [ 45.414746] Workqueue: phy0 ath_reset_work [ath9k] [ 45.419713] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--) [ 45.425910] pc : ath9k_hw_reset+0xc4/0x1c48 [ath9k_hw] [ 45.431234] lr : ath9k_hw_reset+0xc0/0x1c48 [ath9k_hw] [ 45.436548] sp : ffffffc0118dbca0 [ 45.439961] x29: ffffffc0118dbca0 x28: 0000000000000000 [ 45.445442] x27: ffffff800dee4080 x26: 0000000000000000 [ 45.450923] x25: ffffff800df9b9d8 x24: 0000000000000000 [ 45.456404] x23: ffffffc0115f6000 x22: ffffffc008d0d408 [ 45.461885] x21: ffffff800dee5080 x20: ffffff800df9b9d8 [ 45.467366] x19: 0000000000000000 x18: 0000000000000000 [ 45.472846] x17: 0000000000000000 x16: 0000000000000000 [ 45.478326] x15: 0000000000000010 x14: ffffffffffffffff [ 45.483807] x13: ffffffc0918db94f x12: ffffffc011498720 [ 45.489289] x11: 0000000000000003 x10: ffffffc0114806e0 [ 45.494770] x9 : ffffffc01014b2ec x8 : 0000000000017fe8 [ 45.500251] x7 : c0000000ffffefff x6 : 0000000000000001 [ 45.505733] x5 : 0000000000000000 x4 : 0000000000000000 [ 45.511213] x3 : 0000000000000000 x2 : ffffff801fece870 [ 45.516693] x1 : ffffffc00eded000 x0 : 000000000000003f [ 45.522174] Call trace: [ 45.524695] ath9k_hw_reset+0xc4/0x1c48 [ath9k_hw] [ 45.529653] ath_reset_internal+0x1a8/0x2b8 [ath9k] [ 45.534696] ath_reset_work+0x2c/0x40 [ath9k] [ 45.539198] process_one_work+0x210/0x480 [ 45.543339] worker_thread+0x5c/0x510 [ 45.547115] kthread+0x12c/0x130 [ 45.550445] ret_from_fork+0x10/0x1c [ 45.554138] Code: 910922c2 9117e021 95ff0398 b4000294 (b9400a61) [ 45.560430] ---[ end trace 566410ba90b50e8b ]--- [ 45.565193] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 45.572282] SMP: stopping secondary CPUs [ 45.576331] Kernel Offset: disabled [ 45.579924] CPU features: 0x00040002,0000200c [ 45.584416] Memory Limit: none [ 45.587564] Rebooting in 3 seconds.. Signed-off-by: Pali Rohár <pali@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210402122653.24014-1-pali@kernel.org
2020-12-17ath9k: Postpone key cache entry deletion for TXQ frames reference itJouni Malinen
Do not delete a key cache entry that is still being referenced by pending frames in TXQs. This avoids reuse of the key cache entry while a frame might still be transmitted using it. To avoid having to do any additional operations during the main TX path operations, track pending key cache entries in a new bitmap and check whether any pending entries can be deleted before every new key add/remove operation. Also clear any remaining entries when stopping the interface. Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201214172118.18100-6-jouni@codeaurora.org
2020-12-17ath: Modify ath_key_delete() to not need full key entryJouni Malinen
tkip_keymap can be used internally to avoid the reference to key->cipher and with this, only the key index value itself is needed. This allows ath_key_delete() call to be postponed to be handled after the upper layer STA and key entry have already been removed. This is needed to make ath9k key cache management safer. Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201214172118.18100-5-jouni@codeaurora.org
2020-12-17ath9k: Clear key cache explicitly on disabling hardwareJouni Malinen
Now that ath/key.c may not be explicitly clearing keys from the key cache, clear all key cache entries when disabling hardware to make sure no keys are left behind beyond this point. Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201214172118.18100-3-jouni@codeaurora.org
2020-11-11ath9k: remove WDS codeJohannes Berg
The ability to reach this code was hidden behind CONFIG_WIRELESS_WDS, which was just removed. Clean up the driver accordingly. Link: https://lore.kernel.org/r/20201109105103.e1d48ee20b0a.I89f8af0d50a02ce16a922fa790d6c1908f31a496@changeid Acked-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-08-27ath9k: convert tasklets to use new tasklet_setup() APIAllen Pais
In preparation for unconditionally passing the struct tasklet_struct pointer to all tasklet callbacks, switch to using the new tasklet_setup() and from_tasklet() to pass the tasklet pointer explicitly. Signed-off-by: Romain Perier <romain.perier@gmail.com> Signed-off-by: Allen Pais <allen.lkml@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200817090637.26887-3-allen.cryptic@gmail.com
2020-08-17ath9k: add NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 supportAlexander Wetzel
The ath9k driver was so far only able to rekey PTK0 keys correctly due to the best effort queue flush added with commit 62872a9b9a10 ("mac80211: Fix PTK rekey freezes and clear text leak"). Add the needed queue flush and set NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 to tell mac80211 that the driver can now rekey PTK0 keys correctly and no longer needs the best effort flush. Effectively this prevents mac80211 to warn when rekeying a PTK0 key only. Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200804164152.175375-1-alexander@wetzel-home.de
2020-08-14ath9k: Use fallthrough pseudo-keywordGustavo A. R. Silva
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200727193520.GA832@embeddedor
2020-05-30ath9k: Set RX filter based to allow broadcast Action frame RXJouni Malinen
Advertise support for multicast frame registration and update the RX filter based on the recently added FIF_MCAST_ACTION to allow broadcast Action frames to be received. This is needed for Device Provisioning Protocol (DPP) use cases that use broadcast Public Action frames. Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200426084733.7889-1-jouni@codeaurora.org
2020-03-16Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo
ath.git patches for v5.7. Major changes: ath10k * support for getting btcoex settings from Device Tree * support QCA9377 SDIO device ath11k * add HE rate accounting * add thermal sensor and cooling devices
2020-03-11ath9k: Handle txpower changes even when TPC is disabledRemi Pommarel
When TPC is disabled IEEE80211_CONF_CHANGE_POWER event can be handled to reconfigure HW's maximum txpower. This fixes 0dBm txpower setting when user attaches to an interface for the first time with the following scenario: ieee80211_do_open() ath9k_add_interface() ath9k_set_txpower() /* Set TX power with not yet initialized sc->hw->conf.power_level */ ieee80211_hw_config() /* Iniatilize sc->hw->conf.power_level and raise IEEE80211_CONF_CHANGE_POWER */ ath9k_config() /* IEEE80211_CONF_CHANGE_POWER is ignored */ This issue can be reproduced with the following: $ modprobe -r ath9k $ modprobe ath9k $ wpa_supplicant -i wlan0 -c /tmp/wpa.conf & $ iw dev /* Here TX power is either 0 or 3 depending on RF chain */ $ killall wpa_supplicant $ iw dev /* TX power goes back to calibrated value and subsequent calls will be fine */ Fixes: 283dd11994cde ("ath9k: add per-vif TX power capability") Cc: stable@vger.kernel.org Signed-off-by: Remi Pommarel <repk@triplefau.lt> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-02-14mac80211: Fix setting txpower to zeroBen Greear
With multiple VIFS ath10k, and probably others, tries to find the minimum txpower for all vifs and uses that when setting txpower in the firmware. If a second vif is added and starts to scan, it's txpower is not initialized yet and it set to zero. ath10k had a patch to ignore zero values, but then it is impossible to actually set txpower to zero. So, instead initialize the txpower to INT_MIN in mac80211, and let drivers know that means the power has not been set and so should be ignored. This should fix regression in: commit 88407beb1b1462f706a1950a355fd086e1c450b6 Author: Ryan Hsu <ryanhsu@qca.qualcomm.com> Date: Tue Dec 13 14:55:19 2016 -0800 ath10k: fix incorrect txpower set by P2P_DEVICE interface Tested on ath10k 9984 with ath10k-ct firmware. Signed-off-by: Ben Greear <greearb@candelatech.com> Link: https://lore.kernel.org/r/20191217183057.24586-1-greearb@candelatech.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-10-04mac80211: simplify TX aggregation startJohannes Berg
There really is no need to make drivers call the ieee80211_start_tx_ba_cb_irqsafe() function and then schedule the worker if all we want is to set a bit. Add a new return value (that was previously considered invalid) to indicate that the driver is immediately ready for the session, and make drivers use it. The only drivers that remain different are the Intel ones as they need to negotiate more with the firmware. Link: https://lore.kernel.org/r/1570007543-I152912660131cbab2e5d80b4218238c20f8a06e5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-26mac80211: pass the vif to cancel_remain_on_channelEmmanuel Grumbach
This low level driver can find it useful to get the vif when a remain on channel session is cancelled. iwlwifi will need this soon. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://lore.kernel.org/r/20190723180001.5828-1-emmanuel.grumbach@intel.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2018-11-06ath9k: Fix a locking bug in ath9k_add_interface()Dan Carpenter
We tried to revert commit d9c52fd17cb4 ("ath9k: fix tx99 with monitor mode interface") but accidentally missed part of the locking change. The lock has to be held earlier so that we're holding it when we do "sc->tx99_vif = vif;" and also there in the current code there is a stray unlock before we have taken the lock. Fixes: 6df0580be8bc ("ath9k: add back support for using active monitor interfaces for tx99") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-10-13ath9k: fix RX_STAT_INC() etc macrosArnd Bergmann
A couple of macros that deal with statistics in ath9k rely on the declaration of the 'sc' variable, which they dereference. However, when the statistics are disabled, the new instance in ath_cmn_process_fft() causes a warning for an unused variable: drivers/net/wireless/ath/ath9k/common-spectral.c: In function 'ath_cmn_process_fft': drivers/net/wireless/ath/ath9k/common-spectral.c:474:20: error: unused variable 'sc' [-Werror=unused-variable] It's better if those macros only operate on their arguments instead of known variable names, and adding a cast to (void) kills off that warning. Fixes: 03224678c013 ("ath9k: add counters for good and errorneous FFT/spectral frames") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-10-02ath9k: add back support for using active monitor interfaces for tx99Felix Fietkau
Various documented examples on how to set up tx99 with ath9k rely on setting up a regular monitor interface for setting the channel. My previous patch "ath9k: fix tx99 with monitor mode interface" made it possible to set it up this way again. However, it was removing support for using an active monitor interface, which is required for controlling the bitrate as well, since the bitrate is not passed down with a regular monitor interface. This patch partially reverts the previous one, but keeps support for using a regular monitor interface to keep documented steps working in cases where the bitrate does not matter Fixes: d9c52fd17cb48 ("ath9k: fix tx99 with monitor mode interface") Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-08-28ath9k: fix tx99 with monitor mode interfaceFelix Fietkau
Tx99 is typically configured via a monitor mode interface, which does not get added to the driver as a vif. Since the code currently expects a configured virtual interface for tx99, enabling tx99 via debugfs fails. Since the vif is not needed anyway, remove all checks for it. Signed-off-by: Felix Fietkau <nbd@nbd.name> [kvalo@codeaurora.org: s/CPTCFG/CONFIG/] Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-06-29ath9k: use timespec64 for tsf_tsArnd Bergmann
ath9k is the last remaining user of the deprecated getrawmonotonic() interface. There is nothing wrong with this usage, but migrating to a timespec64 based interface lets us clean up the old API. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-06-18Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo
ath.git patches for 4.19. Major changes: ath10k * support channel 173 * fix spectral scan for QCA9984 and QCA9888 chipsets ath6kl * add support for Dell Wireless 1537
2018-06-13ath9k: mark expected switch fall-throughsGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-05-23mac80211: Support adding duration for prepare_tx() callbackIlan Peer
There are specific cases, such as SAE authentication exchange, that might require long duration to complete. For such cases, add support for indicating to the driver the required duration of the prepare_tx() operation, so the driver would still be able to complete the frame exchange. Currently, indicate the duration only for SAE authentication exchange, as SAE authentication can take up to 2000 msec (as defined in IEEE P802.11-REVmd D1.0 p. 3504). As the patch modified the prepare_tx() callback API, also modify the relevant code in iwlwifi. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2017-10-27ath: Convert timers to use timer_setup()Kees Cook
In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Cc: Kalle Valo <kvalo@qca.qualcomm.com> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-09-25ath9k: Avoid a potential deadlockVille Syrjälä
Lockdep warns us that sc_pm_lock and cc_lock can cause a deadlock when cc_lock is acquired by itself with interrupts enabled. Disable irqs whenever taking cc_lock to avoid this. [ 19.094524] kworker/u2:0/5 just changed the state of lock: [ 19.094578] (&(&sc->sc_pm_lock)->rlock){-.-...}, at: [<f836c00e>] ath_isr+0x15e/0x200 [ath9k] [ 19.094674] but this lock took another, HARDIRQ-unsafe lock in the past: [ 19.094731] (&(&common->cc_lock)->rlock){+.-...} [ 19.094741] and interrupts could create inverse lock ordering between them. [ 19.094866] other info that might help us debug this: [ 19.094926] Possible interrupt unsafe locking scenario: [ 19.094985] CPU0 CPU1 [ 19.095036] ---- ---- [ 19.095086] lock(&(&common->cc_lock)->rlock); [ 19.095197] local_irq_disable(); [ 19.095305] lock(&(&sc->sc_pm_lock)->rlock); [ 19.095423] lock(&(&common->cc_lock)->rlock); [ 19.095539] <Interrupt> [ 19.095636] lock(&(&sc->sc_pm_lock)->rlock); [ 19.095745] *** DEADLOCK *** [ 19.095965] 3 locks held by kworker/u2:0/5: [ 19.096067] #0: ("%s"wiphy_name(local->hw.wiphy)){.+.+.+}, at: [<c1067f37>] process_one_work+0x127/0x580 [ 19.096260] #1: ((&local->dynamic_ps_enable_work)){+.+...}, at: [<c1067f37>] process_one_work+0x127/0x580 [ 19.096447] #2: (&sc->mutex){+.+...}, at: [<f836b8b0>] ath9k_config+0x30/0x1d0 [ath9k] [ 19.096639] the shortest dependencies between 2nd lock and 1st lock: [ 19.096813] -> (&(&common->cc_lock)->rlock){+.-...} ops: 38 { [ 19.096816] HARDIRQ-ON-W at: [ 19.096816] __lock_acquire+0x57e/0x1260 [ 19.096816] lock_acquire+0xb1/0x1c0 [ 19.096816] _raw_spin_lock_bh+0x3f/0x50 [ 19.096816] ath_chanctx_set_channel+0xb6/0x2c0 [ath9k] [ 19.096816] ath9k_config+0xa8/0x1d0 [ath9k] [ 19.096816] ieee80211_hw_config+0xa8/0x5f0 [mac80211] [ 19.096816] ieee80211_do_open+0x67a/0x920 [mac80211] [ 19.096816] ieee80211_open+0x41/0x50 [mac80211] [ 19.096816] __dev_open+0xab/0x140 [ 19.096816] __dev_change_flags+0x89/0x150 [ 19.096816] dev_change_flags+0x28/0x60 [ 19.096816] do_setlink+0x290/0x890 [ 19.096816] rtnl_newlink+0x7cf/0x8e0 [ 19.096816] rtnetlink_rcv_msg+0xbf/0x1f0 [ 19.096816] netlink_rcv_skb+0xb9/0xe0 [ 19.096816] rtnetlink_rcv+0x1e/0x30 [ 19.096816] netlink_unicast+0x13a/0x2c0 [ 19.096816] netlink_sendmsg+0x290/0x380 [ 19.096816] ___sys_sendmsg+0x1e2/0x280 [ 19.096816] __sys_sendmsg+0x3f/0x80 [ 19.096816] SyS_socketcall+0x58c/0x6b0 [ 19.096816] do_fast_syscall_32+0x96/0x1d0 [ 19.096816] entry_SYSENTER_32+0x4c/0x7b [ 19.096816] IN-SOFTIRQ-W at: [ 19.096816] __lock_acquire+0x55a/0x1260 [ 19.096816] lock_acquire+0xb1/0x1c0 [ 19.096816] _raw_spin_lock+0x3c/0x50 [ 19.096816] ath_ps_full_sleep+0x24/0x70 [ath9k] [ 19.096816] call_timer_fn+0xa4/0x300 [ 19.096816] run_timer_softirq+0x1b1/0x560 [ 19.096816] __do_softirq+0xb0/0x430 [ 19.096816] do_softirq_own_stack+0x33/0x40 [ 19.096816] irq_exit+0xad/0xc0 [ 19.096816] smp_apic_timer_interrupt+0x31/0x40 [ 19.096816] apic_timer_interrupt+0x37/0x3c [ 19.096816] wp_page_copy+0xb8/0x580 [ 19.096816] do_wp_page+0x64/0x420 [ 19.096816] handle_mm_fault+0x430/0x990 [ 19.096816] __do_page_fault+0x18b/0x430 [ 19.096816] do_page_fault+0xb/0x10 [ 19.096816] common_exception+0x62/0x6a [ 19.096816] INITIAL USE at: [ 19.096816] __lock_acquire+0x204/0x1260 [ 19.096816] lock_acquire+0xb1/0x1c0 [ 19.096816] _raw_spin_lock_bh+0x3f/0x50 [ 19.096816] ath_chanctx_set_channel+0xb6/0x2c0 [ath9k] [ 19.096816] ath9k_config+0xa8/0x1d0 [ath9k] [ 19.096816] ieee80211_hw_config+0xa8/0x5f0 [mac80211] [ 19.096816] ieee80211_do_open+0x67a/0x920 [mac80211] [ 19.096816] ieee80211_open+0x41/0x50 [mac80211] [ 19.096816] __dev_open+0xab/0x140 [ 19.096816] __dev_change_flags+0x89/0x150 [ 19.096816] dev_change_flags+0x28/0x60 [ 19.096816] do_setlink+0x290/0x890 [ 19.096816] rtnl_newlink+0x7cf/0x8e0 [ 19.096816] rtnetlink_rcv_msg+0xbf/0x1f0 [ 19.096816] netlink_rcv_skb+0xb9/0xe0 [ 19.096816] rtnetlink_rcv+0x1e/0x30 [ 19.096816] netlink_unicast+0x13a/0x2c0 [ 19.096816] netlink_sendmsg+0x290/0x380 [ 19.096816] ___sys_sendmsg+0x1e2/0x280 [ 19.096816] __sys_sendmsg+0x3f/0x80 [ 19.096816] SyS_socketcall+0x58c/0x6b0 [ 19.096816] do_fast_syscall_32+0x96/0x1d0 [ 19.096816] entry_SYSENTER_32+0x4c/0x7b [ 19.096816] } [ 19.096816] ... key at: [<f837b694>] __key.61991+0x0/0xffffc96c [ath9k] [ 19.096816] ... acquired at: [ 19.096816] lock_acquire+0xb1/0x1c0 [ 19.096816] _raw_spin_lock+0x3c/0x50 [ 19.096816] ath9k_ps_wakeup+0x85/0xe0 [ath9k] [ 19.096816] ath9k_bss_info_changed+0x2a/0x1b0 [ath9k] [ 19.096816] ieee80211_bss_info_change_notify+0xf3/0x360 [mac80211] [ 19.096816] ieee80211_recalc_txpower+0x33/0x40 [mac80211] [ 19.096816] ieee80211_set_tx_power+0x45/0x1d0 [mac80211] [ 19.096816] cfg80211_wext_siwtxpower+0xd3/0x350 [cfg80211] [ 19.096816] ioctl_standard_call+0x4e/0x400 [ 19.096816] wext_handle_ioctl+0xf4/0x190 [ 19.096816] dev_ioctl+0xb7/0x630 [ 19.096816] sock_ioctl+0x13e/0x2d0 [ 19.096816] do_vfs_ioctl+0x84/0x750 [ 19.096816] SyS_ioctl+0x34/0x60 [ 19.096816] do_fast_syscall_32+0x96/0x1d0 [ 19.096816] entry_SYSENTER_32+0x4c/0x7b [ 19.096816] -> (&(&sc->sc_pm_lock)->rlock){-.-...} ops: 597 { [ 19.096816] IN-HARDIRQ-W at: [ 19.096816] __lock_acquire+0x6ae/0x1260 [ 19.096816] lock_acquire+0xb1/0x1c0 [ 19.096816] _raw_spin_lock_irqsave+0x45/0x60 [ 19.096816] ath_isr+0x15e/0x200 [ath9k] [ 19.096816] __handle_irq_event_percpu+0x44/0x340 [ 19.096816] handle_irq_event_percpu+0x1d/0x50 [ 19.096816] handle_irq_event+0x32/0x60 [ 19.096816] handle_level_irq+0x81/0x100 [ 19.096816] handle_irq+0x9c/0xd0 [ 19.096816] do_IRQ+0x5c/0x120 [ 19.096816] common_interrupt+0x36/0x3c [ 19.096816] _raw_spin_unlock_irqrestore+0x57/0x70 [ 19.096816] ath9k_config+0x16a/0x1d0 [ath9k] [ 19.096816] ieee80211_hw_config+0xa8/0x5f0 [mac80211] [ 19.096816] ieee80211_dynamic_ps_enable_work+0x1c3/0x680 [mac80211] [ 19.096816] process_one_work+0x1d1/0x580 [ 19.096816] worker_thread+0x31/0x380 [ 19.096816] kthread+0xd9/0x110 [ 19.096816] ret_from_fork+0x19/0x24 [ 19.096816] IN-SOFTIRQ-W at: [ 19.096816] __lock_acquire+0x55a/0x1260 [ 19.096816] lock_acquire+0xb1/0x1c0 [ 19.096816] _raw_spin_lock_irqsave+0x45/0x60 [ 19.096816] ath9k_ps_wakeup+0x24/0xe0 [ath9k] [ 19.096816] ath9k_tasklet+0x42/0x260 [ath9k] [ 19.096816] tasklet_action+0x196/0x1e0 [ 19.096816] __do_softirq+0xb0/0x430 [ 19.096816] do_softirq_own_stack+0x33/0x40 [ 19.096816] irq_exit+0xad/0xc0 [ 19.096816] do_IRQ+0x65/0x120 [ 19.096816] common_interrupt+0x36/0x3c [ 19.096816] get_page_from_freelist+0x20a/0x970 [ 19.096816] __alloc_pages_nodemask+0xca/0xed0 [ 19.096816] __get_free_pages+0x14/0x30 [ 19.096816] pgd_alloc+0x1d/0x160 [ 19.096816] mm_init.isra.47+0x13a/0x1b0 [ 19.096816] copy_process.part.54+0xb55/0x1700 [ 19.096816] _do_fork+0xd4/0x6a0 [ 19.096816] SyS_clone+0x27/0x30 [ 19.096816] do_fast_syscall_32+0x96/0x1d0 [ 19.096816] entry_SYSENTER_32+0x4c/0x7b [ 19.096816] INITIAL USE at: [ 19.096816] __lock_acquire+0x204/0x1260 [ 19.096816] lock_acquire+0xb1/0x1c0 [ 19.096816] _raw_spin_lock_irqsave+0x45/0x60 [ 19.096816] ath9k_ps_wakeup+0x24/0xe0 [ath9k] [ 19.096816] ath9k_start+0x29/0x1f0 [ath9k] [ 19.096816] drv_start+0x71/0x270 [mac80211] [ 19.096816] ieee80211_do_open+0x31f/0x920 [mac80211] [ 19.096816] ieee80211_open+0x41/0x50 [mac80211] [ 19.096816] __dev_open+0xab/0x140 [ 19.096816] __dev_change_flags+0x89/0x150 [ 19.096816] dev_change_flags+0x28/0x60 [ 19.096816] do_setlink+0x290/0x890 [ 19.096816] rtnl_newlink+0x7cf/0x8e0 [ 19.096816] rtnetlink_rcv_msg+0xbf/0x1f0 [ 19.096816] netlink_rcv_skb+0xb9/0xe0 [ 19.096816] rtnetlink_rcv+0x1e/0x30 [ 19.096816] netlink_unicast+0x13a/0x2c0 [ 19.096816] netlink_sendmsg+0x290/0x380 [ 19.096816] ___sys_sendmsg+0x1e2/0x280 [ 19.096816] __sys_sendmsg+0x3f/0x80 [ 19.096816] SyS_socketcall+0x58c/0x6b0 [ 19.096816] do_fast_syscall_32+0x96/0x1d0 [ 19.096816] entry_SYSENTER_32+0x4c/0x7b [ 19.096816] } [ 19.096816] ... key at: [<f837b67c>] __key.61994+0x0/0xffffc984 [ath9k] [ 19.096816] ... acquired at: [ 19.096816] check_usage_forwards+0x118/0x120 [ 19.096816] mark_lock+0x2e4/0x590 [ 19.096816] __lock_acquire+0x6ae/0x1260 [ 19.096816] lock_acquire+0xb1/0x1c0 [ 19.096816] _raw_spin_lock_irqsave+0x45/0x60 [ 19.096816] ath_isr+0x15e/0x200 [ath9k] [ 19.096816] __handle_irq_event_percpu+0x44/0x340 [ 19.096816] handle_irq_event_percpu+0x1d/0x50 [ 19.096816] handle_irq_event+0x32/0x60 [ 19.096816] handle_level_irq+0x81/0x100 [ 19.096816] handle_irq+0x9c/0xd0 [ 19.096816] do_IRQ+0x5c/0x120 [ 19.096816] common_interrupt+0x36/0x3c [ 19.096816] _raw_spin_unlock_irqrestore+0x57/0x70 [ 19.096816] ath9k_config+0x16a/0x1d0 [ath9k] [ 19.096816] ieee80211_hw_config+0xa8/0x5f0 [mac80211] [ 19.096816] ieee80211_dynamic_ps_enable_work+0x1c3/0x680 [mac80211] [ 19.096816] process_one_work+0x1d1/0x580 [ 19.096816] worker_thread+0x31/0x380 [ 19.096816] kthread+0xd9/0x110 [ 19.096816] ret_from_fork+0x19/0x24 [ 19.096816] stack backtrace: [ 19.096816] CPU: 0 PID: 5 Comm: kworker/u2:0 Not tainted 4.13.0-mgm-ovl+ #51 [ 19.096816] Hardware name: FUJITSU SIEMENS LIFEBOOK S6120/FJNB16C, BIOS Version 1.26 05/10/2004 [ 19.096816] Workqueue: phy0 ieee80211_dynamic_ps_enable_work [mac80211] [ 19.096816] Call Trace: [ 19.096816] <IRQ> [ 19.096816] dump_stack+0x16/0x19 [ 19.096816] print_irq_inversion_bug.part.37+0x16c/0x179 [ 19.096816] check_usage_forwards+0x118/0x120 [ 19.096816] ? ret_from_fork+0x19/0x24 [ 19.096816] ? print_shortest_lock_dependencies+0x1a0/0x1a0 [ 19.096816] mark_lock+0x2e4/0x590 [ 19.096816] ? print_shortest_lock_dependencies+0x1a0/0x1a0 [ 19.096816] __lock_acquire+0x6ae/0x1260 [ 19.096816] lock_acquire+0xb1/0x1c0 [ 19.096816] ? ath_isr+0x15e/0x200 [ath9k] [ 19.096816] _raw_spin_lock_irqsave+0x45/0x60 [ 19.096816] ? ath_isr+0x15e/0x200 [ath9k] [ 19.096816] ath_isr+0x15e/0x200 [ath9k] [ 19.096816] __handle_irq_event_percpu+0x44/0x340 [ 19.096816] handle_irq_event_percpu+0x1d/0x50 [ 19.096816] handle_irq_event+0x32/0x60 [ 19.096816] ? handle_nested_irq+0x100/0x100 [ 19.096816] handle_level_irq+0x81/0x100 [ 19.096816] handle_irq+0x9c/0xd0 [ 19.096816] </IRQ> [ 19.096816] do_IRQ+0x5c/0x120 [ 19.096816] common_interrupt+0x36/0x3c [ 19.096816] EIP: _raw_spin_unlock_irqrestore+0x57/0x70 [ 19.096816] EFLAGS: 00000286 CPU: 0 [ 19.096816] EAX: f60a3600 EBX: 00000286 ECX: 00000006 EDX: 00000001 [ 19.096816] ESI: f46c9e68 EDI: f46c8620 EBP: f60b5e8c ESP: f60b5e84 [ 19.096816] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 [ 19.096816] ath9k_config+0x16a/0x1d0 [ath9k] [ 19.096816] ieee80211_hw_config+0xa8/0x5f0 [mac80211] [ 19.096816] ? ieee80211_hw_config+0x1db/0x5f0 [mac80211] [ 19.096816] ieee80211_dynamic_ps_enable_work+0x1c3/0x680 [mac80211] [ 19.096816] ? process_one_work+0x127/0x580 [ 19.096816] ? process_one_work+0x127/0x580 [ 19.096816] process_one_work+0x1d1/0x580 [ 19.096816] ? process_one_work+0x127/0x580 [ 19.096816] worker_thread+0x31/0x380 [ 19.096816] kthread+0xd9/0x110 [ 19.096816] ? process_one_work+0x580/0x580 [ 19.096816] ? kthread_create_on_node+0x30/0x30 [ 19.096816] ret_from_fork+0x19/0x24 Cc: QCA ath9k Development <ath9k-devel@qca.qualcomm.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: netdev@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-09-25ath9k: remove cast to void pointerHimanshu Jha
casting to void pointer from any pointer type and vice-versa is done implicitly and therefore casting is not needed in such a case. Done using Coccinellle. Semantic Patch used : @r@ expression x; void* e; type T; identifier f; @@ ( *((T *)e) | ((T *)x)[...] | ((T *)x)->f | - (T *) e ) Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-06-28ath9k: Use mutex_lock to avoid potential race in start/stop rngMiaoqing Pan
Move ath9k_rng_stop/ath9k_rng_start pair into critical section, use mutex_lock to void potential race accessing. Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-02-07ath9k: fix race condition in enabling/disabling IRQsFelix Fietkau
The code currently relies on refcounting to disable IRQs from within the IRQ handler and re-enabling them again after the tasklet has run. However, due to race conditions sometimes the IRQ handler might be called twice, or the tasklet may not run at all (if interrupted in the middle of a reset). This can cause nasty imbalances in the irq-disable refcount which will get the driver permanently stuck until the entire radio has been stopped and started again (ath_reset will not recover from this). Instead of using this fragile logic, change the code to ensure that running the irq handler during tasklet processing is safe, and leave the refcount untouched. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-02-07ath9k: rename tx_complete_work to hw_check_workFelix Fietkau
Also include common MAC alive check. This should make the hang checks more reliable for modes where beacons are not sent and is used as a starting point for further hang check improvements Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-15ath9k: Introduce airtime fairness scheduling between stationsToke Høiland-Jørgensen
This reworks the ath9k driver to schedule transmissions to connected stations in a way that enforces airtime fairness between them. It accomplishes this by measuring the time spent transmitting to or receiving from a station at TX and RX completion, and accounting this to a per-station, per-QoS level airtime deficit. Then, an FQ-CoDel based deficit scheduler is employed at packet dequeue time, to control which station gets the next transmission opportunity. Airtime fairness can significantly improve the efficiency of the network when station rates vary. The following throughput values are from a simple three-station test scenario, where two stations operate at the highest HT20 rate, and one station at the lowest, and the scheduler is employed at the access point: Before / After Fast station 1: 19.17 / 25.09 Mbps Fast station 2: 19.83 / 25.21 Mbps Slow station: 2.58 / 1.77 Mbps Total: 41.58 / 52.07 Mbps The benefit of airtime fairness goes up the more stations are present. In a 30-station test with one station artificially limited to 1 Mbps, we have seen aggregate throughput go from 2.14 to 17.76 Mbps. Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-11-15ath9k: Switch to using mac80211 intermediate software queues.Toke Høiland-Jørgensen
This switches ath9k over to using the mac80211 intermediate software queueing mechanism for data packets. It removes the queueing inside the driver, except for the retry queue, and instead pulls from mac80211 when a packet is needed. The retry queue is used to store a packet that was pulled but can't be sent immediately. The old code path in ath_tx_start that would queue packets has been removed completely, as has the qlen limit tunables (since there's no longer a queue in the driver to limit). The mac80211 intermediate software queues offer significant latency reductions, and this patch allows ath9k to realise them. The exact gains from this varies with the test scenario, but in an access point scenario we have seen latency reductions ranging from 1/3 to as much as an order of magnitude. We also achieve slightly better aggregation. Median latency (ping) figures with this patch applied at the access point, with two high-rate stations and one low-rate station (HT20 5Ghz), running a Flent rtt_fair_var_up test with one TCP flow and one ping flow going to each station: Fast station Slow station Default pfifo_fast qdisc: 430.4 ms 638.7 ms fq_codel qdisc on iface: 35.5 ms 211.8 ms This patch set: 22.4 ms 38.2 ms Median aggregation sizes over the same test: Default pfifo_fast qdisc: 9.5 pkts 1.9 pkts fq_codel qdisc on iface: 11.2 pkts 1.9 pkts This patch set: 13.9 pkts 1.9 pkts This patch is based on Tim's original patch set, but reworked quite thoroughly. Cc: Tim Shepard <shep@alum.mit.edu> Cc: Felix Fietkau <nbd@nbd.name> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-09-09Merge branch 'ath-current' into ath-nextKalle Valo
Commit 3c97f5de1f28 ("ath10k: implement NAPI support") conflicts with ath-current. To avoid any merge problems merge ath-current to ath-next already now. Conflicts: drivers/net/wireless/ath/ath10k/htt_rx.c
2016-09-07ath9k: bring back direction setting in ath9k_{start_stop}Giedrius Statkevičius
A regression was introduced in commit id 79d4db1214a ("ath9k: cleanup led_pin initial") that broken the WLAN status led on my laptop with AR9287 after suspending and resuming. Steps to reproduce: * Suspend (laptop) * Resume (laptop) * Observe that the WLAN led no longer turns ON/OFF depending on the status and is always red Even though for my case it only needs to be set to OUT in ath9k_start but for consistency bring back the IN direction setting as well. Fixes: 79d4db1214a0 ("ath9k: cleanup led_pin initial") Cc: Miaoqing Pan <miaoqing@codeaurora.org> Cc: Kalle Valo <kvalo@qca.qualcomm.com> Cc: <stable@vger.kernel.org> # 4.7+ Link: https://bugzilla.kernel.org/show_bug.cgi?id=151711 Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@gmail.com> [kvalo@qca.qualcomm.com: improve commit log] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-08-22ath9k: fix using sta->drv_priv before initializing itFelix Fietkau
A station pointer can be passed to the driver on tx, before it has been marked as associated. Since ath9k_sta_state was initializing the entry too late, it resulted in some spurious crashes. Fixes: df3c6eb34da5 ("ath9k: Use sta_state() callback") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
generated by cgit v1.2.3-58-ga151 (git 2.39.0) at 2024-11-21 22:22:27 +0000