iwlwifi patches for v5.16
* Support for 160MHz in ranging measurements;
* Some fixes in HE capabilities;
* Fixes in vendor specific capabilities;
* Add the PC of both processors in error dumps;
* Small fix in TDLS;
* Code to sanitize firmware dumps;
* Updates for new FW rate and flags format;
* Continue implementation of new rate and flags format in the FW APIs;
* Some fixes for BZ family initialization;
* Fix session protection in some scenarios;
* Some debugging improvements;
* Fix BT-coex priority;
* Improve PS-poll timeout detection;
* Some other small fixes, clean-ups and improvements.
# gpg: Signature made Fri 22 Oct 2021 11:28:43 AM EEST
# gpg: using RSA key 1772CD7E06F604F5A6EBCB26A1479CA21A3CC5FA
# gpg: Good signature from "Luciano Roth Coelho (Luca) <luca@coelho.fi>" [full]
# gpg: aka "Luciano Roth Coelho (Intel) <luciano.coelho@intel.com>" [full]
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: fdf21cc371 ("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
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: 512b191d96 ("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
Commit 9af7c32cec ("ath10k: add target IRAM recovery feature support")
introduced a new firmware feature flag ATH10K_FW_FEATURE_IRAM_RECOVERY. But
this caused ath10k_pci module load to fail if ATH10K_FW_CRASH_DUMP_RAM_DATA bit
was not enabled in the ath10k coredump_mask module parameter:
[ 2209.328190] ath10k_pci 0000:02:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
[ 2209.434414] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1
[ 2209.547191] ath10k_pci 0000:02:00.0: firmware ver 10.4-3.9.0.2-00099 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 cbade90a
[ 2210.896485] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id 0:1 crc32 a040efc2
[ 2213.603339] ath10k_pci 0000:02:00.0: failed to copy target iram contents: -12
[ 2213.839027] ath10k_pci 0000:02:00.0: could not init core (-12)
[ 2213.933910] ath10k_pci 0000:02:00.0: could not probe fw (-12)
And by default coredump_mask does not have ATH10K_FW_CRASH_DUMP_RAM_DATA
enabled so anyone using a firmware with iram-recovery feature would fail. To my
knowledge only QCA9984 firmwares starting from release 10.4-3.9.0.2-00099
enabled the feature.
The reason for regression was that ath10k_core_copy_target_iram() used
ath10k_coredump_get_mem_layout() to get the memory layout, but when
ATH10K_FW_CRASH_DUMP_RAM_DATA was disabled it would get just NULL and bail out
with an error.
While looking at all this I noticed another bug: if CONFIG_DEV_COREDUMP is
disabled but the firmware has iram-recovery enabled the module load fails with
similar error messages. I fixed that by returning 0 from
ath10k_core_copy_target_iram() when _ath10k_coredump_get_mem_layout() returns
NULL.
Tested-on: QCA9984 hw2.0 PCI 10.4-3.9.0.2-00139
Fixes: 9af7c32cec ("ath10k: add target IRAM recovery feature support")
Signed-off-by: Abinaya Kalaiselvan <akalaise@codeaurora.org>
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211020075054.23061-1-kvalo@codeaurora.org
Using a kernel pointer in place of a dma_addr_t token can
lead to undefined behavior if that makes it into cache
management functions. The compiler caught one such attempt
in a cast:
drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_add_interface':
drivers/net/wireless/ath/ath10k/mac.c:5586:47: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
5586 | arvif->beacon_paddr = (dma_addr_t)arvif->beacon_buf;
| ^
Looking through how this gets used down the way, I'm fairly
sure that beacon_paddr is never accessed again for ATH10K_DEV_TYPE_HL
devices, and if it was accessed, that would be a bug.
Change the assignment to use a known-invalid address token
instead, which avoids the warning and makes it easier to catch
bugs if it does end up getting used.
Fixes: e263bdab9c ("ath10k: high latency fixes for beacon buffer")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211014075153.3655910-1-arnd@kernel.org
Repalce kthread_create/wake_up_process() with kthread_run()
to simplify the code.
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
When the EEPROM data is stored on a MTD partition print an error message
when reading this MTD partition failed. This is currently happening
often in OpenWrt because the initial data was written with using a flash
driver which ignores the error detection data and now OpenWrt uses a
driver which checks it.
With this patch a better error message is shown:
[ 8.986988] mt7915e 0000:01:00.0: WA Firmware Version: DEV_000000, Build Time: 20201105222323
[ 9.100508] mt7915e 0000:01:00.0: reading EEPROM from mtd factory failed: -117
[ 9.144289] mt7915e: probe of 0000:01:00.0 failed with error -22
mt7915 does not work without an EEPROM, MT7922 still works.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Add debugfs knobs to read MCU utilization, which helps user know
firmware status more easily to narrow down CPU bottleneck issues.
Co-developed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
With this patch, driver can support single rate, (HE)GI and HE_LTF
configuration through .set_bitrate_mask().
Tested-by: MeiChia Chiu <meichia.chiu@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Make mt7915_mcu_sta_he_tlv() as a part of mt7915_mcu_add_rate_ctrl() as
firmware rate control should get HE rate information from sta_rec_he,
and reduce a global function accordingly.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Band0 and band1 share the same hardware, so band0 will stop Tx/Rx when
band1 performs Rx calibration. cal_cache is introduced to solve such
corner cases by moving necessary datas from channel_switch to bootup.
Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com>
Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
commit 7f4b792031 ("mt76: mt7615: add ibss support") introduced IBSS
and commit f4ec7fdf7f ("mt76: mt7615: enable support for mesh")
meshpoint support.
Both used in the "get_omac_idx"-function:
if (~mask & BIT(HW_BSSID_0))
return HW_BSSID_0;
With commit d8d59f66d1 ("mt76: mt7615: support 16 interfaces") the
ibss and meshpoint mode should "prefer hw bssid slot 1-3". However,
with that change the ibss or meshpoint mode will not send any beacon on
the mt7622 wifi anymore. Devices were still able to exchange data but
only if a bssid already existed. Two mt7622 devices will never be able
to communicate.
This commits reverts the preferation of slot 1-3 for ibss and
meshpoint. Only NL80211_IFTYPE_STATION will still prefer slot 1-3.
Tested on Banana Pi R64.
Fixes: d8d59f66d1 ("mt76: mt7615: support 16 interfaces")
Signed-off-by: Nick Hainke <vincent@systemli.org>
Acked-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211007225725.2615-1-vincent@systemli.org
Kalle Valo says:
====================
wireless-drivers-next patches for v5.16
Second set of patches for v5.16 and this time we have a big one. We
have the new Realtek driver rtw89 with over 90 kLOC and also over 150
patches for mt76. ath9k also got few new small features. And the usual
cleanups and fixes all over.
Major changes:
rtw89
* new Realtek 802.11ax driver
* supports Realtek 8852AE 802.11ax 2x2 chip
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
mt76
* mt7921 aspm support
* mt7921 testmode support
* mt7915 LED support
* mt7921 6GHz band support
* support for eeprom data in DT
* mt7915 TWT support
* mt7921s SDIO support
* tag 'wireless-drivers-next-2021-10-22' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next: (213 commits)
zd1201: use eth_hw_addr_set()
wl3501_cs: use eth_hw_addr_set()
ray_cs: use eth_hw_addr_set()
...
====================
Link: https://lore.kernel.org/r/20211022075845.0E679C4360D@smtp.codeaurora.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Johannes Berg says:
====================
Quite a few changes:
* the applicable eth_hw_addr_set() and const hw_addr changes
* various code cleanups/refactorings
* stack usage reductions across the wireless stack
* some unstructured find_ie() -> structured find_element()
changes
* a few more pieces of multi-BSSID support
* some 6 GHz regulatory support
* 6 GHz support in hwsim, for testing userspace code
* Light Communications (LC, 802.11bb) early band definitions
to be able to add a first driver soon
* tag 'mac80211-next-for-net-next-2021-10-21' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next: (35 commits)
cfg80211: fix kernel-doc for MBSSID EMA
mac80211: Prevent AP probing during suspend
nl80211: Add LC placeholder band definition to nl80211_band
...
====================
Link: https://lore.kernel.org/r/20211021154953.134849-1-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Sometimes some NICs may fail to initialize, but if we have
such a scenario we may only see an alive timeout (i.e. the
firmware doesn't send us the alive message), and that will
only cause us to fail the interface up.
Try to once grab NIC access during device probe to ensure
we can properly talk to the hardware at all, and to do all
the potential workarounds in that function.
Since we now finish NIC init here, we can remove it from
the later potential read of the RF ID.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211017165728.604dfc8f43bd.I07b58a5c9238f75413a91198452ba1268ee79425@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When auth/assoc completes, we should remove session protection,
except when association is successful, where we need it until a
beacon is received from the AP.
In particular, in the case of assoc comeback, currently the session
protection event just times out, leading to confusing messages:
wlan0: 42:00:00:00:00:00 rejected association temporarily; comeback duration 1000 TU (1024 ms)
iwlwifi 0000:00:00.0: Not associated and the session protection is over already...
wlan0: Connection to AP 42:00:00:00:00:00 lost
wlan0: associate with 42:00:00:00:00:00 (try 2/3)
mac80211 never does anything on the "Connection ... lost" as it's
not even connected.
Removing the session protection when it's no longer needed removes
those confusing messages and lets the device do other things in the
allocated time.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211017162352.95e4bebb069b.I635280e5d26c70414ac6eb5d62b46fe4bd942818@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
