summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* rtlwifi: rtl8188ee: Remove set but not used variables ↵zhengbin2019-10-091-17/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 'v3','rtstatus','reg_ecc','reg_ec4','reg_eac','b_pathb_ok' Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c: In function phy_config_bb_with_pghdr: drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c:652:22: warning: variable v3 set but not used [-Wunused-but-set-variable] drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c: In function rtl88e_phy_config_rf_with_headerfile: drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c:772:7: warning: variable rtstatus set but not used [-Wunused-but-set-variable] drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c: In function rtl88e_phy_iq_calibrate: drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c:1945:6: warning: variable reg_ecc set but not used [-Wunused-but-set-variable] drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c: In function rtl88e_phy_iq_calibrate: drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c:1944:61: warning: variable reg_ec4 set but not used [-Wunused-but-set-variable] drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c: In function rtl88e_phy_iq_calibrate: drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c:1944:34: warning: variable reg_eac set but not used [-Wunused-but-set-variable] drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c: In function rtl88e_phy_iq_calibrate: drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c:1943:19: warning: variable b_pathb_ok set but not used [-Wunused-but-set-variable] They are not used since commit f1d2b4d338bf ("rtlwifi: rtl818x: Move drivers into new realtek directory") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtlwifi: rtl8192c: Remove set but not used variables 'reg_ecc','reg_eac'zhengbin2019-10-091-6/+2
| | | | | | | | | | | | | | | | Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c: In function rtl92c_phy_iq_calibrate: drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c:1373:6: warning: variable reg_ecc set but not used [-Wunused-but-set-variable] drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c: In function rtl92c_phy_iq_calibrate: drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c:1372:34: warning: variable reg_eac set but not used [-Wunused-but-set-variable] They are not used since commit f1d2b4d338bf ("rtlwifi: rtl818x: Move drivers into new realtek directory") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtlwifi: rtl8723ae: Remove set but not used variables ↵zhengbin2019-10-091-11/+3
| | | | | | | | | | | | | | | | | | | | | | 'reg_ecc','reg_ec4','reg_eac','b_pathb_ok' Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c: In function rtl8723e_phy_iq_calibrate: drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c:1346:6: warning: variable reg_ecc set but not used [-Wunused-but-set-variable] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c: In function rtl8723e_phy_iq_calibrate: drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c:1345:61: warning: variable reg_ec4 set but not used [-Wunused-but-set-variable] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c: In function rtl8723e_phy_iq_calibrate: drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c:1345:34: warning: variable reg_eac set but not used [-Wunused-but-set-variable] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c: In function rtl8723e_phy_iq_calibrate: drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c:1344:19: warning: variable b_pathb_ok set but not used [-Wunused-but-set-variable] They are not used since commit f1d2b4d338bf ("rtlwifi: rtl818x: Move drivers into new realtek directory") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtlwifi: rtl8821ae: Remove set but not used variables 'rtstatus','bd'zhengbin2019-10-091-6/+1
| | | | | | | | | | | | | | | | | | Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c: In function rtl8812ae_phy_config_rf_with_headerfile: drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:2079:7: warning: variable rtstatus set but not used [-Wunused-but-set-variable] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c: In function rtl8821ae_phy_config_rf_with_headerfile: drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:2114:7: warning: variable rtstatus set but not used [-Wunused-but-set-variable] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c: In function _rtl8812ae_phy_get_txpower_limit: drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:2354:6: warning: variable bd set but not used [-Wunused-but-set-variable] They are not used since commit f1d2b4d338bf ("rtlwifi: rtl818x: Move drivers into new realtek directory") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driverChris Chiu2019-10-092-7/+278
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have 3 laptops which connect the wifi by the same RTL8723BU. The PCI VID/PID of the wifi chip is 10EC:B720 which is supported. They have the same problem with the in-kernel rtl8xxxu driver, the iperf (as a client to an ethernet-connected server) gets ~1Mbps. Nevertheless, the signal strength is reported as around -40dBm, which is quite good. From the wireshark capture, the tx rate for each data and qos data packet is only 1Mbps. Compare to the Realtek driver at https://github.com/lwfinger/rtl8723bu, the same iperf test gets ~12Mbps or better. The signal strength is reported similarly around -40dBm. That's why we want to improve. After reading the source code of the rtl8xxxu driver and Realtek's, the major difference is that Realtek's driver has a watchdog which will keep monitoring the signal quality and updating the rate mask just like the rtl8xxxu_gen2_update_rate_mask() does if signal quality changes. And this kind of watchdog also exists in rtlwifi driver of some specific chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have the same member function named dm_watchdog and will invoke the corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate mask. With this commit, the tx rate of each data and qos data packet will be 39Mbps (MCS4) with the 0xF00000 as the tx rate mask. The 20th bit to 23th bit means MCS4 to MCS7. It means that the firmware still picks the lowest rate from the rate mask and explains why the tx rate of data and qos data is always lowest 1Mbps because the default rate mask passed is always 0xFFFFFFF ranges from the basic CCK rate, OFDM rate, and MCS rate. However, with Realtek's driver, the tx rate observed from wireshark under the same condition is almost 65Mbps or 72Mbps, which indicating that rtl8xxxu could still be further improved. Signed-off-by: Chris Chiu <chiu@endlessm.com> Reviewed-by: Daniel Drake <drake@endlessm.com> Acked-by: Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rsi: fix potential null dereference in rsi_probe()Denis Efremov2019-10-041-1/+1
| | | | | | | | | | | | | The id pointer can be NULL in rsi_probe(). It is checked everywhere except for the else branch in the idProduct condition. The patch adds NULL check before the id dereference in the rsi_dbg() call. Fixes: 54fdb318c111 ("rsi: add new device model for 9116") Cc: Amitkumar Karwar <amitkarwar@gmail.com> Cc: Siva Rebbagondla <siva8118@gmail.com> Cc: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* libertas: remove redundant assignment to variable retColin Ian King2019-10-041-1/+0
| | | | | | | | | | | The variable ret is being assigned a value that is never read and is being re-assigned a little later on. The assignment is redundant and hence can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: add support for SAE authentication offloadChung-Hsien Hsu2019-10-046-8/+90
| | | | | | | | | | | | The firmware may have SAE authentication code built-in. This is detected by the driver and indicated in the wiphy features flags. User-space can use this flag to determine whether or not to provide the password material for SAE authentication in the nl80211 CONNECT command. Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtw88: fix error handling when setup efuse infoPing-Ke Shih2019-10-041-5/+6
| | | | | | | | | | Disable efuse if the efuse is enabled when we failed to setup the efuse information, otherwise the hardware will not turn off. Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtw88: fix NSS of hw_capPing-Ke Shih2019-10-041-1/+2
| | | | | | | | | | | | | | | 8822C is a 2x2 11ac chip, and then NSS must be less or equal to 2. However, current nss of hw cap is 3, likes hw cap: hci=0x0f, bw=0x07, ptcl=0x03, ant_num=7, nss=3 This commit adds constraint to make sure NSS <= rf_path_num, and result looks like hw cap: hci=0x0f, bw=0x07, ptcl=0x03, ant_num=7, nss=2 Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtw88: use struct rtw_fw_hdr to access firmware headerPing-Ke Shih2019-10-042-34/+48
| | | | | | | | | | This commit doesn't change logic at all, just use struct rtw_fw_hdr to access fixed part of 64 bytes header. Since remaining part is variable length data of actual firmware, we don't define them within the struct. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtw88: raise firmware version debug levelYan-Hsuan Chuang2019-10-041-4/+2
| | | | | | | | | | | | It's better to print firmware version at load time. But since we need to set debug_mask properly to default print rtw_dbg(), raise the debug level to rtw_info() instead. Also change the multiple line style to one line only, it will be easier for log analyzing. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtw88: configure TX queue EDCA parametersYan-Hsuan Chuang2019-10-043-0/+83
| | | | | | | | | | | | | | Set CWmax/CWmin, TXOP and AIFS according to ieee80211_tx_queue_params. Do note that hardware has only one group of EDCA[ac] registers, if more than one vif are added, the EDCA[ac] registers will contain value of params of the most recent set by ieee80211_ops::conf_tx(). And AIFS = AIFSN[ac] * slot_time + SIFS, so if use_short_slot is changed, need to also change AIFS. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtw88: Don't set RX_FLAG_DECRYPTED if packet has no encryptionPing-Ke Shih2019-10-043-2/+15
| | | | | | | | | | | | | | | | The value of GET_RX_DESC_SWDEC() indicates that if this RX packet requires software decryption or not. And software decryption is required when the packet was encrypted and the hardware failed to decrypt it. So, GET_RX_DESC_SWDEC() is negative does not mean that this packet is decrypted, it might just have no encryption at all. To actually see if the packet is decrypted, driver needs to further check if the hardware has successfully decrypted it, with a specific type of encryption algorithm. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtw88: fix beaconing mode rsvd_page memory violation issueYan-Hsuan Chuang2019-10-041-9/+43
| | | | | | | | | | | | | | | | | | | | | | | | | When downloading the reserved page, the first page always contains a beacon for the firmware to reference. For non-beaconing modes such as station mode, also put a blank skb with length=1. And for the beaconing modes, driver will get a real beacon with a length approximate to the page size. But as the beacon is always put at the first page, it does not need a tx_desc, because the TX path will generate one when TXing the reserved page to the hardware. So we could allocate a buffer with a size smaller than the reserved page, when using memcpy() to copy the content of reserved page to the buffer, the over-sized reserved page will violate the kernel memory. To fix it, add the tx_desc before memcpy() the reserved packets to the buffer, then we can get SKBs with correct length when counting the pages in total. And for page 0, count the extra tx_desc_sz that the TX path will generate. This way, the first beacon that allocated without tx_desc can be counted with the extra tx_desc_sz to get actual pages it requires. Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtw88: flush hardware tx queuesYan-Hsuan Chuang2019-10-044-1/+105
| | | | | | | | | | | | | | | | | Sometimes mac80211 will ask us to flush the hardware queues. To flush them, first we need to get the corresponding priority queues from the RQPN mapping table. Then we can check the available pages are equal to the originally reserved pages, which means the hardware has returned all of the pages it used to transmit. Note that now we only check for 100 ms for the priority queue, but sometimes if we have a lot of traffic (ex. 100Mbps up), some of the packets could be dropped. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtw88: add TX-AMSDU supportYan-Hsuan Chuang2019-10-042-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | Based on the mac80211's TXQ implementation, TX-AMSDU can be used to get higher MAC efficiency. To make mac80211 aggregate MSDUs, low level driver just need to leave skbs in the TXQ, and mac80211 will try to aggregate them if possible. As driver will schedule a tasklet when the TX queue is woke, until the tasklet being served, there will have some skbs in the queue if traffic is heavy. Driver can control the max AMSDU size depending on the current bit rate used by hardware/firmware. The higher rates are used, the larger AMSDU size can be. It is tested that can achieve higher T-Put at higher rates. If the environment is relatively clean, and the bit_rate is high enough, we can get about 80Mbps improvement. For lower bit rates, not much gain can we get, so leave the max_amsdu length low to prevent aggregation. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtw88: report tx rate to mac80211 stackTzu-En Huang2019-10-047-19/+143
| | | | | | | | | | | | Whenever the firmware increases/decreases the bit rate used to transmit to a peer, it sends an RA report through C2H to driver. Driver can then record the bit rate in the peer's struct rtw_sta_info, and report to mac80211 when it asks us for the statistics of the sta by ieee80211_ops::sta_statistics Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtw88: take over rate control from mac80211Yan-Hsuan Chuang2019-10-045-2/+87
| | | | | | | | | | | | | | | | | | We can indicate IEEE80211_HW_HAS_RATE_CONTROL to mac80211 because the hardware has its own rate control algorithm. And what driver needs to do is to choose an RA mask according the peer's capabilities. But the hardware is not able to setup BA session by itself. So driver requires to initiate tx BA session for hardware, and tells it if it is possible to transmit AMPDU. The hardware can then aggregate MPDUs. And the size of AMPDU is controlled by the TX descriptor and the register value. Since the TX descriptor will reference the max AMPDU size from ieee80211_sta::ht_cap::ampdu_factor, just set the register value to 0x3f, and let it be controlled by TX descriptor. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtw88: add driver TX queue supportYan-Hsuan Chuang2019-10-045-9/+156
| | | | | | | | | | | | | | | | | | | | | The mac80211 provides software TX queue for driver, as long as driver has hooked ieee80211_ops::wake_tx_queue. Each time a packet is queued onto the TX queue, that queue will be woken up the inform driver to serve the queue. Now driver only supports PCI interface ICs, there's no specific traffic control for each queue, just schedule a tasklet, and dump all of the packets at once to the DMA ring. Instead of TX the packets whenever TX queue is woke, tasklet handler can have more packets dumped to the device, takes advantage of burst write with DMA engine. And if the driver is going to support USB/SDIO ICs, the tasklet can be more flexible for aggregating the packets, enhance the efficiency of bandwidth usage. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtw88: allows to set RTS in TX descriptorYan-Hsuan Chuang2019-10-044-0/+20
| | | | | | | | | | | | | Allows driver to send RTS by filling tx descriptor. The user may want to set the rts threshold. But since we have not been taking over rate control from mac80211 to driver by setting flag IEEE80211_HW_HAS_RATE_CONTROL, there is nothing we can do about it. So here just store the value, and mac80211 will tell us to use rts protection by ieee80211_tx_info::control::use_rts. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtw88: check firmware leave lps successfullyChin-Yen Lee2019-10-043-0/+32
| | | | | | | | | | | | | | | | | | | | | | Driver needs to wait for firmware to restore hardware setting to active mode after leaving lps. After getting H2C from driver for leaving lps, firmware will issue null packet without PS bit to inform AP driver is active, and then restore REG_TCR Register if AP has receiced null packet. But the transmission of null packet may cost much more time in noisy environment. If driver does not wait for firmware, null packet with PS bit could be sent due to incorrect REG_TCR setting. And AP will be confused. In our test, 100ms is enough for firmware to send null packet to AP. If REG_TCR Register is still wrong after 100ms, we will modify it directly, force the PS bit to be cleared Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo2019-10-0331-420/+719
|\ | | | | | | | | | | | | | | ath.git patches for 5.5. Major changes: ath10k * add support for hardware rfkill on devices where firmware supports it
| * wil6210: check len before memcpy() callsDenis Efremov2019-10-021-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | memcpy() in wmi_set_ie() and wmi_update_ft_ies() is called with src == NULL and len == 0. This is an undefined behavior. Fix it by checking "ie_len > 0" before the memcpy() calls. As suggested by GCC documentation: "The pointers passed to memmove (and similar functions in <string.h>) must be non-null even when nbytes==0, so GCC can use that information to remove the check after the memmove call." [1] [1] https://gcc.gnu.org/gcc-4.9/porting_to.html Cc: Maya Erez <merez@codeaurora.org> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ar5523: check NULL before memcpy() in ar5523_cmd()Denis Efremov2019-10-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | memcpy() call with "idata == NULL && ilen == 0" results in undefined behavior in ar5523_cmd(). For example, NULL is passed in callchain "ar5523_stat_work() -> ar5523_cmd_write() -> ar5523_cmd()". This patch adds ilen check before memcpy() call in ar5523_cmd() to prevent an undefined behavior. Cc: Pontus Fuchs <pontus.fuchs@gmail.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: David Laight <David.Laight@ACULAB.COM> Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: add support for hardware rfkillWen Gong2019-10-029-1/+178
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When hardware rfkill is enabled in the firmware it will report the capability via using WMI_TLV_SYS_CAP_INFO_RFKILL bit in the WMI_SERVICE_READY event to the host. ath10k will check the capability, and if it is enabled then ath10k will set the GPIO information to firmware using WMI_PDEV_SET_PARAM. When the firmware detects hardware rfkill is enabled by the user, it will report it via WMI_RFKILL_STATE_CHANGE_EVENTID. Once ath10k receives the event it will send wmi command WMI_PDEV_SET_PARAM to the firmware to enable/disable the radio and also notifies cfg80211. We can't power off the device when rfkill is enabled, as otherwise the firmware would not be able to detect GPIO changes and report them to the host. So when rfkill is enabled, we need to keep the firmware running. Tested with QCA6174 PCI with firmware WLAN.RM.4.4.1-00109-QCARMSWPZ-1. Signed-off-by: Alan Liu <alanliu@codeaurora.org> Signed-off-by: Wen Gong <wgong@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: restore QCA9880-AR1A (v1) detectionChristian Lamparter2019-10-021-11/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch restores the old behavior that read the chip_id on the QCA988x before resetting the chip. This needs to be done in this order since the unsupported QCA988x AR1A chips fall off the bus when resetted. Otherwise the next MMIO Op after the reset causes a BUS ERROR and panic. Cc: stable@vger.kernel.org Fixes: 1a7fecb766c8 ("ath10k: reset chip before reading chip_id in probe") Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: fix offchannel tx failure when no ath10k_mac_tx_frm_has_freqBen Greear2019-10-021-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Offchannel management frames were failing: [18099.253732] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18102.293686] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18105.333653] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18108.373712] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18111.413687] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e36c0 [18114.453726] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3f00 [18117.493773] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e36c0 [18120.533631] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3f00 This bug appears to have been added between 4.0 (which works for us), and 4.4, which does not work. I think this is because the tx-offchannel logic gets in a loop when ath10k_mac_tx_frm_has_freq(ar) is false, so pkt is never actually sent to the firmware for transmit. This patch fixes the problem on 4.9 for me, and now HS20 clients can work again with my firmware. Antonio: tested with 10.4-3.5.3-00057 on QCA4019 and QCA9888 Signed-off-by: Ben Greear <greearb@candelatech.com> Tested-by: Antonio Quartulli <antonio.quartulli@kaiwoo.ai> [kvalo@codeaurora.org: improve commit log, remove unneeded parenthesis] Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath9k_htc: Discard undersized packetsMasashi Honma2019-10-011-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes the hardware will push small packets that trigger a WARN_ON in mac80211. Discard them early to avoid this issue. This patch ports 2 patches from ath9k to ath9k_htc. commit 3c0efb745a172bfe96459e20cbd37b0c945d5f8d "ath9k: discard undersized packets". commit df5c4150501ee7e86383be88f6490d970adcf157 "ath9k: correctly handle short radar pulses". [ 112.835889] ------------[ cut here ]------------ [ 112.835971] WARNING: CPU: 5 PID: 0 at net/mac80211/rx.c:804 ieee80211_rx_napi+0xaac/0xb40 [mac80211] [ 112.835973] Modules linked in: ath9k_htc ath9k_common ath9k_hw ath mac80211 cfg80211 libarc4 nouveau snd_hda_codec_hdmi intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_hda_codec video snd_hda_core ttm snd_hwdep drm_kms_helper snd_pcm crct10dif_pclmul snd_seq_midi drm snd_seq_midi_event crc32_pclmul snd_rawmidi ghash_clmulni_intel snd_seq aesni_intel aes_x86_64 crypto_simd cryptd snd_seq_device glue_helper snd_timer sch_fq_codel i2c_algo_bit fb_sys_fops snd input_leds syscopyarea sysfillrect sysimgblt intel_cstate mei_me intel_rapl_perf soundcore mxm_wmi lpc_ich mei kvm_intel kvm mac_hid irqbypass parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic usbhid hid raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear e1000e ahci libahci wmi [ 112.836022] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 5.3.0-wt #1 [ 112.836023] Hardware name: MouseComputer Co.,Ltd. X99-S01/X99-S01, BIOS 1.0C-W7 04/01/2015 [ 112.836056] RIP: 0010:ieee80211_rx_napi+0xaac/0xb40 [mac80211] [ 112.836059] Code: 00 00 66 41 89 86 b0 00 00 00 e9 c8 fa ff ff 4c 89 b5 40 ff ff ff 49 89 c6 e9 c9 fa ff ff 48 c7 c7 e0 a2 a5 c0 e8 47 41 b0 e9 <0f> 0b 48 89 df e8 5a 94 2d ea e9 02 f9 ff ff 41 39 c1 44 89 85 60 [ 112.836060] RSP: 0018:ffffaa6180220da8 EFLAGS: 00010286 [ 112.836062] RAX: 0000000000000024 RBX: ffff909a20eeda00 RCX: 0000000000000000 [ 112.836064] RDX: 0000000000000000 RSI: ffff909a2f957448 RDI: ffff909a2f957448 [ 112.836065] RBP: ffffaa6180220e78 R08: 00000000000006e9 R09: 0000000000000004 [ 112.836066] R10: 000000000000000a R11: 0000000000000001 R12: 0000000000000000 [ 112.836068] R13: ffff909a261a47a0 R14: 0000000000000000 R15: 0000000000000004 [ 112.836070] FS: 0000000000000000(0000) GS:ffff909a2f940000(0000) knlGS:0000000000000000 [ 112.836071] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 112.836073] CR2: 00007f4e3ffffa08 CR3: 00000001afc0a006 CR4: 00000000001606e0 [ 112.836074] Call Trace: [ 112.836076] <IRQ> [ 112.836083] ? finish_td+0xb3/0xf0 [ 112.836092] ? ath9k_rx_prepare.isra.11+0x22f/0x2a0 [ath9k_htc] [ 112.836099] ath9k_rx_tasklet+0x10b/0x1d0 [ath9k_htc] [ 112.836105] tasklet_action_common.isra.22+0x63/0x110 [ 112.836108] tasklet_action+0x22/0x30 [ 112.836115] __do_softirq+0xe4/0x2da [ 112.836118] irq_exit+0xae/0xb0 [ 112.836121] do_IRQ+0x86/0xe0 [ 112.836125] common_interrupt+0xf/0xf [ 112.836126] </IRQ> [ 112.836130] RIP: 0010:cpuidle_enter_state+0xa9/0x440 [ 112.836133] Code: 3d bc 20 38 55 e8 f7 1d 84 ff 49 89 c7 0f 1f 44 00 00 31 ff e8 28 29 84 ff 80 7d d3 00 0f 85 e6 01 00 00 fb 66 0f 1f 44 00 00 <45> 85 ed 0f 89 ff 01 00 00 41 c7 44 24 10 00 00 00 00 48 83 c4 18 [ 112.836134] RSP: 0018:ffffaa61800e3e48 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde [ 112.836136] RAX: ffff909a2f96b340 RBX: ffffffffabb58200 RCX: 000000000000001f [ 112.836137] RDX: 0000001a458adc5d RSI: 0000000026c9b581 RDI: 0000000000000000 [ 112.836139] RBP: ffffaa61800e3e88 R08: 0000000000000002 R09: 000000000002abc0 [ 112.836140] R10: ffffaa61800e3e18 R11: 000000000000002d R12: ffffca617fb40b00 [ 112.836141] R13: 0000000000000002 R14: ffffffffabb582d8 R15: 0000001a458adc5d [ 112.836145] ? cpuidle_enter_state+0x98/0x440 [ 112.836149] ? menu_select+0x370/0x600 [ 112.836151] cpuidle_enter+0x2e/0x40 [ 112.836154] call_cpuidle+0x23/0x40 [ 112.836156] do_idle+0x204/0x280 [ 112.836159] cpu_startup_entry+0x1d/0x20 [ 112.836164] start_secondary+0x167/0x1c0 [ 112.836169] secondary_startup_64+0xa4/0xb0 [ 112.836173] ---[ end trace 9f4cd18479cc5ae5 ]--- Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath9k_htc: Modify byte order for an error messageMasashi Honma2019-10-011-1/+1
| | | | | | | | | | | | | | rs_datalen is be16 so we need to convert it before printing. Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath9k_hw: fix uninitialized variable dataDenis Efremov2019-10-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, data variable in ar9003_hw_thermo_cal_apply() could be uninitialized if ar9300_otp_read_word() will fail to read the value. Initialize data variable with 0 to prevent an undefined behavior. This will be enough to handle error case when ar9300_otp_read_word() fails. Fixes: 80fe43f2bbd5 ("ath9k_hw: Read and configure thermocal for AR9462") Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Cc: John W. Linville <linville@tuxdriver.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: fix backtrace on coredumpAnilkumar Kolli2019-10-011-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a multiradio board with one QCA9984 and one AR9987 after enabling the crashdump with module parameter coredump_mask=7, below backtrace is seen. vmalloc: allocation failure: 0 bytes kworker/u4:0: page allocation failure: order:0, mode:0x80d2 CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 3.14.77 #130 Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] (unwind_backtrace) from [<c021abf8>] (show_stack+0x10/0x14) (dump_stack+0x80/0xa0) (warn_alloc_failed+0xd0/0xfc) (__vmalloc_node_range+0x1b4/0x1d8) (__vmalloc_node+0x34/0x40) (vzalloc+0x24/0x30) (ath10k_coredump_register+0x6c/0x88 [ath10k_core]) (ath10k_core_register_work+0x350/0xb34 [ath10k_core]) (process_one_work+0x20c/0x32c) (worker_thread+0x228/0x360) This is due to ath10k_hw_mem_layout is not defined for AR9987. For coredump undefined hw ramdump_size is 0. Check for the ramdump_size before allocation memory. Tested on: AR9987, QCA9984 FW version: 10.4-3.9.0.2-00044 Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: coredump: fix IRAM addr for QCA9984, QCA4019, QCA9888 and QCA99x0Anilkumar Kolli2019-10-011-3/+3
| | | | | | | | | | | | | | | | | | | | | | The IRAM start address in coredump was wrong for QCA9984, QCA4019, QCA9888 and QCA99x0. Tested on: QCA9984, QCA4019 FW version: 10.4-3.9.0.2-00044 Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: switch to ieee80211_tx_dequeue_niErik Stromdahl2019-10-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ath10k_mac_tx_push_txq() can be called from process context, we must explicitly disable softirqs before the call into mac80211. By calling ieee80211_tx_dequeue_ni() instead of ieee80211_tx_dequeue() we make sure softirqs are always disabled even in the case when ath10k_mac_tx_push_txq() is called from process context. Calling ieee80211_tx_dequeue_ni() with softirq's already disabled (e.g., from softirq context) should be safe as the local_bh_disable() and local_bh_enable() functions (called from ieee80211_tx_dequeue_ni) are fully reentrant. Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: change sw version print format to hexTomislav Požega2019-10-011-1/+1
| | | | | | | | | | | | | | | | | | Software version within WMI event ready message was displayed in a not very useful decimal format. Change this info to be shown in a hexadecimal format instead. Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: print supported MCS rates within service ready eventTomislav Požega2019-10-014-1/+8
| | | | | | | | | | | | | | | | Add vht_supp_mcs argument to service ready structure and print supported MCS rates in WMI service ready debug message. Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: print service ready returned channel rangeTomislav Požega2019-10-011-1/+5
| | | | | | | | | | | | | | | | | | Displays lowest/highest supported channels for both 2ghz and 5ghz bands as they're fetched within WMI service ready event. These are shown in a frequency format. Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: add 2ghz channel arguments to service ready structureTomislav Požega2019-10-014-0/+12
| | | | | | | | | | | | | | | | Add lowest/highest 2ghz channel arguments for use within WMI service ready structure. Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath9k: remove unused including <linux/version.h>YueHaibing2019-10-011-1/+0
| | | | | | | | | | | | | | Remove including <linux/version.h> that don't need it. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: fix memory leakNavid Emamdoost2019-09-231-0/+1
| | | | | | | | | | | | | | | | In ath10k_usb_hif_tx_sg the allocated urb should be released if usb_submit_urb fails. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: remove the warning of sdio not full supportWen Gong2019-09-231-3/+0
| | | | | | | | | | | | | | | | | | | | | | Recently, it has the basic feature of sdio tested success, so remove it. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00017-QCARMSWP-1. Signed-off-by: Wen Gong <wgong@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath: Use dev_get_drvdata where possibleChuhong Yuan2019-09-233-9/+5
| | | | | | | | | | | | | | | | Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath: fix various spelling mistakesColin Ian King2019-09-233-4/+4
| | | | | | | | | | | | | | | | There are a bunch of spelling mistakes in two ath drivers, fix these. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: fix missing checks for bmi reads and writesKangjie Lu2019-09-231-9/+32
| | | | | | | | | | | | | | | | ath10k_bmi_write32 and ath10k_bmi_read32 can fail. The fix checks their statuses to avoid potential undefined behaviors. Signed-off-by: Kangjie Lu <kjlu@umn.edu> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: Add support to provide higher range mem chunks in wmi init commandSurabhi Vishnoi2019-09-233-2/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the current implementation of wmi init command, there is no provision for the host driver to provide mem chunks addresses with more than 32-bit, to the firmware. WCN3990 is a 35-bit target and can accept mem chunks addresses which are above 32-bit. If firmware supports address range more than 32 bit, it advertises the support by setting the WMI_SERVICE_EXTEND_ADDRESS service. Based on this service fill the upper bits of paddr while providing the mem chunks in the wmi init command. Tested HW: WCN3990 Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1 Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: Add peer param map for tlv and non-tlvRakesh Pillai2019-09-237-9/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The peer param id for PEER_PARAM_USE_FIXED_PWR is different for tlv and non-tlv firmware. This causes incorrect peer param to be set by the driver to the firmware(tlv/non-tlv). Create seperate peer param map for tlv and non-tlv firmware and attach the peer param id based on the firmware type during the init. Tested HW: WCN3990 Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1 Signed-off-by: Rakesh Pillai <pillair@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: Enable MSA region dump support for WCN3990Govind Singh2019-09-215-0/+93
| | | | | | | | | | | | | | | | | | | | | | | | MSA memory region caries the hw descriptors information. Dump MSA region in core dump as this is very helpful in debugging hw issues. Testing: Tested on WCN3990 HW Tested FW: WLAN.HL.3.1-00959-QCAHLSWMTPLZ-1 Signed-off-by: Govind Singh <govinds@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: Add xo calibration support for wifi rf clockGovind Singh2019-09-213-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PMIC XO is the clock source for wifi rf clock in integrated wifi chipset ex: WCN3990. Due to board layout errors XO frequency drifts can cause wifi rf clock inaccuracy. XO calibration test tree in Factory Test Mode is used to find the best frequency offset(for example +/-2KHz )by programming XO trim register. This ensure system clock stays within required 20 ppm WLAN rf clock. Retrieve the xo trim offset via system firmware (e.g., device tree), especially in the case where the device doesn't have a useful EEPROM on which to store the calibrated XO offset (e.g., for integrated Wifi). Calibrated XO offset is sent to fw, which compensate the clock drift by programing the XO trim register. Signed-off-by: Govind Singh <govinds@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * dt: bindings: ath10k: add dt entry for XO calibration supportGovind Singh2019-09-211-1/+1
| | | | | | | | | | | | | | | | Add dt binding to get xo calibration data support for wifi rf clock. Signed-off-by: Govind Singh <govinds@codeaurora.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * ath10k: fix spelling mistake "eanble" -> "enable"Colin Ian King2019-09-171-1/+1
| | | | | | | | | | | | | | There is a spelling mistake in a ath10k_warn warning message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-18 22:40:34 +0000