- 16 3月, 2017 5 次提交
-
-
由 Mohammed Shafi Shajakhan 提交于
Fetch target operating channel during potential radar detection when the interface is just brought up, but no channel is assigned from userspace. In this scenario rx_channel may not be having a valid pointer hence fetch the target operating channel to avoid warnings as below which can be triggered by the commands with DFS testing over longer run comamnds: iw wlan1 set type mesh ifconfig wlan1 up (valid tgt_oper_chan only) iw wlan1 cac trigger freq 5260 HT20 (valid rx_channel, tgt_oper_chan) iw wlan1 cac trigger freq 5280 HT20 iw wlan1 cac trigger freq 5300 HT20 Once the CAC expires, current channel context will be removed and we are only left with the fallback option of using 'target operating channel' Firmware and driver log: ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5, count_false=4 ath: phy1: DFS: radar found on freq=5260: id=5, pri=3151, count=6, count_false=11 ath: phy1: DFS: radar found on freq=5280: id=1, pri=1351, count=6, count_false=4 ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5, count_false=4 ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse, treating as radar ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse, treating as radar Call trace: WARNING: CPU: 1 PID: 2145 at backports-20161201-3.14.77-9ab3068/net/wireless/chan.c:265 cfg80211_set_dfs_state+0x3c/0x88 [cfg80211]() Workqueue: phy1 ieee80211_dfs_radar_detected_work [mac80211] [<c0320770>] (warn_slowpath_null) from [<bf79b90c>] (cfg80211_set_dfs_state+0x3c/0x88 [cfg80211]) [<bf79b90c>] (cfg80211_set_dfs_state [cfg80211]) from [<bf79697c>] (cfg80211_radar_event+0xc4/0x140 [cfg80211]) [<bf79697c>] (cfg80211_radar_event [cfg80211]) from [<bf83c058>] (ieee80211_dfs_radar_detected_work+0xa8/0xb4 [mac80211]) [<bf83c058>] (ieee80211_dfs_radar_detected_work [mac80211]) from [<c0339518>] (process_one_work+0x298/0x4a4) Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Colin Ian King 提交于
The check on ret for an error is redundant because it is already been checked for non-zero earlier on and ret is never non-zero at this point. Fix this by removing the redundant check and error message. Detected by CoverityScan, CID#1357170 ("Logically Dead Code") Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Zefir Kurtisi 提交于
Doing so enables the FFT generation without prior configuration, leading to an IRQ storm caused by invalid (or at least unwanted) PHY errors. Signed-off-by: NZefir Kurtisi <zefir.kurtisi@neratec.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Tamizh chelvam 提交于
If a 5 GHz radio is calibrated for operation in both the low band (channels 36 to 64) and high band(channels 100 to 169), hardware allows operations in all the listed channels. However, if the chip has been calibrated only for the low/high band and a high/low band channel is configured, due to lack of calibration there will be potentially invalid signal on those non calibrated channels. To avoid this problem this patch sets IEEE80211_CHAN_DISABLED flag for those non calibrated channels by using low_5ghz_chan and high_5ghz_chan values which we get from target through wmi service ready event. Driver initialized flags are getting re initialized in handle_channel in cfg80211. So calling the function to disable the non supported channel from reg_notifier(). Signed-off-by: NTamizh chelvam <c_traja@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Mohammed Shafi Shajakhan 提交于
If DFS is not enabled in hostapd (ieee80211h=0) DFS channels shall not be available for use even though the hardware may have the capability to support DFS. With this configuration (DFS disabled in hostapd) trying to bring up ath10k device in DFS channel for AP mode fails and trying to simulate DFS in ath10k debugfs results in a warning in cfg80211 complaining invalid channel and this should be avoided in the driver itself rather than false propogating RADAR detection to mac80211/cfg80211. Fix this by checking for the first vif 'is_started' state(should work for client mode as well) as all the vifs shall be configured for the same channel sys/kernel/debug/ieee80211/phy1/ath10k# echo 1 > dfs_simulate_radar WARNING: at net/wireless/chan.c:265 cfg80211_radar_event+0x24/0x60 Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211] [<c022f2d4>] (warn_slowpath_null) from [<bf72dab8>] (cfg80211_radar_event+0x24/0x60 [cfg80211]) [<bf72dab8>] (cfg80211_radar_event [cfg80211]) from [<bf7813e0>] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211]) [<bf7813e0>] (ieee80211_dfs_radar_detected_work [mac80211]) from [<c0242320>] (process_one_work+0x20c/0x32c) WARNING: at net/wireless/nl80211.c:2488 nl80211_get_mpath+0x13c/0x4cc Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211] [<c022f2d4>] (warn_slowpath_null) from [<bf72dab8>] (cfg80211_radar_event+0x24/0x60 [cfg80211]) [<bf72dab8>] (cfg80211_radar_event [cfg80211]) from [<bf7813e0>] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211]) [<bf7813e0>] (ieee80211_dfs_radar_detected_work [mac80211]) from [<c0242320>] (process_one_work+0x20c/0x32c) Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 09 3月, 2017 15 次提交
-
-
由 Lior David 提交于
Add a new value to the oob_mode module parameter for supporting AP certification. All enabled values of oob_mode (>0) are intended only for debugging and diagnostics. Signed-off-by: NLior David <qca_liord@qca.qualcomm.com> Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Dedy Lansky 提交于
Driver always invoke cfg80211_disconnected() with locally_generated as false. Fix this by reporting true whenever the disconnect is triggered from upper layers (cfg80211) or from within the driver itself (reset, deinit). Signed-off-by: NDedy Lansky <qca_dlansky@qca.qualcomm.com> Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Dedy Lansky 提交于
Upon connect timeout driver invokes _wil6210_disconnect() which iterates over sta array and disconnects each connected sta. In practice, because the connection is still ongoing and because cid is not yet allocated, disconnect is not actually happening. This leaves FW in connecting state while driver is in disconnected state. To fix this, upon connect timeout, explicitly send WMI_DISCONNECT_CMDID to FW to make sure it gets disconnected. Signed-off-by: NDedy Lansky <qca_dlansky@qca.qualcomm.com> Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Hamad Kadmany 提交于
When flush is done, pending events list is manipulated without taking the proper spinlock, which could lead to memory corruption if list is manipulated by wmi worker or by interrupt routine. Signed-off-by: NHamad Kadmany <qca_hkadmany@qca.qualcomm.com> Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Dedy Lansky 提交于
In a fast disconnect/connect sequence, cfg80211_connect_result() can fail to find the bss object which the driver is connecting to. Detailed sequence of events: * Driver is connected in STA mode * Disconnect request arrives from user space. Driver disconnects and calls cfg80211_disconnected() which adds new event to the cfg80211_wq worker thread * Connect request arrives from user space. cfg80211_connect() stores ssid/ssid_len and calls rdev_connect() * __cfg80211_disconnected() runs in worker thread and zero wdev->ssid_len * Connect succeeds. Driver calls cfg80211_connect_result() which fails to find the bss because wdev->ssid_len is zero To overcome this, upon connect request, store the bss object in the driver and upon connect completion pass it to kernel using cfg80211_connect_bss(). Signed-off-by: NDedy Lansky <qca_dlansky@qca.qualcomm.com> Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Maya Erez 提交于
After setting HALP ICR bit, we keep it set until HALP unvote. Masking HALP ICR should protect the driver from hitting the HALP ICR over and over again. However, in case there is another MISC ICR we will read the HALP ICR and issue a completion. This can lead to a case where HALP voting is completed immediately, as the completion is already set. Reinit the HALP completion before the actual vote will clear previous completions and protect from such cases. Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Dedy Lansky 提交于
Some dynamic debug printouts in driver are using print_hex_dump_bytes. However, with dynamic debug disabled, print_hex_dump_bytes outputs to log unconditionally. Use print_hex_dump_debug instead to prevent log pollution when dynamic debug disabled. Signed-off-by: NDedy Lansky <qca_dlansky@qca.qualcomm.com> Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Lior David 提交于
The driver uses the bus_request platform operation to request resources from the platform for a specific bandwidth. Currently the driver requests resources for the maximum theoretical bandwidth, when interface is brought up. Refine this process a bit: now the driver will request a small amount of resources when interface is up, and will only issue the maximum request when connected. This mechanism will be improved further in the future to make more refined requests based on actual bandwidth. Signed-off-by: NLior David <qca_liord@qca.qualcomm.com> Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Lior David 提交于
The driver should not allow starting any type of scan on a stopped P2P device. Current implementation only checked social scan. Signed-off-by: NLior David <qca_liord@qca.qualcomm.com> Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Hamad Kadmany 提交于
device supports 48bit addresses, reflect that by setting the dma mask accordingly. Signed-off-by: NHamad Kadmany <qca_hkadmany@qca.qualcomm.com> Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Christophe Jaillet 提交于
Reorder 'out_free_dxe_pool' and 'out_free_dxe_ctl' error handling labels in order to match the way resources have been allocated. Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Mohammed Shafi Shajakhan 提交于
Doing a channel switch via hostapd_cli seems to update the new channel context for each VAP's appropriately as below in 'ath10k_mac_update_vif_chan', hence we can safely suppress the warning that shows up during this operation and dump the warning only if no vaps are available for channel switch hostapd_cli -i wlan0 chan_switch 5 5200 OK ath10k_pci : mac chanctx switch n_vifs 3 mode 1 ath10k_pci : mac chanctx switch vdev_id 2 freq 5180->5200 width 0->0 ath10k_pci : mac chanctx switch vdev_id 1 freq 5180->5200 width 0->0 ath10k_pci : mac chanctx switch vdev_id 0 freq 5180->5200 width 0->0 Call Trace: WARNING: backports-20161201-3.14.77-9ab3068/drivers/net/wireless/ath/ath10k/mac.c:7126 [<c022f2d4>] (warn_slowpath_null) from [<bf7f150c>] (ath10k_reconfig_complete+0xe4/0x25c [ath10k_core]) [<bf7f150c>] (ath10k_reconfig_complete [ath10k_core]) [<bf7f35f0>] (ath10k_mac_vif_ap_csa_work+0x214/0x370 [ath10k_core]) [<bf7f38b8>] (ath10k_mac_op_change_chanctx+0x108/0x128 [ath10k_core]) [<bf782ac0>] (ieee80211_recalc_chanctx_min_def+0x30c/0x430 [mac80211]) [<bf7830a4>] (ieee80211_recalc_smps_chanctx+0x2ec/0x840 [mac80211]) [<bf7843e8>] (ieee80211_vif_use_reserved_context+0x7c/0xf8 [mac80211]) [<bf7843e8>] (ieee80211_vif_use_reserved_context [mac80211]) [<bf76e5d4>] (ieee80211_csa_finalize_work+0x5c/0x88 [mac80211]) Fixes: d7bf4b4a ("ath10k: fix ar->rx_channel updating logic") Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Dmitry Tunin 提交于
T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 P: Vendor=1eda ProdID=2315 Rev=01.08 S: Manufacturer=ATHEROS S: Product=USB2.0 WLAN S: SerialNumber=12345 C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 6 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) Signed-off-by: NDmitry Tunin <hanipouspilot@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Ryan Hsu 提交于
QCA9377 is the family of QCA61x4 which shared the same procedure to enable the hardware clock that could improve the firmware download time. Signed-off-by: NRyan Hsu <ryanhsu@qca.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Ryan Hsu 提交于
Len Brown reported the system resume time is taking more than 2 seconds in bug - https://bugzilla.kernel.org/show_bug.cgi?id=185621. The reason of the 2 seconds is due to the firmware download time. The chip is booted up in the default reference clock speed to handle the firmware download to chip memory and advanced to the support higher speed clock to run the firmware after all. The default reference clock in the hardware is slow so that the firmware download time is taking up to 2 seconds for a 600KB firmware file. [76796.349701] ath10k_pci : boot uploading firmware image len 688691 [76798.334612] ath10k_pci : htt tx max num pending tx 1056 The resolution here is to enable the higher speed clock if the hardware supported before the firmware download at BMI stage, so that the hardware can handle the firmare download in a more efficient way. This can help to improve the firmware download time from 2 seconds to around 500ms for the same 600KB firmware file. [322858.577919] ath10k_pci boot uploading firmware image len 688691 [322859.093094] ath10k_pci htt tx max num pending tx 1056 The steps to advance to the higher speed clock is very hardware specific, so adding the hardware ops for the hardware that can support this. Reported-by: NLen Brown <lenb@kernel.org> Tested-by: NPaul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: NRyan Hsu <ryanhsu@qca.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 02 3月, 2017 3 次提交
-
-
由 Waldemar Rymarkiewicz 提交于
Board Data File (BDF) is loaded upon driver boot-up procedure. The right board data file is identified, among others, by device and sybsystem ids. The problem, however, can occur when the (default) board data file cannot fulfill with the vendor requirements and it is necessary to use a different board data file. To solve the issue QCA uses SMBIOS type 0xF8 to store Board Data File Name Extension to specify the extension/variant name. The driver will take the extension suffix into consideration and will load the right (non-default) board data file if necessary. If it is unnecessary to use extension board data file, please leave the SMBIOS field blank and default configuration will be used. Example: If a default board data file for a specific board is identified by a string "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028, subsystem-device=0310" then the OEM specific data file, if used, could be identified by variant suffix: "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028, subsystem-device=0310,variant=DE_1AB" If board data file name extension is set but board-2.bin does not contain board data file for the variant, the driver will fallback to the default board data file not to break backward compatibility. This was first applied in commit f2593cb1 ("ath10k: Search SMBIOS for OEM board file extension") but later reverted in commit 005c3490 ("Revert "ath10k: Search SMBIOS for OEM board file extension"". This patch is now otherwise the same as commit f2593cb1 except the regression fixed. Signed-off-by: NWaldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Ingo Molnar 提交于
sched/headers: Prepare to move signal wakeup & sigpending methods from <linux/sched.h> into <linux/sched/signal.h> Fix up affected files that include this signal functionality via sched.h. Acked-by: NLinus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Johannes Berg 提交于
Declaring the factor is counter-intuitive, and people are prone to using small(-ish) values even when that makes no sense. Change the DECLARE_EWMA() macro to take the fractional precision, in bits, rather than a factor, and update all users. While at it, add some more documentation. Acked-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 28 2月, 2017 1 次提交
-
-
由 Masahiro Yamada 提交于
Fix typos and add the following to the scripts/spelling.txt: aligment||alignment I did not touch the "N_BYTE_ALIGMENT" macro in drivers/net/wireless/realtek/rtlwifi/wifi.h to avoid unpredictable impact. I fixed "_aligment_handler" in arch/openrisc/kernel/entry.S because it is surrounded by #if 0 ... #endif. It is surely safe and I confirmed "_alignment_handler" is correct. I also fixed the "controler" I found in the same hunk in arch/openrisc/kernel/head.S. Link: http://lkml.kernel.org/r/1481573103-11329-8-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 22 2月, 2017 1 次提交
-
-
由 Kalle Valo 提交于
This reverts commit f2593cb1. Paul reported that this patch with older board-2.bin ath10k initialisation fails on Dell XPS 13: ath10k_pci 0000:3a:00.0: failed to fetch board data for bus=pci,vendor=168c, device=003e,subsystem-vendor=1a56,subsystem-device=1535,variant=RV_0520 from ath10k/QCA6174/hw3.0/board-2.bin The reason is that the older board-2.bin does not have the variant version of the image name and ath10k does not fallback to the older naming scheme. Reported-by: NPaul Menzel <pmenzel@molgen.mpg.de> Link: https://bugzilla.kernel.org/show_bug.cgi?id=185621#c9 Fixes: f2593cb1 ("ath10k: Search SMBIOS for OEM board file extension") Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 15 2月, 2017 13 次提交
-
-
由 Christian Lamparter 提交于
This patch fixes the OTP register definitions for the AR934x and AR9550 WMAC SoC. Previously, the ath9k driver was unable to initialize the integrated WMAC on an Aerohive AP121: | ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x00000007 != 0x00000004 | ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x00000007 != 0x00000004 | ath: phy0: Unable to initialize hardware; initialization status: -5 | ath9k ar934x_wmac: failed to initialize device | ath9k: probe of ar934x_wmac failed with error -5 It turns out that the AR9300_OTP_STATUS and AR9300_OTP_DATA definitions contain a typo. Cc: Gabor Juhos <juhosg@openwrt.org> Cc: stable@vger.kernel.org Fixes: add295a4 "ath9k: use correct OTP register offsets for AR9550" Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com> Signed-off-by: NChris Blake <chrisrblake93@gmail.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Sven Eckelmann 提交于
The relayfs was changed to use per CPU constructs to handle the rchan buffers. But the users of the rchan buffers in other parts of the kernel were not modified. This caused crashes like BUG: unable to handle kernel paging request at 00003a5198a0b910 IP: [<ffffffffa973cb3a>] ath_cmn_process_fft+0xea/0x610 PGD 0 [ 179.522449] Oops: 0000 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc5 #1 [...] Call Trace: <IRQ> [ 179.656426] [<ffffffffa9704373>] ? ath_rx_tasklet+0x2f3/0xd10 [<ffffffffa9702106>] ? ath9k_tasklet+0x1b6/0x230 [<ffffffffa90dcbd1>] ? tasklet_action+0xf1/0x100 [<ffffffffa9a3cb3f>] ? __do_softirq+0xef/0x284 [<ffffffffa90dd22e>] ? irq_exit+0xae/0xb0 [<ffffffffa9a3c89f>] ? do_IRQ+0x4f/0xd0 [<ffffffffa9a3aa42>] ? common_interrupt+0x82/0x82 <EOI> [ 179.703152] [<ffffffffa9a39c1d>] ? poll_idle+0x2d/0x57 [<ffffffffa908c845>] ? sched_clock+0x5/0x10 [<ffffffffa97bc8d6>] ? cpuidle_enter_state+0xf6/0x2d0 [<ffffffffa911988e>] ? cpu_startup_entry+0x14e/0x230 [<ffffffffaa3cdf70>] ? start_kernel+0x461/0x481 [<ffffffffaa3cd120>] ? early_idt_handler_array+0x120/0x120 [<ffffffffaa3cd413>] ? x86_64_start_kernel+0x14c/0x170 Code: 31 db 41 be ff ff ff ff 4c 8b 26 48 8b 6e 08 49 8b 84 24 60 05 00 00 48 8b 00 0f b7 40 04 66 89 44 24 48 eb 11 48 8b 55 40 48 98 <48> 8b 3c c2 e8 ad a0 a4 ff 01 c3 41 8d 56 01 be 00 02 00 00 48 RIP [<ffffffffa973cb3a>] ath_cmn_process_fft+0xea/0x610 RSP <ffff9b43e7003d20> CR2: 00003a5198a0b910 Fixes: 017c59c0 ("relay: Use per CPU constructs for the relay channel buffer pointers") Cc: Akash Goel <akash.goel@intel.com> Cc: Nick Kossifidis <mickflemm@gmail.com> Reported-by: NMathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de> Signed-off-by: NSven Eckelmann <sven@narfation.org> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Felix Fietkau 提交于
ath_tx_count_airtime is doing a lot of unnecessary work: - Redundant station lookup - Redundant rcu_read_lock/unlock - Useless memcpy of bf->rates - Useless NULL check of bf->bf_mpdu - Redundant lookup of the skb tid Additionally, it tries to look up the mac80211 queue index from the txq, which fails if the frame was delivered via the power save queue. This patch fixes all of these issues by passing down the right set of pointers instead of doing extra work Cc: stable@vger.kernel.org Fixes: 63fefa05 ("ath9k: Introduce airtime fairness scheduling between stations") Signed-off-by: NFelix Fietkau <nbd@nbd.name> Acked-by: NToke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Tobias Klauser 提交于
Instead of using a private copy of struct net_device_stats in struct ath6kl_vif, use stats from struct net_device. Also remove the now unnecessary .ndo_get_stats function. Signed-off-by: NTobias Klauser <tklauser@distanz.ch> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Ryan Hsu 提交于
The variant[] string will be valid only if the bdf_ext is set. The string memory needs to be null-terminated to avoid the undefined garbage appended by the subsequent board file name creation. ath10k_pci 0000:04:00.0: failed to fetch board data for "bus=pci,vendor=168c,device=003e,subsystem-vendor=168c,subsystem-device=3363��P�����" from ath10k/QCA6174/hw3.0/board-2.bin Fixes: f2593cb1 ("ath10k: Search SMBIOS for OEM board file extension") Reported-by: NKalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: NRyan Hsu <ryanhsu@qca.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Kalle Valo 提交于
Currently ath10k unncessarily warns about board id not available from OTP: ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000 ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1 ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.9-2 api 5 features no-p2p,raw-mode crc32 b8d50af5 ath10k_pci 0000:02:00.0: board id is not exist in otp, ignore it ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 ath10k_pci 0000:02:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 But not all boards have the board id in OTP so this is not a problem and no need to confuse the user with that info. So this can be safely changed to a debug message. Also fix grammar in the debug message. Fixes: d2e202c0 ("ath10k: ignore configuring the incorrect board_id") Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
Firmware files are versioned to prevent older driver instances to load unsupported firmware blobs. This is reflected with a fallback logic which attempts to load several firmware files. This however produced a lot of unnecessary warnings sometimes confusing users and leading them to rename firmware files making things even more confusing. Hence use request_firmware_direct() which does not produce extra warnings. This shouldn't really break anything because most modern systems don't rely on udev/hotplug helpers to load firmware files anymore. For example it was confirmed that LEDE does not user helper. This also fixes a 60 second delay per _each_ unexistent firmware/calibration file with distros which have CONFIG_FW_LOADER_USER_HELPER_FALLBACK enabled, RHEL being a notable example. Using ath10k with firmware-2.bin this might end up into a five minute delay in boot. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> [kvalo@qca.qualcomm.com: add more info to the commit log] Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Kalle Valo 提交于
This way user has a better idea what file exactly is missing. This is needed when we switch to using request_firmware_direct() which doesn't print any errors anymore. Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Erik Stromdahl 提交于
To make it easier to handle minimum and maximum firmware API numbers convert the firmware fetch functionality to a loop. If no firmware image is found print an error with minimum and maximum API numbers and the name of firmware directory. This is needed when we switch to using request_firmware_direct() which doesn't print any errors anymore. Also add a new function for creating the fw file name dynamically which makes it easier to add new bus support, for example SDIO and USB, later. Signed-off-by: NErik Stromdahl <erik.stromdahl@gmail.com> [kvalo@qca.qualcomm.com: remove sdio/usb part, new error message, clarify commit log] Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Kalle Valo 提交于
This fixes the below crash when ath10k probe firmware fails, NAPI polling tries to access a rx ring resource which was never allocated. An easy way to reproduce this is easy to remove all the firmware files, load ath10k modules and ath10k will crash when calling 'rmmod ath10k_pci'. The fix is to call napi_enable() from ath10k_pci_hif_start() so that it matches with napi_disable() being called from ath10k_pci_hif_stop(). Big thanks to Mohammed Shafi Shajakhan who debugged this and provided first version of the fix. In this patch I just fix the actual problem in pci.c instead of having a workaround in core.c. BUG: unable to handle kernel NULL pointer dereference at (null) IP: __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core] __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core] Call Trace: [<ffffffffa113ec62>] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90 [ath10k_core] [<ffffffffa113f393>] ath10k_htt_txrx_compl_task+0x433/0x17d0 [ath10k_core] [<ffffffff8114406d>] ? __wake_up_common+0x4d/0x80 [<ffffffff811349ec>] ? cpu_load_update+0xdc/0x150 [<ffffffffa119301d>] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci] [<ffffffffa1195b17>] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci] [<ffffffff817863af>] net_rx_action+0x20f/0x370 Reported-by: NBen Greear <greearb@candelatech.com> Fixes: 3c97f5de ("ath10k: implement NAPI support") Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Amadeusz Sławiński 提交于
I wanted to take a look and it's apparently in other header Signed-off-by: NAmadeusz Sławiński <amadeusz.slawinski@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Amadeusz Sławiński 提交于
cleanup to consolidate type used for len variables Signed-off-by: NAmadeusz Sławiński <amadeusz.slawinski@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Amadeusz Sławiński 提交于
it adds unnecessary level of indirection, while we just access structure field Signed-off-by: NAmadeusz Sławiński <amadeusz.slawinski@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 11 2月, 2017 1 次提交
-
-
由 Russell King 提交于
Fix these errors reported by the 0-day builder by replacing the linux/export.h include with linux/module.h. In file included from include/linux/platform_device.h:14:0, from drivers/net/wireless/ath/ath5k/ahb.c:20: include/linux/device.h:1463:1: warning: data definition has no type or storage class module_init(__driver##_init); \ ^ include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver' module_driver(__platform_driver, platform_driver_register, \ ^~~~~~~~~~~~~ drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 'module_platform_driver' module_platform_driver(ath_ahb_driver); ^~~~~~~~~~~~~~~~~~~~~~ include/linux/device.h:1463:1: error: type defaults to 'int' in declaration of 'module_init' [-Werror=implicit-int] module_init(__driver##_init); \ ^ include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver' module_driver(__platform_driver, platform_driver_register, \ ^~~~~~~~~~~~~ drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 'module_platform_driver' module_platform_driver(ath_ahb_driver); ^~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/ath/ath5k/ahb.c:233:1: warning: parameter names (without types) in function declaration In file included from include/linux/platform_device.h:14:0, from drivers/net/wireless/ath/ath5k/ahb.c:20: include/linux/device.h:1468:1: warning: data definition has no type or storage class module_exit(__driver##_exit); ^ include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver' module_driver(__platform_driver, platform_driver_register, \ ^~~~~~~~~~~~~ drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 'module_platform_driver' module_platform_driver(ath_ahb_driver); ^~~~~~~~~~~~~~~~~~~~~~ include/linux/device.h:1468:1: error: type defaults to 'int' in declaration of 'module_exit' [-Werror=implicit-int] module_exit(__driver##_exit); ^ include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver' module_driver(__platform_driver, platform_driver_register, \ ^~~~~~~~~~~~~ drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 'module_platform_driver' module_platform_driver(ath_ahb_driver); ^~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/ath/ath5k/ahb.c:233:1: warning: parameter names (without types) in function declaration In file included from include/linux/platform_device.h:14:0, from drivers/net/wireless/ath/ath5k/ahb.c:20: drivers/net/wireless/ath/ath5k/ahb.c:233:24: warning: 'ath_ahb_driver_exit' defined but not used [-Wunused-function] module_platform_driver(ath_ahb_driver); ^ include/linux/device.h:1464:20: note: in definition of macro 'module_driver' static void __exit __driver##_exit(void) \ ^~~~~~~~ drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 'module_platform_driver' module_platform_driver(ath_ahb_driver); ^~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/ath/ath5k/ahb.c:233:24: warning: 'ath_ahb_driver_init' defined but not used [-Wunused-function] module_platform_driver(ath_ahb_driver); ^ include/linux/device.h:1459:19: note: in definition of macro 'module_driver' static int __init __driver##_init(void) \ ^~~~~~~~ drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 'module_platform_driver' module_platform_driver(ath_ahb_driver); ^~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk> Acked-by: NKalle Valo <kvalo@codeaurora.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 08 2月, 2017 1 次提交
-
-
由 Johannes Berg 提交于
This is necessary so that - if ath10k is the only driver using dev_coredump*() - the functionality is built into the kernel. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-