summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/ath/wcn36xx
AgeCommit message (Collapse)AuthorFilesLines
2022-05-03Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo1-3/+3
ath.git patches for v5.19. Major changes: ath11k * support setting Specific Absorption Rate (SAR) for WCN6855 * read country code from SMBIOS for WCN6855/QCA6390 * support for WCN6750
2022-04-12wcn36xx: clean up some inconsistent indentingYang Li1-3/+3
Eliminate the follow smatch warning: drivers/net/wireless/ath/wcn36xx/smd.c:3151 wcn36xx_smd_gtk_offload_get_info_rsp() warn: inconsistent indenting Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Acked-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220408000113.129906-1-yang.lee@linux.alibaba.com
2022-04-11mac80211: prepare sta handling for MLO supportSriram R2-25/+28
Currently in mac80211 each STA object is represented using sta_info datastructure with the associated STA specific information and drivers access ieee80211_sta part of it. With MLO (Multi Link Operation) support being added in 802.11be standard, though the association is logically with a single Multi Link capable STA, at the physical level communication can happen via different advertised links (uniquely identified by Channel, operating class, BSSID) and hence the need to handle multiple link STA parameters within a composite sta_info object called the MLD STA. The different link STA part of MLD STA are identified using the link address which can be same or different as the MLD STA address and unique link id based on the link vif. To support extension of such a model, the sta_info datastructure is modified to hold multiple link STA objects with link specific params currently within sta_info moved to this new structure. Similarly this is done for ieee80211_sta as well which will be accessed within mac80211 as well as by drivers, hence trivial driver changes are expected to support this. For current non MLO supported drivers, only one link STA is present and link information is accessed via 'deflink' member. For MLO drivers, we still need to define the APIs etc. to get the correct link ID and access the correct part of the station info. Currently in mac80211, all link STA info are accessed directly via deflink. These will be updated to access via link pointers indexed by link id with MLO support patches, with link id being 0 for non MLO supported cases. Except for couple of macro related changes, below spatch takes care of updating mac80211 and driver code to access to the link STA info via deflink. @ieee80211_sta@ struct ieee80211_sta *s; struct sta_info *si; identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr}; @@ ( s-> - var + deflink.var | si->sta. - var + deflink.var ) @sta_info@ struct sta_info *si; identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth}; @@ ( si-> - var + deflink.var ) Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com [remove MLO-drivers notes from commit message, not clear yet; run spatch] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-01wcn36xx: Improve readability of wcn36xx_caps_nameBenjamin Stürz1-61/+65
Use macros to force strict ordering of the elements. Signed-off-by: Benjamin Stürz <benni@stuerz.xyz> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220328212912.283393-1-benni@stuerz.xyz
2022-03-30wcn36xx: Implement tx_rate reportingEdmond Gagnon6-1/+111
Currently, the driver reports a tx_rate of 6.0 MBit/s no matter the true rate: root@linaro-developer:~# iw wlan0 link Connected to 6c:f3:7f:eb:9b:92 (on wlan0) SSID: SQ-DEVICETEST freq: 5200 RX: 4141 bytes (32 packets) TX: 2082 bytes (15 packets) signal: -77 dBm rx bitrate: 135.0 MBit/s MCS 6 40MHz short GI tx bitrate: 6.0 MBit/s bss flags: short-slot-time dtim period: 1 beacon int: 100 This patch requests HAL_GLOBAL_CLASS_A_STATS_INFO via a hal_get_stats firmware message and reports it via ieee80211_ops::sta_statistics. root@linaro-developer:~# iw wlan0 link Connected to 6c:f3:7f:eb:73:b2 (on wlan0) SSID: SQ-DEVICETEST freq: 5700 RX: 26788094 bytes (19859 packets) TX: 1101376 bytes (12119 packets) signal: -75 dBm rx bitrate: 135.0 MBit/s MCS 6 40MHz short GI tx bitrate: 108.0 MBit/s VHT-MCS 5 40MHz VHT-NSS 1 bss flags: short-slot-time dtim period: 1 beacon int: 100 Tested on MSM8939 with WCN3680B running firmware CNSS-PR-2-0-1-2-c1-00083, and verified by sniffing frames over the air with Wireshark to ensure the MCS indices match. Signed-off-by: Edmond Gagnon <egagnon@squareup.com> Reviewed-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220325224212.159690-1-egagnon@squareup.com
2022-02-14wcn36xx: use struct_size over open coded arithmeticMinghao Chi (CGEL ZTE)1-1/+1
Replace zero-length array with flexible-array member and make use of the struct_size() helper in kmalloc(). For example: struct wcn36xx_hal_ind_msg { struct list_head list; size_t msg_len; u8 msg[]; }; Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi (CGEL ZTE) <chi.minghao@zte.com.cn> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220208015606.1514022-1-chi.minghao@zte.com.cn
2022-02-10wcn36xx: Uninitialized variable in wcn36xx_change_opchannel()Dan Carpenter1-1/+1
This code needs "channel" to be initialized to NULL for it to work correctly. Fixes: d6f2746691cb ("wcn36xx: Track the band and channel we are tuned to") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Bryan O'Donoghue <bryan.odonghue@linaro.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220201125941.GA22458@kili
2022-02-03wcn36xx: clean up some inconsistent indentingYang Li2-7/+7
Eliminate the follow smatch warnings: drivers/net/wireless/ath/wcn36xx/main.c:1394 wcn36xx_get_survey() warn: inconsistent indenting drivers/net/wireless/ath/wcn36xx/txrx.c:379 wcn36xx_rx_skb() warn: inconsistent indenting Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220201041548.18464-1-yang.lee@linux.alibaba.com
2022-01-31wcn36xx: Differentiate wcn3660 from wcn3620Bryan O'Donoghue2-0/+4
The spread of capability between the three WiFi silicon parts wcn36xx supports is: wcn3620 - 802.11 a/b/g wcn3660 - 802.11 a/b/g/n wcn3680 - 802.11 a/b/g/n/ac We currently treat wcn3660 as wcn3620 thus limiting it to 2GHz channels. Fix this regression by ensuring we differentiate between all three parts. Fixes: 8490987bdb9a ("wcn36xx: Hook and identify RF_IRIS_WCN3680") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220125004046.4058284-1-bryan.odonoghue@linaro.org
2022-01-19wcn36xx: Add SNR reporting via get_survey()Bryan O'Donoghue1-0/+44
Add support for get_survey() reporting. Current channel and noise-floor are reported, other parameters such as scan, busy, TX and RX time are not immediately available. Noise is a useful metric to report, so bring it out now. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220115001646.3981501-5-bryan.odonoghue@linaro.org
2022-01-19wcn36xx: Track SNR and RSSI for each RX frameBryan O'Donoghue3-0/+53
The BDs for each RX frame contain both the RSSI and SNR for the received frame. If we track and store this information it can be useful to us in get_survey() and potentially elsewhere. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220115001646.3981501-4-bryan.odonoghue@linaro.org
2022-01-19wcn36xx: Track the band and channel we are tuned toBryan O'Donoghue2-0/+30
Track the band and channel we are currently tuned to by way of pointers to the standard structures that describe them both embedded within the driver. Tracking of the pair makes it much easier when implementing ieee80211_ops->get_survey to return quickly captured metrics for the currently tuned channel. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220115001646.3981501-3-bryan.odonoghue@linaro.org
2022-01-19wcn36xx: Implement get_snr()Bryan O'Donoghue1-0/+5
The wcn36xx BD phy descriptor returns both Received Signal Strength Information (RSSI) and Signal To Noise Ratio (SNR) with each delivered BD. The macro to extract this data is a simple-one liner, easily imported from prima driver. This data will be useful to us when implementing mac80211-ops->get_survey(). Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220115001646.3981501-2-bryan.odonoghue@linaro.org
2022-01-17wcn36xx: Use platform_get_irq_byname() to get the interruptLad Prabhakar1-13/+8
platform_get_resource_byname(pdev, IORESOURCE_IRQ, ..) relies on static allocation of IRQ resources in DT core code, this causes an issue when using hierarchical interrupt domains using "interrupts" property in the node as this bypasses the hierarchical setup and messes up the irq chaining. In preparation for removal of static setup of IRQ resource from DT core code use platform_get_irq_byname(). Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211224192626.15843-7-prabhakar.mahadev-lad.rj@bp.renesas.com
2021-12-16wcn36xx: Implement beacon filteringBryan O'Donoghue4-0/+107
The prima driver facilitates the direct programming of beacon filter tables via SMD commands. The purpose of beacon filters is quote: /* When beacon filtering is enabled, firmware will * analyze the selected beacons received during BMPS, * and monitor any changes in the IEs as listed below. * The format of the table is: * - EID * - Check for IE presence * - Byte offset * - Byte value * - Bit Mask * - Byte reference */ The default filter table looks something like this: tBeaconFilterIe gaBcnFilterTable[12] = { { WLAN_EID_DS_PARAMS, 0u, { 0u, 0u, 0u, 0u } }, { WLAN_EID_ERP_INFO, 0u, { 0u, 0u, 248u, 0u } }, { WLAN_EID_EDCA_PARAM_SET, 0u, { 0u, 0u, 240u, 0u } }, { WLAN_EID_QOS_CAPA, 0u, { 0u, 0u, 240u, 0u } }, { WLAN_EID_CHANNEL_SWITCH, 1u, { 0u, 0u, 0u, 0u } }, { WLAN_EID_QUIET, 1u, { 0u, 0u, 0u, 0u } }, { WLAN_EID_HT_OPERATION, 0u, { 0u, 0u, 0u, 0u } }, { WLAN_EID_HT_OPERATION, 0u, { 1u, 0u, 248u, 0u } }, { WLAN_EID_HT_OPERATION, 0u, { 2u, 0u, 235u, 0u } }, { WLAN_EID_HT_OPERATION, 0u, { 5u, 0u, 253u, 0u } }, { WLAN_EID_PWR_CONSTRAINT, 0u, { 0u, 0u, 0u, 0u } }, { WLAN_EID_OPMODE_NOTIF, 0u, { 0u, 0u, 0u, 0u } } }; Add in an equivalent filter set as present in the prima Linux driver. For now omit the beacon filter "rem" command as the driver does not have an explicit call to that SMD command. The filter mask should only count when we are inside BMPS anyway. Replicating the ability to program the filter table gives us scope to add and remove elements in future. For now though this patch makes the rote-copy of the downstream Linux beacon filter table, which we can tweak as desired from now on. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211214134630.2214840-4-bryan.odonoghue@linaro.org
2021-12-16wcn36xx: Fix physical location of beacon filter commentBryan O'Donoghue1-3/+4
The comment in the header with respect to beacon filtering makes a reference to "the structure above" and "the structure below" which would be informative if the comment appeared in the right place but, it does not. Fix the comment location so that it a least makes sense w/r/t the physical location statements. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211214134630.2214840-3-bryan.odonoghue@linaro.org
2021-12-16wcn36xx: Fix beacon filter structure definitionsBryan O'Donoghue1-3/+3
The beacon filter structures need to be packed. Right now its fine because we don't yet use these structures so just pack them without marking it for backporting. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211214134630.2214840-2-bryan.odonoghue@linaro.org
2021-12-08wcn36xx: Fix max channels retrievalLoic Poulain1-1/+1
Kernel test robot reported:drivers/net/wireless/ath/wcn36xx/smd.c:943:33: sparse: sparse: cast truncates bits from constant value (780 becomes 80) The 'channels' field is not a simple u8 array but an array of channel_params. Using sizeof for retrieving the max number of channels is then wrong. In practice, it was not an issue, because the sizeof returned value is 780, which is truncated in min_t (u8) to 80, which is the value we expect... Fix that properly using ARRAY_SIZE instead of sizeof. Fixes: d707f812bb05 ("wcn36xx: Channel list update before hardware scan") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1638435732-14657-1-git-send-email-loic.poulain@linaro.org
2021-11-26wcn36xx: Use correct SSN for ADD BA requestLoic Poulain3-10/+44
Since firmware uses its own sequence number counters, we need to use firmware number as well when mac80211 generates the ADD_BA request packet. Indeed the firmware sequence counters tend to slightly drift from the mac80211 ones because of firmware offload features like ARP responses. This causes the starting sequence number field of the ADD_BA request to be unaligned, and can possibly cause issues with strict/picky APs. To fix this, we retrieve the current firmware sequence number for a given TID through the smd_trigger_ba API, and use that number as replacement of the mac80211 starting sequence number. This change also ensures that any issue in the smd *ba procedures will cause the ba action to properly fail, and remove useless call to smd_trigger_ba() from IEEE80211_AMPDU_RX_START. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1637604251-11763-1-git-send-email-loic.poulain@linaro.org
2021-11-08wcn36xx: fix RX BD rate mapping for 5GHz legacy ratesBenjamin Li1-3/+1
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: 6ea131acea98 ("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: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211104010548.1107405-3-benl@squareup.com
2021-11-08wcn36xx: populate band before determining rate on RXBenjamin Li1-18/+19
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: 8a27ca394782 ("wcn36xx: Correct band/freq reporting on RX") Signed-off-by: Benjamin Li <benl@squareup.com> Tested-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211104010548.1107405-2-benl@squareup.com
2021-11-08wcn36xx: Put DXE block into reset before freeing memoryBryan O'Donoghue1-0/+6
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: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211105122152.1580542-4-bryan.odonoghue@linaro.org
2021-11-08wcn36xx: Release DMA channel descriptor allocationsBryan O'Donoghue1-0/+5
When unloading the driver we are not releasing the DMA descriptors which we previously allocated. Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211105122152.1580542-3-bryan.odonoghue@linaro.org
2021-11-08wcn36xx: Fix DMA channel enable/disable cycleBryan O'Donoghue1-11/+27
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: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211105122152.1580542-2-bryan.odonoghue@linaro.org
2021-11-01wcn36xx: Indicate beacon not connection loss on MISSED_BEACON_INDBryan O'Donoghue1-2/+2
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: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211027232529.657764-1-bryan.odonoghue@linaro.org
2021-11-01wcn36xx: ensure pairing of init_scan/finish_scan and start_scan/end_scanBenjamin Li3-7/+32
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 d195d7aac09b ("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: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Benjamin Li <benl@squareup.com> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211027170306.555535-4-benl@squareup.com
2021-11-01wcn36xx: implement flush op to speed up connected scanBenjamin Li3-0/+59
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 <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211027170306.555535-3-benl@squareup.com
2021-11-01wcn36xx: add debug prints for sw_scan start/completeBenjamin Li1-0/+4
Add some MAC debug prints for more easily demarcating a software scan when parsing logs. Signed-off-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211027170306.555535-2-benl@squareup.com
2021-10-28wcn36xx: add missing 5GHz channels 136 and 144Benjamin Li2-0/+3
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 <benl@squareup.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211025175359.3591048-3-benl@squareup.com
2021-10-28wcn36xx: switch on antenna diversity feature bitBenjamin Li1-1/+3
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: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211025175359.3591048-2-benl@squareup.com
2021-10-28wcn36xx: Channel list update before hardware scanLoic Poulain4-0/+116
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: 2f3bef4b247e ("wcn36xx: Add hardware scan offload support") Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1635175328-25642-1-git-send-email-loic.poulain@linaro.org
2021-10-27Revert "wcn36xx: Enable firmware link monitoring"Bryan O'Donoghue1-1/+0
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: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211025093037.3966022-2-bryan.odonoghue@linaro.org
2021-10-27wcn36xx: Fix packet drop on resumeLoic Poulain1-0/+11
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 <loic.poulain@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1635150496-19290-1-git-send-email-loic.poulain@linaro.org
2021-10-27wcn36xx: Fix discarded frames due to wrong sequence numberLoic Poulain1-2/+7
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: 84aff52e4f57 ("wcn36xx: Use sequence number allocated by mac80211") Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1635150336-18736-1-git-send-email-loic.poulain@linaro.org
2021-10-27wcn36xx: add proper DMA memory barriers in rx pathBenjamin Li1-1/+11
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: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211023001528.3077822-1-benl@squareup.com
2021-10-27wcn36xx: Fix HT40 capability for 2Ghz bandLoic Poulain1-1/+3
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: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1634737133-22336-1-git-send-email-loic.poulain@linaro.org
2021-10-27Revert "wcn36xx: Disable bmps when encryption is disabled"Bryan O'Donoghue3-15/+1
This reverts commit c6522a5076e1a65877c51cfee313a74ef61cabf8. 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 <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211022140447.2846248-3-bryan.odonoghue@linaro.org
2021-10-27wcn36xx: Treat repeated BMPS entry fail as connection lossBryan O'Donoghue2-0/+10
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: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211022140447.2846248-2-bryan.odonoghue@linaro.org
2021-10-27wcn36xx: Add chained transfer support for AMSDULoic Poulain4-2/+91
WCNSS RX DMA transfer support is limited to 3872 bytes, which is enough for simple MPDUs (single MSDU), but not enough for cases with A-MSDU (depending on max AMSDU size or max MPDU size). In that case the MPDU is spread over multiple transfers, with the first transfer containing the MPDU header and (at least) the first A-MSDU subframe and additional transfer(s) containing the following A-MSDUs. This can be handled with a series of flags to tagging the first and last A-MSDU transfers. In that case we have to bufferize and re-linearize the A-MSDU buffers into a proper MPDU skb before forwarding to mac80211 (in the same way as it is done in ath10k). This change also includes sanity check of the buffer descriptor to prevent skb overflow. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1634557705-11120-1-git-send-email-loic.poulain@linaro.org
2021-10-27wcn36xx: Enable hardware scan offload for 5Ghz bandLoic Poulain1-6/+6
Until now, offload scanning for 5Ghz channels was considered broken. However it was mostly a driver issue, caused by bad reporting of the beacons/probe-resp bands and frequencies, which has been fixed. We can now allow offload scan for 5GHz band, this reduces the scanning time comparing to software driven scanning. Note that offloaded scan is limited to 48 channels, check for this. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1634554678-7993-2-git-send-email-loic.poulain@linaro.org
2021-10-27wcn36xx: Correct band/freq reporting on RXLoic Poulain2-1/+25
For packets originating from hardware scan, the channel and band is included in the buffer descriptor (bd->rf_band & bd->rx_ch). For 2Ghz band the channel value is directly reported in the 4-bit rx_ch field. For 5Ghz band, the rx_ch field contains a mapping index (given the 4-bit limitation). The reserved0 value field is also used to extend 4-bit mapping to 5-bit mapping to support more than 16 5Ghz channels. This change adds correct reporting of the frequency/band, that is used in scan mechanism. And is required for 5Ghz hardware scan support. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1634554678-7993-1-git-send-email-loic.poulain@linaro.org
2021-10-25wcn36xx: Fix tx_status mechanismLoic Poulain2-47/+21
This change fix the TX ack mechanism in various ways: - For NO_ACK tagged packets, we don't need to wait for TX_ACK indication and so are not subject to the single packet ack limitation. So we don't have to stop the tx queue, and can call the tx status callback as soon as DMA transfer has completed. - Fix skb ownership/reference. Only start status indication timeout once the DMA transfer has been completed. This avoids the skb to be both referenced in the DMA tx ring and by the tx_ack_skb pointer, preventing any use-after-free or double-free. - This adds a sanity (paranoia?) check on the skb tx ack pointer. - Resume TX queue if TX status tagged packet TX fails. Cc: stable@vger.kernel.org Fixes: fdf21cc37149 ("wcn36xx: Add TX ack support") Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1634567281-28997-1-git-send-email-loic.poulain@linaro.org
2021-10-25wcn36xx: Fix (QoS) null data frame bitrate/modulationLoic Poulain1-0/+1
We observe unexpected connection drops with some APs due to non-acked mac80211 generated null data frames (keep-alive). After debugging and capture, we noticed that null frames are submitted at standard data bitrate and that the given APs are in trouble with that. After setting the null frame bitrate to control bitrate, all null frames are acked as expected and connection is maintained. Not sure if it's a requirement of the specification, but it seems the right thing to do anyway, null frames are mostly used for control purpose (power-saving, keep-alive...), and submitting them with a slower/simpler bitrate/modulation is more robust. Cc: stable@vger.kernel.org Fixes: 512b191d9652 ("wcn36xx: Fix TX data path") Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1634560399-15290-1-git-send-email-loic.poulain@linaro.org
2021-09-21wcn36xx: Implement Idle Mode Power SaveBryan O'Donoghue4-3/+68
Idle Mode Power Save (IMPS) is a power saving mechanism which when called by wcn36xx will cause the radio hardware to enter power collapse. This particular call maps nicely to a simple conjunction/disjunction around IEEE80211_CONF_CHANGE_IDLE and IEEE80211_CONF_IDLE. Here we enter idle when we are not associated with an AP. The kernel will incrementally toggle idle on/off in the process of trying to establish a connection, thus saving power until we are connected to the AP again, at which point we give way to BMPS if power_save is on. We've validated that with IMPS an apq8039 device which has the wcn36xx module loaded but, has not authenticated with an AP will get to VMIN on suspend and will not without IMPS. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210909153320.2624649-1-bryan.odonoghue@linaro.org
2021-09-21wcn36xx: Add ability for wcn36xx_smd_dump_cmd_req to pass two's complementBryan O'Donoghue1-1/+1
Qcom documents suggest passing of negative values to the dump command, however currently we convert from string to u32 not s32, so we cannot pass a two's complement value to the firmware in this way. There is in fact only one parameter which takes a two's complement value <tigger threshold> in the antenna diversity switch command. Downstream: iwpriv wlan0 dump 71 3 <schedule period> <trigger threshold> <hysteresis value> Upstream: echo "71 3 <schedule period> <trigger threshold> <hysteresis value>" > /sys/kernel/debug/ieee80211/phy0/wcn36xx/dump Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210909144428.2564650-3-bryan.odonoghue@linaro.org
2021-09-21wcn36xx: Fix Antenna Diversity SwitchingBryan O'Donoghue1-1/+3
We have been tracking a strange bug with Antenna Diversity Switching (ADS) on wcn3680b for a while. ADS is configured like this: A. Via a firmware configuration table baked into the NV area. 1. Defines if ADS is enabled. 2. Defines which GPIOs are connected to which antenna enable pin. 3. Defines which antenna/GPIO is primary and which is secondary. B. WCN36XX_CFG_VAL(ANTENNA_DIVERSITY, N) N is a bitmask of available antenna. Setting N to 3 indicates a bitmask of enabled antenna (1 | 2). Obviously then we can set N to 1 or N to 2 to fix to a particular antenna and disable antenna diversity. C. WCN36XX_CFG_VAL(ASD_PROBE_INTERVAL, XX) XX is the number of beacons between each antenna RSSI check. Setting this value to 50 means, every 50 received beacons, run the ADS algorithm. D. WCN36XX_CFG_VAL(ASD_TRIGGER_THRESHOLD, YY) YY is a two's complement integer which specifies the RSSI decibel threshold below which ADS will run. We default to -60db here, meaning a measured RSSI <= -60db will trigger an ADS probe. E. WCN36XX_CFG_VAL(ASD_RTT_RSSI_HYST_THRESHOLD, Z) Z is a hysteresis value, indicating a delta which the RSSI must exceed for the antenna switch to be valid. For example if HYST_THRESHOLD == 3 AntennaId1-RSSI == -60db and AntennaId-2-RSSI == -58db then firmware will not switch antenna. The threshold needs to be -57db or better to satisfy the criteria. F. A firmware feature bit also exists ANTENNA_DIVERSITY_SELECTION. This feature bit is used by the firmware to report if ANTENNA_DIVERSITY_SELECTION is supported. The host is not required to toggle this bit to enable or disable ADS. ADS works like this: A. Every XX beacons the firmware switches to or remains on the primary antenna. B. The firmware then sends a Request-To-Send (RTS) packet to the AP. C. The firmware waits for a Clear-To-Send (CTS) response from the AP. D. The firmware then notes the received RSSI on the CTS packet. E. The firmware then repeats steps A-D on the secondary antenna. F. Subsequently if the RSSI on the measured antenna is better than ASD_TRIGGER_THRESHOLD + the active antenna's RSSI then the measured antenna becomes the active antenna. G. If RSSI rises past ASD_TRIGGER_THRESHOLD then ADS doesn't run at all even if there is a substantially better RSSI on the alternative antenna. What we have been observing is that the RTS packet is being sent but the MAC address is a byte-swapped version of the target MAC. The ADS/RTS MAC is corrupted only when the link is encrypted, if the AP is open the RTS MAC is correct. Similarly if we configure the firmware to an RTS/CTS sequence for regular data - the transmitted RTS MAC is correctly formatted. Internally the wcn36xx firmware uses the indexes in the SMD commands to populate and extract data from specific entries in an STA lookup table. The AP's MAC appears a number of times in different indexes within this lookup table, so the MAC address extracted for the data-transmit RTS and the MAC address extracted for the ADS/RTS packet are not the same STA table index. Our analysis indicates the relevant firmware STA table index is "bssSelfStaIdx". There is an STA populate function responsible for formatting the MAC address of the bssSelfStaIdx including byte-swapping the MAC address. Its clear then that the required STA populate command did not run for bssSelfStaIdx. So taking a look at the sequence of SMD commands sent to the firmware we see the following downstream when moving from an unencrypted to encrypted BSS setup. - WLAN_HAL_CONFIG_BSS_REQ - WLAN_HAL_CONFIG_STA_REQ - WLAN_HAL_SET_STAKEY_REQ Upstream in wcn36xx we have - WLAN_HAL_CONFIG_BSS_REQ - WLAN_HAL_SET_STAKEY_REQ The solution then is to add the missing WLAN_HAL_CONFIG_STA_REQ between WLAN_HAL_CONFIG_BSS_REQ and WLAN_HAL_SET_STAKEY_REQ. No surprise WLAN_HAL_CONFIG_STA_REQ is the routine responsible for populating the STA lookup table in the firmware and once done the MAC sent by the ADS routine is in the correct byte-order. This bug is apparent with ADS but it is also the case that any other firmware routine that depends on the "bssSelfStaIdx" would retrieve malformed data on an encrypted link. Fixes: 3e977c5c523d ("wcn36xx: Define wcn3680 specific firmware parameters") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Benjamin Li <benl@squareup.com> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210909144428.2564650-2-bryan.odonoghue@linaro.org
2021-09-21wcn36xx: handle connection loss indicationBenjamin Li1-11/+33
Firmware sends delete_sta_context_ind when it detects the AP has gone away in STA mode. Right now the handler for that indication only handles AP mode; fix it to also handle STA mode. Cc: stable@vger.kernel.org Signed-off-by: Benjamin Li <benl@squareup.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210901180606.11686-1-benl@squareup.com
2021-08-29wcn36xx: Fix missing frame timestamp for beacon/probe-respLoic Poulain1-0/+4
When receiving a beacon or probe response, we should update the boottime_ns field which is the timestamp the frame was received at. (cf mac80211.h) This fixes a scanning issue with Android since it relies on this timestamp to determine when the AP has been seen for the last time (via the nl80211 BSS_LAST_SEEN_BOOTTIME parameter). Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1629992768-23785-1-git-send-email-loic.poulain@linaro.org
2021-08-29wcn36xx: Allow firmware name to be overridden by DTBjorn Andersson3-2/+10
The WLAN NV firmware blob differs between platforms, and possibly devices, so add support in the wcn36xx driver for reading the path of this file from DT in order to allow these files to live in a generic file system (or linux-firmware). For some reason the parent (wcnss_ctrl) also needs to upload this blob, so rather than specifying the same information in both nodes wcn36xx reads the string from the parent's of_node. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Aníbal Limón <anibal.limon@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210824171225.686683-1-bjorn.andersson@linaro.org
2021-08-29wcn36xx: Ensure finish scan is not requested before start scanJoseph Gates2-1/+5
If the operating channel is the first in the scan list, it was seen that a finish scan request would be sent before a start scan request was sent, causing the firmware to fail all future scans. Track the current channel being scanned to avoid requesting the scan finish before it starts. Cc: <stable@vger.kernel.org> Fixes: 5973a2947430 ("wcn36xx: Fix software-driven scan") Signed-off-by: Joseph Gates <jgates@squareup.com> Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1629286303-13179-1-git-send-email-loic.poulain@linaro.org
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-27 13:21:38 +0300