summaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless
AgeCommit message (Collapse)Author
2020-05-08iwlwifi: remove antenna_coupling module parameterEmmanuel Grumbach
This module parameter should not be mangled by users. This relates to a very old driver and I doubt people can really check the antenna coupling in a way that would make the BT Coexistence work better with a real value. Drop it. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200424182644.6e566897ce0a.I8395a50c1c39522e542366064bff33a33009ce7b@changeid
2020-05-08iwlwifi: yoyo: use hweight_long instead of bit manipulatingMordechay Goodstein
Also we can only have one fid1 or fid2 set so no need to check if the fid2 is set in case fid1 wasn't set. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200424182644.34e74106bad3.Ic3a9f0a35fed47b02ebcd27c2dc2b50cb1e56bdf@changeid
2020-05-08iwlwifi: yoyo: add support for parsing SHARED_MEM_ALLOC version 4Mordechay Goodstein
The new version adds the information for RX2C FIFO addresses. Use the new addresses to parse the FIFO info when dumping. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200424182643.97cc25d96b53.I65fd0400d80f505bd6d7eed442f12db24b25bbe3@changeid
2020-05-08iwlwifi: fw api: fix PHY data 2/3 positionJohannes Berg
In AX210 devices, the PHY data wasn't actually reported, but now that it's going to be reported it turns out that the position is supposed to be the other way around, fix that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200424182643.06de959301f5.I544c353a8a811f107bd66d168e37920237ecf071@changeid
2020-05-07Merge tag 'wireless-drivers-next-2020-05-07' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for v5.8 First set of patches for v5.8. Changes all over, ath10k apparently seeing most new features this time. rtw88 also had lots of changes due to preparation for new hardware support. In this pull request there's also a new macro to include/linux/iopoll: read_poll_timeout_atomic(). This is needed by rtw88 for atomic polling. Major changes: ath11k * add debugfs file for testing ADDBA and DELBA * add 802.11 encapsulation offload on hardware support * add htt_peer_stats_reset debugfs file ath10k * enable VHT160 and VHT80+80 modes * enable radar detection in secondary segment * sdio: disable TX complete indication to improve throughput * sdio: decrease power consumption * sdio: add HTT TX bundle support to increase throughput * sdio: add rx bitrate reporting ath9k * improvements to AR9002 calibration logic carl9170 * remove buggy P2P_GO support p54usb * add support for AirVasT USB stick rtw88 * add support for antenna configuration ti wlcore * add support for AES_CMAC cipher iwlwifi * support for a few new FW API versions * new hw configs ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-07b43: remove dead function b43_rssinoise_postprocess()Jason Yan
This function is dead for more than 10 years. Remove it. Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-06Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo
ath.git patches for v5.8. Major changes: ath11k * add 802.11 encapsulation offload on hardware support * add htt_peer_stats_reset debugfs file ath10k * sdio: decrease power consumption * sdio: add HTT TX bundle support to increase throughput * sdio: add rx bitrate reporting ath9k * improvements to AR9002 calibration logic carl9170 * remove buggy P2P_GO support
2020-05-06rtlwifi: rtl8188ee: remove Comparison to bool in rf.cJason Yan
Fix the following coccicheck warning: drivers/net/wireless/realtek/rtlwifi/rtl8188ee/rf.c:476:6-14: WARNING: Comparison to bool drivers/net/wireless/realtek/rtlwifi/rtl8188ee/rf.c:54:5-22: WARNING: Comparison to bool Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200504113321.41118-1-yanaijie@huawei.com
2020-05-06b43: remove Comparison of 0/1 to bool variable in pio.cJason Yan
Fix the following coccicheck warning: drivers/net/wireless/broadcom/b43/pio.c:768:10-25: WARNING: Comparison of 0/1 to bool variable Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200504113311.41026-1-yanaijie@huawei.com
2020-05-06b43: remove Comparison of 0/1 to bool variable in phy_n.cJason Yan
Fix the following coccicheck warning: drivers/net/wireless/broadcom/b43/phy_n.c:5510:19-32: WARNING: Comparison of 0/1 to bool variable Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200504113300.40895-1-yanaijie@huawei.com
2020-05-06libertas_tf: avoid a null dereference in pointer privColin Ian King
Currently there is a check if priv is null when calling lbtf_remove_card but not in a previous call to if_usb_reset_dev that can also dereference priv. Fix this by also only calling lbtf_remove_card if priv is null. It is noteable that there don't seem to be any bugs reported that the null pointer dereference has ever occurred, so I'm not sure if the null check is required, but since we're doing a null check anyway it should be done for both function calls. Addresses-Coverity: ("Dereference before null check") Fixes: baa0280f08c7 ("libertas_tf: don't defer firmware loading until start()") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200501173900.296658-1-colin.king@canonical.com
2020-05-06mwifiex: avoid -Wstringop-overflow warningArnd Bergmann
gcc-10 reports a warning for mwifiex_cmd_802_11_key_material_v1: drivers/net/wireless/marvell/mwifiex/sta_cmd.c: In function 'mwifiex_cmd_802_11_key_material_v1': cc1: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=] In file included from drivers/net/wireless/marvell/mwifiex/sta_cmd.c:23: drivers/net/wireless/marvell/mwifiex/fw.h:993:9: note: at offset 0 to object 'action' with size 2 declared here 993 | __le16 action; | ^~~~~~ As the warning makes no sense, I reported it as a bug for gcc. In the meantime using a temporary pointer for the key data makes the code easier to read and stops the warning. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94881 Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200430213101.135134-4-arnd@arndb.de
2020-05-06rtlwifi: remove comparison of 0/1 to bool variableJason Yan
The variable 'rtlpriv->rfkill.rfkill_state' is bool and can directly assigned to bool values. Fix the following coccicheck warning: drivers/net/wireless/realtek/rtlwifi/core.c:1725:14-42: WARNING: Comparison of 0/1 to bool variable Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200429140924.7750-1-yanaijie@huawei.com
2020-05-06brcmsmac: remove Comparison to bool in brcms_b_txstatus()Jason Yan
Fix the following coccicheck warning: drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:1060:6-12: WARNING: Comparison to bool Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200504113357.41422-1-yanaijie@huawei.com
2020-05-06brcmfmac: Add P2P Action Frame retry delay to fix GAS Comeback Response ↵Justin Li
failure issue It was observed that P2P Cert. 5.1.19: DEVUT responds to Service Discovery request failed due to DUT did not send GAS Comeback Response after receiving request from test bed P2P peer. To fix this issue, we need to add P2P Action Frame retry delay to enhance P2P connection under VSDB and noisy environment, since the peer can be in other channels under VSDB. Signed-off-by: Justin Li <Justin.Li@cypress.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1588572453-194663-4-git-send-email-wright.feng@cypress.com
2020-05-06brcmfmac: Fix P2P Group Formation failure via Go-neg methodJoseph Chuang
P2P group formation fails since either peer is not able to send go-neg confirm or dut is not able to send go-neg response. To fix this, retry limit should be increased and dwell time check should be added. Signed-off-by: Joseph Chuang <joseph.chuang@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1588572453-194663-3-git-send-email-wright.feng@cypress.com
2020-05-06brcmfmac: support the second p2p connectionWright Feng
With RSDB feature, firmware is able to support two P2P-AGO or two P2P-GC at the same time. So we add the second p2p connection type to map to the second P2P connection bsscfg. Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1588572453-194663-2-git-send-email-wright.feng@cypress.com
2020-05-06rtw88: fix an issue about leak system resourcesDejin Zheng
the related system resources were not released when pci_iomap() return error in the rtw_pci_io_mapping() function. add pci_release_regions() to fix it. Fixes: e3037485c68ec1a ("rtw88: new Realtek 802.11ac driver") Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200504083442.3033-1-zhengdejin5@gmail.com
2020-05-06rtw88: 8723d: add interface configurations tablePing-Ke Shih
Interface configuration table is used to configure PCI PHY that are normally decided by design or bootstrap pin, and driver can do additional settings by this table. 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> Link: https://lore.kernel.org/r/20200504105010.10780-9-yhchuang@realtek.com
2020-05-06rtw88: 8723d: Set IG register for CCK ratePing-Ke Shih
DIG sets only one IG register for most chips, but 8723D need to set additional register for CCK rate. 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> Link: https://lore.kernel.org/r/20200504105010.10780-8-yhchuang@realtek.com
2020-05-06rtw88: 8723d: Add chip_ops::false_alarm_statisticsPing-Ke Shih
This ops is used to do statistics of false alarm periodically, and then fine tune RX initial gain to adaptive different circumstance. There are three steps, hold/get/reset counter, to retrieve false alarm counters that consist of CCK and OFDM. In addition to false alarm counters, it also collects CRC ok/error counters of CCK, OFDM and HT. 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> Link: https://lore.kernel.org/r/20200504105010.10780-7-yhchuang@realtek.com
2020-05-06rtw88: 8723d: some chips don't support LDPCPing-Ke Shih
Some chips are not able to receive LDPC packets. Add an attribute to rtw_chip_info to determine if the LDPC capability in [ht/vht]_cap should be advertised or not. 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> Link: https://lore.kernel.org/r/20200504105010.10780-6-yhchuang@realtek.com
2020-05-06rtw88: handle C2H_CCX_TX_RPT to know if packet TX'ed successfullyPing-Ke Shih
TX status report of 8723D differs from 8822B/8822C, it uses C2H_CCX_TX_RPT (0x03) with different format. With sequence number and TX status, driver can know if certain packet was transmitted successfully. 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> Link: https://lore.kernel.org/r/20200504105010.10780-5-yhchuang@realtek.com
2020-05-06rtw88: 8723d: Add set_channelPing-Ke Shih
Set MAC/BB/RF register according to specified channel. The function rtw_set_channel_mac() is used to set MAC registers, but 8723D only need some of them. For channel 14, we need to set different CCK DFIR values, so restore the values when channel 1 to 13 is selected. Spur calibration is needed in channel 13 and 14, and we do notch if spur is over threshold. 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> Link: https://lore.kernel.org/r/20200504105010.10780-4-yhchuang@realtek.com
2020-05-06rtw88: 8723d: Add query_rx_descPing-Ke Shih
This ops is used to parse RX descriptor to know the length of received packet and containing PHY status. If PHY status is existing, the order is RX descriptor, PHY status and then packet. There are two types of PHY status, named CCK and OFDM. Their size are the same, but formats are different. struct ieee80211_rx_status is also filled depends on above information. 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> Link: https://lore.kernel.org/r/20200504105010.10780-3-yhchuang@realtek.com
2020-05-06rtw88: 8723d: Add DIG parameterPing-Ke Shih
To improve user experience in field, we need DIG to adjust RX initial gain depends on field situation. Since each chip has its own register address, this commit defines 8723d specific address. 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> Link: https://lore.kernel.org/r/20200504105010.10780-2-yhchuang@realtek.com
2020-05-06ray_cs: use true,false for bool variableJason Yan
Fix the following coccicheck warning: drivers/net/wireless/ray_cs.c:2797:5-14: WARNING: Comparison of 0/1 to bool variable drivers/net/wireless/ray_cs.c:2798:2-11: WARNING: Assignment of 0/1 to bool variable Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200426103709.6730-1-yanaijie@huawei.com
2020-05-06rtlwifi: use true,false for bool variable in rtl_init_rfkill()Jason Yan
The 'blocked' is a bool variable, and '==' expression itself is bool too. So no need to convert it to 0/1. This fixes the following coccicheck warning: drivers/net/wireless/realtek/rtlwifi/base.c:508:13-41: WARNING: Comparison of 0/1 to bool variable Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200426094115.23294-1-yanaijie@huawei.com
2020-05-06ipw2x00: Remove a memory allocation failure log messageChristophe JAILLET
Axe a memory allocation failure log message. This message is useless and incorrect (vmalloc is not used here for the memory allocation) This has been like that since the very beginning of this driver in commit 43f66a6ce8da ("Add ipw2200 wireless driver.") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200424154527.27309-1-christophe.jaillet@wanadoo.fr
2020-05-06rtw88: Use udelay instead of usleep in atomic contextKai-Heng Feng
It's incorrect to use usleep in atomic context. Switch to a macro which uses udelay instead of usleep to prevent the issue. Fixes: 6343a6d4b213 ("rtw88: Add delay on polling h2c command status bit") Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200423073007.3566-1-kai.heng.feng@canonical.com
2020-05-06ath11k: Replace zero-length array with flexible-arrayGustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200504201224.GA32282@embeddedor
2020-05-06ath9k_htc: Silence undersized packet warningsMasashi Honma
Some devices like TP-Link TL-WN722N produces this kind of messages frequently. kernel: ath: phy0: Short RX data len, dropping (dlen: 4) This warning is useful for developers to recognize that the device (Wi-Fi dongle or USB hub etc) is noisy but not for general users. So this patch make this warning to debug message. Reported-By: Denis <pro.denis@protonmail.com> Ref: https://bugzilla.kernel.org/show_bug.cgi?id=207539 Fixes: cd486e627e67 ("ath9k_htc: Discard undersized packets") Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200504214443.4485-1-masashi.honma@gmail.com
2020-05-06ath6kl: Replace zero-length array with flexible-arrayGustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200504200838.GA31974@embeddedor
2020-05-06ath11k: fix kernel panic by freeing the msdu received with invalid lengthTamizh Chelvam
In certain scenario host receives the packets with invalid length which causes below kernel panic. Free up those msdus to avoid this kernel panic. 2270.028121: <6> task: ffffffc0008306d0 ti: ffffffc0008306d0 task.ti: ffffffc0008306d0 2270.035247: <2> PC is at skb_panic+0x40/0x44 2270.042784: <2> LR is at skb_panic+0x40/0x44 2270.521775: <2> [<ffffffc0004a06e0>] skb_panic+0x40/0x44 2270.524039: <2> [<ffffffc0004a1278>] skb_put+0x54/0x5c 2270.529264: <2> [<ffffffbffcc373a8>] ath11k_dp_process_rx_err+0x320/0x5b0 [ath11k] 2270.533860: <2> [<ffffffbffcc30b68>] ath11k_dp_service_srng+0x80/0x268 [ath11k] 2270.541063: <2> [<ffffffbffcc1d554>] ath11k_hal_rx_reo_ent_buf_paddr_get+0x200/0xb64 [ath11k] 2270.547917: <2> [<ffffffc0004b1f74>] net_rx_action+0xf8/0x274 2270.556247: <2> [<ffffffc000099df4>] __do_softirq+0x128/0x228 2270.561625: <2> [<ffffffc00009a130>] irq_exit+0x84/0xcc 2270.567008: <2> [<ffffffc0000cfb28>] __handle_domain_irq+0x8c/0xb0 2270.571695: <2> [<ffffffc000082484>] gic_handle_irq+0x6c/0xbc Signed-off-by: Tamizh Chelvam <tamizhr@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1588611568-20791-1-git-send-email-tamizhr@codeaurora.org
2020-05-06ath11k: Add support to reset htt peer statsAshok Raj Nagarajan
This patch add supports to reset the per peer htt stats. Usage: echo 1 > /sys/kernel/debug/ieee80211/phyX/netdev:wlanX/stations/<peer MAC addr>/htt_peer_stats_reset While doing so, sync the wmi services between FW and host. Signed-off-by: Ashok Raj Nagarajan <arnagara@codeaurora.org> Signed-off-by: Tamizh Chelvam <tamizhr@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1588610147-20231-1-git-send-email-tamizhr@codeaurora.org
2020-05-06carl9170: remove P2P_GO supportChristian Lamparter
This patch follows up on a bug-report by Frank Schäfer that discovered P2P GO wasn't working with wpa_supplicant. This patch removes part of the broken P2P GO support but keeps the vif switchover code in place. Cc: <stable@vger.kernel.org> Link: <https://lkml.kernel.org/r/3a9d86b6-744f-e670-8792-9167257edef8@googlemail.com> Reported-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200425092811.9494-1-chunkeey@gmail.com
2020-05-06ath11k: add tx hw 802.11 encapsulation offloading supportJohn Crispin
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
2020-05-05ath11k: fix resource unavailability for htt stats after peer stats displaySowmiya Sree Elavalagan
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: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1588592755-10427-1-git-send-email-ssreeela@codeaurora.org
2020-05-05ath11k: use true,false for bool variablesJason Yan
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: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200504113336.41249-1-yanaijie@huawei.com
2020-05-05ath10k: Add support for targets without trustzoneRakesh Pillai
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: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1586971906-20985-4-git-send-email-pillair@codeaurora.org
2020-05-05ath10k: Setup the msa resources before qmi initRakesh Pillai
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 <pillair@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1586971906-20985-3-git-send-email-pillair@codeaurora.org
2020-05-05ath10k: remove the max_sched_scan_reqs valueWen Gong
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: ce834e280f2f875 ("ath10k: support NET_DETECT WoWLAN feature") Signed-off-by: Wen Gong <wgong@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20191114050001.4658-1-wgong@codeaurora.org
2020-05-05ath10k: Avoid override CE5 configuration for QCA99X0 chipsetsMaharaja Kennadyrajan
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: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1587649759-14381-1-git-send-email-mkenna@codeaurora.org
2020-05-04net: partially revert dynamic lockdep key changesCong Wang
This patch reverts the folowing commits: commit 064ff66e2bef84f1153087612032b5b9eab005bd "bonding: add missing netdev_update_lockdep_key()" commit 53d374979ef147ab51f5d632dfe20b14aebeccd0 "net: avoid updating qdisc_xmit_lock_key in netdev_update_lockdep_key()" commit 1f26c0d3d24125992ab0026b0dab16c08df947c7 "net: fix kernel-doc warning in <linux/netdevice.h>" commit ab92d68fc22f9afab480153bd82a20f6e2533769 "net: core: add generic lockdep keys" but keeps the addr_list_lock_key because we still lock addr_list_lock nestedly on stack devices, unlikely xmit_lock this is safe because we don't take addr_list_lock on any fast path. Reported-and-tested-by: syzbot+aaa6fa4949cc5d9b7b25@syzkaller.appspotmail.com Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Taehee Yoo <ap420073@gmail.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Acked-by: Taehee Yoo <ap420073@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-04brcmfmac: no need to check return value of debugfs_create functionsGreg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. In doing this, make brcmf_debugfs_add_entry() return void as no one was even paying attention to the return value. Cc: Arend van Spriel <arend.vanspriel@broadcom.com> Cc: Franky Lin <franky.lin@broadcom.com> Cc: Hante Meuleman <hante.meuleman@broadcom.com> Cc: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Cc: Wright Feng <wright.feng@cypress.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafał Miłecki" <rafal@milecki.pl> Cc: linux-wireless@vger.kernel.org Cc: brcm80211-dev-list.pdl@broadcom.com Cc: brcm80211-dev-list@cypress.com Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200429101526.GA2094124@kroah.com
2020-05-04brcmfmac: remove comparison to bool in brcmf_fws_attach()Jason Yan
Fix the following coccicheck warning: drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c:2359:6-40: WARNING: Comparison to bool Signed-off-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Chi-hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200426094053.23132-1-yanaijie@huawei.com
2020-05-04brcmfmac: add vendor ie for association responsesRyohei Kondo
Miracast Certification clause 6.1.2 may fail if there is no WFD IE in p2p assoc response. This change allows WFD IE to be added to p2p assoc response. Related WFA certification: 6.1.2 P-SnUT operating as a Group Owner accepts a WFD Session with a Reference Source Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Ryohei Kondo <ryohei.kondo@cypress.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1587970803-77700-6-git-send-email-chi-hsien.lin@cypress.com
2020-05-04brcmfmac: only generate random p2p address when neededChi-Hsien Lin
P2p spec mentioned that the p2p device address should be the globally administered address with locally administered bit set. Therefore, follow this guideline by default. When the primary interface is set to a locally administered address, the locally administered bit cannot be set again. Generate a random locally administered address for this case. Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1587970803-77700-5-git-send-email-chi-hsien.lin@cypress.com
2020-05-04brcmfmac: p2p cert 6.1.9-support GOUT handling p2p presence requestMadhan Mohan R
Send p2p presence response from the p2p interface address instead of the p2p device address. This is needed for p2p cert 6.1.9 to pass. Signed-off-by: Madhan Mohan R <MadhanMohan.R@cypress.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1587970803-77700-4-git-send-email-chi-hsien.lin@cypress.com
2020-05-04brcmfmac: remove arp_hostip_clear from brcmf_netdev_stopWright Feng
The firmware does not respond ARP request and causes ping failure with following steps: 1. Bring up interface ifconfig wlan0 up or start wpa_supplicant 2. Set the IP address ifconfig wlan0 192.168.100.10 3. Bring down interface or ifconfig wlan0 down or kill wpa_supplicant 4. Bring up interface again and set the same IP address 5. Connect to AP(192.168.100.1) and ping to AP will be failed. FMAC clears arp_hostip when bringing down the interface, but not set it back if setting the same IP address. We are able to see the IP address in interface info(inconfig wlan0) but the ping still cannot work because the firmware ARP offload does not respond the ARP request. Because of that, we remove "arp_hostip_clear" from function "brcmf_netdev_stop" Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Reviewed-by: Franky Lin <franky.lin@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1587970803-77700-3-git-send-email-chi-hsien.lin@cypress.com
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-06 20:46:27 +0000