summaryrefslogtreecommitdiff
path: root/drivers/net/wireless (follow)
Commit message (Collapse)AuthorAge
...
* | | | | ath10k: fix some typo in spectral code commmentsMohammed Shafi Shajakhan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found this obvious typo while going through the spectral code design in ath10k Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: disable TX_STBC for tx chainmask of 1Mohammed Shafi Shajakhan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Disable TX_STBC for both HT and VHT if the devices tx chainmask is '1' TX_STBC is required only for devices with tx_chainmask > 1. This fixes a ping failure for QCA9887 (1x1) in HT/VHT mode Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: enable beacon loss detection support for 10.4Mohammed Shafi Shajakhan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable beacon loss detection support for 10.4 by handling roam event. With this change QCA99X0 station is able to detect beacon loss when the AP is powered off Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: fix potential null dereference bugsBob Copeland2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Smatch warns about a number of cases in ath10k where a pointer is null-checked after it has already been dereferenced, in code involving ath10k private virtual interface pointers. Fix these by making the dereference happen later. Addresses the following smatch warnings: drivers/net/wireless/ath/ath10k/mac.c:3651 ath10k_mac_txq_init() warn: variable dereferenced before check 'txq' (see line 3649) drivers/net/wireless/ath/ath10k/mac.c:3664 ath10k_mac_txq_unref() warn: variable dereferenced before check 'txq' (see line 3659) drivers/net/wireless/ath/ath10k/htt_tx.c:70 __ath10k_htt_tx_txq_recalc() warn: variable dereferenced before check 'txq->sta' (see line 52) drivers/net/wireless/ath/ath10k/htt_tx.c:740 ath10k_htt_tx_get_vdev_id() warn: variable dereferenced before check 'cb->vif' (see line 736) drivers/net/wireless/ath/ath10k/txrx.c:86 ath10k_txrx_tx_unref() warn: variable dereferenced before check 'txq' (see line 84) drivers/net/wireless/ath/ath10k/wmi.c:1837 ath10k_wmi_op_gen_mgmt_tx() warn: variable dereferenced before check 'cb->vif' (see line 1825) Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: remove unneccessary WARN_ON_ONCE in rx during ACSMohammed Shafi Shajakhan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The below warning message seems to hit occasionally with the following combination (IPQ4019 + ACS scan) where we receive packets as a self peer when hostapd does ACS when we bring up AP mode . ath10k has the below fall back mechanism to fetch current operating channel in rx (it will check for the next channel tracking variable if the current one is NULL) [scan channel] --> [rx channel] --> [peer channel] --> [vdev channel] --> [any vdev channel] --> [target oper channel] 'scan channel' and 'target operating channel' are directly fetched from firmware events. All the others should be updated by mac80211. During ACS scan we wouldn't have a valid channel context assigned from mac80211 ('ar->rx_channel'), and also relying on ('ar->scan_channel') is not helpful (it becomes NULL when it goes to BSS channel and also when the scan event is completed). In short we cannot always rely on these two channel tracking variables. 'Target Operating Channel' (ar->tgt_oper_chan) seems to keep track of the current operating even while we are doing ACS scan and etc. Hence remove this un-necessary warning message and continue with target_operating channel. At the worst case scenario when the target operating channel is invalid (NULL) we already have an ath10k warning message to notify we really don't have a proper channel configured in rx to update the rx status("no channel configured; ignoring frame(s)!") WARNING: CPU: 0 PID: 0 at ath/ath10k/htt_rx.c:803 [<c0318838>] (warn_slowpath_null) from [<bf4a0104>] (ath10k_htt_rx_h_channel+0xe0/0x1b8 [ath10k_core]) [<bf4a0104>] (ath10k_htt_rx_h_channel [ath10k_core]) from [<bf4a025c>] (ath10k_htt_rx_h_ppdu+0x80/0x288 [ath10k_core]) [<bf4a025c>] (ath10k_htt_rx_h_ppdu [ath10k_core]) from [<bf4a1a9c>] (ath10k_htt_txrx_compl_task+0x724/0x9d4 [ath10k_core]) [<bf4a1a9c>] (ath10k_htt_txrx_compl_task [ath10k_core]) Fixes:3b0499e9ce42 ("ath10k: reduce warning messages during rx without proper channel context") Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: fix crash during card removalMohammed Shafi Shajakhan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Usually when the firmware crashes we check for the value 'FW_IND_EVENT_PENDING' in 'FW_INDICATOR_ADDRESS' and proceed with disabling the irq and dumping firmware 'crash dump'. Now when the PCI card is unplugged from the device the PCI controller seems to generate a spurious interrupt after some time which was as treated a firmware crash and resulting in the below race condition (and eventually crashing the system) ath10k_core_unregister -> ath10k_core_free_board_files ...... device unplug spurious interrupt ......... ath10k_pci_taklet -> ath10k_pci_fw_crashed_dump ...etc Clearly even after the firmware board files related data structure is freed up we are getting a spurious interrupt from PCI with 0xfffffff in the 'FW_INDICATOR_ADDRESS' resulting in scheduling of the pci tasklet and doing a crash dump, printing f/w board related info resulting in the below crash. Fix this by detecting this spurious interrupt in ath10k PCI irq handler itself and return IRQ_NONE. Thanks to Michal Kazior for helping us conclude the most appropriate fix. Call trace: EIP is at ath10k_debug_print_board_info+0x39/0xb0 [ath10k_core] EAX: 00000000 EBX: d4de15a0 ECX: 00000000 EDX: 00000064 ESI: f615ddd0 EDI: f8530000 EBP: f615de3c ESP: f615ddbc DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 CR0: 80050033 CR2: 00000004 CR3: 01c0a000 CR4: 000006f0 Stack: f615ddd0 00000064 f8b4ecdd 00000000 00000000 00412f4e 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Call Trace: [<f8b1f517>] ath10k_print_driver_info+0x17/0x30 [ath10k_core] [<f875463a>] ath10k_pci_fw_crashed_dump+0x7a/0xe0 [ath10k_pci] [<f87549d0>] ath10k_pci_tasklet+0x70/0x90 [ath10k_pci] [<c106151e>] tasklet_action+0x9e/0xb0 Cc: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: fix deadlock while processing rx_in_ord_indRajkumar Manoharan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 5c86d97bcc1d ("ath10k: combine txrx and replenish task") introduced deadlock while processing rx in order indication message for qca6174 based devices. While merging replenish and txrx tasklets, replenish task should be called out of htt rx ring locking since it is also try to acquire the same lock. Unfortunately this issue is not exposed by other solutions (qca988x, qca99x0 & qca4019), as rx_in_ord_ind message is specific to qca6174 based devices. This patch fixes ============================================= [ INFO: possible recursive locking detected ] 4.7.0-rc2-wt-ath+ #1353 Tainted: G E --------------------------------------------- swapper/3/0 is trying to acquire lock: (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d7ef19>] ath10k_htt_rx_msdu_buff_replenish+0x29/0x90 [ath10k_core] but task is already holding lock: (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d82cab>] ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&htt->rx_ring.lock)->rlock); lock(&(&htt->rx_ring.lock)->rlock); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by swapper/3/0: #0: (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d82cab>] ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=119151 Fixes: 5c86d97bcc1d ("ath10k: combine txrx and replenish task") Reported-by: Mike Lothian <mike@fireburn.co.uk> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: fix cycle counter wraparound handling for QCA4019Vasanthakumar Thiagarajan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In QCA4019, cycle counter wraparound is not tied to rx clear counter. Each counter would wraparound individually and after wraparound the respective counter will be reset to 0x7fffffff while other counter still running unaffected. Define a new wraparound type for this behaviour and handle it separately so that rx clear counter wraparound is also handled just like cycle counter. With this type of wraparound we can accurately compute and report channel active/busy time when any of the counter overflows. Fixes: ee9ca147c59 ("ath10k: Fix survey reporting with QCA4019") Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: define an enum to enable cycle counter wraparound logicVasanthakumar Thiagarajan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QCA988X hw implements a different cycle counter wraparound behaviour when compared to QCA4019. To properly handle different wraparound logic for these chipsets replace already available bool hw_params member, has_shifted_cc_wraparound, with an enum which could be extended to handle different wraparound behaviour. This patch keeps the existing logic functionally same and a prepares cycle counter wraparound handling to extend for other chips. Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> [kvalo@qca.qualcomm.com: change also QCA9887 wrap type] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: fix CCK h/w rates for QCA99X0 and newer chipsetsMohammed Shafi Shajakhan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CCK hardware table mapping from QCA99X0 onwards got revised. The CCK hardware rate values are in a proper order wrt. to rate and preamble as below ATH10K_HW_RATE_REV2_CCK_LP_1M = 1, ATH10K_HW_RATE_REV2_CCK_LP_2M = 2, ATH10K_HW_RATE_REV2_CCK_LP_5_5M = 3, ATH10K_HW_RATE_REV2_CCK_LP_11M = 4, ATH10K_HW_RATE_REV2_CCK_SP_2M = 5, ATH10K_HW_RATE_REV2_CCK_SP_5_5M = 6, ATH10K_HW_RATE_REV2_CCK_SP_11M = 7, This results in reporting of rx frames (with CCK rates) totally wrong for QCA99X0, QCA4019. Fix this by having separate CCK rate table for these chipsets with rev2 suffix and registering the correct rate mapping to mac80211 based on the new hw_param (introduced) 'cck_rate_map_rev2' which shall be true for any newchipsets from QCA99X0 onwards Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: remove duplicate and unused rx rate flagsMohammed Shafi Shajakhan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All these flags are not used and their use is completely covered by 'ath10k_hw_rate_ofdm', 'ath10k_hw_rate_cck', and RX_PPDU_START_RATE_FLAG Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: fix some of the macro definitions of HTT_RX_IND messageVasanthakumar Thiagarajan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Only five bits are defined to pass tid information in HTT_RX_IND message, so the mask which can be used to extract tid should be 0x1f instead of the current 0x3f. Also, macros which can be used to extract flush_valid and release_valid bits have to be left shifted one bit less because these information follow the tid right after. This patch does not really fix anything functionally because these macros are not used currently. Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: fix crash related to printing featuresBen Greear2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This looks like a regression from commit c4cdf753ed42 ("ath10k: move fw_features to struct ath10k_fw_file"), we were printing the features from a wrong struct. Fixes: c4cdf753ed42 ("ath10k: move fw_features to struct ath10k_fw_file") Signed-off-by: Ben Greear <greearb@candelatech.com> [kvalo@qca.qualcomm.com: improve commit log] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: add board data download from targetSven Eckelmann2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The QCA9887 stores its calibration data (board.bin) inside the EEPROM of the target. This has to be downloaded manually to allow the device to initialize correctly. Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com> [kvalo@qca.qualcomm.com: handle -EOPNOTSUPP and s/fetch_board_data/fetch_cal_eeprom] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: add QCA9887 chipset supportSven Eckelmann2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the hardware name, revision, firmware names and update the pci_id table. QA9887 HW1.0 is supposed to be similar to QCA988X HW2.0 . Details about he firmware interface are currently unknown. Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com> [kvalo@qca.qualcomm.com: add a warning about experimental support] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: fix deadlock when peer cannot be createdBen Greear2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We must not attempt to send WMI packets while holding the data-lock, as it may deadlock: BUG: sleeping function called from invalid context at drivers/net/wireless/ath/ath10k/wmi.c:1824 in_atomic(): 1, irqs_disabled(): 0, pid: 2878, name: wpa_supplicant ============================================= [ INFO: possible recursive locking detected ] 4.4.6+ #21 Tainted: G W O --------------------------------------------- wpa_supplicant/2878 is trying to acquire lock: (&(&ar->data_lock)->rlock){+.-...}, at: [<ffffffffa0721511>] ath10k_wmi_tx_beacons_iter+0x26/0x11a [ath10k_core] but task is already holding lock: (&(&ar->data_lock)->rlock){+.-...}, at: [<ffffffffa070251b>] ath10k_peer_create+0x122/0x1ae [ath10k_core] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&ar->data_lock)->rlock); lock(&(&ar->data_lock)->rlock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by wpa_supplicant/2878: #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff816493ca>] rtnl_lock+0x12/0x14 #1: (&ar->conf_mutex){+.+.+.}, at: [<ffffffffa0706932>] ath10k_add_interface+0x3b/0xbda [ath10k_core] #2: (&(&ar->data_lock)->rlock){+.-...}, at: [<ffffffffa070251b>] ath10k_peer_create+0x122/0x1ae [ath10k_core] #3: (rcu_read_lock){......}, at: [<ffffffffa062f304>] rcu_read_lock+0x0/0x66 [mac80211] stack backtrace: CPU: 3 PID: 2878 Comm: wpa_supplicant Tainted: G W O 4.4.6+ #21 Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.5 06/07/2013 0000000000000000 ffff8801fcadf8f0 ffffffff8137086d ffffffff82681720 ffffffff82681720 ffff8801fcadf9b0 ffffffff8112e3be ffff8801fcadf920 0000000100000000 ffffffff82681720 ffffffffa0721500 ffff8801fcb8d348 Call Trace: [<ffffffff8137086d>] dump_stack+0x81/0xb6 [<ffffffff8112e3be>] __lock_acquire+0xc5b/0xde7 [<ffffffffa0721500>] ? ath10k_wmi_tx_beacons_iter+0x15/0x11a [ath10k_core] [<ffffffff8112d0d0>] ? mark_lock+0x24/0x201 [<ffffffff8112e908>] lock_acquire+0x132/0x1cb [<ffffffff8112e908>] ? lock_acquire+0x132/0x1cb [<ffffffffa0721511>] ? ath10k_wmi_tx_beacons_iter+0x26/0x11a [ath10k_core] [<ffffffffa07214eb>] ? ath10k_wmi_cmd_send_nowait+0x1ce/0x1ce [ath10k_core] [<ffffffff816f9e2b>] _raw_spin_lock_bh+0x31/0x40 [<ffffffffa0721511>] ? ath10k_wmi_tx_beacons_iter+0x26/0x11a [ath10k_core] [<ffffffffa0721511>] ath10k_wmi_tx_beacons_iter+0x26/0x11a [ath10k_core] [<ffffffffa07214eb>] ? ath10k_wmi_cmd_send_nowait+0x1ce/0x1ce [ath10k_core] [<ffffffffa062eb18>] __iterate_interfaces+0x9d/0x13d [mac80211] [<ffffffffa062f609>] ieee80211_iterate_active_interfaces_atomic+0x32/0x3e [mac80211] [<ffffffffa07214eb>] ? ath10k_wmi_cmd_send_nowait+0x1ce/0x1ce [ath10k_core] [<ffffffffa071fa9f>] ath10k_wmi_tx_beacons_nowait.isra.13+0x14/0x16 [ath10k_core] [<ffffffffa0721676>] ath10k_wmi_cmd_send+0x71/0x242 [ath10k_core] [<ffffffffa07023f6>] ath10k_wmi_peer_delete+0x3f/0x42 [ath10k_core] [<ffffffffa0702557>] ath10k_peer_create+0x15e/0x1ae [ath10k_core] [<ffffffffa0707004>] ath10k_add_interface+0x70d/0xbda [ath10k_core] [<ffffffffa05fffcc>] drv_add_interface+0x123/0x1a5 [mac80211] [<ffffffffa061554b>] ieee80211_do_open+0x351/0x667 [mac80211] [<ffffffffa06158aa>] ieee80211_open+0x49/0x4c [mac80211] [<ffffffff8163ecf9>] __dev_open+0x88/0xde [<ffffffff8163ef6e>] __dev_change_flags+0xa4/0x13a [<ffffffff8163f023>] dev_change_flags+0x1f/0x54 [<ffffffff816a5532>] devinet_ioctl+0x2b9/0x5c9 [<ffffffff816514dd>] ? copy_to_user+0x32/0x38 [<ffffffff816a6115>] inet_ioctl+0x81/0x9d [<ffffffff816a6115>] ? inet_ioctl+0x81/0x9d [<ffffffff81621cf8>] sock_do_ioctl+0x20/0x3d [<ffffffff816223c4>] sock_ioctl+0x222/0x22e [<ffffffff8121cf95>] do_vfs_ioctl+0x453/0x4d7 [<ffffffff81625603>] ? __sys_recvmsg+0x4c/0x5b [<ffffffff81225af1>] ? __fget_light+0x48/0x6c [<ffffffff8121d06b>] SyS_ioctl+0x52/0x74 [<ffffffff816fa736>] entry_SYSCALL_64_fastpath+0x16/0x7a Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: enable ipq4019 device probe in ahb moduleRaja Mani2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All the necessary patches to make wifi running (over AHB) on ipq4019 SoC are ready now. It's good to enable ipq4019 wifi device probing in ahb module and remove work in progress debug print. Device tree change is there in the public review by below commit message "qcom: ipq4019: add wifi nodes to ipq4019 SoC device tree" Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com> Signed-off-by: Raja Mani <rmani@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: add pdev param support to enable/disable btcoexRajkumar Manoharan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 10.4 firmware has support to enable or disable btcoex functionality without reloading firmware via wmi pdev param. Add provision to send pdev param command via existing btcoex knob. Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: add new ATH10K_FW_FEATURE_BTCOEX_PARAMRajkumar Manoharan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This feature flag will be used for firmware to support BT-Coex feature without reloading firmware via WMI pdev param. To support Bluetooth coexistence pdev param, WMI_COEX_GPIO_SUPPORT of extended resource config should be enabled always. This firmware IE is used to configure WMI_COEX_GPIO_SUPPORT. Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: update module descriptionRajkumar Manoharan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update module description to advertise all supported QCA 802.11ac devices. Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: remove unused phy_mode_to_bandRajkumar Manoharan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove unused inline function phy_mode_to_band. Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: fix operating irq mode for ahb deviceRajkumar Manoharan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Earlier when operating irq mode is legacy, interrupts are disabled and re-enabled based on num_msi_intrs. commit cfe9011a05a8 ("ath10k: remove MSI range support") replaced num_msi_intrs by oper_irq_mode. Since oper_irq_mode is not initialized for ahb devices (i.e qca4019), device boot up is failed during probe. Fixes: cfe9011a05a8 ("ath10k: remove MSI range support") Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: fix error while writing 'simulate_fw_crash' debugfsMohammed Shafi Shajakhan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix invalid argument error while writing 'simulate_fw_crash', though the funcionality is working fine we get an error 'invalid argument' because 'count' value is not returned properly (no reason to reduce the count value for removing the newline) Fixes the below write error: /sys/kernel/debug/ieee80211/phy0/ath10k# echo hw-restart > simulate_fw_crash -bash: echo: write error: Invalid argument Also move the 'conf_mutex' as it is really not required for fetching the userspace buffer. Reported-by: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: fix diag_read to collect data for larger memoryAshok Raj Nagarajan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | diag_read uses dma_alloc_coherent to allocate memory requested by the caller. If this memory requested is larger, more than DIAG_TRANSFER_LIMIT (2K), then it is likely that we may not get the requested memory and we would fail. To solve this, request dma_alloc_coherent for only DIAG_TRANSFER_LIMIT, and reuse this buffer multiple times as needed to copy the data requested in smaller chunks of size not more than DIAG_TRANSFER_LIMIT. Previously we were reading into the caller's only after getting the complete requested data. Fixes: 68c03249f388 ('ath10k: convert pci_alloc_consistent() to dma_alloc_coherent()') Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: fix legacy rate packet debug messagesMohammed Shafi Shajakhan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Legacy rate packets may not necessarily be having a rx status flag of '0' always, for example management frame have flags like RX_FLAG_ONLY_MONITOR / RX_FLAG_MACTIME_END also set Just check 'VHT' and 'HT' flags are not set , and simply clasify it as legacy rate packets Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: reduce warning messages during rx without proper channel contextMohammed Shafi Shajakhan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WARN_ON_ONCE when we receive packets for self peer when mac80211 had not assigned a proper channel context. This scenario happens in QCA4019 when we start the AP via hostapd in background and start it once again in the background without killing the previous instance! This happens intermittently when we start / stop hostapd in a while loop (incase the hostapd is not properly killed). This results in mac80211 chancontext to be unassigned, while the self peer continuous receive packets in target operating channel. This results in lot of call traces in the rx path. Make this as a WARN_ON_ONCE to avoid flooding the console which result in rebooting low memory systems, while still reporting the warning once that we are receiving packets in target operating channel and to indicate that something is happening which is not the expected result. WARNING: CPU: 0 PID: 0 at ath/ath10k/htt_rx.c:803 [<c0318838>] (warn_slowpath_null) from [<bf4a0104>] (ath10k_htt_rx_h_channel+0xe0/0x1b8 [ath10k_core]) [<bf4a0104>] (ath10k_htt_rx_h_channel [ath10k_core]) from [<bf4a025c>] (ath10k_htt_rx_h_ppdu+0x80/0x288 [ath10k_core]) [<bf4a025c>] (ath10k_htt_rx_h_ppdu [ath10k_core]) from [<bf4a1a9c>] (ath10k_htt_txrx_compl_task+0x724/0x9d4 [ath10k_core]) [<bf4a1a9c>] (ath10k_htt_txrx_compl_task [ath10k_core]) Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: improve tx schedulingMichal Kazior2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recent changes revolving around implementing wake_tx_queue support introduced a significant performance regressions on some (slower, uni-proc) systems. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: enable support for QCA9984Vasanthakumar Thiagarajan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QCA9984 shares the same configuration with QCA99X0. Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: define rx_ppdu_end for QCA9984Vasanthakumar Thiagarajan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QCA9984 Rx descriptor has two 32-bit words of location information when compared to one 32-bit word in QCA99X0. To handle this difference in rx descriptor ppdu_end, define a new ppdu_end for QCA9984 descriptor which has the new structure to represent rx_location_info. Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: clean up growing hw checks during safe and full resetVasanthakumar Thiagarajan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Store pci chip secific reset funtions in struct ath10k_pci as callbacks during early ath10k_pci_probe() and use the callback to perform chip specific resets. This patch essentially adds two callback in ath10k_pci, one for doing soft reset and the other for hard reset. By using callbacks we can get rid of those hw revision checks in ath10k_pci_safe_chip_reset() and ath10k_pci_chip_reset(). As such this patch does not fix any issue. Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: move rx_location_info out of struct rx_pkt_endVasanthakumar Thiagarajan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Define rx_location_info in struct rx_ppdu_end_qca99x0 after rx_pkt_end. This is to prepare rx_ppdu_end for QCA9984 chip. Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: Fix survey reporting with QCA4019Vasanthakumar Thiagarajan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In QCA4019, cycle counter wraparound in same fashion as QCA988X. When the cycle counter wraparound it resets to 0x7fffffff. Set has_shifted_cc_wraparound to true for QCA4019 to enable the code path to handle cycle counter wraparound for consistent survey report. Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: suppress warnings when getting wmi peer_rate_code_list eventVasanthakumar Thiagarajan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 10.4, fw sends WMI PEER_RATECODE_LIST_EVENTID after successful peer_assoc cmd. As of now this event is not of much use and not implemented. Change the debug level and messsage as appropriate to suppress "Unknown eventid: 36898". Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: release pre_cal_file while unloading driverRajkumar Manoharan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Failing to release pre_cal_file caldata on deinit causes memory leak. Fixes: b131129d9657 ("ath10k: fix calibration init sequence of qca99x0") Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: update bss channel survey informationRajkumar Manoharan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During hw scan, firmware sends two channel information events (pre- complete, complete) to host for each channel change. The snap shot of cycle counters (rx_clear and total) between these two events are given for survey dump. In order to get latest survey statistics of all channels, a scan request has to be issued. In general, an AP DUT is brought up, it won't leave BSS channel except few cases like overlapping bss or radar detection. So survey statistics of bss channel is always referring to older data that are collected before starting AP (either ACS/OBSS scan). To collect latest survey information from target, firmware provides WMI interface to read cycle counters from hardware. For each survey dump request, BSS channel cycle counters are read and cleared in hardware. This makes sure that behavior is in align with ath9k survey report. So survey dump always gives snap shot of cycle counters b/w two survey requests. Signed-off-by: Yanbo Li <yanbol@qca.qualcomm.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: handle pdev_chan_info wmi eventRajkumar Manoharan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add handler to process bss channel information wmi event that will be received upon sending pdev_chan_info_request wmi command. Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: implement wmi_pdev_bss_chan_info_requestRajkumar Manoharan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add WMI ops to send pdev_bss_chan_info_request command to target. This command will be used to retrieve updated cycle counters and noise floor value of current operating channel (bss channel). Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: add pdev bss channel info wmi definitionsRajkumar Manoharan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add WMI definitions for pdev bss channel information request and event. Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: move spectral related structures under ath10k debugfsMohammed Shafi Shajakhan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Spectral related structures are accessed / modified only if ath10k debugfs is enabled, so it makes more sense to move them under ATH10K_DEBUGFS Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: remove VHT capabilities from 2.4GHzJohannes Berg2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the spec, VHT doesn't exist in 2.4GHz. There are vendor extensions to allow a subset of VHT to work (notably 256-QAM), but since mac80211 doesn't support those advertising VHT capability on 2.4GHz leads to the behaviour of reporting VHT capabilities but not being able to use any of them due to mac80211's code requiring 80 MHz support. Remove the VHT capabilities from 2.4GHz for now. If mac80211 gets extended to use the (likely Broadcom) vendor IEs for it and handles the lack of 80 MHz support, it can be added back. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: fix a typo in ath10k_start()Mohammed Shafi Shajakhan2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fix a typo (spelling mistake) in 'ath10k_start' Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: add max_tx_power for QCA6174 WLAN.RM.2.0 firmwareAlan Liu2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QCA6174 WLAN.RM.2.0 firmware uses max_tx_power instead of using max_reg_power to set transmission power. The tx power was about -50dbm, after applying this change, it become -32dbm. Signed-off-by: Alan Liu <alanliu@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: remove enum ath10k_swap_code_seg_bin_typeKalle Valo2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's not needed for anything so just get rid of it. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: switch testmode to use ath10k_core_fetch_firmware_api_n()Kalle Valo2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that all firmware-N.bin related are within struct ath10k_fw_file we can switch to use ath10k_core_fetch_firmware_api_n() and delete almost identical ath10k_tm_fetch_utf_firmware_api_2(). Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: move htt_op_version to struct ath10k_fw_fileKalle Valo2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Preparation for testmode.c to use ath10k_core_fetch_board_data_api_n(). Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: move wmi_op_version to struct ath10k_fw_fileKalle Valo2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Preparation for testmode.c to use ath10k_core_fetch_board_data_api_n(). Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: move fw_features to struct ath10k_fw_fileKalle Valo2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Preparation for testmode.c to use ath10k_core_fetch_board_data_api_n(). Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: move fw_version inside struct ath10k_fw_fileKalle Valo2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Preparation for testmode.c to use ath10k_core_fetch_board_data_api_n(). Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: refactor firmware images to struct ath10k_fw_componentsKalle Valo2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To make it easier to share ath10k_core_fetch_board_data_api_n() with testmode.c refactor all firmware components to struct ath10k_fw_components. This structure will hold firmware related files, for example firmware-N.bin and board-N.bin. For firmware-N.bin create a new struct ath10k_fw_file which contains the actual firmware image as well as the parsed data from the image. Modify ath10k_core_start() to take struct ath10k_fw_components() as an argument which makes it possible in following patches to drop some ugly hacks from testmode.c. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | | ath10k: remove deprecated firmware API 1 supportKalle Valo2017-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This has ben deprecated years ago, I haven't heard anyone using it since and most likely it won't even work anymore. So just remove all of it. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-07-29 18:34:23 +0000