Kalle Valo says:
====================
wireless-next patches for v6.1
Few stack changes and lots of driver changes in this round. brcmfmac
has more activity as usual and it gets new hardware support. ath11k
improves WCN6750 support and also other smaller features. And of
course changes all over.
Note: in early September wireless tree was merged to wireless-next to
avoid some conflicts with mac80211 patches, this shouldn't cause any
problems but wanted to mention anyway.
Major changes:
mac80211
- refactoring and preparation for Wi-Fi 7 Multi-Link Operation (MLO)
feature continues
brcmfmac
- support CYW43439 SDIO chipset
- support BCM4378 on Apple platforms
- support CYW89459 PCIe chipset
rtw89
- more work to get rtw8852c supported
- P2P support
- support for enabling and disabling MSDU aggregation via nl80211
mt76
- tx status reporting improvements
ath11k
- cold boot calibration support on WCN6750
- Target Wake Time (TWT) debugfs support for STA interface
- support to connect to a non-transmit MBSSID AP profile
- enable remain-on-channel support on WCN6750
- implement SRAM dump debugfs interface
- enable threaded NAPI on all hardware
- WoW support for WCN6750
- support to provide transmit power from firmware via nl80211
- support to get power save duration for each client
- spectral scan support for 160 MHz
wcn36xx
- add SNR from a received frame as a source of system entropy
* tag 'wireless-next-2022-09-30' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (231 commits)
wifi: rtl8xxxu: Improve rtl8xxxu_queue_select
wifi: rtl8xxxu: Fix AIFS written to REG_EDCA_*_PARAM
wifi: rtl8xxxu: gen2: Enable 40 MHz channel width
wifi: rtw89: 8852b: configure DLE mem
wifi: rtw89: check DLE FIFO size with reserved size
wifi: rtw89: mac: correct register of report IMR
wifi: rtw89: pci: set power cut closed for 8852be
wifi: rtw89: pci: add to do PCI auto calibration
wifi: rtw89: 8852b: implement chip_ops::{enable,disable}_bb_rf
wifi: rtw89: add DMA busy checking bits to chip info
wifi: rtw89: mac: define DMA channel mask to avoid unsupported channels
wifi: rtw89: pci: mask out unsupported TX channels
iwlegacy: Replace zero-length arrays with DECLARE_FLEX_ARRAY() helper
ipw2x00: Replace zero-length array with DECLARE_FLEX_ARRAY() helper
wifi: iwlwifi: Track scan_cmd allocation size explicitly
brcmfmac: Remove the call to "dtim_assoc" IOVAR
brcmfmac: increase dcmd maximum buffer size
brcmfmac: Support 89459 pcie
brcmfmac: increase default max WOWL patterns to 16
cw1200: fix incorrect check to determine if no element is found in list
...
====================
Link: https://lore.kernel.org/r/20220930150413.A7984C433D6@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ieee80211_tx_queue_params.aifs is not supposed to be written directly
to the REG_EDCA_*_PARAM registers. Instead process it like the vendor
drivers do. It's kinda hacky but it works.
This change boosts the download speed and makes it more stable.
Tested with RTL8188FU but all the other supported chips should also
benefit.
Fixes: 26f1fad29a ("New driver: rtl8xxxu (mac80211)")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Jes Sorensen <jes@trained-monkey.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/038cc03f-3567-77ba-a7bd-c4930e3b2fad@gmail.com
The module parameter ht40_2g was supposed to enable 40 MHz operation,
but it didn't.
Tell the firmware about the channel width when updating the rate mask.
This makes it work with my gen 2 chip RTL8188FU.
I'm not sure if anything needs to be done for the gen 1 chips, if 40
MHz channel width already works or not. They update the rate mask with
a different structure which doesn't have a field for the channel width.
Also set the channel width correctly for sta_statistics.
Fixes: f653e69009 ("rtl8xxxu: Implement basic 8723b specific update_rate_mask() function")
Fixes: bd917b3d28 ("rtl8xxxu: fill up txrate info for gen1 chips")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Jes Sorensen <jes@trained-monkey.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/3a950997-7580-8a6b-97a0-e0a81a135456@gmail.com
We tell driver developers to always pass NAPI_POLL_WEIGHT
as the weight to netif_napi_add(). This may be confusing
to newcomers, drop the weight argument, those who really
need to tweak the weight can use netif_napi_add_weight().
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> # for CAN
Link: https://lore.kernel.org/r/20220927132753.750069-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ath.git patches for v6.1. Major changes:
ath11k
* cold boot calibration support on WCN6750
* Target Wake Time (TWT) debugfs support for STA interface
* support to connect to a non-transmit MBSSID AP profile
* enable remain-on-channel support on WCN6750
* implement SRAM dump debugfs interface
* enable threaded NAPI on all hardware
* WoW support for WCN6750
* support to provide transmit power from firmware via nl80211
* support to get power save duration for each client
* spectral scan support for 160 MHz
wcn36xx
* add SNR from a received frame as a source of system entropy
When STA roams from one AP to another, after roam is complete, host
driver tries to get TIM information from firmware. This is no longer
supported in the firmware & hence, this call will always fail.
This failure results in the below message being displayed on the
console all the time when roam is done.
ieee80211 phy0: brcmf_update_bss_info: wl dtim_assoc failed (-52)
Changes ensure that the host driver will no longer try to get TIM
information from firmware.
Signed-off-by: Ramesh Rangavittal <ramesh.rangavittal@infineon.com>
Signed-off-by: Chi-hsien Lin <chi-hsien.lin@infineon.com>
Signed-off-by: Ian Lin <ian.lin@infineon.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220922104140.11889-5-ian.lin@infineon.com
The bug is here: "} else if (item) {".
The list iterator value will *always* be set and non-NULL by
list_for_each_entry(), so it is incorrect to assume that the iterator
value will be NULL if the list is empty or no element is found in list.
Use a new value 'iter' as the list iterator, while use the old value
'item' as a dedicated pointer to point to the found element, which
1. can fix this bug, due to now 'item' is NULL only if it's not found.
2. do not need to change all the uses of 'item' after the loop.
3. can also limit the scope of the list iterator 'iter' *only inside*
the traversal loop by simply declaring 'iter' inside the loop in the
future, as usage of the iterator outside of the list_for_each_entry
is considered harmful. https://lkml.org/lkml/2022/2/17/1032
Fixes: a910e4a94f ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets")
Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220413091723.17596-1-xiam0nd.tong@gmail.com
We are seeing system hangs during WoWLAN suspend, and get below
two stacks:
Stack1:
[ffffb02cc1557b20] __schedule at ffffffff8bb10860
[ffffb02cc1557ba8] schedule at ffffffff8bb10f24
[ffffb02cc1557bb8] schedule_timeout at ffffffff8bb16d88
[ffffb02cc1557c30] wait_for_completion at ffffffff8bb11778
[ffffb02cc1557c78] __flush_work at ffffffff8b0b30cd
[ffffb02cc1557cf0] __cancel_work_timer at ffffffff8b0b33ad
[ffffb02cc1557d60] ath11k_mac_drain_tx at ffffffffc0c1f0ca [ath11k]
[ffffb02cc1557d70] ath11k_wow_op_suspend at ffffffffc0c5201e [ath11k]
[ffffb02cc1557da8] __ieee80211_suspend at ffffffffc11e2bd3 [mac80211]
[ffffb02cc1557dd8] wiphy_suspend at ffffffffc0f901ac [cfg80211]
[ffffb02cc1557e08] dpm_run_callback at ffffffff8b75118a
[ffffb02cc1557e38] __device_suspend at ffffffff8b751630
[ffffb02cc1557e70] async_suspend at ffffffff8b7519ea
[ffffb02cc1557e88] async_run_entry_fn at ffffffff8b0bf4ce
[ffffb02cc1557ea8] process_one_work at ffffffff8b0b1a24
[ffffb02cc1557ee0] worker_thread at ffffffff8b0b1c4a
[ffffb02cc1557f18] kthread at ffffffff8b0b9cb8
[ffffb02cc1557f50] ret_from_fork at ffffffff8b001d32
Stack2:
[ffffb02cc00b7d18] __schedule at ffffffff8bb10860
[ffffb02cc00b7da0] schedule at ffffffff8bb10f24
[ffffb02cc00b7db0] schedule_preempt_disabled at ffffffff8bb112b4
[ffffb02cc00b7db8] __mutex_lock at ffffffff8bb127ea
[ffffb02cc00b7e38] ath11k_mgmt_over_wmi_tx_work at ffffffffc0c1aa44 [ath11k]
[ffffb02cc00b7ea8] process_one_work at ffffffff8b0b1a24
[ffffb02cc00b7ee0] worker_thread at ffffffff8b0b1c4a
[ffffb02cc00b7f18] kthread at ffffffff8b0b9cb8
[ffffb02cc00b7f50] ret_from_fork at ffffffff8b001d32
From the first stack, ath11k_mac_drain_tx calls
cancel_work_sync(&ar->wmi_mgmt_tx_work) and waits all packets to be sent
out or dropped. However, we find from Stack2 that this work item is blocked
because ar->conf_mutex is already held by ath11k_wow_op_suspend.
Fix this issue by moving ath11k_mac_wait_tx_complete to the start of
ath11k_wow_op_suspend where ar->conf_mutex has not been acquired. And
this change also makes the logic in ath11k_wow_op_suspend match the
logic in ath11k_mac_op_start and ath11k_mac_op_stop.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220919021435.2459-1-quic_bqiang@quicinc.com
There are two types of 160 MHz spectral scan support mentioned below
1. Fragmented approach
2. Single event approach
In this fragmented approach, single 160 MHz will be split as two
80 MHz buffer. First fft sample buffer will contain spectral scan
result of primary 80 MHz and the second fft sample buffer will contain
secondary 80 MHz and here cfreq1 and cfreq2 will be mentioned.
In case of 160 MHz on 36th channel will contain cfreq1 as 5210 and
cfreq2 as 5290. Chipsets which support this approach are IPQ8074/IPQ6018.
Replacing freq1 with freq2 in every secondary sepctral scan event to
distinguish between two different 80 MHz spectral event data.
In the 2nd approach each fft sample buffer will contain spectral scan
result for whole 160 MHz by mentioning cfreq1 as 5250 which is center
frequency of whole 160 MHz. Chipset which support this approach is QCN9074.
Host will receive spectral event from target for every 5 fft samples.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01120-QCAHKSWPL-1
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01120-QCAHKSWP
Signed-off-by: Tamizh Chelvam Raja <quic_tamizhr@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220725055001.15194-1-quic_tamizhr@quicinc.com
Add support to get the following power save information through debugfs interface,
* Current ps state of the peer
* Time duration since the peer is in power save
* Total duration of the peer spent in power save
Above information is helpful in debugging the issues with power save clients.
This patch also add trace log support for PS timekeeper to track the PS state
change of the peers alongs with the peer MAC address and timestamp.
Use the below commands to get the above power save information,
To know the time_since_station_in_power_save:
cat /sys/kernel/debug/ieee80211/phyX/netdev:wlanX/stations/
XX:XX:XX:XX:XX:XX/current_ps_duration
To know power_save_duration:
cat /sys/kernel/debug/ieee80211/phyX/netdev:wlanX/stations/
XX:XX:XX:XX:XX:XX/total_ps_duration
To reset the power_save_duration of all stations connected to AP:
echo 1 > /sys/kernel/debug/ieee80211/phyX/ath11k/reset_ps_duration
To enable/disable the ps_timekeeper:
echo Y > /sys/kernel/debug/ieee80211/phyX/ath11k/ps_timekeeper_enable
Y = 1 to enable and Y = 0 to disable.
To record PS timekeeer logs after enabling ps_timekeeper:
trace-cmd record -e ath11k_ps_timekeeper
Tested-on: Tested-on: IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1
Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com>
Signed-off-by: Tamizh Chelvam Raja <quic_tamizhr@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220725054601.14719-1-quic_tamizhr@quicinc.com
This patch try to fix the following error.
Wed Jun 1 22:19:30 2022 kern.warn kernel: [ 119.561227] ath11k c000000.wifi: peer already added vdev id 0 req, vdev id 1 present
Wed Jun 1 22:19:30 2022 kern.warn kernel: [ 119.561282] ath11k c000000.wifi: Failed to add peer: 28:c2:1f:xx:xx:xx for VDEV: 0
Wed Jun 1 22:19:30 2022 kern.warn kernel: [ 119.568053] ath11k c000000.wifi: Failed to add station: 28:c2:1f:xx:xx:xx for VDEV: 0
Wed Jun 1 22:19:31 2022 daemon.notice hostapd: wlan2: STA 28:c2:1f:xx:xx:xx IEEE 802.11: Could not add STA to kernel driver
Wed Jun 1 22:19:31 2022 daemon.notice hostapd: wlan2: STA 28:c2:1f:xx:xx:xx IEEE 802.11: did not acknowledge authentication response
Wed Jun 1 22:19:31 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 28:c2:1f:xx:xx:xx
Wed Jun 1 22:19:31 2022 daemon.info hostapd: wlan1: STA 28:c2:1f:xx:xx:xx IEEE 802.11: disassociated due to inactivity
Wed Jun 1 22:19:32 2022 daemon.info hostapd: wlan1: STA 28:c2:1f:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
To repro this:
- Have 2 Wifi with the same bssid and pass on different band (2.4 and
5GHz)
- Enable 802.11r Fast Transaction with same mobility domain
- FT Protocol: FT over the Air
From a openwrt system issue the command (with the correct mac)
ubus call hostapd.wlan1 wnm_disassoc_imminent '{"addr":"28:C2:1F:xx:xx:xx"}'
Notice the log printing the errors.
The cause of this error has been investigated and we found that this is
related to the WiFi Fast Transaction feature. We observed that this is
triggered when the router tells the device to change band. In this case
the device first auth to the other band and then the disconnect path
from the prev band is triggered.
This is problematic with the current rhash implementation since the
addrs is used as key and the logic of "adding first, delete later"
conflicts with the rhash logic.
In fact peer addition will fail since the peer is already added and with
that fixed a peer deletion will cause unitended effect by removing the
peer just added.
Current solution to this is to add additional logic to the peer delete,
make sure we are deleting the correct peer taken from the rhash
table (and fallback to the peer list) and for the peer add logic delete
the peer entry for the rhash list before adding the new one (counting as
an error only when a peer with the same vlan_id is asked to be added).
With this change, a sta can correctly transition from 2.4GHz and 5GHZ
with no drop and no error are printed.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1
Fixes: 7b0c70d92a ("ath11k: Add peer rhash table support")
Signed-off-by: Christian 'Ansuel' Marangi <ansuelsmth@gmail.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220603164559.27769-1-ansuelsmth@gmail.com
Check IEEE80211_TX_CTL_NO_CCK_RATE flag to avoid sending frames with
CCK rates in 2GHz band.
In TX flow, add IEEE80211_TX_CTL_NO_CCK_RATE flag to check and get its
lowest rate without CCK rates if the TX type is mgmt frames or data frames.
Besides, the decision of phy rate and retry rate in P2P mode are also
be handled.
In P2P GO mode, it should send beacon of no CCK rates in its frame rate.
Therefore, We add a condition to decide which rate is added to beacon
content.
Moreover, we avoid setting a mask of rates to be used for rate control
selection before and after connection in P2P mode.
Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220922010435.12167-3-pkshih@realtek.com
