- 06 May, 2020 1 commit
-
-
John Crispin authored
This patch adds support for ethernet rxtx mode to the driver. The feature is enabled via a new module parameter. If enabled to driver will enable the feature on a per vif basis if all other requirements were met. Signed-off-by:
Shashidhar Lakkavalli <slakkavalli@datto.com> Signed-off-by:
John Crispin <john@phrozen.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200430152814.18481-1-john@phrozen.org
-
- 05 May, 2020 7 commits
-
-
Sowmiya Sree Elavalagan authored
htt stats are not working after htt peer stats display and also after htt peer stats reset. Trying to dump htt stats shows "Resource temporarily unavailable". This is because of "ar->debug.htt_stats.stats_req" member is being consecutively used for all htt stats without being reset during the previous usage. Hence assigning NULL to this member after freeing the allocated memory fixes the issue. console logs below: # echo 9 >/sys/kernel/debug/ath11k/ipq8074/mac1/htt_stats_type # cat /sys/kernel/debug/ath11k/ipq8074/mac1/htt_stats_type 9 # cat /sys/kernel/debug/ath11k/ipq8074/mac1/htt_stats cat: can't open '/sys/kernel/debug/ath11k/ipq8074/mac1/htt_stats' : Resource temporarily unavailable Signed-off-by:
Sowmiya Sree Elavalagan <ssreeela@codeaurora.org> Signed-off-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/net/wireless/ath/ath11k/dp_rx.c:2964:1-39: WARNING: Assignment of 0/1 to bool variable drivers/net/wireless/ath/ath11k/dp_rx.c:2965:1-38: WARNING: Assignment of 0/1 to bool variable Signed-off-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
-
Rakesh Pillai authored
Add the support to attach and map iommu domain for targets which do not have the support of TrustZone. Tested HW: WCN3990 Tested FW: WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1 Signed-off-by:
Rakesh Pillai <pillair@codeaurora.org> Signed-off-by:
-
Rakesh Pillai authored
Move the msa resources setup out of qmi init and setup the msa resources as a part of probe before the qmi init is done. Tested HW: WCN3990 Tested FW: WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1 Signed-off-by:
-
Rakesh Pillai authored
Add a wifi-firmware subnode for the wifi node. This wifi-firmware subnode is needed for the targets which do not support TrustZone. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Wen Gong authored
The struct cfg80211_wowlan of NET_DETECT WoWLAN feature share the same struct cfg80211_sched_scan_request together with scheduled scan request feature, and max_sched_scan_reqs of wiphy is only used for sched scan, and ath10k does not support scheduled scan request feature, so ath10k does not set flag NL80211_FEATURE_SCHED_SCAN_RANDOM_MAC_ADDR, but ath10k set max_sched_scan_reqs of wiphy to a non zero value 1, then function nl80211_add_commands_unsplit of cfg80211 will set it support command NL80211_CMD_START_SCHED_SCAN because max_sched_scan_reqs is a non zero value, but actually ath10k not support it, then it leads a mismatch result for sched scan of cfg80211, then application shill found the mismatch and stop running case of MAC random address scan and then the case fail. After remove max_sched_scan_reqs value, it keeps match for sched scan and case of MAC random address scan pass. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029. Tested with QCA6174 PCIe with firmware WLAN.RM.4.4.1-00110-QCARMSWP-1. Fixes: ce834e28 ("ath10k: support NET_DETECT WoWLAN feature") Signed-off-by:
Wen Gong <wgong@codeaurora.org> Signed-off-by:
-
Maharaja Kennadyrajan authored
As the exisiting CE configurations are defined in global, there are the chances of QCA99X0 family chipsets CE configurations are getting changed by the ath10k_pci_override_ce_config() function. The override will be hit and CE5 configurations will be changed, when the user bring up the QCA99X0 chipsets along with QCA6174 or QCA9377 chipset. (Bring up QCA99X0 family chipsets after QCA6174 or QCA9377). Hence, fixing this issue by moving the global CE configuration to radio specific CE configuration. Tested hardware: QCA9888 & QCA6174 Tested firmware: 10.4-3.10-00047 & WLAN.RM.4.4.1.c3-00058 Signed-off-by:
Maharaja Kennadyrajan <mkenna@codeaurora.org> Signed-off-by:
-
- 04 May, 2020 4 commits
-
-
Sathishkumar Muruganandam authored
Added DBG_MAC prints to track vdev create, delete, start and stop events. Signed-off-by:
Sathishkumar Muruganandam <murugana@codeaurora.org> Signed-off-by:
-
Sathishkumar Muruganandam authored
In Multi-AP VAP scenario with frequent interface up-down, there is a chance that ath11k_mgmt_over_wmi_tx_work() will dequeue a skb corresponding to currently deleted/stopped vdev. FW will assert on receiving mgmt_tx_wmi cmd for already deleted vdev. Hence adding validation checks for arvif present on the corresponding ar before sending mgmt_tx_wmi cmd. Signed-off-by:
-
Wei Yongjun authored
Fix to return negative error code -ENOMEM from the error handling case instead of 0, as done elsewhere in this function. Fixes: d0998eb8 ("ath11k: optimise ath11k_dp_tx_completion_handler") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Wei Yongjun authored
'cmd' is malloced in ath10k_bmi_lz_data_large() and should be freed before leaving from the error handling cases, otherwise it will cause memory leak. Fixes: d58f466a ("ath10k: add large size for BMI download data for SDIO") Signed-off-by:
-
- 28 Apr, 2020 12 commits
-
-
Wei Yongjun authored
A spin lock is taken here so we should use GFP_ATOMIC. Fixes: d5c65159 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by:
-
Wen Gong authored
For legacy mode, tx bitrate not show correct sometimes, for example: iw wlan0 link Connected to 8c:21:0a:b3:5a:64 (on wlan0) SSID: tplinkgw freq: 2462 RX: 19672 bytes (184 packets) TX: 9851 bytes (87 packets) signal: -51 dBm rx bitrate: 54.0 MBit/s tx bitrate: 2.8 MBit/s This patch use the tx bitrate info from WMI_TLV_PEER_STATS_INFO_EVENTID report from firmware, and tx bitrate show correct. iw wlan0 link Connected to 8c:21:0a:b3:5a:64 (on wlan0) SSID: tplinkgw freq: 2462 RX: 13973 bytes (120 packets) TX: 6737 bytes (57 packets) signal: -52 dBm rx bitrate: 54.0 MBit/s tx bitrate: 54.0 MBit/s This patch only effect SDIO chip, ath10k_mac_sta_get_peer_stats_info has check for bitrate_statistics of hw_params, it is enabled only for "qca6174 hw3.2 sdio". Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042. Signed-off-by: -
Wen Gong authored
The rate code and rate kbps report by WMI_TLV_PEER_STATS_INFO_EVENTID from firmware contains all the bitrate info which include OFDM, CCK, HT/VHT, and mac80211 need the struct rate_info which include below parameters: flags: bitflag of flags from &enum rate_info_flags mcs: mcs index if struct describes an HT/VHT/HE rate legacy: bitrate in 100kbit/s for 802.11abg nss: number of streams (VHT & HE only) bw: bandwidth (from &enum rate_info_bw) For OFDM/CCK, its rate kbps indicate the bitrate, for HT/VHT, mac80211 need the above 5 parameters to cacluate the bitrate and show by iw. After parse the bitrate info, iw show the correct rx bitrate: localhost ~ # iw wlan0 link rx bitrate: 234.0 MBit/s VHT-MCS 3 80MHz VHT-NSS 2 rx bitrate: 40.5 MBit/s MCS 2 40MHz rx bitrate: 72.2 MBit/s MCS 7 short GI rx bitrate: 54.0 MBit/s rx bitrate: 48.0 MBit/s Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042. Signed-off-by:
-
Wen Gong authored
For SDIO chip, its rx indication is struct htt_rx_indication_hl, which does not include the bitrate info as well as PCIe, for PCIe, it use function ath10k_htt_rx_h_rates to parse the bitrate info in struct rx_ppdu_start and then report it to mac80211 via ieee80211_rx_status. SDIO does not have the same info as PCIe, then iw command can not get the rx bitrate by "iw wlan0 station dump". for example, it always show 6.0 MBit/s localhost ~ # iw wlan0 link Connected to 3c:28:6d:96:fd:69 (on wlan0) SSID: kukui_test freq: 5180 RX: 111800 bytes (595 packets) TX: 35419 bytes (202 packets) signal: -41 dBm rx bitrate: 6.0 MBit/s This patch is to send WMI_TLV_REQUEST_PEER_STATS_INFO_CMDID to firmware for ath10k_sta_statistics and save the rx bitrate for WMI event WMI_TLV_PEER_STATS_INFO_EVENTID. This patch only effect SDIO chip, ath10k_mac_sta_get_peer_stats_info has check for bitrate_statistics of hw_params, this patch only enable it for "qca6174 hw3.2 sdio". Tested with QCA6174 SDIO firmware WLAN.RMH.4.4.1-00042. Signed-off-by:
-
Wen Gong authored
For wmi tlv type, firmware disable peer stats info by default, after enable it, firmware will report WMI_TLV_PEER_STATS_INFO_EVENTID if ath10k send WMI_TLV_REQUEST_PEER_STATS_INFO_CMDID to firmware. Enable it will only set a flag in firmware, firmware will not report it without receive request WMI command. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042. Signed-off-by:
-
Jason Yan authored
The '>' expression itself is bool, no need to convert it to bool again. This fixes the following coccicheck warning: drivers/net/wireless/ath/ath5k/ani.c:504:56-61: WARNING: conversion to bool not needed here Signed-off-by:
-
Sergey Ryazanov authored
ADC & I/Q calibrations could take infinite time to comple, since they depend on received frames. In particular the I/Q mismatch calibration requires receiving of OFDM frames for completion. But in the 2.4GHz band, a station could receive only CCK frames for a very long time. And while we wait for the completion of one of the mentioned calibrations, the NF calibration is blocked. Moreover, in some environments, I/Q calibration is unable to complete until a correct noise calibration will be performed due to AGC behaviour. In order to avoid delaying NF calibration on forever, limit the maximum duration of ADCs & I/Q calibrations. If the calibration is not completed within the maximum time, it will be interrupted and a next calibration will be performed. The code that selects the next calibration has been reworked to the loop so incompleted calibration will be respinned later. Ð maximum calibration time of 30 seconds was selected to give the calibration enough time to complete and to not interfere with the long (NF) calibration. Run tested with AR9220. Signed-off-by:
Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by:
-
Sergey Ryazanov authored
Previously after the calibration validity period is over, calibrations are invalidated in a one at time manner. So, for AR9002 family, which has three calibrations, the full recalibration interval becomes 3 x ATH_RESTART_CALINTERVAL. And each next calibration will be separated by the ATH_RESTART_CALINTERVAL time from a previous one. It seems like it is better to do whole recalibration at once. Also, this change makes the driver behaviour a little simpler. So, invalidate all calibrations at once at the end of the calibration validity interval. This change affects only AR9002 chips family, since the AR9003 utilize only a single calibration. Signed-off-by:
-
Sergey Ryazanov authored
NF calibration and other elements of long calibration are usually faster than ADCs & I/Q calibrations due to independence of receiption of the OFDM signal. Moreover sometime I/Q calibration can not be completed at all without preceding NF calibration. This is due to AGC, which has a habit to block a weak signal without regular NF calibration. Thus, we do not need to deferr the long calibration forever. So, if the long calibration is requested, then deferr the ADCs & I/Q calibration(s) and run the longcal (the NF calibration in particular) to obtain fresh noise data. Run tested with AR9220. Signed-off-by:
-
Sergey Ryazanov authored
Each of AGC & I/Q calibrations can take a long time. Long calibration and NF calibration in particular are forbiden for parallel run with ADC & I/Q calibrations. So, the chip could not be ready to perform the long calibration at the time of request. And a request to perform the long calibration may be lost. In order to fix this, preserve the long calibration request as a calibration state flag and restore the long calibration request each time the calibration function is called again (i.e. on each subsequent ivocation of the short calibration). This feature will be twice useful after the next change, which will make it possible to start the long calibration before all ADCs & I/Q calibrations are completed. Run tested with AR9220. Signed-off-by:
-
Sergey Ryazanov authored
The NFCAL_PENDING flag is set by the ath9k_hw_start_nfcal() routine, so there is no reason to set it manually after calling it during the AR9002 calibrations initialization. Signed-off-by:
-
Sergey Ryazanov authored
ADC calibration is only required for a 80 MHz sampling rate (i.e. for 40 MHz channels), when the chip utilizes the pair of ADCs in interleved mode. Calibration on a 20 MHz channel will never be completed. Previous channel check is trying to exclude all channels where the calibration will get stuck. It effectively blocks the calibration run for HT20 channels, but fails to exclude 20 MHz channels without HT (e.g. legacy mode channels). Fix this issue by reworking the channel check to explicitly allow ADCs gain & DC offset calibrations for HT40 channels only. Also update the complicated comment to make it clear that these calibrations are for multi-ADC mode only. Stuck ADCs calibration blocks the NF calibration, what could make it impossible to work in a noisy evironment: too big Rx attentuation, invalid RSSI value, etc. So this change is actually more of a NF calibration fix rather then the ADC calibration fix. Run tested with AR9220. Signed-off-by:
-
- 27 Apr, 2020 3 commits
-
-
Wen Gong authored
When tx complete is disabled, all tx status will be set with status HTT_TX_COMPL_STATE_ACK and indicate to mac80211 by ieee80211_tx_status, then it does not have the statistics for retries and failed packets. count of tx retries and tx failed of command "iw wlan0 station dump" are both 0. If tx complete is not disabled, then firmware report the tx status and ath10k indicate the status to mac80211, then mac80211 save the statistics and command "iw wlan0 station dump" show them. for example: localhost ~ # iw dev wlan0 station dump Station 3c:28:6d:96:fd:69 (on wlan0) inactive time: 5 ms rx bytes: 1325012 rx packets: 6477 tx bytes: 85264 tx packets: 518 tx retries: 0 tx failed: 0 This patch only effect chips with tx complete disabled, e.g. SDIO. with this patch, output of command "iw dev wlan0 station dump": Station c4:04:15:5d:97:22 (on wlan0) inactive time: 608 ms rx bytes: 180366 rx packets: 991 tx bytes: 98765577 tx packets: 64624 tx retries: 14682 tx failed: 47086 Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042. Signed-off-by: -
Wen Gong authored
When run command "iw dev wlan0 station dump", the rx duration is 0. When firmware indicate WMI_UPDATE_STATS_EVENTID, extended flag of statsis not set by default, so firmware do not report rx duration. one sample: localhost # iw wlan0 station dump Station c4:04:15:5d:97:22 (on wlan0) inactive time: 48 ms rx bytes: 21670 rx packets: 147 tx bytes: 11529 tx packets: 100 tx retries: 88 tx failed: 36 beacon loss: 1 beacon rx: 31 rx drop misc: 47 signal: -72 [-74, -75] dBm signal avg: -71 [-74, -75] dBm beacon signal avg: -71 dBm tx bitrate: 54.0 MBit/s MCS 3 40MHz rx bitrate: 1.0 MBit/s rx duration: 0 us This patch enable firmware's extened flag of stats by setting flag WMI_TLV_STAT_PEER_EXTD of ar->fw_stats_req_mask which is set in ath10k_core_init_firmware_features via WMI_REQUEST_STATS_CMDID. After apply this patch, rx duration show value with the command: Station c4:04:15:5d:97:22 (on wlan0) inactive time: 883 ms rx bytes: 44289 rx packets: 265 tx bytes: 10838 tx packets: 93 tx retries: 899 tx failed: 103 beacon loss: 0 beacon rx: 78 rx drop misc: 46 signal: -71 [-74, -76] dBm signal avg: -70 [-74, -76] dBm beacon signal avg: -70 dBm tx bitrate: 54.0 MBit/s MCS 3 40MHz rx bitrate: 1.0 MBit/s rx duration: 358004 us This patch do not have side effect for all chips, because function ath10k_debug_fw_stats_request is already exported to debugfs "fw_stats" and WMI_REQUEST_STATS_CMDID is safely sent after condition checked by ath10k_peer_stats_enabled in ath10k_sta_statistics. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042. Signed-off-by: -
Karthikeyan Periyasamy authored
we are sending the reo flush command for the deleted peer tid after the ageout period reaches 1 second. This handling causes reo ring get full when more than 128 clients are disconnected continuously. so added the count for flush list and reo flush command is triggered after the list count reaches the threshold value, it is configured as 64 (half of the reo ring). This will avoid the situation where reo ring get full. Signed-off-by:
Karthikeyan Periyasamy <periyasa@codeaurora.org> Signed-off-by:
-
- 23 Apr, 2020 2 commits
-
-
Wen Gong authored
sdio chip use DMA buffer to receive TX packet from ath10k, and it has limitation of each buffer, if the packet size exceed the credit size, it will trigger error in firmware. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00017-QCARMSWP-1. Signed-off-by:
-
Maharaja Kennadyrajan authored
The driver is allowing the invalid tx/rx chainmask configuration (other than 1,3,7,15) set by the user. It causes the firmware crash due to the invalid chainmask values. Hence, reject the invalid chainmask values in the driver by not sending the pdev set command to the firmware. Tested hardware: QCA9888 Tested firmware: 10.4-3.10-00047 Signed-off-by:
-
- 22 Apr, 2020 5 commits
-
-
Wen Gong authored
When station connected to AP, and run TX traffic such as TCP/UDP, and system enter suspend state, then mac80211 call ath10k_flush with set drop flag, recently it only send wmi peer flush to firmware and firmware will flush all pending TX packets, for PCIe, firmware will indicate the TX packets status to ath10k, and then ath10k indicate to mac80211 TX complete with the status, then all the packets has been flushed at this moment. For SDIO chip, it is different, its TX complete indication is disabled by default, and it has a tx queue in ath10k, and its tx credit control is enabled, total tx credit is 96, when its credit is not sufficient, then the packets will buffered in the tx queue of ath10k, max packets is TARGET_TLV_NUM_MSDU_DESC_HL which is 1024, for SDIO, when mac80211 call ath10k_flush with set drop flag, maybe it have pending packets in tx queue of ath10k, and if it does not have sufficient tx credit, the packets will stay in queue untill tx credit report from firmware, if it is a noisy environment, tx speed is low and the tx credit report from firmware will delay more time, then the num_pending_tx will remain > 0 untill all packets send to firmware. After the 1st ath10k_flush, mac80211 will call the 2nd ath10k_flush without set drop flag immediately, then it will call to ath10k_mac_wait_tx_complete, and it wait untill num_pending_tx become to 0, in noisy environment, it is esay to wait about near 5 seconds, then it cause the suspend take long time. 1st and 2nd callstack of ath10k_flush [ 303.740427] ath10k_sdio mmc1:0001:1: ath10k_flush drop:1, pending:0-0 [ 303.740495] ------------[ cut here ]------------ [ 303.740739] WARNING: CPU: 1 PID: 3921 at /mnt/host/source/src/third_party/kernel/v4.19/drivers/net/wireless/ath/ath10k/mac.c:7025 ath10k_flush+0x54/0x104 [ath10k_core] [ 303.740757] Modules linked in: bridge stp llc ath10k_sdio ath10k_core rfcomm uinput cros_ec_rpmsg mtk_seninf mtk_cam_isp mtk_vcodec_enc mtk_fd mtk_vcodec_dec mtk_vcodec_common mtk_dip mtk_mdp3 videobuf2_dma_contig videobuf2_memops v4l2_mem2mem videobuf2_v4l2 videobuf2_common hid_google_hammer hci_uart btqca bluetooth dw9768 ov8856 ecdh_generic ov02a10 v4l2_fwnode mtk_scp mtk_rpmsg rpmsg_core mtk_scp_ipi ipt_MASQUERADE fuse iio_trig_sysfs cros_ec_sensors_ring cros_ec_sensors_sync cros_ec_light_prox cros_ec_sensors industrialio_triggered_buffer [ 303.740914] kfifo_buf cros_ec_activity cros_ec_sensors_core lzo_rle lzo_compress ath mac80211 zram cfg80211 joydev [last unloaded: ath10k_core] [ 303.741009] CPU: 1 PID: 3921 Comm: kworker/u16:10 Tainted: G W 4.19.95 #2 [ 303.741027] Hardware name: MediaTek krane sku176 board (DT) [ 303.741061] Workqueue: events_unbound async_run_entry_fn [ 303.741086] pstate: 60000005 (nZCv daif -PAN -UAO) [ 303.741166] pc : ath10k_flush+0x54/0x104 [ath10k_core] [ 303.741244] lr : ath10k_flush+0x54/0x104 [ath10k_core] [ 303.741260] sp : ffffffdf080e77a0 [ 303.741276] x29: ffffffdf080e77a0 x28: ffffffdef3730040 [ 303.741300] x27: ffffff907c2240a0 x26: ffffffde6ff39afc [ 303.741321] x25: ffffffdef3730040 x24: ffffff907bf61018 [ 303.741343] x23: ffffff907c2240a0 x22: ffffffde6ff39a50 [ 303.741364] x21: 0000000000000001 x20: ffffffde6ff39a50 [ 303.741385] x19: ffffffde6bac2420 x18: 0000000000017200 [ 303.741407] x17: ffffff907c24a000 x16: 0000000000000037 [ 303.741428] x15: ffffff907b49a568 x14: ffffff907cf332c1 [ 303.741476] x13: 00000000000922e4 x12: 0000000000000000 [ 303.741497] x11: 0000000000000001 x10: 0000000000000007 [ 303.741518] x9 : f2256b8c1de4bc00 x8 : f2256b8c1de4bc00 [ 303.741539] x7 : ffffff907ab5e764 x6 : 0000000000000000 [ 303.741560] x5 : 0000000000000080 x4 : 0000000000000001 [ 303.741582] x3 : ffffffdf080e74a8 x2 : ffffff907aa91244 [ 303.741603] x1 : ffffffdf080e74a8 x0 : 0000000000000024 [ 303.741624] Call trace: [ 303.741701] ath10k_flush+0x54/0x104 [ath10k_core] [ 303.741941] __ieee80211_flush_queues+0x1dc/0x358 [mac80211] [ 303.742098] ieee80211_flush_queues+0x34/0x44 [mac80211] [ 303.742253] ieee80211_set_disassoc+0xc0/0x5ec [mac80211] [ 303.742399] ieee80211_mgd_deauth+0x720/0x7d4 [mac80211] [ 303.742535] ieee80211_deauth+0x24/0x30 [mac80211] [ 303.742720] cfg80211_mlme_deauth+0x250/0x3bc [cfg80211] [ 303.742849] cfg80211_mlme_down+0x90/0xd0 [cfg80211] [ 303.742971] cfg80211_disconnect+0x340/0x3a0 [cfg80211] [ 303.743087] __cfg80211_leave+0xe4/0x17c [cfg80211] [ 303.743203] cfg80211_leave+0x38/0x50 [cfg80211] [ 303.743319] wiphy_suspend+0x84/0x5bc [cfg80211] [ 303.743335] dpm_run_callback+0x170/0x304 [ 303.743346] __device_suspend+0x2dc/0x3e8 [ 303.743356] async_suspend+0x2c/0xb0 [ 303.743370] async_run_entry_fn+0x48/0xf8 [ 303.743383] process_one_work+0x304/0x604 [ 303.743394] worker_thread+0x248/0x3f4 [ 303.743403] kthread+0x120/0x130 [ 303.743416] ret_from_fork+0x10/0x18 [ 303.743812] ath10k_sdio mmc1:0001:1: ath10k_flush drop:0, pending:0-0 [ 303.743858] ------------[ cut here ]------------ [ 303.744057] WARNING: CPU: 1 PID: 3921 at /mnt/host/source/src/third_party/kernel/v4.19/drivers/net/wireless/ath/ath10k/mac.c:7025 ath10k_flush+0x54/0x104 [ath10k_core] [ 303.744075] Modules linked in: bridge stp llc ath10k_sdio ath10k_core rfcomm uinput cros_ec_rpmsg mtk_seninf mtk_cam_isp mtk_vcodec_enc mtk_fd mtk_vcodec_dec mtk_vcodec_common mtk_dip mtk_mdp3 videobuf2_dma_contig videobuf2_memops v4l2_mem2mem videobuf2_v4l2 videobuf2_common hid_google_hammer hci_uart btqca bluetooth dw9768 ov8856 ecdh_generic ov02a10 v4l2_fwnode mtk_scp mtk_rpmsg rpmsg_core mtk_scp_ipi ipt_MASQUERADE fuse iio_trig_sysfs cros_ec_sensors_ring cros_ec_sensors_sync cros_ec_light_prox cros_ec_sensors industrialio_triggered_buffer kfifo_buf cros_ec_activity cros_ec_sensors_core lzo_rle lzo_compress ath mac80211 zram cfg80211 joydev [last unloaded: ath10k_core] [ 303.744256] CPU: 1 PID: 3921 Comm: kworker/u16:10 Tainted: G W 4.19.95 #2 [ 303.744273] Hardware name: MediaTek krane sku176 board (DT) [ 303.744301] Workqueue: events_unbound async_run_entry_fn [ 303.744325] pstate: 60000005 (nZCv daif -PAN -UAO) [ 303.744403] pc : ath10k_flush+0x54/0x104 [ath10k_core] [ 303.744480] lr : ath10k_flush+0x54/0x104 [ath10k_core] [ 303.744496] sp : ffffffdf080e77a0 [ 303.744512] x29: ffffffdf080e77a0 x28: ffffffdef3730040 [ 303.744534] x27: ffffff907c2240a0 x26: ffffffde6ff39afc [ 303.744556] x25: ffffffdef3730040 x24: ffffff907bf61018 [ 303.744577] x23: ffffff907c2240a0 x22: ffffffde6ff39a50 [ 303.744598] x21: 0000000000000000 x20: ffffffde6ff39a50 [ 303.744620] x19: ffffffde6bac2420 x18: 000000000001831c [ 303.744641] x17: ffffff907c24a000 x16: 0000000000000037 [ 303.744662] x15: ffffff907b49a568 x14: ffffff907cf332c1 [ 303.744683] x13: 00000000000922ea x12: 0000000000000000 [ 303.744704] x11: 0000000000000001 x10: 0000000000000007 [ 303.744747] x9 : f2256b8c1de4bc00 x8 : f2256b8c1de4bc00 [ 303.744768] x7 : ffffff907ab5e764 x6 : 0000000000000000 [ 303.744789] x5 : 0000000000000080 x4 : 0000000000000001 [ 303.744810] x3 : ffffffdf080e74a8 x2 : ffffff907aa91244 [ 303.744831] x1 : ffffffdf080e74a8 x0 : 0000000000000024 [ 303.744853] Call trace: [ 303.744929] ath10k_flush+0x54/0x104 [ath10k_core] [ 303.745098] __ieee80211_flush_queues+0x1dc/0x358 [mac80211] [ 303.745277] ieee80211_flush_queues+0x34/0x44 [mac80211] [ 303.745424] ieee80211_set_disassoc+0x108/0x5ec [mac80211] [ 303.745569] ieee80211_mgd_deauth+0x720/0x7d4 [mac80211] [ 303.745706] ieee80211_deauth+0x24/0x30 [mac80211] [ 303.745853] cfg80211_mlme_deauth+0x250/0x3bc [cfg80211] [ 303.745979] cfg80211_mlme_down+0x90/0xd0 [cfg80211] [ 303.746103] cfg80211_disconnect+0x340/0x3a0 [cfg80211] [ 303.746219] __cfg80211_leave+0xe4/0x17c [cfg80211] [ 303.746335] cfg80211_leave+0x38/0x50 [cfg80211] [ 303.746452] wiphy_suspend+0x84/0x5bc [cfg80211] [ 303.746467] dpm_run_callback+0x170/0x304 [ 303.746477] __device_suspend+0x2dc/0x3e8 [ 303.746487] async_suspend+0x2c/0xb0 [ 303.746498] async_run_entry_fn+0x48/0xf8 [ 303.746510] process_one_work+0x304/0x604 [ 303.746521] worker_thread+0x248/0x3f4 [ 303.746530] kthread+0x120/0x130 [ 303.746542] ret_from_fork+0x10/0x18 one sample's debugging log: it wait 3190 ms(5000 - 1810). 1st ath10k_flush, it has 120 packets in tx queue of ath10k: <...>-1513 [000] .... 25374.786005: ath10k_log_err: ath10k_sdio mmc1:0001:1 ath10k_flush drop:1, pending:120-0 <...>-1513 [000] ...1 25374.788375: ath10k_log_warn: ath10k_sdio mmc1:0001:1 ath10k_htt_tx_mgmt_inc_pending htt->num_pending_mgmt_tx:0 <...>-1500 [001] .... 25374.790143: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:121 2st ath10k_flush, it has 121 packets in tx queue of ath10k: <...>-1513 [000] .... 25374.790571: ath10k_log_err: ath10k_sdio mmc1:0001:1 ath10k_flush drop:0, pending:121-0 <...>-1513 [000] .... 25374.791990: ath10k_log_err: ath10k_sdio mmc1:0001:1 ath10k_mac_wait_tx_complete state:1 pending:121-0 <...>-1508 [001] .... 25374.792696: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:46 <...>-1508 [001] .... 25374.792700: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:46 <...>-1508 [001] .... 25374.792729: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:121 <...>-1508 [001] .... 25374.792937: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:88, count:32, len:49792 <...>-1508 [001] .... 25374.793031: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:75, count:14, len:21784 kworker/u16:0-25773 [003] .... 25374.793701: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx complete, eid:1, pending complete count:46 <...>-1881 [000] .... 25375.073178: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:24 <...>-1881 [000] .... 25375.073182: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:24 <...>-1881 [000] .... 25375.073429: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:75 <...>-1879 [001] .... 25375.074090: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx complete, eid:1, pending complete count:24 <...>-1881 [000] .... 25375.074123: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:51, count:24, len:37344 <...>-1879 [001] .... 25375.270126: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:26 <...>-1879 [001] .... 25375.270130: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:26 <...>-1488 [000] .... 25375.270174: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:51 <...>-1488 [000] .... 25375.270529: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:25, count:26, len:40456 <...>-1879 [001] .... 25375.270693: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx complete, eid:1, pending complete count:26 <...>-1488 [001] .... 25377.775885: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:12 <...>-1488 [001] .... 25377.775890: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:12 <...>-1488 [001] .... 25377.775933: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:25 <...>-1488 [001] .... 25377.776059: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:13, count:12, len:18672 <...>-1879 [001] .... 25377.776100: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx complete, eid:1, pending complete count:12 <...>-1488 [001] .... 25377.878079: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:15 <...>-1488 [001] .... 25377.878087: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:15 <...>-1879 [000] .... 25377.878323: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:13 <...>-1879 [000] .... 25377.878487: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:0, count:13, len:20228 <...>-1879 [000] .... 25377.878497: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx complete, eid:1, pending complete count:13 <...>-1488 [001] .... 25377.919927: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:11 <...>-1488 [001] .... 25377.919932: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:13 <...>-1488 [001] .... 25377.919976: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:0 <...>-1881 [000] .... 25377.982645: ath10k_log_warn: ath10k_sdio mmc1:0001:1 HTT_T2H_MSG_TYPE_MGMT_TX_COMPLETION status:0 <...>-1513 [001] .... 25377.982973: ath10k_log_err: ath10k_sdio mmc1:0001:1 ath10k_mac_wait_tx_complete time_left:1810, pending:0-0 Flush all pending TX packets for the 1st ath10k_flush reduced the wait time of the 2nd ath10k_flush and then suspend take short time. This Patch only effect SDIO chips. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042. Signed-off-by:
-
Wen Gong authored
The default credit size is 1792 bytes, but the IP mtu is 1500 bytes, then it has about 290 bytes's waste for each data packet on sdio transfer path for TX bundle, it will reduce the transmission utilization ratio for data packet. This patch enable the small credit size in firmware, firmware will use the new credit size 1556 bytes, it will increase the transmission utilization ratio for data packet on TX patch. It results in significant performance improvement on TX path. This patch only effect sdio chip, it will not effect PCI, SNOC etc. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00017-QCARMSWP-1. Signed-off-by:
-
Wen Gong authored
The transmission utilization ratio for sdio bus for small packet is slow, because the space and time cost for sdio bus is same for large length packet and small length packet. So the speed of data for large length packet is higher than small length. Test result of different length of data: data packet(byte) cost time(us) calculated rate(Mbps) 256 28 73 512 33 124 1024 35 234 1792 45 318 14336 168 682 28672 333 688 57344 660 695 This patch change the TX packet from single packet to a large length bundle packet, max size is 32, it results in significant performance improvement on TX path. Also there's a fourth thread "ath10k_tx_complete_wq" added to ath10k as it improves TCP RX throughput (values in Mbps): TCP-RX TCP-TX UDP-RX UDP-TX use workqueue_tx_complete 423 357 448 412 change it to ar->workqueue 410 360 449 414 change it to ar->workqueue_aux 405 339 446 401 This patch only effect sdio chip, it will not effect PCI, SNOC etc. It only enable bundle for sdio chip. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00017-QCARMSWP-1. Signed-off-by: -
Jason Yan authored
The '==' expression itself is bool, no need to convert it to bool again. This fixes the following coccicheck warning: drivers/net/wireless/ath/ath11k/debug.c:198:57-62: WARNING: conversion to bool not needed here drivers/net/wireless/ath/ath11k/debug.c:218:58-63: WARNING: conversion to bool not needed here Signed-off-by:
-
Jason Yan authored
The '==' expression itself is bool, no need to convert it to bool again. This fixes the following coccicheck warning: drivers/net/wireless/ath/ath11k/dp_rx.c:255:46-51: WARNING: conversion to bool not needed here Signed-off-by:
-
- 21 Apr, 2020 4 commits
-
-
Kalle Valo authored
That way we don't need to have an empty function in sdio.c. No functional changes, compile tested only. Signed-off-by:
-
Kalle Valo authored
The _hif_ prefix should be used only on functions part of ath10k_hif_ops, so remove it from functions which should not have it. No functional changes, compile tested only. Signed-off-by:
-
Wen Gong authored
This patch is to set register to allow the mbox enter sleep status if it does not have tx traffic and wakeup it if tx traffic arrive. After mbox enter sleep status, the soc will enter sleep status by firmware, this will save power. The power consume drops from about 90mW to about 10mW with this patch. This patch only effect sdio chip. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029. Signed-off-by:
-
Kalle Valo authored
Convert ath10k_hif_swap_mailbox() to a more generic op so that bus drivers can do more than just swap the mailbox, for example set power save settings like in the following sdio patch. No functional changes, compile tested only. Signed-off-by:
-
- 15 Apr, 2020 2 commits
-
-
Sriram R authored
IPQ8074 HW supports three TCL rings for tx. Currently these rings are mapped based on the Access categories, viz. VO, VI, BE, BK. In case, one of the traffic type dominates, then it could stress the same tcl rings. Rather, it would be optimal to make use of all the rings in a round robin fashion irrespective of the traffic type so that the load could be evenly distributed among all the rings. Also, in case the selected ring is busy or full, a retry mechanism is used to ensure other available ring is selected without dropping the packet. In SMP systems, this change avoids a single CPU from getting hogged when heavy traffic of same category is transmitted. The tx completion interrupts corresponding to the used tcl ring would be more which causes the assigned CPU to get hogged. Distribution of tx packets to different tcl rings helps balance this load. Signed-off-by:
Sriram R <srirrama@codeaurora.org> Signed-off-by:
-
Govindaraj Saminathan authored
should not overwrite the error code. No buffer available then return invalid. For other failures return the error code of actual failure. Signed-off-by:
Govindaraj Saminathan <gsamin@codeaurora.org> Signed-off-by:
-
