linux-dev/drivers/net/wireless/ath, branch linus/master

ath6kl: Use cc-disable-warning to disable -Wdangling-pointer

2022-05-24T18:20:01Z

Clang does not support this option so the build fails: error: unknown warning option '-Wno-dangling-pointer' [-Werror,-Wunknown-warning-option] Use cc-disable-warning so that the option is only added when it is supported. Fixes: bd1d129daa3e ("wifi: ath6k: silence false positive -Wno-dangling-pointer warning on GCC 12") Reported-by: "kernelci.org bot" Signed-off-by: Nathan Chancellor Reviewed-by: Tom Rix Link: https://lore.kernel.org/r/20220524145655.869822-1-nathan@kernel.org Signed-off-by: Jakub Kicinski

wifi: carl9170: silence a GCC 12 -Warray-bounds warning

2022-05-23T00:23:15Z

carl9170 has a big union (struct carl9170_cmd) with all the command types in it. But it allocates buffers only large enough for a given command. This upsets GCC 12: drivers/net/wireless/ath/carl9170/cmd.c:125:30: warning: array subscript ‘struct carl9170_cmd[0]’ is partly outside array bounds of ‘unsigned char[8]’ [-Warray-bounds] 125 | tmp->hdr.cmd = cmd; | ~~~~~~~~~~~~~^~~~~ Punt the warning to W=1 for now. Hopefully GCC will learn to recognize which fields are in-bounds. Acked-by: Christian Lamparter Acked-by: Kalle Valo Signed-off-by: Jakub Kicinski

wifi: ath6k: silence false positive -Wno-dangling-pointer warning on GCC 12

2022-05-23T00:23:05Z

For some reason GCC 12 decided to complain about the common pattern of queuing an object onto a list on the stack in ath6k: inlined from ‘ath6kl_htc_mbox_tx’ at drivers/net/wireless/ath/ath6kl/htc_mbox.c:1142:3: include/linux/list.h:74:19: warning: storing the address of local variable ‘queue’ in ‘*&packet_15(D)->list.prev’ [-Wdangling-pointer=] 74 | new->prev = prev; | ~~~~~~~~~~^~~~~~ Move the warning to W=1, hopefully it goes away with a compiler update. Acked-by: Kalle Valo Signed-off-by: Jakub Kicinski

wifi: ath9k: silence array-bounds warning on GCC 12

2022-05-23T00:23:05Z

GCC 12 says: drivers/net/wireless/ath/ath9k/mac.c: In function ‘ath9k_hw_resettxqueue’: drivers/net/wireless/ath/ath9k/mac.c:373:22: warning: array subscript 32 is above array bounds of ‘struct ath9k_tx_queue_info[10]’ [-Warray-bounds] 373 | qi = &ah->txq[q]; | ~~~~~~~^~~ I don't know where it got the 32 from, relegate the warning to W=1+. Acked-by: Kalle Valo Signed-off-by: Jakub Kicinski

Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git

2022-05-16T10:16:34Z

ath.git patches for v5.19. Major changes: ath11k * enable keepalive during WoWLAN suspend * implement remain-on-channel support

mac80211: extend current rate control tx status API

2022-05-16T08:05:02Z

This patch adds the new struct ieee80211_rate_status and replaces 'struct rate_info *rate' in ieee80211_tx_status with pointer and length annotation. The struct ieee80211_rate_status allows to: (1) receive tx power status feedback for transmit power control (TPC) per packet or packet retry (2) dynamic mapping of wifi chip specific multi-rate retry (mrr) chains with different lengths (3) increase the limit of annotatable rate indices to support IEEE802.11ac rate sets and beyond ieee80211_tx_info, control and status buffer, and ieee80211_tx_rate cannot be used to achieve these goals due to fixed size limitations. Our new struct contains a struct rate_info to annotate the rate that was used, retry count of the rate and tx power. It is intended for all information related to RC and TPC that needs to be passed from driver to mac80211 and its RC/TPC algorithms like Minstrel_HT. It corresponds to one stage in an mrr. Multiple subsequent instances of this struct can be included in struct ieee80211_tx_status via a pointer and a length variable. Those instances can be allocated on-stack. The former reference to a single instance of struct rate_info is replaced with our new annotation. An extension is introduced to struct ieee80211_hw. There are two new members called 'tx_power_levels' and 'max_txpwr_levels_idx' acting as a tx power level table. When a wifi device is registered, the driver shall supply all supported power levels in this list. This allows to support several quirks like differing power steps in power level ranges or alike. TPC can use this for algorithm and thus be designed more abstract instead of handling all possible step widths individually. Further mandatory changes in status.c, mt76 and ath11k drivers due to the removal of 'struct rate_info *rate' are also included. status.c already uses the information in ieee80211_tx_status->rate in radiotap, this is now changed to use ieee80211_rate_status->rate_idx. mt76 driver already uses struct rate_info to pass the tx rate to status path. The new members of the ieee80211_tx_status are set to NULL and 0 because the previously passed rate is not relevant to rate control and accurate information is passed via tx_info->status.rates. For ath11k, the txrate can be passed via this struct because ath11k uses firmware RC and thus the information does not interfere with software RC. Compile-Tested: current wireless-next tree with all flags on Tested-on: Xiaomi 4A Gigabit (MediaTek MT7603E, MT7612E) with OpenWrt Linux 5.10.113 Signed-off-by: Jonas Jelonek Link: https://lore.kernel.org/r/20220509173958.1398201-2-jelonek.jonas@gmail.com Signed-off-by: Johannes Berg

ath11k: remove redundant assignment to variables vht_mcs and he_mcs

2022-05-10T16:34:17Z

The variables vht_mcs and he_mcs are being initialized in the start of for-loops however they are re-assigned new values in the loop and not used outside the loop. The initializations are redundant and can be removed. Cleans up clang scan warnings: warning: Although the value stored to 'vht_mcs' is used in the enclosing expression, the value is never actually read from 'vht_mcs' [deadcode.DeadStores] warning: Although the value stored to 'he_mcs' is used in the enclosing expression, the value is never actually read from 'he_mcs' [deadcode.DeadStores] Signed-off-by: Colin Ian King Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220507184155.26939-1-colin.i.king@gmail.com

ath11k: Reuse the available memory after firmware reload

2022-05-10T16:33:33Z

Ath11k allocates memory when firmware requests memory in QMI. Coldboot calibration and firmware recovery uses firmware reload. On firmware reload, firmware sends memory request again. If Ath11k allocates memory on first firmware boot, reuse the available memory. Also check if the segment type and size is same on the next firmware boot. Reuse if segment type/size is same as previous firmware boot else free the segment and allocate the segment with size/type. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.6.0.1-00752-QCAHKSWPL_SILICONZ-1 Signed-off-by: Anilkumar Kolli Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220506141448.10340-1-quic_akolli@quicinc.com

wil6210: remove 'freq' debugfs

2022-05-10T16:32:45Z

This is completely racy, remove it. Signed-off-by: Johannes Berg Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220506095451.9852305a92c8.I05155824a1b9059eb59beccde81786dc69de354a@changeid

ath11k: Designating channel frequency when sending management frames

2022-05-10T16:32:08Z

In case of Passpoint, the WLAN interface may be requested to remain on a specific channel and then to send some management frames on that channel. Now chanfreq of wmi_mgmt_send_cmd is set as 0, as a result firmware may choose a default but wrong channel. Fix it by assigning chanfreq field with the designated channel. This change only applies to WCN6855 and QCA6390, other chips are not affected. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Baochen Qiang Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220506013614.1580274-4-quic_bqiang@quicinc.com