- 29 11月, 2019 2 次提交
-
-
由 Karthikeyan Periyasamy 提交于
Handled the error case with proper resource cleanup and moved the handling into a separate function from ath11k_mac_sta_state. Signed-off-by: NKarthikeyan Periyasamy <periyasa@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Ganesh Sesetti 提交于
The Previous configuartion of htt stats sounding info and pdev cca stats are invalid due to that getting time out error. Changing htt stats sounding info value from 0xFF to 0x00 and htt pdev cca stats from 0x10 to 0x00 Signed-off-by: NGanesh Sesetti <gseset@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 27 11月, 2019 9 次提交
-
-
由 Govind Singh 提交于
During driver load below warn logs are printed in the console if firmware doesn't support some optional HTC services, ex:pktlog. It is likely some older fw version may not support PKTLOG HTC service as legacy fw uses HTC DATA service for pktlog. Move this log to debug level to remove un-necessary warn message on console. htc.c:803: ath10k_warn(ar, "unsupported HTC service id: %d\n", htc.c:881: ath10k_warn(ar, "unsupported HTC service id: %d\n", Signed-off-by: NGovind Singh <govinds@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 John Crispin 提交于
Trigger the WMI call en/disabling OBSS PD when the bss config changes or we assoc to an AP that broadcasts the IE. Signed-off-by: NJohn Crispin <john@phrozen.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 John Crispin 提交于
Add target wait time wmi calls to the driver. En/disable the support from when the bss_config changes. We ignore the cmd completion events. Signed-off-by: NShashidhar Lakkavalli <slakkavalli@datto.com> Signed-off-by: NJohn Crispin <john@phrozen.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 John Crispin 提交于
Add basic HE support to the driver. The sband_iftype data is generated from the capabilities read from the FW. Signed-off-by: NShashidhar Lakkavalli <slakkavalli@datto.com> Signed-off-by: NJohn Crispin <john@phrozen.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Tamizh chelvam 提交于
Remove unexecuted code while handling amsdu packets. The same logic is done before calling ath11k_dp_rx_msdu_coalesce Signed-off-by: NTamizh chelvam <tamizhr@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Tamizh chelvam 提交于
TX rate stats for the retried packets for a station comes through tx completion events. Assigning hw reported bandwidth information directly to station's txrate bandwidth will cause below warning. Fix this warning by converting the hw reported bandwidth to mac80211 base bandwidth. [ 134.758190] PC is at cfg80211_calculate_bitrate+0x1bc/0x214 [cfg80211] [ 134.765730] LR is at cfg80211_calculate_bitrate+0x1bc/0x214 [cfg80211] [ 134.875014] [<ffffffbffca8d708>] cfg80211_calculate_bitrate+0x1bc/0x214 [cfg80211] [ 134.877192] [<ffffffbffcaa9704>] nl80211_put_sta_rate+0x54/0xf24 [cfg80211] [ 134.884829] [<ffffffbffcaa9d48>] nl80211_put_sta_rate+0x698/0xf24 [cfg80211] [ 134.891687] [<ffffffbffcaaa490>] nl80211_put_sta_rate+0xde0/0xf24 [cfg80211] [ 134.898975] [<ffffffc0004de748>] genl_lock_dumpit+0x30/0x4c [ 134.905998] [<ffffffc0004dc264>] netlink_dump+0xf4/0x248 [ 134.911291] [<ffffffc0004dc910>] __netlink_dump_start+0xe0/0x174 [ 134.916850] [<ffffffc0004df114>] genl_family_rcv_msg+0x130/0x2c0 Signed-off-by: NTamizh chelvam <tamizhr@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 John Crispin 提交于
We can regularly see the following message. - "ath11k c000000.wifi1: failed to find the peer with peer_id 4" This happens when the FW starts sending stats for the peer whilst the peer is not fully associated. Convert this info message to a debug one. Signed-off-by: NShashidhar Lakkavalli <slakkavalli@datto.com> Signed-off-by: NJohn Crispin <john@phrozen.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 John Crispin 提交于
Everytime a new peer gets associated, we see the following message in the log - ath11k c000000.wifi1: Unknown eventid: 0x6017 Ignore this event for now. We probably need to handle the event properly when we add OMI support. Signed-off-by: NShashidhar Lakkavalli <slakkavalli@datto.com> Signed-off-by: NJohn Crispin <john@phrozen.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 John Crispin 提交于
mac80211 expects the definition of what HE rate info is available inside a struct prepended to the skb. Signed-off-by: NShashidhar Lakkavalli <slakkavalli@datto.com> Signed-off-by: NJohn Crispin <john@phrozen.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 25 11月, 2019 17 次提交
-
-
由 Kalle Valo 提交于
Add an entry for ath11k to the MAINTAINERS file. Signed-off-by: NJohn Crispin <john@phrozen.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Kalle Valo 提交于
ath11k is a new driver for Qualcomm IEEE 802.11ax devices, first supporting only IPQ8074 SoC using the shared memory AHB bus. ath11k uses mac80211 and supports AP, Station and Mesh modes. Even though ath11k has some similar code as with ath10k (especially the WMI layer) it was concluded to be simpler to have a "clean start" for ath11k code base and not try to share the code with ath10k. This makes maintenance easier and avoids major changes in ath10k, which would have significantly increased the risk of regressions in existing setups. Even though the driver is very similar with ath10k but there are major differences as well. The datapath is completely different. ath11k supports multiple MACs, called "soc" in the firmware interface. And there's only one WMI interface to support. Currently ath11k supports only IEEE 802.11ac mode, but patches for 802.11ax are available and they will be submitted after ath11k is accepted to upstream. The firmware images are available from ath11k-firmware repository but they will be also submitted to linux-firmware: https://github.com/kvalo/ath11k-firmware This was tested with firmware version WLAN.HK.2.1.0.1-00629-QCAHKSWPL_SILICONZ-1. The driver has had multiple authors who are listed in alphabetical order below. Signed-off-by: NAnilkumar Kolli <akolli@codeaurora.org> Signed-off-by: NBhagavathi Perumal S <bperumal@codeaurora.org> Signed-off-by: NGanesh Sesetti <gseset@codeaurora.org> Signed-off-by: NGovindaraj Saminathan <gsamin@codeaurora.org> Signed-off-by: NJohn Crispin <john@phrozen.org> Signed-off-by: NJulia Lawall <julia.lawall@lip6.fr> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Signed-off-by: NKarthikeyan Periyasamy <periyasa@codeaurora.org> Signed-off-by: Nkbuild test robot <lkp@intel.com> Signed-off-by: NMaharaja Kennadyrajan <mkenna@codeaurora.org> Signed-off-by: NManikanta Pubbisetty <mpubbise@codeaurora.org> Signed-off-by: NMiles Hu <milehu@codeaurora.org> Signed-off-by: NMuna Sinada <msinada@codeaurora.org> Signed-off-by: NPradeep Kumar Chitrapu <pradeepc@codeaurora.org> Signed-off-by: NRajkumar Manoharan <rmanohar@codeaurora.org> Signed-off-by: NSathishkumar Muruganandam <murugana@codeaurora.org> Signed-off-by: NShashidhar Lakkavalli <slakkavalli@datto.com> Signed-off-by: NSriram R <srirrama@codeaurora.org> Signed-off-by: NSven Eckelmann <seckelmann@datto.com> Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@codeaurora.org> Signed-off-by: NVenkateswara Naralasetty <vnaralas@codeaurora.org>
-
由 Kalle Valo 提交于
ath11k is a driver for Qualcomm IEEE 802.11ax devices. Add a bindings document for the driver, first documenting IPQ8074 which is the only device ath11k currently supports. Signed-off-by: NAnilkumar Kolli <akolli@codeaurora.org> Reviewed-by: NRob Herring <robh@kernel.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Colin Ian King 提交于
There is a check on the retry counter invalid_buf_id_retry that is always false because invalid_buf_id_retry is initialized to zero on each iteration of a while-loop. Fix this by initializing the retry counter before the while-loop starts. Addresses-Coverity: ("Logically dead code") Fixes: b4a967b7 ("wil6210: reset buff id in status message after completion") Signed-off-by: NColin Ian King <colin.king@canonical.com> Reviewed-by: NMaya Erez <merez@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Linus Lüssing 提交于
So far, frames were forwarded regardless of the FCS correctness leading to userspace applications listening on the monitor mode interface to receive potentially broken frames, even with the "fcsfail" flag unset. By default, with the "fcsfail" flag of a monitor mode interface unset, frames with FCS errors should be dropped. With this patch, the fcsfail flag is taken into account correctly. Tested-on: QCA4019 firmware-5-ct-full-community-12.bin-lede.011 Cc: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: NLinus Lüssing <ll@simonwunderlich.de> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Wen Gong 提交于
iw command only show rssi without each chain's rssi on sdio iw wlan0 station dump Station a0:40:a0:93:3e:de (on wlan0) signal: -82 dBm signal avg: -82 dBm after this patch, it will show each chain's rssi on sdio Station a0:40:a0:93:3e:de (on wlan0) signal: -82 [-84, -88] dBm signal avg: -82 [-84, -87] dBm For QCA6174 PCIe, the ppdu have the correct rssi of each chain, it indicate rssi of rx data by ath10k_htt_rx_h_signal. For sdio chip, the rssi of each chain stored in rx management reported by firmware, the ath10k_wmi_tlv_op_pull_mgmt_rx_ev which used for tlv wmi will get the rssi of each chain and stored them in wmi_mgmt_rx_ev_arg, then indicate them to mac80211. For non-tlv wmi chip, it will not get the rssi of each chain and not indicate to mac80211, for non-tlv wmi chip, this patch will not have impact. For tlv wmi chip, if the rssi of chain in mgmt is valid, it will be indicate to mac80211, tested with QCA6174 PCIe/SDIO, the rssi of 2 chain in mgmt is valid. rssi of chains in mgmt of QCA6174 SDIO: 92096.652780: ath10k:ath10k_log_warn: ath10k_sdio mmc1:0001:1 rssi[0]:70 92096.657324: ath10k:ath10k_log_warn: ath10k_sdio mmc1:0001:1 rssi[1]:68 92096.662009: ath10k:ath10k_log_warn: ath10k_sdio mmc1:0001:1 rssi[2]:128 92096.666647: ath10k:ath10k_log_warn: ath10k_sdio mmc1:0001:1 rssi[3]:128 rssi of chains in mgmt of QCA6174 PCIe: [ 1581.049816] ath10k_pci 0000:02:00.0: mgmt rssi[0]:17 [ 1581.049818] ath10k_pci 0000:02:00.0: mgmt rssi[1]:22 [ 1581.049821] ath10k_pci 0000:02:00.0: mgmt rssi[2]:128 [ 1581.049823] ath10k_pci 0000:02:00.0: mgmt rssi[3]:128 after apply this patch, the iw's rssi of PCIe do not changed, result is same with before. iw wlan0 station dump of QCA6174 PCIe: Station 6c:e8:73:b8:92:dc (on wlan0) signal: -70 [-77, -72] dBm signal avg: -69 [-78, -72] dBm iw wlan-5000mhz station dump of QCA9984 PCIe connected with 2 client which has 2 chain: Station 70:48:0f:1f:1a:b2 (on wlan-5000mhz) signal: -47 [-55, -48, -87, -88] dBm signal avg: -42 [-50, -43, -83, -86] dBm Station ac:c1:ee:39:e3:83 (on wlan-5000mhz) signal: -43 [-46, -45, -79, -84] dBm signal avg: -43 [-46, -46, -82, -83] dBm Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00017-QCARMSWP-1. Tested with QCA6174 PCIe with firmware WLAN.RM.4.4.1-00110-QCARMSWP-1. Tested with QCA9984 PCIe with firmware 10.4-3.9.0.2-00040. Signed-off-by: NWen Gong <wgong@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Jeffrey Hugo 提交于
When the BDF download QMI message has the end field set to 1, it signals the end of the transfer, and triggers the firmware to do a CRC check. The BDFs for msm8998 devices fail this check, yet the firmware is happy to still use the BDF. It appears that this error is not caught by the downstream drive by concidence, therefore there are production devices in the field where this issue needs to be handled otherwise we cannot support wifi on them. So, attempt to detect this scenario as best we can and treat it as non-fatal. Signed-off-by: NJeffrey Hugo <jeffrey.l.hugo@gmail.com> Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Jeffrey Hugo 提交于
When ath10k_qmi_init() fails, the error handling does not free the irq resources, which causes an issue if we EPROBE_DEFER as we'll attempt to (re-)register irqs which are already registered. Fix this by doing a power off since we just powered on the hardware, and freeing the irqs as error handling. Fixes: ba94c753 ("ath10k: add QMI message handshake for wcn3990 client") Signed-off-by: NJeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Wen Gong 提交于
Add NL80211_FEATURE_ND_RANDOM_MAC_ADDR for NLO will enable the random mac address for netdetect case. iw command: iw phy0 wowlan enable net-detect net-detect randomize=AA:7B:A1:AC:B2:41/FF:FF:FF:FF:FF:FF interval 5000 delay 30 freqs 2412 matches ssid foo. After suspend, DUT will send probe request with mac AA:7B:A1:AC:B2:41. WCN3990, QCA9377, QCA6174 PCI also support this feature. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029. Signed-off-by: NWen Gong <wgong@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Jeffrey Hugo 提交于
Firmware with the build id QC_IMAGE_VERSION_STRING=WLAN.HL.1.0.2-XXXX does not support the QMI_WLFW_HOST_CAP_REQ_V01 message and will return the QMI not supported error to the ath10k driver. Since not supporting this message is not fatal to the firmware nor the ath10k driver, lets catch this particular scenario and ignore it so that we can still bring up wifi services successfully. Signed-off-by: NJeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Wen Gong 提交于
Download firmware time cost of SDIO is too long, it is about 480ms, add large size 2048 bytes for BMI download for SDIO chip, its time cost will reduced to 240ms. This will optimize the download firmware time cost. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00017-QCARMSWP-1. Signed-off-by: NWen Gong <wgong@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Wen Gong 提交于
the tlv len is set to the total len of the wmi cmd, it will trigger firmware crash, correct the tlv len. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00017-QCARMSWP-1 and QCA6174 PCIE with firmware WLAN.RM.4.4.1-00110-QCARMSWPZ-1. Fixes: ce834e28 ("ath10k: support NET_DETECT WoWLAN feature") Signed-off-by: NWen Gong <wgong@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Kalle Valo 提交于
It seems to be unused. Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Kalle Valo 提交于
Do some cosmetic cleanup while reviewing the files. No functional changes. Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Wen Gong 提交于
For RX, it has two parts, one is to read data from sdio, another is to indicate the packets to upper stack. Recently it has only one thread to do all RX things, it results that it is sequential for RX and low throughout, change RX to parallel for the two parts will increase throughout. This patch move the indication to a workqueue, it results in significant performance improvement on RX path. Udp rx throughout is 200Mbps without this patch, and it arrives 400Mbps with this patch. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00017-QCARMSWPZ-1 Signed-off-by: NWen Gong <wgong@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Wen Gong 提交于
The max bundle size support by firmware is 32, change it from 8 to 32 will help performance. This results in significant performance improvement on RX path. The real max rx bundle is decided in ath10k_htc_wait_target(), it is the min value of HTC_HOST_MAX_MSG_PER_RX_BUNDLE and the value reported from firmware. So this change shouldn't cause any regressions with other hardware supported by ath10k. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00017-QCARMSWPZ-1. Signed-off-by: NWen Gong <wgong@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Alagu Sankar 提交于
The existing implementation of initiating multiple sdio transfers for receive bundling is slowing down the receive speed. Combining the transfers using a bundle method would be ideal. 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 Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00017-QCARMSWPZ-1 Signed-off-by: NAlagu Sankar <alagusankar@silex-india.com> Signed-off-by: NWen Gong <wgong@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 15 11月, 2019 3 次提交
-
-
由 Eduardo Abinader 提交于
Signed-off-by: NEduardo Abinader <eduardoabinader@gmail.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Bjorn Andersson 提交于
Unless we sleep for a while before transitioning the MSA memory to WLAN the MPSS.AT.4.0.c2-01184-SDM845_GEN_PACK-1 firmware triggers a security violation fairly reliably. Unforutnately recovering from this failure always results in the entire system freezing. Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Bjorn Andersson 提交于
This reverts commit 334f5b61. This caused ath10k_snoc on Qualcomm MSM8998, SDM845 and QCS404 platforms to trigger an assert in the firmware: err_qdi.c:456:EF:wlan_process:1:cmnos_thread.c:3900:Asserted in wlan_vdev.c:_wlan_vdev_up:3219 Revert the offending commit for now. Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 08 11月, 2019 3 次提交
-
-
由 Ikjoon Jang 提交于
Downloading ath10k firmware needs a large number of IOs and cpuidle's miss predictions make it worse. In the worst case, resume time can be three times longer than the average on sdio. This patch disables cpuidle during firmware downloading by applying PM_QOS_CPU_DMA_LATENCY in ath10k_download_fw(). Tested-on: QCA9880 Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00029 Signed-off-by: NIkjoon Jang <ikjn@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Zhi Chen 提交于
STA number was not restored if OOM happened. Tested: QCA9984 with firmware ver 10.4-3.9.0.1-00018 Signed-off-by: NZhi Chen <zhichen@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Miaoqing Pan 提交于
ath10k does not provide transmit rate info per MSDU in tx completion, mark that as -1 so mac80211 will ignore the rates. This fixes mac80211 update Mesh link metric with invalid transmit rate info. Tested HW: QCA9984 Tested FW: 10.4-3.9.0.2-00035 Signed-off-by: NHou Bao Hou <houbao@codeaurora.org> Signed-off-by: NAnilkumar Kolli <akolli@codeaurora.org> Signed-off-by: NMiaoqing Pan <miaoqing@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 07 11月, 2019 6 次提交
-
-
由 Yan-Hsuan Chuang 提交于
Driver could access a NULL firmware pointer if we don't return here. Fixes: 5195b904 ("rtw88: avoid FW info flood") Reported-by: Nkbuild test robot <lkp@intel.com> Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Ping-Ke Shih 提交于
This leak was found by testing the EDIMAX EW-7612 on Raspberry Pi 3B+ with Linux 5.4-rc5 (multi_v7_defconfig + rtlwifi + kmemleak) and noticed a single memory leak during probe: unreferenced object 0xec13ee40 (size 176): comm "kworker/u8:1", pid 36, jiffies 4294939321 (age 5580.790s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<fc1bbb3e>] __netdev_alloc_skb+0x9c/0x164 [<863dfa6e>] rtl92c_set_fw_rsvdpagepkt+0x254/0x340 [rtl8192c_common] [<9572be0d>] rtl92cu_set_hw_reg+0xf48/0xfa4 [rtl8192cu] [<116df4d8>] rtl_op_bss_info_changed+0x234/0x96c [rtlwifi] [<8933575f>] ieee80211_bss_info_change_notify+0xb8/0x264 [mac80211] [<d4061e86>] ieee80211_assoc_success+0x934/0x1798 [mac80211] [<e55adb56>] ieee80211_rx_mgmt_assoc_resp+0x174/0x314 [mac80211] [<5974629e>] ieee80211_sta_rx_queued_mgmt+0x3f4/0x7f0 [mac80211] [<d91091c6>] ieee80211_iface_work+0x208/0x318 [mac80211] [<ac5fcae4>] process_one_work+0x22c/0x564 [<f5e6d3b6>] worker_thread+0x44/0x5d8 [<82c7b073>] kthread+0x150/0x154 [<b43e1b7d>] ret_from_fork+0x14/0x2c [<794dff30>] 0x0 It is because 8192cu doesn't implement usb_cmd_send_packet(), and this patch just frees the skb within the function to resolve memleak problem by now. Since 8192cu doesn't turn on fwctrl_lps that needs to download command packet for firmware via the function, applying this patch doesn't affect driver behavior. Reported-by: NStefan Wahren <wahrenst@gmx.net> Signed-off-by: NPing-Ke Shih <pkshih@realtek.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Daniel Golle 提交于
On 2019-10-28 06:07, wbob wrote: > Hello Roman, > > while reading around drivers/net/wireless/ralink/rt2x00/rt2800lib.c > I stumbled on what I think is an edit of yours made in error in march > 2017: > > https://github.com/torvalds/linux/commit/41977e86#diff-dae5dc10da180f3b055809a48118e18aR5281 > > RT6352 in line 5281 should not have been introduced as the "else if" > below line 5291 can then not take effect for a RT6352 device. Another > possibility is for line 5291 to be not for RT6352, but this seems > very unlikely. Are you able to clarify still after this substantial time? > > 5277: static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev) > ... > 5279: } else if (rt2x00_rt(rt2x00dev, RT5390) || > 5280: rt2x00_rt(rt2x00dev, RT5392) || > 5281: rt2x00_rt(rt2x00dev, RT6352)) { > ... > 5291: } else if (rt2x00_rt(rt2x00dev, RT6352)) { > ... Hence remove errornous line 5281 to make the driver actually execute the correct initialization routine for MT7620 chips. As it was requested by Stanislaw Gruszka remove setting values of MIMO_PS_CFG and TX_PIN_CFG. MIMO_PS_CFG is responsible for MIMO power-safe mode (which is disabled), hence we can drop setting it. TX_PIN_CFG is set correctly in other functions, and as setting this value breaks some devices, rather don't set it here during init, but only modify it later on. Fixes: 41977e86 ("rt2x00: add support for MT7620") Reported-by: Nwbob <wbob@jify.de> Reported-by: NRoman Yeryomin <roman@advem.lv> Signed-off-by: NDaniel Golle <daniel@makrotopia.org> Acked-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 YueHaibing 提交于
drivers/net/wireless//realtek/rtl818x/rtl8180/rtl8225se.c:83:17: warning: 'rtl8225sez2_tx_power_cck' defined but not used [-Wunused-const-variable=] drivers/net/wireless//realtek/rtl818x/rtl8180/rtl8225se.c:79:17: warning: 'rtl8225sez2_tx_power_cck_A' defined but not used [-Wunused-const-variable=] drivers/net/wireless//realtek/rtl818x/rtl8180/rtl8225se.c:75:17: warning: 'rtl8225sez2_tx_power_cck_B' defined but not used [-Wunused-const-variable=] drivers/net/wireless//realtek/rtl818x/rtl8180/rtl8225se.c:71:17: warning: 'rtl8225sez2_tx_power_cck_ch14' defined but not used [-Wunused-const-variable=] drivers/net/wireless//realtek/rtl818x/rtl8180/rtl8225se.c:62:17: warning: 'rtl8225se_tx_power_ofdm' defined but not used [-Wunused-const-variable=] drivers/net/wireless//realtek/rtl818x/rtl8180/rtl8225se.c:53:17: warning: 'rtl8225se_tx_power_cck_ch14' defined but not used [-Wunused-const-variable=] drivers/net/wireless//realtek/rtl818x/rtl8180/rtl8225se.c:44:17: warning: 'rtl8225se_tx_power_cck' defined but not used [-Wunused-const-variable=] drivers/net/wireless//realtek/rtl818x/rtl8180/rtl8225se.c:40:17: warning: 'rtl8225se_tx_gain_cck_ofdm' defined but not used [-Wunused-const-variable=] They are never used, so can be removed. Signed-off-by: NYueHaibing <yuehaibing@huawei.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 YueHaibing 提交于
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:841:7: warning: variable free_pdu set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:842:30: warning: variable tx_rts_count set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:842:6: warning: variable tx_rts set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:843:7: warning: variable totlen set but not used [-Wunused-but-set-variable] They are never used, so can be removed. Signed-off-by: NYueHaibing <yuehaibing@huawei.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Yan-Hsuan Chuang 提交于
The LPS threshold was set to 2, means driver will leave LPS mode if there is more than 2 frames TX/RX for every 2 seconds. This makes driver enter/leave LPS frequently even if we just "ping -i1" to the others. Apparently we do not want to leave LPS mode if there is only some background traffics or web surfing. By experiment, set this to 50 is a more reasonable value to lower the over all power consumption. Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-