aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/wireless/ath/ath9k
AgeCommit message (Collapse)AuthorFilesLines
2019-09-26drivers: net: Fix Kconfig indentationGravatar Krzysztof Kozlowski 1-1/+1
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Kalle Valo <kvalo@codeaurora.org> Reviewed-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-10ath9k: release allocated buffer if timed outGravatar Navid Emamdoost 1-0/+1
In ath9k_wmi_cmd, the allocated network buffer needs to be released if timeout happens. Otherwise memory will be leaked. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-09-10ath9k_htc: release allocated buffer if timed outGravatar Navid Emamdoost 1-0/+3
In htc_config_pipe_credits, htc_setup_complete, and htc_connect_service if time out happens, the allocated buffer needs to be released. Otherwise there will be memory leak. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-09-10ath9k: Remove unneeded variable to store return valueGravatar zhong jiang 1-3/+1
ath9k_reg_rmw_single do not need return value to cope with different cases. And change functon return type to void. Signed-off-by: zhong jiang <zhongjiang@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-09-04ath9k: dynack: set ackto to max timeout in ath_dynack_resetGravatar Lorenzo Bianconi 1-7/+13
Initialize acktimeout to the maximum configurable value in ath_dynack_reset in order to not disconnect long distance static links enabling dynack and even to take care of possible errors configuring a static timeout. Moreover initialize station timeout value to the current acktimeout value Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-09-04ath9k: dynack: set max timeout according to channel widthGravatar Lorenzo Bianconi 1-8/+30
Compute maximum configurable ackimeout/ctstimeout according to channel width (clockrate) Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-09-04ath9k: dynack: properly set last timeout timestamp in ath_dynack_resetGravatar Lorenzo Bianconi 1-1/+1
Add compute timeout to last computation timestamp in ath_dynack_reset in order to not run ath_dynack_compute_ackto immediately Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-09-04ath9k: dyanck: introduce ath_dynack_set_timeout routineGravatar Lorenzo Bianconi 1-16/+21
Introduce ath_dynack_set_timeout routine to configure slottime/ack/cts timeouts and remove duplicated code Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-09-04ath9k: dynack: fix possible deadlock in ath_dynack_node_{de}initGravatar Lorenzo Bianconi 1-4/+4
Fix following lockdep warning disabling bh in ath_dynack_node_init/ath_dynack_node_deinit [ 75.955878] -------------------------------- [ 75.955880] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 75.955884] swapper/0/0 [HC0[0]:SC1[3]:HE1:SE0] takes: [ 75.955888] 00000000792a7ee0 (&(&da->qlock)->rlock){+.?.}, at: ath_dynack_sample_ack_ts+0x4d/0xa0 [ath9k_hw] [ 75.955905] {SOFTIRQ-ON-W} state was registered at: [ 75.955912] lock_acquire+0x9a/0x160 [ 75.955917] _raw_spin_lock+0x2c/0x70 [ 75.955927] ath_dynack_node_init+0x2a/0x60 [ath9k_hw] [ 75.955934] ath9k_sta_state+0xec/0x160 [ath9k] [ 75.955976] drv_sta_state+0xb2/0x740 [mac80211] [ 75.956008] sta_info_insert_finish+0x21a/0x420 [mac80211] [ 75.956039] sta_info_insert_rcu+0x12b/0x2c0 [mac80211] [ 75.956069] sta_info_insert+0x7/0x70 [mac80211] [ 75.956093] ieee80211_prep_connection+0x42e/0x730 [mac80211] [ 75.956120] ieee80211_mgd_auth.cold+0xb9/0x15c [mac80211] [ 75.956152] cfg80211_mlme_auth+0x143/0x350 [cfg80211] [ 75.956169] nl80211_authenticate+0x25e/0x2b0 [cfg80211] [ 75.956172] genl_family_rcv_msg+0x198/0x400 [ 75.956174] genl_rcv_msg+0x42/0x90 [ 75.956176] netlink_rcv_skb+0x35/0xf0 [ 75.956178] genl_rcv+0x1f/0x30 [ 75.956180] netlink_unicast+0x154/0x200 [ 75.956182] netlink_sendmsg+0x1bf/0x3d0 [ 75.956186] ___sys_sendmsg+0x2c2/0x2f0 [ 75.956187] __sys_sendmsg+0x44/0x80 [ 75.956190] do_syscall_64+0x55/0x1a0 [ 75.956192] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 75.956194] irq event stamp: 2357092 [ 75.956196] hardirqs last enabled at (2357092): [<ffffffff818c62de>] _raw_spin_unlock_irqrestore+0x3e/0x50 [ 75.956199] hardirqs last disabled at (2357091): [<ffffffff818c60b1>] _raw_spin_lock_irqsave+0x11/0x80 [ 75.956202] softirqs last enabled at (2357072): [<ffffffff8106dc09>] irq_enter+0x59/0x60 [ 75.956204] softirqs last disabled at (2357073): [<ffffffff8106dcbe>] irq_exit+0xae/0xc0 [ 75.956206] other info that might help us debug this: [ 75.956207] Possible unsafe locking scenario: [ 75.956208] CPU0 [ 75.956209] ---- [ 75.956210] lock(&(&da->qlock)->rlock); [ 75.956213] <Interrupt> [ 75.956214] lock(&(&da->qlock)->rlock); [ 75.956216] *** DEADLOCK *** [ 75.956217] 1 lock held by swapper/0/0: [ 75.956219] #0: 000000003bb5675c (&(&sc->sc_pcu_lock)->rlock){+.-.}, at: ath9k_tasklet+0x55/0x240 [ath9k] [ 75.956225] stack backtrace: [ 75.956228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.0-rc1-wdn+ #13 [ 75.956229] Hardware name: Dell Inc. Studio XPS 1340/0K183D, BIOS A11 09/08/2009 [ 75.956231] Call Trace: [ 75.956233] <IRQ> [ 75.956236] dump_stack+0x67/0x90 [ 75.956239] mark_lock+0x4c1/0x640 [ 75.956242] ? check_usage_backwards+0x130/0x130 [ 75.956245] ? sched_clock_local+0x12/0x80 [ 75.956247] __lock_acquire+0x484/0x7a0 [ 75.956250] ? __lock_acquire+0x3b9/0x7a0 [ 75.956252] lock_acquire+0x9a/0x160 [ 75.956259] ? ath_dynack_sample_ack_ts+0x4d/0xa0 [ath9k_hw] [ 75.956262] _raw_spin_lock_bh+0x34/0x80 [ 75.956268] ? ath_dynack_sample_ack_ts+0x4d/0xa0 [ath9k_hw] [ 75.956275] ath_dynack_sample_ack_ts+0x4d/0xa0 [ath9k_hw] [ 75.956280] ath_rx_tasklet+0xd09/0xe90 [ath9k] [ 75.956286] ath9k_tasklet+0x102/0x240 [ath9k] [ 75.956288] tasklet_action_common.isra.0+0x6d/0x170 [ 75.956291] __do_softirq+0xcc/0x425 [ 75.956294] irq_exit+0xae/0xc0 [ 75.956296] do_IRQ+0x8a/0x110 [ 75.956298] common_interrupt+0xf/0xf [ 75.956300] </IRQ> [ 75.956303] RIP: 0010:cpuidle_enter_state+0xb2/0x400 [ 75.956308] RSP: 0018:ffffffff82203e70 EFLAGS: 00000202 ORIG_RAX: ffffffffffffffd7 [ 75.956310] RAX: ffffffff82219800 RBX: ffffffff822bd0a0 RCX: 0000000000000000 [ 75.956312] RDX: 0000000000000046 RSI: 0000000000000006 RDI: ffffffff82219800 [ 75.956314] RBP: ffff888155a01c00 R08: 00000011af51aabe R09: 0000000000000000 [ 75.956315] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 [ 75.956317] R13: 00000011af51aabe R14: 0000000000000003 R15: ffffffff82219800 [ 75.956321] cpuidle_enter+0x24/0x40 [ 75.956323] do_idle+0x1ac/0x220 [ 75.956326] cpu_startup_entry+0x14/0x20 [ 75.956329] start_kernel+0x482/0x489 [ 75.956332] secondary_startup_64+0xa4/0xb0 Fixes: c774d57fd47c ("ath9k: add dynamic ACK timeout estimation") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-09-04ath9k: add loader for AR92XX (and older) pci(e)Gravatar Christian Lamparter 3-0/+233
Atheros cards with a AR92XX generation (and older) chip usually store their pci(e) initialization vectors on an external eeprom chip. However these chips technically don't need the eeprom chip attached, the AR9280 Datasheet in section "6.1.2 DEVICE_ID" describes that "... if the EEPROM content is not valid, a value of 0xFF1C returns when read from the register". So, they will show up on the system's pci bus. However in that state, ath9k can't load, since it relies on having the correct pci-id, otherwise it doesn't know what chip it actually is. This happens on many embedded devices like routers and accesspoint since they want to keep the BOM low and store the pci(e) initialization vectors together with the calibration data on the system's FLASH, which is out of reach of the ath9k chip. Furthermore, Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway) need to be able to initialize the PCIe wifi device. Normally, this should be done as a pci quirk during the early stages of booting linux. However, this isn't possible for devices which have the init code for the Atheros chip stored on NAND in an UBI volume. Hence, this module can be used to initialize the chip when the user-space is ready to extract the init code. Martin Blumenstingl prodived the following fixes: owl-loader: add support for OWL emulation PCI devices owl-loader: don't re-scan the bus when ath9k_pci_fixup failed owl-loader: use dev_* instead of pr_* logging functions owl-loader: auto-generate the eeprom filename as fallback owl-loader: add a debug message when swapping the eeprom data owl-loader: add missing newlines in log messages Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-07-26mac80211: pass the vif to cancel_remain_on_channelGravatar Emmanuel Grumbach 1-1/+2
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>
2019-07-08Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netGravatar David S. Miller 2-2/+2
Two cases of overlapping changes, nothing fancy. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-27ath9k: correctly handle short radar pulsesGravatar Zefir Kurtisi 1-1/+5
In commit 3c0efb745a17 ("ath9k: discard undersized packets") the lower bound of RX packets was set to 10 (min ACK size) to filter those that would otherwise be treated as invalid at mac80211. Alas, short radar pulses are reported as PHY_ERROR frames with length set to 3. Therefore their detection stopped working after that commit. NOTE: ath9k drivers built thereafter will not pass DFS certification. This extends the criteria for short packets to explicitly handle PHY_ERROR frames. Fixes: 3c0efb745a17 ("ath9k: discard undersized packets") Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-06-26ath: fix SPDX tagsGravatar Kalle Valo 2-2/+2
Commit ec8f24b7faaf ("treewide: Add SPDX license identifier - Makefile/Kconfig") marked various Makefiles and Kconfig files within ath directories as GPL-2.0. But these modules and drivers are actually ISC: * ath * ar5523 * ath10k * ath5k * ath6kl * ath9k * wcn36xx * wil6210 Fix SPDX tags accordingly. Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-05-27Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitGravatar Kalle Valo 7-50/+38
ath.git patches for 5.3. Major changes: ath10k * enable SDIO support, first one being QCA6174 hw3.2
2019-05-21treewide: Add SPDX license identifier - Makefile/KconfigGravatar Thomas Gleixner 1-0/+1
Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-05net: wireless: support of_get_mac_address new ERR_PTR errorGravatar Petr Štetiar 1-1/+1
There was NVMEM support added to of_get_mac_address, so it could now return ERR_PTR encoded error values, so we need to adjust all current users of of_get_mac_address to this new fact. Signed-off-by: Petr Štetiar <ynezz@true.cz> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-29ath9k: drop redundant code in ar9003_hw_set_channelGravatar Tomislav Požega 1-21/+3
AR9330, AR9485, AR9531, AR9550, AR9561 and AR9565 all use same channel set register configuration which allows for small code size reduction. Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-29ath9k: Remove some set but not used variablesGravatar YueHaibing 1-11/+0
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/ath/ath9k/xmit.c: In function 'ath_tx_count_frames': drivers/net/wireless/ath/ath9k/xmit.c:413:25: warning: variable 'fi' set but not used [-Wunused-but-set-variable] drivers/net/wireless/ath/ath9k/xmit.c: In function 'ath_tx_complete_aggr': drivers/net/wireless/ath/ath9k/xmit.c:449:24: warning: variable 'hdr' set but not used [-Wunused-but-set-variable] drivers/net/wireless/ath/ath9k/xmit.c: In function 'ath_tx_start': drivers/net/wireless/ath/ath9k/xmit.c:2274:18: warning: variable 'avp' set but not used [-Wunused-but-set-variable] drivers/net/wireless/ath/ath9k/xmit.c:2269:24: warning: variable 'hdr' set but not used [-Wunused-but-set-variable] These variables are not used any more and can be removed. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-29ath9k: Differentiate between max combined and per chain powerGravatar Sven Eckelmann 5-6/+8
The ath9k driver uses as maximum allowed txpower the constant MAX_RATE_POWER. It is used to set a maximum txpower limit for the PHY (which is combined txpower) and also the maximum txpower for per chain rates. Its value 63 is derived from the maximum number the registers can store for the per chain txpower. The max txpower a user can set because of this is 31 dBm (floor(63 / 2)). This also means that a device with multiple tx chains is even limited further: * 1 chain: 31 dBm per chain * 2 chains: 28 dBm per chain * 3 chains: 26 dBm per chain This combined txpower limit of 31 dBm becomes even more problematic when some extra antenna gain is set in the EEPROM. A high power device is then no longer able to reach its potential limits. Instead the code dealing with the combined txpower must use a higher limit than 63 and only the code dealing with the per chain txpower have to use the limit of 63. Since the antenna gain can be quite large and 8 bit variables are often used in ath9k for txpower, a large, divisible by two number like 254 is a good choice for this new limit. Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-29ath9k: Check for errors when reading SREV registerGravatar Tim Schumacher 1-9/+23
Right now, if an error is encountered during the SREV register read (i.e. an EIO in ath9k_regread()), that error code gets passed all the way to __ath9k_hw_init(), where it is visible during the "Chip rev not supported" message. ath9k_htc 1-1.4:1.0: ath9k_htc: HTC initialized with 33 credits ath: phy2: Mac Chip Rev 0x0f.3 is not supported by this driver ath: phy2: Unable to initialize hardware; initialization status: -95 ath: phy2: Unable to initialize hardware; initialization status: -95 ath9k_htc: Failed to initialize the device Check for -EIO explicitly in ath9k_hw_read_revisions() and return a boolean based on the success of the operation. Check for that in __ath9k_hw_init() and abort with a more debugging-friendly message if reading the revisions wasn't successful. ath9k_htc 1-1.4:1.0: ath9k_htc: HTC initialized with 33 credits ath: phy2: Failed to read SREV register ath: phy2: Could not read hardware revision ath: phy2: Unable to initialize hardware; initialization status: -95 ath: phy2: Unable to initialize hardware; initialization status: -95 ath9k_htc: Failed to initialize the device This helps when debugging by directly showing the first point of failure and it could prevent possible errors if a 0x0f.3 revision is ever supported. Signed-off-by: Tim Schumacher <timschumi@gmx.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-29ath9k: Don't trust TX status TID number when reporting airtimeGravatar Toke Høiland-Jørgensen 1-3/+4
As already noted a comment in ath_tx_complete_aggr(), the hardware will occasionally send a TX status with the wrong tid number. If we trust the value, airtime usage will be reported to the wrong AC, which can cause the deficit on that AC to become very low, blocking subsequent attempts to transmit. To fix this, account airtime usage to the TID number from the original skb, instead of the one in the hardware TX status report. Reported-by: Miguel Catalan Cid <miguel.catalan@i2cat.net> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-08mac80211: make ieee80211_schedule_txq schedule empty TXQsGravatar Felix Fietkau 1-1/+4
Currently there is no way for the driver to signal to mac80211 that it should schedule a TXQ even if there are no packets on the mac80211 part of that queue. This is problematic if the driver has an internal retry queue to deal with software A-MPDU retry. This patch changes the behavior of ieee80211_schedule_txq to always schedule the queue, as its only user (ath9k) seems to expect such behavior already: it calls this function on tx status and on powersave wakeup whenever its internal retry queue is not empty. Also add an extra argument to ieee80211_return_txq to get the same behavior. This fixes an issue on ath9k where tx queues with packets to retry (and no new packets in mac80211) would not get serviced. Fixes: 89cea7493a346 ("ath9k: Switch to mac80211 TXQ scheduling and airtime APIs") Signed-off-by: Felix Fietkau <nbd@nbd.name> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-02-26ath9k: remove set but not used variable 'acq'Gravatar YueHaibing 1-8/+1
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/ath/ath9k/recv.c: In function 'ath_rx_count_airtime': drivers/net/wireless/ath/ath9k/recv.c:1010:18: warning: variable 'acq' set but not used [-Wunused-but-set-variable] It's not used after 89cea7493a34 ("ath9k: Switch to mac80211 TXQ scheduling and airtime APIs"). Also remove related variables. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-26ath9k: debugfs: Fix SPUR-DOWN fieldGravatar Andrea Greco 1-1/+1
SPUR DOWN field returns spurup instead of spurdown. Signed-off-by: Andrea Greco <a.greco@4sigma.it> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-26ath9k: Make sure to zero status.tx_time before reporting TX statusGravatar Toke Høiland-Jørgensen 1-0/+3
Since ath9k reports airtime usage directly using the ieee80211_report_airtime() callback, it shouldn't also report it using the tx_time in status. Make sure the field is zeroed before TX status is reported to avoid spurious airtime being accounted by bits being left over from earlier uses of the cb. Fixes: 89cea7493a34 ("ath9k: Switch to mac80211 TXQ scheduling and airtime APIs") Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-12ath9k: Switch to mac80211 TXQ scheduling and airtime APIsGravatar Toke Høiland-Jørgensen 7-276/+75
This moves the ath9k driver to use the mac80211 TXQ scheduling and airtime accounting APIs, removing the corresponding state tracking inside the driver. Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk> [rmanohar@codeaurora.org: fixed checkpatch error and warnings] Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-07ath: move spin_lock_bh to spin_lock in taskletGravatar Zhiwei Jiang 1-3/+3
as you are already in a tasklet, it is unnecessary to call spin_lock_bh, because softirq already disable BH. Signed-off-by: Zhiwei Jiang <qq282012236@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-07ath9k: do not return invalid pointers as a *dentryGravatar Greg Kroah-Hartman 1-0/+3
When calling debugfs functions, they can now return error values if something went wrong. If that happens, return a NULL as a *dentry to the relay core instead of passing it an illegal pointer. The relay core should be able to handle an illegal pointer, but add this check to be safe. Cc: Kalle Valo <kvalo@codeaurora.org> Cc: QCA ath9k Development <ath9k-devel@qca.qualcomm.com> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-04ath9k: eeprom: Use scnprintf instead of snprintfGravatar Kees Cook 1-6/+6
Change snprintf to scnprintf. There are generally two cases where using snprintf causes problems. 1) Uses of size += snprintf(buf, SIZE - size, fmt, ...) In this case, if snprintf would have written more characters than what the buffer size (SIZE) is, then size will end up larger than SIZE. In later uses of snprintf, SIZE - size will result in a negative number, leading to problems. Note that size might already be too large by using size = snprintf before the code reaches a case of size += snprintf. 2) If size is ultimately used as a length parameter for a copy back to user space, then it will potentially allow for a buffer overflow and information disclosure when size is greater than SIZE. When the size is used to index the buffer directly, we can have memory corruption. This also means when size = snprintf... is used, it may also cause problems since size may become large. Copying to userspace is mitigated by the HARDENED_USERCOPY kernel configuration. The solution to these issues is to use scnprintf which returns the number of characters actually written to the buffer, so the size variable will never exceed SIZE. Cc: Willy Tarreau <w@1wt.eu> Cc: Silvio Cesare <silvio.cesare@gmail.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-01-10ath9k: Avoid OF no-EEPROM quirks without qca,no-eepromGravatar Daniel F. Dickinson 1-3/+3
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 <martin.blumenstingl@googlemail.com>) "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 <chunkeey@gmail.com> 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 <martin.blumenstingl@googlemail.com> Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Daniel F. Dickinson <cshored@thecshore.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-12-03Merge tag 'wireless-drivers-next-for-davem-2018-11-30' of ↵Gravatar David S. Miller 9-35/+50
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 4.21 First set of patches for 4.21. Most notable here is support for Quantenna's QSR1000/QSR2000 chipsets and more flexible ways to provide nvram files for brcmfmac. Major changes: brcmfmac * add support for first trying to get a board specific nvram file * add support for getting nvram contents from EFI variables qtnfmac * use single PCIe driver for all platforms and rename Kconfig option CONFIG_QTNFMAC_PEARL_PCIE to CONFIG_QTNFMAC_PCIE * add support for QSR1000/QSR2000 (Topaz) family of chipsets ath10k * add support for WCN3990 firmware crash recovery * add firmware memory dump support for QCA4019 wil6210 * add firmware error recovery while in AP mode ath9k * remove experimental notice from dynack feature iwlwifi * PCI IDs for some new 9000-series cards * improve antenna usage on connection problems * new firmware debugging infrastructure * some more work on 802.11ax * improve support for multiple RF modules with 22000 devices cordic * move cordic macros and defines to a public header file * convert brcmsmac and b43 to fully use cordic library ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-11-06ath9k: Fix a locking bug in ath9k_add_interface()Gravatar Dan Carpenter 1-2/+1
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-11-06ath9k: dynack: remove 'experimental' tagGravatar Lorenzo Bianconi 1-1/+1
Remove experimental tag from dynack Kconfig entry since it has been tested on outdoor 25Km links Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath9k: dynack: make ewma estimation fasterGravatar Lorenzo Bianconi 4-12/+29
In order to make propagation time estimation faster, use current sample as ewma output value during 'late ack' tracking Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath9k: dynack: check da->enabled first in sampling routinesGravatar Lorenzo Bianconi 1-2/+2
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 <koen.vandeputte@ncentric.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath9k: dynack: move debug log after buffer incrementsGravatar Lorenzo Bianconi 1-14/+12
Move debug log in ath_dynack_sample_tx_ts and ath_dynack_sample_ack_ts after timestamp buffer head/tail increments in order to make debugging more user friendly Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06ath9k: dynack: use authentication messages for 'late' ackGravatar Lorenzo Bianconi 1-1/+2
In order to properly support dynack in ad-hoc mode running wpa_supplicant, take into account authentication frames for 'late ack' detection. This patch has been tested on devices mounted on offshore high-voltage stations connected through ~24Km link Reported-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-05ath9k: remove set but not used variable 'new_flags'Gravatar zhong jiang 1-3/+1
new_flags is not used after setting its value. It is safe to remove the unused variable. Signed-off-by: zhong jiang <zhongjiang@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-05ath9k: hw: mark expected switch fall-throughGravatar Gustavo A. R. Silva 1-0/+1
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1056532 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-05ath9k: ar9002_phy: mark expected switch fall-throughsGravatar Gustavo A. R. Silva 1-1/+1
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1056532 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-05ath9k: ar5008_phy: mark expected switch fall-throughGravatar Gustavo A. R. Silva 1-1/+1
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1056532 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-10-13ath9k: fix RX_STAT_INC() etc macrosGravatar Arnd Bergmann 7-49/+49
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 tx99Gravatar Felix Fietkau 4-3/+17
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-10-02ath9k: fix reporting calculated new FFT upper maxGravatar Simon Wunderlich 1-1/+1
Since the debug print code is outside of the loop, it shouldn't use the loop iterator anymore but instead print the found maximum index. Cc: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-10-02ath9k: FFT magnitude check: don't consider lower 3 data bitsGravatar Simon Wunderlich 1-8/+11
There were a lot of Magnitude Mismatch while getting FFT samples on my hardware (Atheros AR9462. I've compared the reported magnitude with the data in the FFT bin, and the FFT bin was less accurate: [ 5395.193030] ath: phy0: FFT HT20 frame: max mag 0x89,max_mag_idx 28, ,magnitude 0x89 max_exp 0, data[28] = 0x88 [ 5395.194525] ath: phy0: FFT HT20 frame: max mag 0x89,max_mag_idx 28, ,magnitude 0x89 max_exp 0, data[28] = 0x88 [ 5395.196012] ath: phy0: FFT HT20 frame: max mag 0x88,max_mag_idx 28, ,magnitude 0x88 max_exp 0, data[28] = 0x88 [ 5395.197509] ath: phy0: FFT HT20 frame: max mag 0x6C,max_mag_idx 28, ,magnitude 0x6C max_exp 0, data[28] = 0x68 [ 5395.199015] ath: phy0: FFT HT20 frame: max mag 0x78,max_mag_idx 28, ,magnitude 0x78 max_exp 0, data[28] = 0x78 [ 5395.200497] ath: phy0: FFT HT20 frame: max mag 0xA1,max_mag_idx 28, ,magnitude 0xA1 max_exp 0, data[28] = 0xA0 [ 5395.202011] ath: phy0: FFT HT20 frame: max mag 0x91,max_mag_idx 28, ,magnitude 0x91 max_exp 0, data[28] = 0x90 [ 5395.203482] ath: phy0: FFT HT20 frame: max mag 0x89,max_mag_idx 28, ,magnitude 0x89 max_exp 0, data[28] = 0x88 [ 5395.204999] ath: phy0: FFT HT20 frame: max mag 0x27,max_mag_idx 4, ,magnitude 0x27 max_exp 0, data[4] = 0x20 [ 5395.206461] ath: phy0: FFT HT20 frame: max mag 0x41,max_mag_idx 28, ,magnitude 0x41 max_exp 0, data[28] = 0x40 [ 5395.207977] ath: phy0: FFT HT20 frame: max mag 0x51,max_mag_idx 28, ,magnitude 0x51 max_exp 0, data[28] = 0x50 [ 5395.209454] ath: phy0: FFT HT20 frame: max mag 0x53,max_mag_idx 28, ,magnitude 0x53 max_exp 0, data[28] = 0x50 [ 5395.210940] ath: phy0: FFT HT20 frame: max mag 0x40,max_mag_idx 28, ,magnitude 0x40 max_exp 0, data[28] = 0x40 [ 5395.212441] ath: phy0: FFT HT20 frame: max mag 0x59,max_mag_idx 28, ,magnitude 0x59 max_exp 0, data[28] = 0x58 [ 5395.213932] ath: phy0: FFT HT20 frame: max mag 0x53,max_mag_idx 28, ,magnitude 0x53 max_exp 0, data[28] = 0x50 [ 5395.215428] ath: phy0: FFT HT20 frame: max mag 0x7D,max_mag_idx 28, ,magnitude 0x7D max_exp 0, data[28] = 0x78 [ 5395.216910] ath: phy0: FFT HT20 frame: max mag 0x8C,max_mag_idx 28, ,magnitude 0x8C max_exp 0, data[28] = 0x88 [ 5395.218413] ath: phy0: FFT HT20 frame: max mag 0x7B,max_mag_idx 28, ,magnitude 0x7B max_exp 0, data[28] = 0x78 [ 5395.219900] ath: phy0: FFT HT20 frame: max mag 0x43,max_mag_idx 28, ,magnitude 0x43 max_exp 0, data[28] = 0x40 It seems like the lower 3 bits on my hardware are always zeroed, but the magnitude matches otherwise. Therefore, let's not make the magnitude check so strict so we can get those samples released to userspace. Cc: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-10-02ath9k: fix and simplify FFT max index retrievalGravatar Simon Wunderlich 2-39/+23
FFT max index retrieval was not retrieved correctly for HT20/HT40 FFT frames. Fixing the retrieval allows us to remove the fixup function as well. While at it, split the spectral_max_index function into versions for ht20 and ht40 to simplify the code. Cc: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-10-02ath9k: return when short FFT frame was handledGravatar Simon Wunderlich 1-1/+1
With the loop break like this, there are false "FFT report truncated" messages because the iterator is not advanced as the check expects. Instead, just return, for a single frame there is nothing left to be done anyways. Cc: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-10-02ath9k: add counters for good and errorneous FFT/spectral framesGravatar Simon Wunderlich 3-2/+19
This is helpful to see whether spectral samples get discarded. Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-10-01ath9k: debug: remove set but not used variable 'fops_dump_nfcal'Gravatar YueHaibing 1-13/+0
'fops_dump_nfcal' is not used since commit 4447d815fd0f ("ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>