- 15 Nov, 2021 9 commits
-
-
P Praneesh authored
In data path, to reduce the CPU cycles spending on descriptor access wrapper function, changed those functions as static inline. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1.r2-00012-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01695-QCAHKSWPL_SILICONZ-1 Co-developed-by:
Sriram R <srirrama@codeaurora.org> Signed-off-by:
Jouni Malinen <jouni@codeaurora.org> Signed-off-by:
P Praneesh <ppranees@codeaurora.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1630560820-21905-4-git-send-email-ppranees@codeaurora.org
-
P Praneesh authored
tcl_data and reo_dst rings are currently being allocated using dma_allocate_coherent() which is non cacheable. Allocating ring memory from cacheable memory area allows cached descriptor access and prefetch next descriptors to optimize CPU usage during descriptor processing on NAPI. Based on the hardware param we can enable or disable this feature for the corresponding platform. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1.r2-00012-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01695-QCAHKSWPL_SILICONZ-1 Co-developed-by:
Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> Signed-off-by:
-
P Praneesh authored
Host driver doesn't need to process CE8 interrupts (used by target independently) The volume of interrupts is huge within short interval, CPU0 CPU1 CPU2 CPU3 14022188 0 0 0 GIC 71 Edge ce8 Hence disabling unused CE8 interrupt will improve CPU usage. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1.r2-00012-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01695-QCAHKSWPL_SILICONZ-1 Co-developed-by:
-
Venkateswara Naralasetty authored
Currently the updated bandwidth for the peer will be configured to the firmware after channel switch from the sta_rc_update_wk. If the updated bandwidth is greater than the configured peer phymode during the peer assoc may result firmware assert. For example, initially AP is in HE40 mode and the peer phymode is configured as MODE_11AX_HE40 during peer assoc. Now user change the channel width to HE80 then, the peer bandwidth will be updated as HE80 to the firmware. This will trigger firmware assert due to peer bandwidth is greater than the peer phymode. Fix this issue by sending peer assoc command before setting the updated peer bandwith to firmware. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Venkateswara Naralasetty <quic_vnaralas@quicinc.com> Signed-off-by:
-
Seevalamuthu Mariappan authored
Below compilation error is reported when built with W=1, drivers/net/wireless/ath/ath11k/mac.c:5408:22: error: parameter 'changed_flags' set but not used [-Werror,-Wunused-but-set-parameter] changed_flags is set, but left unused. So, remove unnecessary set. Compile tested only. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Seevalamuthu Mariappan <quic_seevalam@quicinc.com> Signed-off-by:
-
Karthikeyan Periyasamy authored
In CE pipe cleanup, DMA memory gets freed by the aligned address (base_addr_owner_space) which is wrong. It needs to be freed by the address (base_addr_owner_space_unaligned) returned by dma_alloc. So free the dma memory by the proper address. This was found in code review. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-00729-QCAHKSWPL_SILICONZ-3 v2 Signed-off-by:
Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Signed-off-by:
-
Karthikeyan Periyasamy authored
In STA kickout event processing, the peer object is protected under spin lock BH. Release this lock after picking up the vdev_id from the peer object instead after ieee80211_report_low_ack(). This will minimize the lock hold period which will improve performance since base_lock is used across the data path. This was found in code review. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-00729-QCAHKSWPL_SILICONZ-3 v2 Signed-off-by:
-
Karthikeyan Periyasamy authored
When there is an error in add interface process from ath11k_mac_set_kickout(), the code attempts to handle a fallback for add_interface. When this fallback succeeds, the driver returns zero rather than error code. This leads to success for the non created VAP. In cleanup, driver gets remove interface callback for the non created VAP and proceeds to self peer delete request which leads to FW assert. Since it was already deleted on the fallback of add interface, return the actual error code instead of fallback return code. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-00729-QCAHKSWPL_SILICONZ-3 v2 Signed-off-by:
-
Karthikeyan Periyasamy authored
Firmware expects host to authorize the peer after the successful key install. But host authorize the peer before the key install, this trigger the firmware assert which leads to Q6 crash. To avoid this Q6 crash, host should authorize the peer after the key install. So introduce is_authorized in peer object to identify that peer is authorize or not. When IEEE80211_STA_CONTROL_PORT flag is unset, peer move to authorize state before the vdev up. When the same flag is set then peer move to authorize state after vdev up. So added authorise check in ath11k_bss_assoc() to handle the earlier state transition case. Also added the WMI authorize procedure in ath11k_mac_op_sta_state() to handle the non-earlier state transition case. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01492-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
- 12 Nov, 2021 3 commits
-
-
Rameshkumar Sundaram authored
AUTH flag is needed when peer assoc command is sent from host in security mode for non-assoc cases. Firmware will handle AUTH flag when client is associating as AUTH flag will be set after key exchange. For internally provided peer assoc commands from host, there won't be any key exchange, so AUTH flag is expected to be set in host. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01838-QCAHKSWPL_SILICONZ-1 Co-developed-by:
Lavanya Suresh <lavaks@codeaurora.org> Signed-off-by:
Rameshkumar Sundaram <quic_ramess@quicinc.com> Signed-off-by:
-
Rameshkumar Sundaram authored
HTT_PPDU_STATS_CFG_PDEV_ID bit mask for target FW PPDU stats request message was set as bit 8 to 15. Bit 8 is reserved for soc stats and pdev id starts from bit 9. Hence change the bitmask as bit 9 to 15 and fill the proper pdev id in the request message. In commit 701e48a4 ("ath11k: add packet log support for QCA6390"), both HTT_PPDU_STATS_CFG_PDEV_ID and pdev_mask were changed, but this pdev_mask calculation is not valid for platforms which has multiple pdevs with 1 rxdma per pdev, as this is writing same value(i.e. 2) for all pdevs. Hence fixed it to consider pdev_idx as well, to make it compatible for both single and multi pd cases. Tested on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01092-QCAHKSWPL_SILICONZ-1 Tested on: IPQ6018 hw1.0 WLAN.HK.2.5.0.1-01067-QCAHKSWPL_SILICONZ-1 Fixes: 701e48a4 ("ath11k: add packet log support for QCA6390") Co-developed-by:
Sathishkumar Muruganandam <murugana@codeaurora.org> Signed-off-by:
Rameshkumar Sundaram <ramess@codeaurora.org> Signed-off-by:
-
Zekun Shen authored
Unexpected WDCMSG_TARGET_START replay can lead to null-ptr-deref when ar->tx_cmd->odata is NULL. The patch adds a null check to prevent such case. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] ar5523_cmd+0x46a/0x581 [ar5523] ar5523_probe.cold+0x1b7/0x18da [ar5523] ? ar5523_cmd_rx_cb+0x7a0/0x7a0 [ar5523] ? __pm_runtime_set_status+0x54a/0x8f0 ? _raw_spin_trylock_bh+0x120/0x120 ? pm_runtime_barrier+0x220/0x220 ? __pm_runtime_resume+0xb1/0xf0 usb_probe_interface+0x25b/0x710 really_probe+0x209/0x5d0 driver_probe_device+0xc6/0x1b0 device_driver_attach+0xe2/0x120 I found the bug using a custome USBFuzz port. It's a research work to fuzz USB stack/drivers. I modified it to fuzz ath9k driver only, providing hand-crafted usb descriptors to QEMU. After fixing the code (fourth byte in usb packet) to WDCMSG_TARGET_START, I got the null-ptr-deref bug. I believe the bug is triggerable whenever cmd->odata is NULL. After patching, I tested with the same input and no longer see the KASAN report. This was NOT tested on a real device. Signed-off-by:
Zekun Shen <bruceshenzk@gmail.com> Signed-off-by:
-
- 10 Nov, 2021 2 commits
-
-
Carl Huang authored
To reduce power consumption enable 802.11 power save mode in station mode. This allows both radio and CPU to sleep more. Only enable the mode on QCA6390 and WCN6855, it's unknown how other hardware families support this feature. To test that power save mode is running run "iw dev wls1 set power_save off", check there is no NULL Data frame seen by a sniffer. And run "iw dev wls1 set power_save on" and check there is a NULL Data frame in sniffer. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by:
Carl Huang <cjhuang@codeaurora.org> Signed-off-by:
-
Kalle Valo authored
It's more descriptive to use the actual enum used by the firmware instead of a boolean so change ath11k_wmi_pdev_set_ps_mode() to use a boolean. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by:
-
- 08 Nov, 2021 5 commits
-
-
Benjamin Li authored
The linear mapping between the BD rate field and the driver's 5GHz legacy rates table (wcn_5ghz_rates) does not only apply for the latter four rates -- it applies to all eight rates. Fixes: 6ea131ac ("wcn36xx: Fix warning due to bad rate_idx") Signed-off-by:
Benjamin Li <benl@squareup.com> Tested-by:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
Benjamin Li authored
status.band is used in determination of status.rate -- for 5GHz on legacy rates there is a linear shift between the BD descriptor's rate field and the wcn36xx driver's rate table (wcn_5ghz_rates). We have a special clause to populate status.band for hardware scan offload frames. However, this block occurs after status.rate is already populated. Correctly handle this dependency by moving the band block before the rate block. This patch addresses kernel warnings & missing scan results for 5GHz APs that send their beacons/probe responses at the higher four legacy rates (24-54 Mbps), when using hardware scan offload: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:4532 ieee80211_rx_napi+0x744/0x8d8 Modules linked in: wcn36xx [...] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.19.107-g73909fa #1 Hardware name: Square, Inc. T2 (all variants) (DT) Call trace: dump_backtrace+0x0/0x148 show_stack+0x14/0x1c dump_stack+0xb8/0xf0 __warn+0x2ac/0x2d8 warn_slowpath_null+0x44/0x54 ieee80211_rx_napi+0x744/0x8d8 ieee80211_tasklet_handler+0xa4/0xe0 tasklet_action_common+0xe0/0x118 tasklet_action+0x20/0x28 __do_softirq+0x108/0x1ec irq_exit+0xd4/0xd8 __handle_domain_irq+0x84/0xbc gic_handle_irq+0x4c/0xb8 el1_irq+0xe8/0x190 lpm_cpuidle_enter+0x220/0x260 cpuidle_enter_state+0x114/0x1c0 cpuidle_enter+0x34/0x48 do_idle+0x150/0x268 cpu_startup_entry+0x20/0x24 rest_init+0xd4/0xe0 start_kernel+0x398/0x430 ---[ end trace ae28cb759352b403 ]--- Fixes: 8a27ca39 ("wcn36xx: Correct band/freq reporting on RX") Signed-off-by:
-
Bryan O'Donoghue authored
When deiniting the DXE hardware we should reset the block to ensure there is no spurious DMA write transaction from the downstream WCNSS to upstream MSM at a skbuff address we will have released. Fixes: 8e84c258 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by:
-
Bryan O'Donoghue authored
When unloading the driver we are not releasing the DMA descriptors which we previously allocated. Fixes: 8e84c258 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by:
-
Bryan O'Donoghue authored
Right now we have a broken sequence where we enable DMA channel interrupts which can be left enabled and never disabled if we hit an error path. Worse still when we unload the driver, the DMA channel interrupt bits are left intact. About the only saving grace here is that we do remember to disable the wcnss interrupt when unload the driver. Fixes: 8e84c258 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by:
-
- 01 Nov, 2021 7 commits
-
-
Yang Guang authored
Using swap() make it more readable. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Yang Guang <yang.guang5@zte.com.cn> Signed-off-by:
-
Bryan O'Donoghue authored
Firmware can trigger a missed beacon indication, this is not the same as a lost signal. Flag to Linux the missed beacon and let the WiFi stack decide for itself if the link is up or down by sending its own probe to determine this. We should only be signalling the link is lost when the firmware indicates Fixes: 8e84c258 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by:
-
Benjamin Li authored
An SMD capture from the downstream prima driver on WCN3680B shows the following command sequence for connected scans: - init_scan_req - start_scan_req, channel 1 - end_scan_req, channel 1 - start_scan_req, channel 2 - ... - end_scan_req, channel 3 - finish_scan_req - init_scan_req - start_scan_req, channel 4 - ... - end_scan_req, channel 6 - finish_scan_req - ... - end_scan_req, channel 165 - finish_scan_req Upstream currently never calls wcn36xx_smd_end_scan, and in some cases[1] still sends finish_scan_req twice in a row or before init_scan_req. A typical connected scan looks like this: - init_scan_req - start_scan_req, channel 1 - finish_scan_req - init_scan_req - start_scan_req, channel 2 - ... - start_scan_req, channel 165 - finish_scan_req - finish_scan_req This patch cleans up scanning so that init/finish and start/end are always paired together and correctly nested. - init_scan_req - start_scan_req, channel 1 - end_scan_req, channel 1 - finish_scan_req - init_scan_req - start_scan_req, channel 2 - end_scan_req, channel 2 - ... - start_scan_req, channel 165 - end_scan_req, channel 165 - finish_scan_req Note that upstream will not do batching of 3 active-probe scans before returning to the operating channel, and this patch does not change that. To match downstream in this aspect, adjust IEEE80211_PROBE_DELAY and/or the 125ms max off-channel time in ieee80211_scan_state_decision. [1]: commit d195d7aa ("wcn36xx: Ensure finish scan is not requested before start scan") addressed one case of finish_scan_req being sent without a preceding init_scan_req (the case of the operating channel coinciding with the first scan channel); two other cases are: 1) if SW scan is started and aborted immediately, without scanning any channels, we send a finish_scan_req without ever sending init_scan_req, and 2) as SW scan logic always returns us to the operating channel before calling wcn36xx_sw_scan_complete, finish_scan_req is always sent twice at the end of a SW scan Fixes: 8e84c258 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: -
Benjamin Li authored
Without ieee80211_ops->flush implemented to empty HW queues, mac80211 will do a 100ms dead wait after stopping SW queues, before leaving the operating channel to resume a software connected scan[1]. (see ieee80211_scan_state_resume) This wait is correctly included in the calculation for whether or not we've exceeded max off-channel time, as it occurs after sending the null frame with PS bit set. Thus, with 125 ms max off-channel time we only have 25 ms of scan time, which technically isn't even enough to scan one channel (although mac80211 always scans at least one channel per off- channel window). Moreover, for passive probes we end up spending at least 100 ms + 111 ms (IEEE80211_PASSIVE_CHANNEL_TIME) "off-channel"[2], which exceeds the listen interval of 200 ms that we provide in our association request frame. That's technically out-of-spec. [1]: Until recently, wcn36xx performed software (rather than FW-offloaded) scanning when 5GHz channels are requested. This apparent limitation is now resolved -- see commit 1395f8a6a4d5 ("wcn36xx: Enable hardware scan offload for 5Ghz band"). [2]: in quotes because about 100 ms of it is still on-channel but with PS set Signed-off-by: -
Benjamin Li authored
Add some MAC debug prints for more easily demarcating a software scan when parsing logs. Signed-off-by:
-
Christian Lamparter authored
ATH10K chips are used it wide range of routers, accesspoints, range extenders, network appliances. On these embedded devices, calibration data is often stored on the main system's flash and was out of reach for the driver. To bridge this gap, ath10k is getting extended to pull the (pre-)calibration data through nvmem subsystem. To do this, a nvmem-cell containing the information can either be specified in the platform data or via device-tree. Tested with: Netgear EX6150v2 (IPQ4018 - pre-calibration method) TP-Link Archer C7 v2 (QCA9880v2 - old calibration method) Cc: Robert Marko <robimarko@gmail.com> Cc: Thibaut VARÈNE <hacks@slashdirt.org> Signed-off-by:Christian Lamparter <chunkeey@gmail.com> Signed-off-by:
-
Wen Gong authored
Commit 6f4d7030 ("ath11k: support SMPS configuration for 6 GHz") changed "if (ht_cap & WMI_HT_CAP_DYNAMIC_SMPS)" to "if (ht_cap & WMI_HT_CAP_DYNAMIC_SMPS || ar->supports_6ghz)" which means NL80211_FEATURE_DYNAMIC_SMPS is enabled for all chips which support 6 GHz. However, WCN6855 supports 6 GHz but it does not support feature NL80211_FEATURE_DYNAMIC_SMPS, and this can lead to MU-MIMO test failures for WCN6855. Disable NL80211_FEATURE_DYNAMIC_SMPS for WCN6855 since its ht_cap does not support WMI_HT_CAP_DYNAMIC_SMPS. Enable the feature only on QCN9074 as that's the only other device supporting 6 GHz band. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by:
Wen Gong <wgong@codeaurora.org> Signed-off-by:
-
- 28 Oct, 2021 7 commits
-
-
Johan Hovold authored
Add the missing endpoint max-packet sanity check to probe() to avoid division by zero in ath10k_usb_hif_tx_sg() in case a malicious device has broken descriptors (or when doing descriptor fuzz testing). Note that USB core will reject URBs submitted for endpoints with zero wMaxPacketSize but that drivers doing packet-size calculations still need to handle this (cf. commit 2548288b ("USB: Fix: Don't skip endpoint descriptors with maxpacket=0")). Fixes: 9cbee358 ("ath6kl: add full USB support") Cc: stable@vger.kernel.org # 3.5 Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
Add the missing endpoint max-packet sanity check to probe() to avoid division by zero in ath10k_usb_hif_tx_sg() in case a malicious device has broken descriptors (or when doing descriptor fuzz testing). Note that USB core will reject URBs submitted for endpoints with zero wMaxPacketSize but that drivers doing packet-size calculations still need to handle this (cf. commit 2548288b ("USB: Fix: Don't skip endpoint descriptors with maxpacket=0")). Fixes: 4db66499 ("ath10k: add initial USB support") Cc: stable@vger.kernel.org # 4.14 Cc: Erik Stromdahl <erik.stromdahl@gmail.com> Signed-off-by:
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 241b128b ("ath6kl: add back beginnings of USB support") Cc: stable@vger.kernel.org # 3.4 Signed-off-by:
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 4db66499 ("ath10k: add initial USB support") Cc: stable@vger.kernel.org # 4.14 Cc: Erik Stromdahl <erik.stromdahl@gmail.com> Signed-off-by:
-
Benjamin Li authored
The official feature-complete WCN3680B driver (known as prima, open source but not upstream) supports channels 136 and 144. However, these channels are missing in upstream. Add them here to get closer to feature parity with prima. Signed-off-by:
-
Benjamin Li authored
The official feature-complete WCN3680B driver (known as prima, open source but not upstream) sends this feature bit. As we wish to support the antenna diversity feature in upstream, we need to set this bit as well. Signed-off-by:
-
Loic Poulain authored
The channel scan list must be updated before triggering a hardware scan so that firmware takes into account the regulatory info for each single channel such as active/passive config, power, DFS, etc... Without this the firmware uses its own internal default channel configuration, which is not aligned with mac80211 regulatory rules, and misses several channels (e.g. 144). Fixes: 2f3bef4b ("wcn36xx: Add hardware scan offload support") Signed-off-by:
-
- 27 Oct, 2021 7 commits
-
-
Bryan O'Donoghue authored
Firmware link offload monitoring can be made to work in 3/4 cases by switching on firmware feature bit WLANACTIVE_OFFLOAD - Secure power-save on - Secure power-save off - Open power-save on However, with an open AP if we switch off power-saving - thus never entering Beacon Mode Power Save - BMPS, firmware never forwards loss of beacon upwards. We had hoped that WLANACTIVE_OFFLOAD and some fixes for sequence numbers would unblock this but, it hasn't and further investigation is required. Its possible to have a complete set of Secure power-save on/off and Open power-save on/off provided we use Linux' link monitoring mechanism. While we debug the Open AP failure we need to fix upstream. This reverts commit c973fdad79f6eaf247d48b5fc77733e989eb01e1. Signed-off-by:
-
Loic Poulain authored
If the system is resumed because of an incoming packet, the wcn36xx RX interrupts is fired before actual resuming of the wireless/mac80211 stack, causing any received packets to be simply dropped. E.g. a ping request causes a system resume, but is dropped and so never forwarded to the IP stack. This change fixes that, disabling DMA interrupts on suspend to no pass packets until mac80211 is resumed and ready to handle them. Note that it's not incompatible with RX irq wake. Signed-off-by:
-
Loic Poulain authored
The firmware is offering features such as ARP offload, for which firmware crafts its own (QoS)packets without waking up the host. Point is that the sequence numbers generated by the firmware are not in sync with the host mac80211 layer and can cause packets such as firmware ARP reponses to be dropped by the AP (too old SN). To fix this we need to let the firmware manages the sequence numbers by its own (except for QoS null frames). There is a SN counter for each QoS queue and one global/baseline counter for Non-QoS. Fixes: 84aff52e ("wcn36xx: Use sequence number allocated by mac80211") Signed-off-by:
-
Benjamin Li authored
This is essentially exactly following the dma_wmb()/dma_rmb() usage instructions in Documentation/memory-barriers.txt. The theoretical races here are: 1. DXE (the DMA Transfer Engine in the Wi-Fi subsystem) seeing the dxe->ctrl & WCN36xx_DXE_CTRL_VLD write before the dxe->dst_addr_l write, thus performing DMA into the wrong address. 2. CPU reading dxe->dst_addr_l before DXE unsets dxe->ctrl & WCN36xx_DXE_CTRL_VLD. This should generally be harmless since DXE doesn't write dxe->dst_addr_l (no risk of freeing the wrong skb). Fixes: 8e84c258 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by:
-
Loic Poulain authored
All wcn36xx controllers are supposed to support HT40 (and SGI40), This doubles the maximum bitrate/throughput with compatible APs. Tested with wcn3620 & wcn3680B. Cc: stable@vger.kernel.org Fixes: 8e84c258 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by:
-
Bryan O'Donoghue authored
This reverts commit c6522a50. Testing on tip-of-tree shows that this is working now. Revert this and re-enable BMPS for Open APs. Signed-off-by:
-
Bryan O'Donoghue authored
On an open AP when you pull the plug on the AP, if we are not already in BMPS mode then the firmware will not generate a disconnection event. Instead we need to monitor for failure to enter BMPS and treat a string of failures as connection loss. Secure AP connections don't appear to demonstrate this behavior so the work-around is limited to open APs only. Signed-off-by:
-
