Introduce 'ieee80211_mgmt_ba()' to avoid code duplication between
'ieee80211_send_addba_resp()', 'ieee80211_send_addba_request()',
and 'ieee80211_send_delba()', ensure that all related addresses
are '__aligned(2)', and prefer convenient 'ether_addr_copy()'
over generic 'memcpy()'. No functional changes expected.
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Link: https://patch.msgid.link/20240725090925.6022-1-dmantipov@yandex.ru
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Correct the name field in multi_radio's MODULE_PARM_DESC.
Fixes: d2601e34a102 ("wifi: mac80211_hwsim: add support for multi-radio wiphy")
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Acked-by: Felix Fietkau <nbd@nbd.name>
Link: https://patch.msgid.link/20240712074938.26437-1-kevin_yang@realtek.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The pointers in adapter->priv[] are allocated in mwifiex_register().
With an allocation failed the function will return an error and
driver initialization is aborted. This makes all checks for valid
priv pointers unnecessary throughout the driver. In many places
the pointers are assumed to be valid without checks, this patch
removes the remaining checks.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240816-mwifiex-remove-priv-checks-v1-1-6dd6553e8ed9@pengutronix.de
Smatch complains that:
drivers/net/wireless/marvell/mwifiex/cfg80211.c:4408 mwifiex_cfg80211_authenticate()
error: uninitialized symbol 'varptr'.
It's a check for NULL, but "varptr" is either non-NULL or uninitialized.
Initialize it to NULL.
Fixes: 36995892c271 ("wifi: mwifiex: add host mlme for client mode")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/d7d043b2-95d5-4e1d-b340-5d7330053ac6@stanley.mountain
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
So, in order to avoid ending up with a flexible-array member in the
middle of multiple other structs, we use the `__struct_group()`
helper to create new tagged structures with the suffix `_hdr`.
These structures group together all the members of the original
flexible structures except the flexible arrays.
As a result, the arrays are effectively separated from the rest of the
members without modifying the memory layout of the flexible structures.
We then change the type of the middle struct members currently causing
trouble from the original flex struct to the newly created structs with
suffix `_hdr`.
We also want to ensure that when new members need to be added to the
flexible structures, they are always included within the newly created
tagged structs. For this, we use `static_assert()`. This ensures that the
memory layout for both the flexible structure and the new tagged struct
is the same after any changes.
This approach avoids having to implement the `_hdr` structures as
completely separate structures, thus preventing having to maintain
two independent but basically identical structures, closing the door
to potential bugs in the future.
We also use `container_of()` whenever we need to retrieve a pointer to
the flexible structure, through which we can access the flexible-array
member, if necessary.
Also, remove a couple of unused zero-length arrays and flexible-array
members.
So, with these changes, fix the following warnings:
drivers/net/wireless/intel/iwlegacy/commands.h:1196:38: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlegacy/commands.h:1197:36: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlegacy/commands.h:2505:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlegacy/commands.h:2549:26: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlegacy/commands.h:2654:31: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlegacy/commands.h:2665:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlegacy/commands.h:2673:26: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlegacy/commands.h:3349:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/Zr2gxERA3RL3EwRe@elsanto
With host_mlme support being added mwifiex_cfg80211_ops is no longer
constant, but supplemented with the host_mlme related ops when host_mlme
support is enabled. This doesn't work with multiple adapters when only
few of then have host_mlme support. Duplicate mwifiex_cfg80211_ops
before using it and keep the original constant.
While at it mark mwifiex_cfg80211_ops const to prevent people from
changing it again during runtime.
Fixes: 36995892c271c ("wifi: mwifiex: add host mlme for client mode")
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240809-mwifiex-duplicate-mwifiex_cfg80211_ops-v1-1-23e0e6290ace@pengutronix.de
This is a fairly light pull request since ath12k is still working on
MLO-related changes, and the other drivers are mostly in maintenance
mode with a few cleanups and bug fixes.
Major changes:
ath12k
* DebugFS support for transmit DE stats
* Make ASPM support hardware-dependent
* Align BSS Channel information command and message with firmware
ath11k
* Use work queue for beacon tx events
ath9k
* Use devm for gpio_request_one
* Use unmanaged PCI functions in ath9k_pci_owl_loader()
-----BEGIN PGP SIGNATURE-----
iIoEABYKADIWIQQ/mtSHzPUi16IfDEksFbugiYzLewUCZrpKTBQcampvaG5zb25A
a2VybmVsLm9yZwAKCRAsFbugiYzLe5oZAP9Iyt9lTZXnl/eMHSNEB7Z5LE0huB/m
v9YOIggnYUBbJgEAoHf7n6xyoiSjESM9R1KZc8Dv4R0MZRRG5qY+pDigwwg=
=DvtP
-----END PGP SIGNATURE-----
Merge tag 'ath-next-20240812' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
ath.git patches for v6.12
This is a fairly light pull request since ath12k is still working on
MLO-related changes, and the other drivers are mostly in maintenance
mode with a few cleanups and bug fixes.
Major changes:
ath12k
* DebugFS support for transmit DE stats
* Make ASPM support hardware-dependent
* Align BSS Channel information command and message with firmware
ath11k
* Use work queue for beacon tx events
ath9k
* Use devm for gpio_request_one
* Use unmanaged PCI functions in ath9k_pci_owl_loader()
Commit 5c4250092fad ("wifi: mwl8k: Avoid -Wflex-array-member-not-at-end
warnings") introduced tagged `struct mwl8k_cmd_pkt_hdr`. We want to
ensure that when new members need to be added to the flexible structure,
they are always included within this tagged struct.
We use `static_assert()` to ensure that the memory layout for both
the flexible structure and the tagged struct is the same after any
changes.
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/ZrVCg51Q9M2fTPaF@cute
A pull-request for v6.12 containing fixes and features, and list major
changes below:
rtw88:
- improve USB performance by aggregation
- fix RX bandwidth for rx_status
rtw89:
- support new WiFi 6 chip RTL8852BE-VT
- support WoWLAN net-detect feature
- support hardware encryption in unicast management frames
- support hardware rfkill
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuyEnvMdOsBl1WjpdjlvZYmhshd8FAma1cDoACgkQjlvZYmhs
hd+8dw/+Pp+PBt6yKBBdTrNuTXAqHJPrWIfCmvguQQnKq0iUtQf/OZjle5GAOvsW
kIdlf/YbKxxMUrrw01Edj+XUxvgRVD2jvmviEOKgA04WoPKjIjZ6eyJgs/90NJa0
dmTrfogOGwpaPkDDOxcU2SNSFNgr84V99VG+/AZo/A5yATm/0LSWTDTdJJ9h4YSN
4hmqWOaB7ytX9KvpBYa6U0W3wkeObr7cP0cPrHjLJZ1qO7eboc6CNy39m/H57RIx
2fL7AlWTZdQJ5wHcPaVehQs4D/ul3jxWQOjaqbGiaRE9lyabPGCV8W0ffr6qTOf9
6/usRoE41GoRiqk1e8sZ8iZWe+XCytOwVLx31dnC/sRhgByAom08JIDbJYKJP1Ev
2kBeD/pPL4lAgGEzm8I/bbk918beJufLnwxBGf6XZGweKWjUolyi10xJ70YeK+LN
sO4M2Z552bOEIdahGNdXKvHqyo3n+nRsH1zHXp2n7pVmECVZqrq1TWStJzELLL1d
ygPsHJbR9ZOdJhWsEOuWprq73qua8Qrk3CFsd1QavqtFcVnlxokI1C0sjSajyVQt
I33IDXYGJoommQi9TIJrojv0D5ZTWIGSWFuQQ53zWHv00WDEdmfYinkJr8vJbbNM
ALgf/wboiuiqRlTlL9HoeGp5Sll7Oyv0wXPLEoRuBzI+3uaf8LA=
=/F45
-----END PGP SIGNATURE-----
Merge tag 'rtw-next-2024-08-09' of https://github.com/pkshih/rtw
rtw-next patches for v6.12
A pull-request for v6.12 containing fixes and features, and list major
changes below:
rtw88:
- improve USB performance by aggregation
- fix RX bandwidth for rx_status
rtw89:
- support new WiFi 6 chip RTL8852BE-VT
- support WoWLAN net-detect feature
- support hardware encryption in unicast management frames
- support hardware rfkill
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
So, in order to avoid ending up with a flexible-array member in the
middle of multiple other structs, we use the `__struct_group()`
helper to create a new tagged `struct libipw_hdr_3addr_hdr`.
This structure groups together all the members of the flexible
`struct libipw_hdr_3addr` except the flexible array.
As a result, the array is effectively separated from the rest of the
members without modifying the memory layout of the flexible structure.
We then change the type of the middle struct members currently causing
trouble from `struct libipw_hdr_3addr` to `struct libipw_hdr_3addr_hdr`.
We also want to ensure that when new members need to be added to the
flexible structure, they are always included within the newly created
tagged struct. For this, we use `static_assert()`. This ensures that the
memory layout for both the flexible structure and the new tagged struct
is the same after any changes.
This approach avoids having to implement `struct libipw_hdr_3addr_hdr`
as a completely separate structure, thus preventing having to maintain
two independent but basically identical structures, closing the door
to potential bugs in the future.
Also, remove a couple of unused structures `struct libipw_ibss_dfs` and
`struct libipw_assoc_request`.
So, with these changes, fix the following warnings:
drivers/net/wireless/intel/ipw2x00/libipw.h:403:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:420:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:433:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:441:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:447:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:460:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:468:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:476:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:592:36: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/ZrJqtUpCI+uCeb4D@cute
bss_config->key_mgmt specifies the AKM suites that are usable in
hardware. This variable is set to specific values while iterating
over the advertised AKM suites. This means the final value of the
variable depends on the order of the entries in the AKM suites
array. Instead of setting the variable, just set the relevant bits
in the key_mgmt bit field to make us independent of the order of
entries.
This behaviour is derived from the downstream driver that does the
same.
Also, set bss_config->key_mgmt to zero explicitly right before the
loop. bss_config has been zero allocated by the caller already, but
do so again to save the reader from following the code path.
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20240723-mwifiex-wpa-psk-sha256-v3-2-025168a91da1@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240805-mwifiex-wpa-psk-sha256-v4-2-e1eee80508e6@pengutronix.de
The WPA flags setting only depends on the wpa_versions bitfield and not
on the AKM suite, so move it out of the switch/case to simplify the code
a bit. Also set bss_config->protocol to zero explicitly. This is done
only to make the code clearer, bss_config has been zero alloced by the
caller, so should be zero already. No functional change intended.
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20240723-mwifiex-wpa-psk-sha256-v3-1-025168a91da1@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240805-mwifiex-wpa-psk-sha256-v4-1-e1eee80508e6@pengutronix.de
This reverts commit 92da4ce847bc5d942ddfdb102dba92f4e2797a59.
Felix pointed out that moving to devm for request_irq() can lead to a use after
free, and that avoiding that means having explicit frees that makes the devm
thing pretty pointless. So let's just revert the patch.
Link: https://lore.kernel.org/r/201f06b6-14f5-41bb-8897-49665cf14b66@nbd.name
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240808103758.11696-1-toke@toke.dk
Enable USB RX aggregation when there is at least 1 Mbps RX or TX
traffic, otherwise disable it.
USB RX aggregation improves the RX speed of RTL8811CU on certain ARM
systems, like the NanoPi NEO Core2. Before: 28 Mbps, after: 231 Mbps.
It also improves the RX speed of RTL8822CU on some x86_64 systems.
Before: ~200 Mbps, after: ~300 Mbps.
The official drivers for these chips use the same logic for SDIO, but
for some reason the SDIO driver in rtw88 always enables RX aggregation,
so this patch only toggles aggregation for USB devices.
RTL8703B is likely not found in USB devices, and RTL8723DU doesn't like
aggregation.
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/b4c0d54c-6755-4b0f-9dd7-f9196fd74b68@gmail.com
The chips can be configured to aggregate several frames into a single
USB transfer. Modify rtw_usb_rx_handler() to support this case.
RX aggregation improves the RX speed of RTL8811CU on certain ARM
systems, like the NanoPi NEO Core2. It also improves the RX speed of
RTL8822CU on some x86_64 systems.
Currently none of the chips are configured to aggregate frames.
Tested with RTL8822CU, RTL8811CU, and RTL8723DU.
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/f845826d-de71-492d-9a22-e48c07989a1f@gmail.com
Update the number of received unicast data frames and bytes every time
a frame is received. This is what the PCI and SDIO drivers do.
This has an influence on the power saving, bluetooth coexistence, and
(in a future patch) the use of RX aggregation.
Tested with RTL8822CU, RTL8811CU, and RTL8723DU.
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/75a2ca52-8f01-45c5-926f-d3a68ae3b284@gmail.com
This is needed in order to make USB RX aggregation work with RTL8811CU
(and presumably RTL8822BU and RTL8822CU also).
I don't know what BIT_DMA_BURST_CNT, BIT_DMA_MODE, and BIT_DROP_DATA_EN
are doing.
Tested with RTL8822CU, RTL8811CU, and RTL8723DU.
The RX speed is unchanged in my tests.
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/ac569c6f-7129-4341-b523-901fe10cabff@gmail.com
The rtl8xxxu has all the rtl8192cu USB IDs except for the
following 3 so add them to the untested section so they
can be used with the rtl8xxxu as the rtl8192cu are well
supported.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240806082233.3837436-1-pbrobinson@gmail.com
The Kconfig notes mention staging drivers that have
since been removed so update the driver's description
so it no longer references the staging rtl8723au and
rtl8192u drivers which have now been deleted.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240805221910.3765214-1-pbrobinson@gmail.com
The delay option is the period in unit of second for WoWLAN firmware
to wait before the first scan. We get the option from cfg80211 and
practice it. Another, in some platform, WoWLAN firmware may found
configured network and then trigger resume process, before suspend
process is completed, lead to the wakeup function failed.
So the default value is set one to avoid the issue.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240805090028.27768-5-pkshih@realtek.com
Net-detect is an option of WoWLAN to allow the device to
be woken up from suspend mode when configured network is detected.
When user enables net-detect and lets the device enter suspend
state, WoWLAN firmware will periodically scan until beacon or
probe response of configured networks are received. If configured
networks are detected, WoWLAN firmware will trigger resume process.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240805090028.27768-4-pkshih@realtek.com
When net-detect is enabled, WoWLAN firmware will periodically
scan until beacon or probe response of configured networks are
received. To reduce power consumption, the FW-IPS mode is
implemented to keep WiFi chip in idle mode between each scan.
The FW-IPS is controlled by WoWLAN firmware to turn of some critical
electrical components, and is different from the original IPS mode
which most electrical components are turned off.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240805090028.27768-3-pkshih@realtek.com
Driver has supported different WoWLAN reason code by commit 0e5210217768
("wifi: rtw89: wow: update WoWLAN reason register for different FW")
since firmware version 0.27.80.0. The old driver can't support two
kinds of WoWLAN reason, so increase firmware format to v1.
Also driver tables of BB and RF registers and power values will be added
into v1 format.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240805090028.27768-2-pkshih@realtek.com
'struct lpphy_tx_gain_table_entry' are not modified in this driver.
Constifying this structure moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
16481 6232 0 22713 58b9 drivers/net/wireless/broadcom/b43/tables_lpphy.o
After:
=====
text data bss dec hex filename
22305 395 0 22700 58ac drivers/net/wireless/broadcom/b43/tables_lpphy.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-By: Michael Büsch <m@bues.ch>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/e33bc9e6dff4a5b6cd8d0ab5399aa1abac5bef9d.1722753127.git.christophe.jaillet@wanadoo.fr
Currently ampdu_factor is wrongly calculated in ath12k_peer_assoc_h_he(), fix it.
This is found during code review.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4
Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240710021819.87216-1-quic_bqiang@quicinc.com
struct wmi_pdev_bss_chan_info_event is not similar to the firmware
struct definition, this will cause some random failures.
Fix by matching the struct wmi_pdev_bss_chan_info_event with the
firmware structure definition.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: P Praneesh <quic_ppranees@quicinc.com>
Signed-off-by: Karthikeyan Kathirvel <quic_kathirve@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240331183232.2158756-3-quic_kathirve@quicinc.com
Currently, the firmware returns incorrect pdev_id information in
WMI_PDEV_BSS_CHAN_INFO_EVENTID, leading to incorrect filling of
the pdev's survey information.
To prevent this issue, when requesting BSS channel information
through WMI_PDEV_BSS_CHAN_INFO_REQUEST_CMDID, firmware expects
pdev_id as one of the arguments in this WMI command.
Add pdev_id to the struct wmi_pdev_bss_chan_info_req_cmd and fill it
during ath12k_wmi_pdev_bss_chan_info_request(). This resolves the
issue of sending the correct pdev_id in WMI_PDEV_BSS_CHAN_INFO_EVENTID.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: P Praneesh <quic_ppranees@quicinc.com>
Signed-off-by: Karthikeyan Kathirvel <quic_kathirve@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240331183232.2158756-2-quic_kathirve@quicinc.com
During PCI based hardware device start up, ASPM is disabled for all. And
once firmware is ready, it is restored back. However, not all hardwares
(for example QCN9274) supports ASPM. Hence there is a need to conditionally
restore ASPM back. Or else, for such hardwares, issue can be seen during
sending and receiving packets.
Introduce a new hardware param supports_aspm which identifies whether a
given hardware supports ASPM or not and then accordingly restore it.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240709055817.3371406-1-quic_adisi@quicinc.com
We should not be checking the return values from debugfs creation at all: the
debugfs functions are designed to handle errors of previously called functions
and just transparently abort the creation of debugfs entries when debugfs is
disabled. If we check the return value and abort driver initialisation, we break
the driver if debugfs is disabled (such as when booting with debugfs=off).
Earlier versions of ath9k accidentally did the right thing by checking the
return value, but only for NULL, not for IS_ERR(). This was "fixed" by the two
commits referenced below, breaking ath9k with debugfs=off starting from the 6.6
kernel (as reported in the Bugzilla linked below).
Restore functionality by just getting rid of the return value check entirely.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=219122
Fixes: 1e4134610d93 ("wifi: ath9k: use IS_ERR() with debugfs_create_dir()")
Fixes: 6edb4ba6fb5b ("wifi: ath9k: fix parameter check in ath9k_init_debug()")
Reported-by: Daniel Tobias <dan.g.tob@gmail.com>
Tested-by: Daniel Tobias <dan.g.tob@gmail.com>
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240805110225.19690-1-toke@toke.dk
Using devm_gpio_request_one() is simpler as then we don't need to call
gpio_free().
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240731210312.7622-1-rosenp@gmail.com
It may get wrong bitrate when connecting to AP set VHT 20MHz,
and thus we fix it to follow Wi-Fi spec.
Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240731070506.46100-6-pkshih@realtek.com
Add hardware encryption support for unicast management frames for
8922AE and 8852CE. Other chips will continue to use software
encryption for unicast management frames.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240731070506.46100-5-pkshih@realtek.com
Update scan offload H2C format to fit firmware version 35.21.
The new fields indicate lengths of variable length members, so
when driver and firmware are using mismatch version, FW could
handle the parsing better.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240731070506.46100-3-pkshih@realtek.com
For firmware version 0.35.31 and above, update H2C RFK
pre-notify to new implementation. Rename existing H2C
to v0 for backward compatibility.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240731070506.46100-2-pkshih@realtek.com
In 'brcms_c_ffpld_check_txfunfl()', 'current_ampdu_cnt' is hardcoded to
zero, so 'txunfl_ratio' is always zero as well and some dead code can be
removed. Compile tested only.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Dmitry Kandybka <d.kandybka@gmail.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240801101531.6626-1-d.kandybka@gmail.com
When the firmware interface layer was refactored it provided various
"get" and "set" functions. For the "get" in some cases a parameter
needed to be passed down to firmware as a key indicating what to
"get" turning the output parameter of the "get" function into an
input parameter as well. To accommodate this the "get" function blindly
copies the parameter which in some places resulted in an uninitialized
warnings from the compiler. These have been fixed by initializing the
input parameter in the past. Recently another batch of similar fixes
were submitted to address clang static checker warnings [1].
Proposing another solution by introducing a "query" variant which is used
when the (input) parameter is needed by firmware. The "get" variant will
only fill the (output) parameter with the result received from firmware
taking care of proper endianess conversion.
[1] https://lore.kernel.org/all/20240702122450.2213833-1-suhui@nfschina.com/
Fixes: 81f5dcb80830 ("brcmfmac: refactor firmware interface layer.")
Reported-by: Su Hui <suhui@nfschina.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240727185617.253210-1-arend.vanspriel@broadcom.com
In the "struct brcmf_ampdu_rx_reorder", change the 'pktslots' field into
flexible array.
It saves the size of a pointer when the memory is allocated and avoids
an indirection when the array is used.
It also removes the usage of a pointer arithmetic and saves a few lines of
code.
Finally, struct_size() can be used. It is not a must have here, because
it is easy to see that buf_size can not overflow, but still, it is a good
practice.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/f4ca6b887ca1290c71e76247218adea4d1c42442.1721547559.git.christophe.jaillet@wanadoo.fr
Add host based MLME to enable WPA3 functionalities in AP mode.
This feature required a firmware with the corresponding V2 Key API
support. The feature (WPA3) is currently enabled and verified only
on IW416. Also, verified no regression with change when host MLME
is disabled.
Signed-off-by: David Lin <yu-hao.lin@nxp.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240704033001.603419-3-yu-hao.lin@nxp.com
Add host based MLME to enable WPA3 functionalities in client mode.
This feature required a firmware with the corresponding V2 Key API
support. The feature (WPA3) is currently enabled and verified only
on IW416. Also, verified no regression with change when host MLME
is disabled.
Signed-off-by: David Lin <yu-hao.lin@nxp.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240704033001.603419-2-yu-hao.lin@nxp.com
The maximum number of AKM suites will be set to two if not specified by
the driver. Set it to CFG80211_MAX_NUM_AKM_SUITES to let userspace
specify up to ten AKM suites in the akm_suites array.
Without only the first two AKM suites will be used, further ones are
ignored.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240530130156.1651174-1-s.hauer@pengutronix.de
Originally, rtw89_btc_phymap() and rtw89_btc_path_phymap() access chan
with hard-code RTW89_CHANCTX_0. But, they are problematic when the chip
supports multiple channels.
So, change their prototype and pass chanctx_idx ahead. Let callers still
pass RTW89_CHANCTX_0 for now, but we will refine callers in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240727080650.12195-8-pkshih@realtek.com
Originally, these H2C commands access chan with hard-code RTW89_CHANCTX_0.
They are problematic when the chip supports multiple channels. So, correct
them by accessing right chan under rtwvif.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240727080650.12195-7-pkshih@realtek.com
For chips supporting multiple channels, they need to get target info
from rtwvif, e.g. PHY index and Chanctx index.
So, change rfk_scan prototype and pass rtwvif ahead.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240727080650.12195-6-pkshih@realtek.com
For chips supporting multiple channels, they need to get target info
from rtwvif, e.g. PHY index and Chanctx index.
So, change rfk_channel prototype and pass rtwvif ahead.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240727080650.12195-5-pkshih@realtek.com
Originally, we planed to fill MAC_0/1 indicators with chanctx and
use sub_entity_xxx for these things. However, there are some reasons
listed below which make us give up this plan after we know our Wi-Fi 7
HW design.
1. one link is bound to one HW band during its life time
but, one link might change chanctx dynamically
2. in concurrent mode, assume 1st vif is MLD
1st vif's 2nd link might use the same chanctx as 2nd vif
but, they are not on the same HW band
So, we let sub_entity_xxx stuffs deal with only chanctx now. And, to be
more readable, we rename sub_entity related words to chanctx.
No logic is changed.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240727080650.12195-4-pkshih@realtek.com
