summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* ipw2200: prepare for const netdev->dev_addrJakub Kicinski2021-10-202-4/+4
| | | | | | | | | netdev->dev_addr will be come const soon, constify the argument to command send to avoid compiler warnings. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211018235021.1279697-10-kuba@kernel.org
* airo: use eth_hw_addr_set()Jakub Kicinski2021-10-201-14/+13
| | | | | | | | | | | | | | | | Commit 406f42fa0d3c ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it got through appropriate helpers. Use dev_addr_set() to match the existing logic. setup_card() is always passed netdev->dev_addr, so pass the netdev pointer instead and assign the address using a helper there. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211018235021.1279697-9-kuba@kernel.org
* brcmfmac: prepare for const netdev->dev_addrJakub Kicinski2021-10-201-2/+2
| | | | | | | | | netdev->dev_addr will become const soon. Make sure local variables maintain that qualifier. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211018235021.1279697-8-kuba@kernel.org
* atmel: use eth_hw_addr_set()Jakub Kicinski2021-10-201-5/+10
| | | | | | | | | | | | | | | Commit 406f42fa0d3c ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it got through appropriate helpers. Use a buffer on the stack. Note that atmel_get_mib() is a wrapper around atmel_copy_to_host(). For the to device direction we just need to make sure functions respect argument being cost. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211018235021.1279697-7-kuba@kernel.org
* wil6210: use eth_hw_addr_set()Jakub Kicinski2021-10-203-5/+7
| | | | | | | | | | | | | Commit 406f42fa0d3c ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it got through appropriate helpers. Do the special encoding on the stack, then copy the address. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211018235021.1279697-6-kuba@kernel.org
* ath6kl: use eth_hw_addr_set()Jakub Kicinski2021-10-201-4/+5
| | | | | | | | | | | | | Commit 406f42fa0d3c ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it got through appropriate helpers. Do the special encoding on the stack, then copy the address. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211018235021.1279697-5-kuba@kernel.org
* wireless: use eth_hw_addr_set() for dev->addr_len casesJakub Kicinski2021-10-202-2/+2
| | | | | | | | | | | | | | | | | | Convert all WiFi drivers from memcpy(... dev->addr_len) to eth_hw_addr_set(): @@ expression dev, np; @@ - memcpy(dev->dev_addr, np, dev->addr_len) + eth_hw_addr_set(dev, np) Manually checked the netdevs are allocated with alloc_etherdev(), so dev->addr_len must be equal to ETH_ALEN. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211018235021.1279697-4-kuba@kernel.org
* wireless: use eth_hw_addr_set() instead of ether_addr_copy()Jakub Kicinski2021-10-204-7/+7
| | | | | | | | | | | | | | | | | | | Commit 406f42fa0d3c ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it got through appropriate helpers. Convert wireless from ether_addr_copy() to eth_hw_addr_set(): @@ expression dev, np; @@ - ether_addr_copy(dev->dev_addr, np) + eth_hw_addr_set(dev, np) Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211018235021.1279697-3-kuba@kernel.org
* wireless: use eth_hw_addr_set()Jakub Kicinski2021-10-2011-20/+18
| | | | | | | | | | | | | | | Convert all WiFi drivers from memcpy(... ETH_ADDR) to eth_hw_addr_set(): @@ expression dev, np; @@ - memcpy(dev->dev_addr, np, ETH_ALEN) + eth_hw_addr_set(dev, np) Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211018235021.1279697-2-kuba@kernel.org
* iwlwifi: cfg: set low-latency-xtal for some integrated So devicesJohannes Berg2021-10-201-1/+1
| | | | | | | | | | | | The integrated So devices covered by the iwl_so_long_latency_trans_cfg configuration should all have low-latency-xtal enabled, so do that. While at it, remove the TODO, I've checked the other values as well. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: 6f60fb03c8e7 ("iwlwifi: move SnJ and So rules to the new tables") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20211016114029.8b5480113f53.I80b5b4ebea84e56f3b3143fc1ee7097be8b4ae78@changeid
* iwlwifi: pnvm: read EFI data only if long enoughJohannes Berg2021-10-201-3/+7
| | | | | | | | | | | If the data we get from EFI is not even long enough for the package struct we expect then ignore it entirely. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: a1a6a4cf49ec ("iwlwifi: pnvm: implement reading PNVM from UEFI") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20211016114029.33feba783518.I54a5cf33975d0330792b3d208b225d479e168f32@changeid
* iwlwifi: pnvm: don't kmemdup() more than we haveJohannes Berg2021-10-201-4/+3
| | | | | | | | | | | We shouldn't kmemdup() more data than we have, that might cause the code to crash. Fix that by updating the length before the kmemdup. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20211016114029.ab0e64c3fba9.Ic6a3295fc384750b51b4270bf0b7d94984a139f2@changeid
* iwlwifi: change all JnP to NO-160 configurationYaara Baruch2021-10-201-3/+3
| | | | | | | | | JnP should not have the 160 MHz. Signed-off-by: Yaara Baruch <yaara.baruch@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20211016114029.ee163f4a7513.I7f87bd969a0b038c7f3a1a962d9695ffd18c5da1@changeid
* iwlwifi: mvm: reset PM state on unsuccessful resumeJohannes Berg2021-10-201-1/+4
| | | | | | | | | | | | If resume fails for some reason, we need to set the PM state back to normal so we're able to send commands during firmware reset, rather than failing all of them because we're in D3. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: 708a39aaca22 ("iwlwifi: mvm: don't send commands during suspend\resume transition") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20211016114029.7ceb9eaca9f6.If0cbef38c6d07ec1ddce125878a4bdadcb35d2c9@changeid
* Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo2021-10-2025-108/+315
|\ | | | | | | | | | | | | | | | | | | | | | | ath.git patches for v5.16. Major changes: ath9k * add option to reset the wifi chip via debugfs * convert Device Tree bindings to the json-schema * support Device Tree ieee80211-freq-limit property to limit channels
| * ath5k: replace snprintf in show functions with sysfs_emitQing Wang2021-10-181-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | coccicheck complains about the use of snprintf() in sysfs show functions. Fix the coccicheck warning: WARNING: use scnprintf or sprintf. Use sysfs_emit instead of scnprintf or sprintf makes more sense. Signed-off-by: Qing Wang <wangqing@vivo.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1634095651-4273-1-git-send-email-wangqing@vivo.com
| * ath10k: fix max antenna gain unitSven Eckelmann2021-10-132-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most of the txpower for the ath10k firmware is stored as twicepower (0.5 dB steps). This isn't the case for max_antenna_gain - which is still expected by the firmware as dB. The firmware is converting it from dB to the internal (twicepower) representation when it calculates the limits of a channel. This can be seen in tpc_stats when configuring "12" as max_antenna_gain. Instead of the expected 12 (6 dB), the tpc_stats shows 24 (12 dB). Tested on QCA9888 and IPQ4019 with firmware 10.4-3.5.3-00057. Fixes: 02256930d9b8 ("ath10k: use proper tx power unit") Signed-off-by: Sven Eckelmann <seckelmann@datto.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20190611172131.6064-1-sven@narfation.org
| * ath9k: fix an IS_ERR() vs NULL checkDan Carpenter2021-10-131-2/+2
| | | | | | | | | | | | | | | | | | | | The devm_kmemdup() function doesn't return error pointers, it returns NULL on error. Fixes: eb3a97a69be8 ("ath9k: fetch calibration data via nvmem subsystem") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211011123533.GA15188@kili
| * ath11k: Identify DFS channel when sending scan channel list commandBaochen Qiang2021-10-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WMI_CHAN_INFO_DFS flag should be set when configuring a DFS channel included in scan channel list. Without it, firmware will not send a probe request frame which is needed in connection to an AP configured with hidden SSID/network_id. So fix this to allow probe request frames to be sent in cases where a beacon frame has been seen on the channel first. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211011054919.77071-1-bqiang@codeaurora.org
| * ath9k: support DT ieee80211-freq-limit property to limit channelsChristian Lamparter2021-10-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The common DT property can be used to limit the available channels but ath9k has to manually call wiphy_read_of_freq_limits(). I would have put this into ath9k_of_init(). But it didn't work there. The reason is that in ath9k_of_init() the channels and bands are not yet registered in the wiphy struct. So there isn't any channel to flag as disabled. Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211009212847.1781986-1-chunkeey@gmail.com
| * ath11k: Change number of TCL rings to one for QCA6390Baochen Qiang2021-10-117-21/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Some targets, QCA6390 for example, use only one TCL ring, it is better to initialize only one ring and leave others untouched for such targets. This is a theoretical fix found during code review, no visible impact. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914163726.38604-1-jouni@codeaurora.org
| * ath11k: Handle MSI enablement during rmmod and SSRBaochen Qiang2021-10-111-5/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing "rmmod ath11k_pci", ath11k performs global SOC reset and MHI reset, where 0 address access is captured by IOMMU. See log below: ... [ 133.953860] ath11k_pci 0000:02:00.0: setting mhi state: DEINIT(1) [ 133.959714] ath11k_pci 0000:02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000a address=0x0 flags=0x0020] [ 133.973854] ath11k_pci 0000:02:00.0: MHISTATUS 0xff04 [ 133.974095] ath11k_pci 0000:02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000a address=0x0 flags=0x0020] ... This issue is also observed in SSR process, cause a similar sequence as above is performed. Such an invalid access occurs because, during rmmod or SSR, MSI address is cleared but HW MSI functionality not disabled, thus HW target is able to raise an MSI transaction with 0 as MSI address. So it can be fixed by simply disabling MSI before reset. For SSR, since MSI functionality is still needed after target is brought back, we need to reenable it. Also change naming of some interfaces related. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210913180246.193388-5-jouni@codeaurora.org
| * ath: dfs_pattern_detector: Fix possible null-pointer dereference in ↵Tuo Li2021-10-111-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | channel_detector_create() kzalloc() is used to allocate memory for cd->detectors, and if it fails, channel_detector_exit() behind the label fail will be called: channel_detector_exit(dpd, cd); In channel_detector_exit(), cd->detectors is dereferenced through: struct pri_detector *de = cd->detectors[i]; To fix this possible null-pointer dereference, check cd->detectors before the for loop to dereference cd->detectors. Reported-by: TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by: Tuo Li <islituo@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210805153854.154066-1-islituo@gmail.com
| * ath11k: Use kcalloc() instead of kzalloc()Gustavo A. R. Silva2021-10-111-4/+4
| | | | | | | | | | | | | | | | | | | | Use 2-factor multiplication argument form kcalloc() instead of kzalloc(). Link: https://github.com/KSPP/linux/issues/162 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211006181204.GA913553@embeddedor
| * ath11k: Remove redundant assignment to variable fw_sizeColin Ian King2021-10-111-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | Variable fw_size is being assigned a value that is never read and being re-assigned a new value in the next statement. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Fixes: 336e7b53c82f ("ath11k: clean up BDF download functions") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211006105529.1011239-1-colin.king@canonical.com
| * ath11k: Fix spelling mistake "incompaitiblity" -> "incompatibility"Colin Ian King2021-10-071-1/+1
| | | | | | | | | | | | | | | | There is a spelling mistake in an ath11k_warn message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211006083217.349596-1-colin.king@canonical.com
| * ath11k: Remove unused variable in ath11k_dp_rx_mon_merg_msdus()Tim Gardner2021-10-051-9/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Coverity complains that a constant variable guards dead code. In fact, mpdu_buf is set NULL and never updated. 4834err_merge_fail: null: At condition mpdu_buf, the value of mpdu_buf must be NULL. dead_error_condition: The condition mpdu_buf cannot be true. CID 92162 (#1 of 1): 'Constant' variable guards dead code (DEADCODE) dead_error_line: Execution cannot reach the expression decap_format != DP_RX_DECAP_TYPE_RAW inside this statement: if (mpdu_buf && decap_forma.... Local variable mpdu_buf is assigned only once, to a constant value, making it effectively constant throughout its scope. If this is not the intent, examine the logic to see if there is a missing assignment that would make mpdu_buf not remain constant. 4835 if (mpdu_buf && decap_format != DP_RX_DECAP_TYPE_RAW) { Fix this by removing mpdu_buf and unreachable code. Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: ath11k@lists.infradead.org Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210927150743.19816-1-tim.gardner@canonical.com
| * dt-bindings: net: wireless: qca,ath9k: convert to the json-schemaChristian Lamparter2021-10-053-48/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This replaces the existing .txt binding file. Furthermore, this also helps with validating DTS files. Introduced binding changes: 1. added inherited mac-address nvmem property 2. added inherited ieee80211-freq-limit property 3. added new calibration nvmem property 4. added second example (taken from the Netgear WNDR3700v2) Reason: Setting qca,no-eeprom; takes presedence over nvmem-cells. I think a different example is needed, because the driver can only reads from one calibration source per device. 5. (re-added) chip list (based on data from ath9k's pci.c) Added binding .yaml to MAINTAINERS. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210924223509.52525-1-chunkeey@gmail.com
| * ath9k: Fix potential interrupt storm on queue resetLinus Lüssing2021-10-051-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In tests with two Lima boards from 8devices (QCA4531 based) on OpenWrt 19.07 we could force a silent restart of a device with no serial output when we were sending a high amount of UDP traffic (iperf3 at 80 MBit/s in both directions from external hosts, saturating the wifi and causing a load of about 4.5 to 6) and were then triggering an ath9k_queue_reset(). Further debugging showed that the restart was caused by the ath79 watchdog. With disabled watchdog we could observe that the device was constantly going into ath_isr() interrupt handler and was returning early after the ATH_OP_HW_RESET flag test, without clearing any interrupts. Even though ath9k_queue_reset() calls ath9k_hw_kill_interrupts(). With JTAG we could observe the following race condition: 1) ath9k_queue_reset() ... -> ath9k_hw_kill_interrupts() -> set_bit(ATH_OP_HW_RESET, &common->op_flags); ... <- returns 2) ath9k_tasklet() ... -> ath9k_hw_resume_interrupts() ... <- returns 3) loops around: ... handle_int() -> ath_isr() ... -> if (test_bit(ATH_OP_HW_RESET, &common->op_flags)) return IRQ_HANDLED; x) ath_reset_internal(): => never reached <= And in ath_isr() we would typically see the following interrupts / interrupt causes: * status: 0x00111030 or 0x00110030 * async_cause: 2 (AR_INTR_MAC_IPQ) * sync_cause: 0 So the ath9k_tasklet() reenables the ath9k interrupts through ath9k_hw_resume_interrupts() which ath9k_queue_reset() had just disabled. And ath_isr() then keeps firing because it returns IRQ_HANDLED without actually clearing the interrupt. To fix this IRQ storm also clear/disable the interrupts again when we are in reset state. Cc: Sven Eckelmann <sven@narfation.org> Cc: Simon Wunderlich <sw@simonwunderlich.de> Cc: Linus Lüssing <linus.luessing@c0d3.blue> Fixes: 872b5d814f99 ("ath9k: do not access hardware on IRQs during reset") Signed-off-by: Linus Lüssing <ll@simonwunderlich.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914192515.9273-3-linus.luessing@c0d3.blue
| * ath9k: add option to reset the wifi chip via debugfsLinus Lüssing2021-10-052-4/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes, in yet unknown cases the wifi chip stops working. To allow a watchdog in userspace to easily and quickly reset the wifi chip, add the according functionality to userspace. A reset can then be triggered via: $ echo 1 > /sys/kernel/debug/ieee80211/phy0/ath9k/reset The number of user resets can further be tracked in the row "User reset" in the same file. So far people usually used "iw scan" to fix ath9k chip hangs from userspace. Which triggers the ath9k_queue_reset(), too. The reset file however has the advantage of less overhead, which makes debugging bugs within ath9k_queue_reset() easier. Signed-off-by: Linus Lüssing <ll@simonwunderlich.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914192515.9273-2-linus.luessing@c0d3.blue
| * ath10k: Don't always treat modem stop events as crashesStephen Boyd2021-10-053-1/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When rebooting on sc7180 Trogdor devices I see the following crash from the wifi driver. ath10k_snoc 18800000.wifi: firmware crashed! (guid 83493570-29a2-4e98-a83e-70048c47669c) This is because a modem stop event looks just like a firmware crash to the driver, the qmi connection is closed in both cases. Use the qcom ssr notifier block to stop treating the qmi connection close event as a firmware crash signal when the modem hasn't actually crashed. See ath10k_qmi_event_server_exit() for more details. This silences the crash message seen during every reboot. Fixes: 3f14b73c3843 ("ath10k: Enable MSA region dump support for WCN3990") Cc: Youghandhar Chintala <youghand@codeaurora.org> Cc: Abhishek Kumar <kuabhs@chromium.org> Cc: Steev Klimaszewski <steev@kali.org> Cc: Matthias Kaehlcke <mka@chromium.org> Cc: Rakesh Pillai <pillair@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Rakesh Pillai <pillair@codeaurora.org> Tested-By: Youghandhar Chintala <youghand@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210922233341.182624-1-swboyd@chromium.org
* | mwifiex: Deactive host sleep using HSCFG after it was activated manuallyJonas Dreßler2021-10-204-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When powersaving (so either wifi powersaving or deep sleep, depending on which state the firmware is in) is disabled, the way the firmware goes into host sleep is different: Usually the firmware implicitely enters host sleep on the next SLEEP event we get when we configured host sleep via HSCFG before. When powersaving is disabled though, there are no SLEEP events, the way we enter host sleep in that case is different: The firmware will send us a HS_ACT_REQ event and after that we "manually" make the firmware enter host sleep by sending it another HSCFG command with the action HS_ACTIVATE. Now waking up from host sleep appears to be different depending on whether powersaving is enabled again: When powersaving is enabled, the firmware implicitely leaves host sleep as soon as it wakes up and sends us an AWAKE event. When powersaving is disabled though, it apparently doesn't implicitely leave host sleep, but instead we need to send it a HSCFG command with the HS_CONFIGURE action and the HS_CFG_CANCEL condition. We didn't do that so far, which is why waking up from host sleep was broken when powersaving is disabled. So add some additional state to mwifiex_adapter where we keep track of whether host sleep was activated manually via HS_ACTIVATE, and if that was the case, deactivate it manually again via HS_CFG_CANCEL. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211016153244.24353-6-verdre@v0yd.nl
* | mwifiex: Send DELBA requests according to specJonas Dreßler2021-10-201-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While looking at on-air packets using Wireshark, I noticed we're never setting the initiator bit when sending DELBA requests to the AP: While we set the bit on our del_ba_param_set bitmask, we forget to actually copy that bitmask over to the command struct, which means we never actually set the initiator bit. Fix that and copy the bitmask over to the host_cmd_ds_11n_delba command struct. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Acked-by: Pali Rohár <pali@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211016153244.24353-5-verdre@v0yd.nl
* | mwifiex: Fix an incorrect commentJonas Dreßler2021-10-201-1/+1
| | | | | | | | | | | | | | | | We're sending DELBA requests here, not ADDBA requests. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211016153244.24353-4-verdre@v0yd.nl
* | mwifiex: Log an error on command failure during key-material uploadJonas Dreßler2021-10-201-2/+8
| | | | | | | | | | | | | | | | | | | | | | Sometimes the KEY_MATERIAL command can fail with the 88W8897 firmware (when this happens exactly seems pretty random). This appears to prevent the access point from starting, so it seems like a good idea to log an error in that case. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211016153244.24353-3-verdre@v0yd.nl
* | mwifiex: Don't log error on suspend if wake-on-wlan is disabledJonas Dreßler2021-10-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | It's not an error if someone chooses to put their computer to sleep, not wanting it to wake up because the person next door has just discovered what a magic packet is. So change the loglevel of this annoying message from ERROR to INFO. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211016153244.24353-2-verdre@v0yd.nl
* | rtw89: remove unneeded semicolonYang Li2021-10-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Eliminate the following coccicheck warning: ./drivers/net/wireless/realtek/rtw89/pci.c:1348:2-3: Unneeded semicolon Reported-by: Abaci Robot <abaci@linux.alibaba.com> Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1634630094-1156-1-git-send-email-yang.lee@linux.alibaba.com
* | rtw89: fix return value check in rtw89_cam_send_sec_key_cmd()Yang Yingliang2021-10-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Fix the return value check which testing the wrong variable in rtw89_cam_send_sec_key_cmd(). Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211018033102.1813058-1-yangyingliang@huawei.com
* | mwl8k: Fix use-after-free in mwl8k_fw_state_machine()Zheyu Ma2021-10-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the driver fails to request the firmware, it calls its error handler. In the error handler, the driver detaches device from driver first before releasing the firmware, which can cause a use-after-free bug. Fix this by releasing firmware first. The following log reveals it: [ 9.007301 ] BUG: KASAN: use-after-free in mwl8k_fw_state_machine+0x320/0xba0 [ 9.010143 ] Workqueue: events request_firmware_work_func [ 9.010830 ] Call Trace: [ 9.010830 ] dump_stack_lvl+0xa8/0xd1 [ 9.010830 ] print_address_description+0x87/0x3b0 [ 9.010830 ] kasan_report+0x172/0x1c0 [ 9.010830 ] ? mutex_unlock+0xd/0x10 [ 9.010830 ] ? mwl8k_fw_state_machine+0x320/0xba0 [ 9.010830 ] ? mwl8k_fw_state_machine+0x320/0xba0 [ 9.010830 ] __asan_report_load8_noabort+0x14/0x20 [ 9.010830 ] mwl8k_fw_state_machine+0x320/0xba0 [ 9.010830 ] ? mwl8k_load_firmware+0x5f0/0x5f0 [ 9.010830 ] request_firmware_work_func+0x172/0x250 [ 9.010830 ] ? read_lock_is_recursive+0x20/0x20 [ 9.010830 ] ? process_one_work+0x7a1/0x1100 [ 9.010830 ] ? request_firmware_nowait+0x460/0x460 [ 9.010830 ] ? __this_cpu_preempt_check+0x13/0x20 [ 9.010830 ] process_one_work+0x9bb/0x1100 Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1634356979-6211-1-git-send-email-zheyuma97@gmail.com
* | rsi: stop thread firstly in rsi_91x_init() error handlingZiyang Xuan2021-10-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When fail to init coex module, free 'common' and 'adapter' directly, but common->tx_thread which will access 'common' and 'adapter' is running at the same time. That will trigger the UAF bug. ================================================================== BUG: KASAN: use-after-free in rsi_tx_scheduler_thread+0x50f/0x520 [rsi_91x] Read of size 8 at addr ffff8880076dc000 by task Tx-Thread/124777 CPU: 0 PID: 124777 Comm: Tx-Thread Not tainted 5.15.0-rc5+ #19 Call Trace: dump_stack_lvl+0xe2/0x152 print_address_description.constprop.0+0x21/0x140 ? rsi_tx_scheduler_thread+0x50f/0x520 kasan_report.cold+0x7f/0x11b ? rsi_tx_scheduler_thread+0x50f/0x520 rsi_tx_scheduler_thread+0x50f/0x520 ... Freed by task 111873: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x109/0x140 kfree+0x117/0x4c0 rsi_91x_init+0x741/0x8a0 [rsi_91x] rsi_probe+0x9f/0x1750 [rsi_usb] Stop thread before free 'common' and 'adapter' to fix it. Fixes: 2108df3c4b18 ("rsi: add coex support") Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211015040335.1021546-1-william.xuanziyang@huawei.com
* | MAINTAINERS: mt76: update MTK folksRyder Lee2021-10-201-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | Add more MTK folks to actively maintain the wireless chipsets across segments. The work is becoming increasingly complicated and various and we can provides hardware related perspectives to offload Felix's workload, especially for the 11ax and upcoming 11be devices Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Acked-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/eb888ae0e43a980c2c1aaed372a9b5e8098ea4ef.1634107511.git.ryder.lee@mediatek.com
* | rtw89: Remove redundant check of ret after call to rtw89_mac_enable_bb_rfColin Ian King2021-10-181-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | The function rtw89_mac_enable_bb_rf is a void return type, so there is no return error code to ret, so the following check for an error in ret is redundant dead code and can be removed. Addresses-Coverity: ("Logically dead code") Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211015152113.33179-1-colin.king@canonical.com
* | rtw89: Fix two spelling mistakes in debug messagesColin Ian King2021-10-181-2/+2
| | | | | | | | | | | | | | | | | | There are two spelling mistakes in rtw89_debug messages. Fix them. Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211015105004.11817-1-colin.king@canonical.com
* | MAINTAINERS: add rtw89 wireless driverPing-Ke Shih2021-10-181-0/+6
| | | | | | | | | | | | | | | | Add maintainer and email to MAINTAINERS file. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211013092827.43642-1-pkshih@realtek.com
* | mwifiex: Try waking the firmware until we get an interruptJonas Dreßler2021-10-181-5/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems that the PCIe+USB firmware (latest version 15.68.19.p21) of the 88W8897 card sometimes ignores or misses when we try to wake it up by writing to the firmware status register. This leads to the firmware wakeup timeout expiring and the driver resetting the card because we assume the firmware has hung up or crashed. Turns out that the firmware actually didn't hang up, but simply "missed" our wakeup request and didn't send us an interrupt with an AWAKE event. Trying again to read the firmware status register after a short timeout usually makes the firmware wake up as expected, so add a small retry loop to mwifiex_pm_wakeup_card() that looks at the interrupt status to check whether the card woke up. The number of tries and timeout lengths for this were determined experimentally: The firmware usually takes about 500 us to wake up after we attempt to read the status register. In some cases where the firmware is very busy (for example while doing a bluetooth scan) it might even miss our requests for multiple milliseconds, which is why after 15 tries the waiting time gets increased to 10 ms. The maximum number of tries it took to wake the firmware when testing this was around 20, so a maximum number of 50 tries should give us plenty of safety margin. Here's a reproducer for those firmware wakeup failures I've found: 1) Make sure wifi powersaving is enabled (iw dev wlp1s0 set power_save on) 2) Connect to any wifi network (makes firmware go into wifi powersaving mode, not deep sleep) 3) Make sure bluetooth is turned off (to ensure the firmware actually enters powersave mode and doesn't keep the radio active doing bluetooth stuff) 4) To confirm that wifi powersaving is entered ping a device on the LAN, pings should be a few ms higher than without powersaving 5) Run "while true; do iwconfig; sleep 0.0001; done", this wakes and suspends the firmware extremely often 6) Wait until things explode, for me it consistently takes <5 minutes BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681 Cc: stable@vger.kernel.org Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211011133224.15561-3-verdre@v0yd.nl
* | mwifiex: Read a PCI register after writing the TX ring write pointerJonas Dreßler2021-10-181-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On the 88W8897 PCIe+USB card the firmware randomly crashes after setting the TX ring write pointer. The issue is present in the latest firmware version 15.68.19.p21 of the PCIe+USB card. Those firmware crashes can be worked around by reading any PCI register of the card after setting that register, so read the PCI_VENDOR_ID register here. The reason this works is probably because we keep the bus from entering an ASPM state for a bit longer, because that's what causes the cards firmware to crash. This fixes a bug where during RX/TX traffic and with ASPM L1 substates enabled (the specific substates where the issue happens appear to be platform dependent), the firmware crashes and eventually a command timeout appears in the logs. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681 Cc: stable@vger.kernel.org Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211011133224.15561-2-verdre@v0yd.nl
* | wireless: Remove redundant 'flush_workqueue()' callsChristophe JAILLET2021-10-1313-21/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'destroy_workqueue()' already drains the queue before destroying it, so there is no need to flush it explicitly. Remove the redundant 'flush_workqueue()' calls. This was generated with coccinelle: @@ expression E; @@ - flush_workqueue(E); destroy_workqueue(E); Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/0855d51423578ad019c0264dad3fe47a2e8af9c7.1633849511.git.christophe.jaillet@wanadoo.fr
* | mt7601u: Remove redundant initialization of variable retColin Ian King2021-10-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The variable ret is being initialized with a value that is never read, it is assigned later on with a different value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Jakub Kicinski <kubakici@wp.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211007234153.31222-1-colin.king@canonical.com
* | rtlwifi: rtl8192ee: Remove redundant initialization of variable versionColin Ian King2021-10-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The variable version is being initialized with a value that is never read, it is being updated afterwards in both branches of an if statement. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211007163722.20165-1-colin.king@canonical.com
* | rtw89: add Realtek 802.11ax driverPing-Ke Shih2021-10-1341-0/+91102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This driver named rtw89, which is the next generation of rtw88, supports Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC, Spatial reuse, TWT and BSS coloring; now some of them aren't implemented though. The chip architecture is entirely different from the chips supported by rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges are totally redefined, so it's impossible to reuse register definition. To communicate with firmware, new H2C/C2H format is proposed. In order to have better utilization, TX DMA flow is changed to two stages DMA. To provide rich RX status information, additional RX PPDU packets are added. Since there are so many differences mentioned above, we decide to propose a new driver. It has many authors, they are listed in alphabetic order: Chin-Yen Lee <timlee@realtek.com> Ping-Ke Shih <pkshih@realtek.com> Po Hao Huang <phhuang@realtek.com> Tzu-En Huang <tehuang@realtek.com> Vincent Fann <vincent_fann@realtek.com> Yan-Hsuan Chuang <tony0620emma@gmail.com> Zong-Zhe Yang <kevin_yang@realtek.com> Tested-by: Aaron Ma <aaron.ma@canonical.com> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-15 10:51:12 +0100