This pull request contains iwlwifi features and cleanups. Notably:
- Bump max core version for BZ/SC/DR to 106.
- Add KUnit tests for link grading, RSSI adjustment, and beacon
handling;
- Drop core101 support and remove TLC config v4/v5 compatibility code.
- Fixes:
Fix PCIe write pointer detection
Fix STEP_URM register address
Remove unneeded WoWLAN warning
reduce NIC wakeups during dump.
Revert MODULE_FIRMWARE relocation change
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQM3A3Pv7vbm9vtjWbacY7uyt+OfQUCaiA4nQAKCRDacY7uyt+O
fcECAQC8YSlz1duQiMiuLTQ1WJ55yG8hncvPlgvUwEUHD8E/wgEAgjHPS566XWfU
/H4pc3CEZT+w8LRHhvvJiYWXpmmnvgs=
=+5Cu
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-next-2026-06-03' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
Miri Korenblit says:
====================
wifi: iwlwifi-next : updates - 2026-06-03
This pull request contains iwlwifi features and cleanups. Notably:
- Bump max core version for BZ/SC/DR to 106.
- Add KUnit tests for link grading, RSSI adjustment, and beacon
handling;
- Drop core101 support and remove TLC config v4/v5 compatibility code.
- Fixes:
Fix PCIe write pointer detection
Fix STEP_URM register address
Remove unneeded WoWLAN warning
reduce NIC wakeups during dump.
Revert MODULE_FIRMWARE relocation change
====================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In ath12k, add driver support for WDS mode.
In ath11k and ath12k, a number of cleanups and minor bug fixes.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ/mtSHzPUi16IfDEksFbugiYzLewUCah7oAwAKCRAsFbugiYzL
e4FRAQDP7XeGi3lDh02TlRthSY1z1fw8dTnUoHrok3MozxwGrQEAztgSQg1wjERh
PAKcUibVH/ebQf5MHziPl+/ZR24RCwM=
=iZG5
-----END PGP SIGNATURE-----
Merge tag 'ath-next-20260602' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
Jeff Johnson says:
==================
ath.git patches for v7.2 (PR #3)
In ath12k, add driver support for WDS mode.
In ath11k and ath12k, a number of cleanups and minor bug fixes.
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The firmware version number check for IGTK introduced in
commit c34dbc5900 ("wifi: wlcore: Add support for IGTK key")
lets the amount of ciphers decrease on every boot of a too old firmware and
that is practically happening. It also does not take into account other
chips than the wl18xx. On some wl128x, the following can be observed
when connecting via nm to a common ap:
[ 484.113311] wlcore: WARNING could not set keys
[ 484.117828] wlcore: ERROR Could not add or replace key
[ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5)
[ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142
[ 484.139923] wlcore: pc: 0x0, hint_sts: 0x00000048 count: 1
[ 484.145721] wlcore: down
[ 484.148986] ieee80211 phy0: Hardware restart was requested
[ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142)
[ 484.633758] wlcore: Association completed.
[ 484.690490] wlcore: ERROR command execute failure 14
[ 484.690490] ------------[ cut here ]------------
[ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xx_queue_recovery_work+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892
This repeats endlessly.
Always disable IGTK on wl12xx and fix the decrementing mess.
Fixes: c34dbc5900 ("wifi: wlcore: Add support for IGTK key")
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Link: https://patch.msgid.link/20260604103316.377251-1-andreas@kemnade.info
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
sys_systime is an alias for sys_realtime. The latter will be removed so
switch the code over to the new naming scheme.
No functional change.
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Tested-by: Arthur Kiyanovski <akiyano@amazon.com>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20260529195557.946612509@kernel.org
iwlwifi only supports CLOCK_REALTIME timestamps and provides an incomplete
result without system counter values etc.
It also zeros struct system_device_crosststamp, which is already zeroed in
the core and initialized with the clock ID.
Remove the zeroing and reject any request for a clock ID other than REALTIME.
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Tested-by: Arthur Kiyanovski <akiyano@amazon.com>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20260529195557.535447186@kernel.org
Add tests for PSD/EIRP RSSI adjustment which compensates measurements
when APs use PSD-based power scaling with bandwidth.
Tests cover all power types, bandwidths, and limiting scenarios.
Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
Link: https://patch.msgid.link/20260531135036.a18b8d0acd62.I68dfcc17359ab8a5abdc84e1e21db4ad1671af41@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
FW core102 bumped TLC_MNG_CONFIG_CMD_API_S from version 5 to
version 6. The v4 and v5 compatibility paths in
iwl_mld_send_tlc_cmd() are no longer reachable on any supported
firmware.
Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com>
Link: https://patch.msgid.link/20260531135036.c0e2dbfd0569.I44f8eb4d985bb9590b65b77e9a3dd157e4bd5e79@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
We don't acually need to always check the return value. For example, if
we send a command to remove an object - we can assume success
(if it fails it is probably because the fw is dead, and then it doesn't
have the object anyway).
Remove the annotations.
Link: https://patch.msgid.link/20260531135036.434473c7b29a.I455e0c3f93c25635df708da7d3216c183dbdbbbb@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
BZ, DR and SC no longer need to accept core101 firmware.
Raise the minimum supported firmware core from 101 to 102 so
these families only match supported core102 and newer images.
Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com>
Link: https://patch.msgid.link/20260531135036.4ece89be11a9.If00f9c7e011ec75219d28a38ca2077a926afc70e@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
FW core102 removed both DC2DC_CONFIG_CMD_API_S and
DC2DC_CONFIG_CMD_RSP_API_S. The only driver-side artifact is
enum iwl_dc2dc_config_id in fw/api/config.h, which has no
callers in any .c file across all driver paths (mld/mvm/xvt).
Remove the dead definition.
Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com>
Link: https://patch.msgid.link/20260531135036.487ceed62714.I13cf8cc214c68899379112e8e52f0cd38dc7b6f8@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Ever since the TFD queue size is no longer limited to 256 entries,
this code has been wrong, and might erroneously not detect a move
if it was by a multiple of 256. Not a big deal, but fix it while
I see it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260531135036.87ffbeab298e.I4fae41383b6756bccbed250985e0521b68a40d0c@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Our binding handling for P2P-Device can run into the following
scenario, as observed by our testing:
- a station interface is connected on some channel
- the P2P-Device does a remain-on-channel (ROC) on that channel
- the ROC ends, and the P2P-Device is removed from the binding,
but the phy_ctxt pointer is left around as a PHY cache so we
don't need to recalibrate to the channel again and again in
case it's not shared
- a binding update by the station interface, even a removal,
will re-add the P2P-Device to the binding
- the P2P-Device is removed, which removes the PHY context, but
it's still in the binding so the firmware crashes
Since the P2P device is removed from the binding and only re-
added by unrelated code, but we want to keep the phy_ctxt around
as a cache for future ROC usage, fix it by adding a boolean that
indicates whether or not the P2P-Device should be added to the
binding, and handle that in the binding iterator. That way, the
station interface cannot re-add the P2P-Device to the binding
when that isn't active.
Assisted-by: Github Copilot:claude-opus-4-6
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260527230313.07f94335ae06.I384238b0859343c4a9a9dda20682be1aad89cc9d@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Clearly, from a user perspective, it must be valid to configure
WoWLAN and then suspend while not connected to a network. Since
mac80211 doesn't distinguish these cases and simply calls the
driver to suspend whenever WoWLAN is configured, the driver has
to cleanly handle the case where it's called for WoWLAN, it's
not connected but there's also no netdetect configured.
Remove the WARN_ON() and keep returning 1 to disconnect and
then suspend.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260527230313.19720967372b.Iff30814510a26f9f609f98eeea3111c50c1afb31@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
IWL_BZ_UCODE_CORE_MAX is undefined in cfg/rf-fm.c, this
causes __stringify(core) to turn it into the literal
token text, so MODULE_FIRMWARE entries are generated as
"iwlwifi...-cIWL_BZ_UCODE_CORE_MAX.ucode",
instead of the actual number.
This reverts the commit below.
Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com>
Link: https://patch.msgid.link/20260527230313.a10bc3359dca.I446a1340c635f07aff3efaba5317635e010c156f@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
While associated to MLD AP with active EMLSR, set all scan
operations as fast-balance scans. The only exception is when a
fragmented scan is planned (high traffic or low latency), in
which case the fragmented scan is preserved.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Link: https://patch.msgid.link/20260527230313.32d278842b0e.Ia3d73e4085eefc4d3921e93de4107b2d6a6f922e@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Add a new FW TLV (IWL_UCODE_TLV_FW_NAN_MAX_CHAN_SWITCH_TIME) that
allows the firmware to specify the NAN maximum channel switch time
in microseconds.
When the TLV is present, use its value for the NAN device capability.
Otherwise, fall back to the default of 4 milliseconds.
Signed-off-by: Israel Kozitz <israel.kozitz@intel.com>
Link: https://patch.msgid.link/20260527230313.e8ae1a3adacd.I15b933407ca3974a65047b63b4f9b00bed3520fb@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The mimo field of the sta command is badly named. It really carries the
initial SMPS value as it is in the association request of the client
station (when we are the AP).
In NAN we don't have this information, just mark SMPS as disabled.
Link: https://patch.msgid.link/20260527230313.abd136be474e.I9eb663d953b482236345ffbcb611f28facea83c1@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Given that we now use v3 rates with FW index throughout,
_to_hwrate() is confusing, since the hardware still uses
the PLCP value, the driver just doesn't see that now (as
it talks to firmware, not hardware.)
Rename this to iwl_mvm_rate_idx_to_fw_idx() to more
clearly indicate what it's doing.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260527230313.a60c8aea5b6c.I6af48d5d9748e184eed9d3437d312291cab61d7f@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
We dereference the mld_sta pointer before checking for NULL.
But we do check the sta pointer, and sta != NULL means mld_sta != NULL,
so there is no real issue.
Fix it anyway to silence the warning.
Link: https://patch.msgid.link/20260527200512.506707-2-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Currently, the dump code attempts to dump any number of
memories and register banks, as defined by the firmware.
Especially when the device is failing, this can lead to
excessive time spent attempting to acquire NIC access
over and over again.
Improve the code to only attempt to acquire NIC access
once or twice, but using the new memory dump functions
that may drop the spinlock etc. Mark all dump regions
that require NIC access, and skip them if we couldn't
obtain that.
In order to avoid CPU latency due to the increased time
holding the spinlock (and possibly disabling softirqs),
drop locks and call cond_resched() after each section
(if holding NIC access) but don't release HW NIC access.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260527230313.bec886142cc8.I41f2eaf2403b38147504d5dab0a7414de2699adc@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
AX231 is a device that is based on AX211 that doesn't support 6E and
its bandwidth is limited to 80 MHz.
Just reuse the radio config from AX203 which has the exact same
characteristics.
It has a specific subdevice ID to allow the driver to differentiate
between AX211 and AX231.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260512082114.0685ed313987.Ibcfa24e196ac778405d2843f0984b66ca167704e@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Pull-request includes many random fixes and new features.
Major changes are listed below:
rtl8xxxu:
* declare supported channel width by firmware report
rtw88:
* validate RX descriptor to avoid malformed data causing warnings
rtw89:
* support USB devices RTL8922AU
* add sysfs entry to show SN and UUID for specific USB devices
* support to switch USB 3.0 mode for higher performance
* add more fields (mainly SIG-A/SIG-B) to radiotap in monitor mode
* offload packed IO to firmware to reduce IO time (for USB devices)
* add debugfs to diagnose BB healthy
* more preparations for RTL8922DE
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuyEnvMdOsBl1WjpdjlvZYmhshd8FAmof2vIACgkQjlvZYmhs
hd8Zvg//dgZR/XeDKnWS0wrI8kKock83ITTClT2en+N3BKlVRJp2SkU17F1owp5s
XHHFpyc29wWOJFy2+/rYiDr4Av0kL0Mkapsguh+bqHvJYrl3nlAziriEouQjTu/E
wHe3bz0j5wbR6eEGlUQ1dR5978CoQiAz70vtSwzcrULCqGD64DROB4eFidZO41m2
gON9Ldwc1oWWUnoIk3vwe9/19G7gkBcSWB7mSHJaxn5Od0Ma37qE6pXqtJ6o/hk2
WExhtWxfloMGRncyj1Mmcydyfuoh24pxZENnGjUSx0P2ndEpf/YwPtyoYYKL99ic
2dQ6xgZzToq3ykyWxp6Hi336UNRHD88udL1TNgpQ3gXllFfBLuRd39HBXcywPRf7
lViysy7BgS2325It99yumEzTIF13x0znrA5Z9R2wXK30DPxaL3Ov3Z4PSbUDgBCR
3fky5v9GXJ6nNOUETWCvOzJ1gTKrWexxNGX5MTAm2gd84kBg8ndAPH0qcc7wFjJC
o7qHTCtGBCu5pSnxgxL3y8dTrk/WQYhMM0FjqF1ok2ddxJDtgw4FYg/MW82gh2bf
CvS36+GTJg8KF1rHPfMrEpcCFcVMlJQs1l8kfbaXMQrXvpPsvyHjSr3RSKfxEalD
GNiOGWRi0MhL1V9An9JHr5tbWGfCAcEp0DMv/ykvLTQiYwogLWc=
=7iaf
-----END PGP SIGNATURE-----
Merge tag 'rtw-next-2026-06-03' of https://github.com/pkshih/rtw
Ping-Ke Shih says:
==================
rtw-next patches for -next
Pull-request includes many random fixes and new features.
Major changes are listed below:
rtl8xxxu:
* declare supported channel width by firmware report
rtw88:
* validate RX descriptor to avoid malformed data causing warnings
rtw89:
* support USB devices RTL8922AU
* add sysfs entry to show SN and UUID for specific USB devices
* support to switch USB 3.0 mode for higher performance
* add more fields (mainly SIG-A/SIG-B) to radiotap in monitor mode
* offload packed IO to firmware to reduce IO time (for USB devices)
* add debugfs to diagnose BB healthy
* more preparations for RTL8922DE
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
qtnf_pcie_topaz_probe() currently calls devm_request_irq() and only then
disable_irq(). request_irq() installs the action in the irq core
immediately, so qtnf_pcie_topaz_interrupt() can run before the Topaz
private IRQ consumers are initialized, if the hardware misbehaves.
This window is reachable on a running system as soon as probe has
successfully registered pdev->irq but before qtnf_pcie_init_shm_ipc()
sets shm_ipc_ep_in/out.irq_handler. If an interrupt is delivered in
this interval, qtnf_pcie_topaz_interrupt() calls
qtnf_shm_ipc_irq_handler() for shm_ipc_ep_in/out while their irq_handler
callbacks are still unset, so the driver can observe an early IRQ
before its IPC consumer state is ready.
The issue was found on Linux v6.18.21 by our static analysis tool while
scanning request_irq()/disable_irq() registration-order bugs in
wireless PCIe drivers, and then manually reviewed.
Request the IRQ with IRQF_NO_AUTOEN instead and keep the existing
enable_irq() in qtnf_post_init_ep() as the point where interrupts
become visible. This closes the early-IRQ window while preserving the
intended bring-up order.
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Link: https://patch.msgid.link/20260531145435.701703-1-runyu.xiao@seu.edu.cn
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Remove WIPHY_FLAG_SUPPORTS_5_10_MHZ and 5/10 MHz channel
width support. We contemplated this back in early 2023
and didn't do it yet, but nobody stepped up to maintain
it.
It's already _mostly_ dead code since it can really only
be used for AP and maybe IBSS and monitor, but not on a
client since there's no way to scan (and hasn't been in
a very long time, if ever), so the only thing that ever
could really happen with it was run syzbot and trip over
assumptions in the code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20260529084502.080c5885f0b7.I77cc94485b523c3c006005b9233db13cd4e077b3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Expose the device's Serial Number (SN) and UUID from EFUSE via two
read-only sysfs attributes, `serial_number` and `uuid`, on the ieee80211
phy device under the `rtw89_usb` attribute group.
This hardware identification information is essential for user-space
applications to uniquely identify, track, and manage specific Wi-Fi
adapters. For example, in automated factory provisioning or device
management systems, user-space tools rely on the EFUSE serial number and
UUID to bind configurations to specific physical adapters. Currently,
standard wireless APIs do not expose this low-level hardware
information, making these sysfs nodes the only viable solution for
user space to extract this data.
The attributes are gated behind a new RTW89_QUIRK_HW_INFO_SYSFS quirk,
enabled only for the VID 0x28de / PID 0x2432 device via the
dev_id_quirks field in rtw89_driver_info.
Example usage from user-space:
$ cat /sys/class/ieee80211/phy0/rtw89_usb/serial_number
3642000123
$ cat /sys/class/ieee80211/phy0/rtw89_usb/uuid
aaec2b7c-0a55-4727-8de0-b30febccbbaa
Cc: Elliot Saba <sabae@valvesoftware.com>
Cc: Charles Lohr <charlesl@valvesoftware.com>
Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260529075032.16807-3-pkshih@realtek.com
Add a dev_id_quirks field to rtw89_driver_info so that per-device
(VID/PID) quirks can be expressed independently of chip-level
default_quirks. Apply the bitmap in rtw89_alloc_ieee80211_hw() so
both USB and PCI probes benefit automatically.
All existing driver_info structs initialize dev_id_quirks to 0;
no behavior change.
Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260529075032.16807-2-pkshih@realtek.com
Skip the ACPI capability check for all USB devices by default,
allowing them to use their default configurations.
For USB dongles, customers will manage their own compliance and
certification. This initial patch focuses on the generic USB skip
infrastructure; specific customer certifications and localized
configurations will be handled by quirks afterward.
Signed-off-by: David Lee <sc.lee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260525082636.31105-1-pkshih@realtek.com
Add the specific USB device ID which adapter tested fully functional on
Fedora 44 with kernel 7.0.8-200.fc44.x86_64 and linux-firmware
20260410-1.fc44.
Reported-by: Guillermo Servera Negre <guillem@gservera.com>
Tested-by: Guillermo Servera Negre <guillem@gservera.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260525011728.6836-1-pkshih@realtek.com
Whenever hardware receives 4-address EAPOL frames from an unauthorized
station it is routed through WBM/RXDMA error path with the
HAL_REO_ENTR_RING_RXDMA_ECODE_UNAUTH_WDS_ERR error code. But, the
current driver does not handle the 4-address EAPOL frames
in the WBM error path. As a result, these frames are dropped,
causing authentication failures and connectivity issues for 4-address
stations.
Add support to correctly process these frames and forward them to mac80211
for proper handling. This prevents the loss of 4-address EAPOL frames and
ensures reliable connectivity for WDS/4-address clients.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Co-developed-by: Sathishkumar Muruganandam <quic_murugana@quicinc.com>
Signed-off-by: Sathishkumar Muruganandam <quic_murugana@quicinc.com>
Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260525110942.2890212-7-tamizh.raja@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
mac80211 currently relies on receiving 4-address frames from connected
stations to trigger AP_VLAN interface creation. However, when ethernet
encapsulation offload is enabled, mac80211 only receives 802.3 frames
and cannot differentiate between 3-address and 4-address formats,
preventing AP_VLAN creation.
Enable mac80211 to detect 4-address traffic by converting 802.3 frames
back into 802.11 frames in the driver and setting the FROM_DS and TO_DS
bits using the RX_MSDU_END_INFO5_FROM_DS and RX_MSDU_END_INFO5_TO_DS
fields. This restores 4-address frame visibility to mac80211 and allows
it to trigger AP_VLAN interface creation.
Skip this frame conversion once the AP_VLAN interface is created and the
station is attached to it.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260525110942.2890212-6-tamizh.raja@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Currently, the firmware processes all NULL frames internally and
does not forward them to the host. As a result, the host never
receives 4-address NULL frames sent by a 4-address station.
These 4-address NULL frames are sent by the station to indicate
to the AP that it is operating in 4-address mode.
Enable WMI_RSRC_CFG_FLAGS2_WDS_NULL_FRAME_SUPPORT flag during WMI
initialization after verifying the WMI_SERVICE_WDS_NULL_FRAME_SUPPORT
service capability. This enables the firmware to forward all NULL frames
to the host. Add host-side handling to parse 4-address NULL frames and
forward them to mac80211 to support proper AP_VLAN interface creation.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Co-developed-by: Sarika Sharma <sarika.sharma@oss.qualcomm.com>
Signed-off-by: Sarika Sharma <sarika.sharma@oss.qualcomm.com>
Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260525110942.2890212-5-tamizh.raja@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Currently driver does not enable the hardware/firmware support for handling
4-address multicast frames in the Tx/Rx path when 8023_ENCAP_OFFLOAD is
enabled. Add the required support to ensure correct processing of multicast
traffic in 4-address mode.
Enable this functionality by setting the WMI_VDEV_PARAM_AP_ENABLE_NAWDS
vdev parameter when the 8023_ENCAP_OFFLOAD feature is active. Override
peer metadata values for 4-address multicast packet transmission by using
the station's ast_hash and ast_idx instead of vdev-level metadata,
and set HAL_TCL_DATA_CMD_INFO4_IDX_LOOKUP_OVERRIDE to indicate this
override.
Suppress firmware peer-map events for 4-address frames by setting the
WMI_RSRC_CFG_FLAGS2_FW_AST_INDICATION_DISABLE flag during WMI
initialization. This prevents inconsistencies in the host's peer list.
Add the IEEE80211_OFFLOAD_ENCAP_4ADDR VIF offload flag to notify mac80211
that 4-address Ethernet encapsulation offload is supported.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260525110942.2890212-4-tamizh.raja@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
The current driver does not support enabling 4-address mode data traffic
in WDS mode. Add the required functionality by introducing the
sta_set_4addr() API, which is invoked when a 4-address AP/STA connects.
This API sends the WMI_PEER_USE_4ADDR peer parameter to notify firmware
about the 4-address peer, allowing firmware and hardware to transmit
and receive frames in 4-address format for that peer.
For 4-address multicast packet transmission, update the handling
to set peer metadata values in HAL_TCL_DATA_CMD_INFO1_CMD_NUM instead
of using vdev metadata values. Vdev metadata is used only for 3-address
and 4-address unicast traffic and for 3-address multicast traffic.
The peer metadata path embeds the correct peer_id, enabling proper
multicast transmission in 4-address mode.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260525110942.2890212-3-tamizh.raja@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Set WDS vdev parameter during station interface creation to enable
4-address mode. Unlike AP interfaces that set peer-specific 4-address
mode parameters after receiving 4-address frames from stations, station
interfaces must send all data frames in 4-address mode immediately after
association, including 4-address NULL frames.
Firmware requires 4-address notification for station interfaces during
vdev creation. Configure the WDS vdev parameter for station interfaces.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Co-developed-by: Ramya Gnanasekar <ramya.gnanasekar@oss.qualcomm.com>
Signed-off-by: Ramya Gnanasekar <ramya.gnanasekar@oss.qualcomm.com>
Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260525110942.2890212-2-tamizh.raja@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
When multiple links switch channel contexts around the same time, mac80211
may complete CSA for several links together and invoke
ath12k_mac_op_switch_vif_chanctx() with an array of vifs spanning more than
one underlying radio in a single-wiphy configuration.
The driver currently assumes that all entries in the vifs array belong to the
same radio and derives the radio context from the first element. On multi-radio
hardware, this can lead to incorrect vdev selection/updates and may corrupt
driver state when the number of vifs exceeds what a single radio supports.
Fix this by validating each vif's switch request and then processing vifs
grouped by their associated radio. For each vif, ensure the band does not
change across the switch and that both old/new channel contexts resolve to a
valid ath12k device. Reject attempts to move a vif between radios (not
supported for now) and return -EOPNOTSUPP to upper layers.
Then, iterate through the input vifs, collect all unprocessed entries that map
to the same radio, and invoke ath12k_mac_update_vif_chan() separately for each
radio group. This removes any reliance on mac80211 providing the array grouped
by radio or sharing old_ctx pointers across vifs.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1
Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
Co-developed-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260522091828.3199584-1-maharaja.kennadyrajan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Currently, the driver uses memory profile parameters to determine the
maximum number of supported clients, with a default limit of 512 for
single-radio and 128 for DBS and DBS+SBS configurations. However,
some devices have lower hardware limits depending on the radio
configuration. Exceeding these hardware-specific limits can lead to
firmware crashes.
Add hardware parameters in ath12k_hw_params to define the maximum supported
clients for each radio configuration. The driver uses the minimum of the
memory profile limit and the hardware capability limit to prevent exceeding
hardware constraints.
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260515030909.3312511-1-aaradhana.sahu@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
_ieee80211_set_active_links() calls _ieee80211_link_use_channel() for
each newly-added link and WARN_ON_ONCE()s if it fails. The call uses
assign_on_failure=true, which allows mac80211 to continue despite
driver failures, but when a mac80211-level channel validation fails
(e.g., combinations check, DFS, or no available radio),
drv_assign_vif_chanctx() is never reached. Since ath12k_mac_vdev_create()
is only called from that path, arvif->is_created remains false and
arvif->ar remains NULL for the failed link.
The subsequent drv_change_sta_links() call reaches
ath12k_mac_op_change_sta_links(), which allocates an arsta and sets
ahsta->links_map |= BIT(link_id) for the broken link before checking
whether the link is ready. When the vdev was never created, only
station_add() is skipped, but the link remains in links_map.
Any subsequent operation iterating links_map and dereferencing arvif->ar
without a NULL check will crash. Two observed examples are NULL deref in
ath12k_mac_ml_station_remove() on disconnect and in ath12k_mac_op_set_key()
when wpa_supplicant installs PTK keys.
BUG: Unable to handle kernel NULL pointer dereference at 0x00000000
pc : ath12k_mac_station_post_remove+0x40/0xe8 [ath12k]
Call trace:
ath12k_mac_station_post_remove+0x40/0xe8 [ath12k]
ath12k_mac_op_sta_state+0xb60/0x1720 [ath12k]
drv_sta_state+0x100/0xbd8 [mac80211]
__sta_info_destroy_part2+0x148/0x178 [mac80211]
ieee80211_set_disassoc+0x500/0x678 [mac80211]
BUG: Unable to handle kernel NULL pointer dereference at 0x00000000
pc : ath12k_mac_op_set_key+0x1f8/0x2c0 [ath12k]
Call trace:
ath12k_mac_op_set_key+0x1f8/0x2c0 [ath12k]
drv_set_key+0x70/0x100 [mac80211]
ieee80211_key_enable_hw_accel+0x78/0x260 [mac80211]
ieee80211_add_key+0x16c/0x2ac [mac80211]
nl80211_new_key+0x138/0x280 [cfg80211]
Fix this by checking arvif->is_created before calling
ath12k_mac_alloc_assign_link_sta(). This prevents the broken link from
entering links_map, so all subsequent operations iterating the bitmap
are protected. The reliability of arvif->is_created across all error
paths is ensured by the preceding patch.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Fixes: a27fa6148d ("wifi: ath12k: support change_sta_links() mac80211 op")
Signed-off-by: Wei Zhang <wei.zhang@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260512044906.1735821-3-wei.zhang@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
ath12k_mac_vdev_create() has three error path issues that leave arvif
in an inconsistent state:
1. When ath12k_wmi_vdev_create() fails, the function returns directly
without clearing arvif->ar, which was already set before the WMI
call. Subsequent code checking arvif->ar to determine vdev readiness
will see a non-NULL value despite no vdev existing in firmware.
2. When ath12k_wmi_send_peer_delete_cmd() fails in err_peer_del, the
code jumped to err: skipping the DP peer cleanup and vdev rollback,
leaving num_created_vdevs, vdev maps and arvif list membership live.
3. When ath12k_wait_for_peer_delete_done() fails, the code jumped to
err_vdev_del: skipping the DP peer cleanup.
Fix by changing the ath12k_wmi_vdev_create() failure to goto err instead
of returning directly, routing both err_peer_del failure paths through
err_dp_peer_del: for proper DP peer and vdev rollback, and consolidating
the arvif state cleanup at err:.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Fixes: 477cabfdb7 ("wifi: ath12k: modify link arvif creation and removal for MLO")
Signed-off-by: Wei Zhang <wei.zhang@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260512044906.1735821-2-wei.zhang@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
For some chipsets, firmware can report HTT_T2H_MSG_TYPE_PEER_MAP2 with
peer_id 0 as a valid value for mapping ath12k_dp_link_peer to
ath12k_dp_peer.
ath12k_dp_peer_find_by_peerid() currently treats peer_id 0 as invalid.
When firmware assigns peer_id 0, peer lookup fails. As a result,
DHCP OFFER packets are dropped in __ieee80211_rx_handle_packet()
because pubsta is NULL.
ath12k_dp_rx_deliver_msdu() <- rx_info->peer_id 0
ath12k_dp_peer_find_by_peerid -> peer NULL
ieee80211_rx_napi <- pubsta NULL
ieee80211_rx_list
__ieee80211_rx_handle_packet <- pubsta NULL, skb undelivered
The following error in the TX completion path is caused by the same issue:
ath12k_wifi7_pci 0000:04:00.0: dp_tx: failed to find the peer with peer_id 0
The error message is triggered by:
ath12k_wifi7_dp_tx_complete_msdu
ath12k_dp_link_peer_find_by_peerid <- ts->peer_id 0
ath12k_dp_peer_find_by_peerid -> peer NULL
ath12k_dp_tx_htt_tx_complete_buf
ath12k_dp_link_peer_find_by_peerid <- peer_id 0
ath12k_dp_peer_find_by_peerid -> peer NULL
Fix this by allowing peer_id 0 in ath12k_dp_peer_find_by_peerid() and
rejecting only values >= ATH12K_DP_PEER_ID_INVALID.
Also update peer_id 0 handling in monitor path:
Always call ath12k_dp_link_peer_find_by_peerid() in
ath12k_dp_rx_h_find_link_peer() to fetch the peer, including when
peer_id is 0.
Always store peer_id in ppdu_info->peer_id in
ath12k_wifi7_dp_mon_rx_parse_status_tlv(), including peer_id 0.
Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00074-QCACOLSWPL_V1_TO_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Signed-off-by: Hangtian Zhu <hangtian.zhu@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260512025732.1297849-1-hangtian.zhu@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
In ath12k_wifi7_dp_rx_h_verify_tkip_mic(), the call to
ath12k_dp_rx_check_nwifi_hdr_len_valid() may return false when the
NWIFI header length is invalid, causing the function to abort early with
-EINVAL.
When this happens, the error propagates to
ath12k_wifi7_dp_rx_h_defrag(), which clears first_frag by setting it
to NULL. As a result, the corresponding MSDU is no longer referenced
by the defragmentation path and is never freed.
This leads to a memory leak for the affected MSDU on this error path.
Proper cleanup is required to ensure the MSDU is released when header
validation fails during TKIP MIC verification.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Fixes: 9a0dddfb30 ("wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi")
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Reviewed-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260512021108.2031651-1-miaoqing.pan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
In monitor mode, the driver incorrectly assigns the legacy rate
to the rate_idx field of the radiotap header for HT/VHT/HE/EHT
frames, ignoring the actual MCS value parsed from the hardware.
This causes packet analyzers (like Wireshark) to display incorrect
MCS values (e.g., legacy base rates instead of the true MCS).
Fix this by assigning ppdu_info->mcs as the default rate_mcs
in ath12k_dp_mon_fill_rx_rate(), and remove rate_idx assignments in
ath12k_dp_mon_update_radiotap() to preserve
the previously calculated MCS values (including the HT NSS offset).
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ
Fixes: 5393dcb452 ("wifi: ath12k: change the status update in the monitor Rx")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220864
Signed-off-by: Kwan Lai Chee Hou <laicheehou9@gmail.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260507015336.14636-1-laicheehou9@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
When P2P support is enabled, wpa_supplicant creates a p2p-device
interface by default, which implicitly consumes one vdev. On systems
managed by NetworkManager, this interface cannot be reliably disabled,
leaving only two usable interfaces for user configurations.
Increase num_vdevs to four for QCA6390 hw2.0, WCN6855 hw2.0/hw2.1,
QCA2066 hw2.1, and QCA6698AQ hw2.1 to account for the implicit
p2p-device and enable common concurrency scenarios such as AP + AP + STA.
This change increases interface concurrency in the two-channel scenario
by raising the maximum vdev limit, while keeping other combination rules
unchanged.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
Tested-on: QCA2066 hw2.1 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.9
Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
Signed-off-by: Wei Zhang <wei.zhang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260525020711.2590815-1-wei.zhang@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
In the WBM error path, while processing TKIP MIC errors, MSDU length
is fetched from the hal_rx_desc's msdu_end. This MSDU length is
directly passed to skb_put() without validation. In stress test
scenarios, the WBM error ring may receive invalid descriptors, which
could lead to an invalid MSDU length.
To fix this, add a check to drop the skb when the calculated MSDU
length is greater than the skb size.
This is adapted from the discussion/patch of the ath12k driver [1].
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
Link: https://lore.kernel.org/linux-wireless/20250416021903.3178962-1-nithyanantham.paramasivam@oss.qualcomm.com/ # [1]
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260512022351.2033155-3-miaoqing.pan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
In certain cases, hardware might provide packets with a
length greater than the maximum native Wi-Fi header length.
This can lead to accessing and modifying fields in the header
within the ath11k_dp_rx_h_undecap_nwifi() function for the
DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and
potentially result in invalid data access and memory corruption.
Kernel stack is corrupted in: ath11k_dp_rx_h_undecap+0x6b0/0x6b0 [ath11k]
Call trace:
ath11k_dp_rx_h_mpdu+0x0/0x2e8 [ath11k]
ath11k_dp_rx_h_mpdu+0x1e0/0x2e8 [ath11k]
ath11k_dp_rx_wbm_err+0x1e0/0x450 [ath11k]
ath11k_dp_rx_process_wbm_err+0x2fc/0x460 [ath11k]
ath11k_dp_service_srng+0x2e0/0x348 [ath11k]
Add a sanity check before processing the SKB to prevent invalid
data access in the undecap native Wi-Fi function for the
DP_RX_DECAP_TYPE_NATIVE_WIFI decap type.
This adapted from the discussion/patch of the ath12k driver [1].
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
Link: https://lore.kernel.org/linux-wireless/20250211090302.4105141-1-tamizh.raja@oss.qualcomm.com/ # [1]
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260512022351.2033155-2-miaoqing.pan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Convert kzalloc_obj + kcalloc to kzalloc_flex to save an allocation.
Add __counted_by to get extra runtime analysis. Move counting variable
assignment immediately after allocation before any potential accesses.
kzalloc_flex does this anyway for GCC >= 15.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260428205017.26288-1-rosenp@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
In most distributions, NetworkManager shuts the device down before
entering system suspend, so fast suspend is typically not used.
On older devices, resume currently tries to grab NIC access to infer
whether the device was powered off while suspended. That probe is only
meaningful for the fast-suspend path where the device is expected to
remain alive.
Unfortunately, for unclear reasons, grabbing NIC access was harmful as
reported in the bugzilla ticket below.
Workaround this issue by simply not grabbing NIC access if fast suspend
is not used.
Cc: stable@vger.kernel.org
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221501
Assisted-by: GitHub Copilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260531133005.e2ed9e0cd44f.If283625983a843933e0c01561a421daff184e9e9@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
MCC_ALLOWED_AP_TYPE_CMD exceeds the fixed copied host-command buffer
and triggers warnings in the gen2 enqueue path when command
0xc05 is sent.
Use IWL_HCMD_DFL_NOCOPY as it was done before the offending commit.
Fixes: 078df640ef ("wifi: iwlwifi: mld: add support for iwl_mcc_allowed_ap_type_cmd v2")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260529085453.9af349ab459b.I348df3980764c15efce0099a35fe8a88fb2a6ee2@changeid
TX power constraints must be sent to the firmware before link
activation. If not, the firmware will use default power values.
Fix this by moving the iwl_mld_send_ap_tx_power_constraint_cmd()
call from iwl_mld_start_ap_ibss() to iwl_mld_assign_vif_chanctx(),
before iwl_mld_activate_link() for AP interfaces. Also update
the guard in the function to allow it to run before link activation
for AP interfaces.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260529085453.06c94b01efd2.Id43bdfe5eb030061c23348779687ba71b5f58182@changeid
For ath12k:
- Add thermal throttling and cooling device support
- Add support for handling incumbent signal interference in 6 GHz
- Add support for channel 177 in the 5 GHz band
In addition, a large number of cleanup and minor bug fixing across
all supported drivers.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ/mtSHzPUi16IfDEksFbugiYzLewUCahXEHAAKCRAsFbugiYzL
e4+OAQCK3CILFdb8JbEVgROb/bfAmGWCAkdEBIMxEbGITQSQCAEAsdLEntym8eJA
rjCjLNz62Dn5KoQLaV436nCjC+UjWwo=
=3Pqg
-----END PGP SIGNATURE-----
Merge tag 'ath-next-20260526' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
Jeff Johnson says:
==================
ath.git patches for v7.2 (PR #2)
For ath12k:
- Add thermal throttling and cooling device support
- Add support for handling incumbent signal interference in 6 GHz
- Add support for channel 177 in the 5 GHz band
In addition, a large number of cleanup and minor bug fixing across
all supported drivers.
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This contains mainly:
UHR support (DPS, DUO, multi-link PM), NAN enhancements
(multicast, schedule config v2, multiple stations), EMLSR fixes, new
Killer/LNL device IDs, firmware API cleanups, and a few bugfixes
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQM3A3Pv7vbm9vtjWbacY7uyt+OfQUCahWQRAAKCRDacY7uyt+O
fSziAP9kJeU1HvEsGF4k5GHP65F/eLvq7hVrQGfx7Q/vP+ZnkAD+O3SZsyoL8mL1
LAr+ixjuMQ6yLd5xonTJvvtyPQwmVAw=
=SpPv
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-next-2026-05-26' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
Miri Korenblit says:
====================
iwlwifi - next: 2026-05-26
This contains mainly:
UHR support (DPS, DUO, multi-link PM), NAN enhancements
(multicast, schedule config v2, multiple stations), EMLSR fixes, new
Killer/LNL device IDs, firmware API cleanups, and a few bugfixes
====================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
It's useful to be able to see the link addresses when the
interface links change, so add some prints to hwsim for the
vif link change callback.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260527224151.b22a048abc7c.Ief2132c5c4bb67fa56e90eb8e7d59dfd9f2b9378@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The current S1G channel list in mac80211_hwsim does not represent
what S1G drivers would advertise that being 1MHz primaries. Also,
include the NO_PRIMARY flag on the edgeband 1MHz primaries to emulate
US operation such that it can also be tested.
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20260527033828.183821-3-lachlan.hodges@morsemicro.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211_hwsim_sta_rc_update() is unable to handle S1G widths so
when a new STA is added under a S1G vif the WARN is hit preventing
hwsim use for S1G. For now, skip calling rc_update() for S1G
interfaces. This is required such that the soon-to-be S1G hwsim tests
can successfully run.
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20260527033828.183821-2-lachlan.hodges@morsemicro.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We know that "start_raw" is true so remove this check and pull the code
in an tab.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Link: https://patch.msgid.link/ahPypOdz-KXh5KAJ@stanley.mountain
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The Realtek wifi 6/7 devices which support USB 3 are weird: when first
plugged in, they pretend to be USB 2. The driver needs to send some
commands to the device, which make it disappear and come back as a
USB 3 device.
Implement the required commands in rtw89.
Add a new function rtw89_usb_write32_quiet() to avoid the warnings
when writing to R_{AX,BE}_PAD_CTRL2. Even though the write succeeds,
usb_control_msg() returns -EPROTO, probably because the USB device
disappears immediately. This results in some confusing warnings in
the kernel log.
When a USB 3 device is plugged into a USB 2 port, rtw89 will try to
switch it to USB 3 mode only once. The device will disappear and come
back still in USB 2 mode, of course.
Tested with RTL8832AU, RTL8832BU, RTL8832CU, and RTL8912AU.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/e955451c-93a1-4d04-8024-d224a04f1d4a@gmail.com
Some RTL8821CE cards can return frames with corrupted RX descriptor,
causing warnings and crashes if they are passed to the upper layers.
The PHY status size field is 4 bits wide, but in rtw88 its value should
only be 0 or 4. Checking this catches most of the corrupt frames.
If a PHY status is present, the PHY status size should not be 0.
The frame size should not be less than or equal to 4 and should not
exceed 11454.
The rate should not exceed 4SS MCS9.
Discard the frame if any of these checks fail.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221286
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Tested-by: Oleksandr Havrylov <goainwo@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/5bfecba3-8a90-4e0f-9558-af5cd8a14975@gmail.com
By default, BB enables triangular spectrum by a series of register
settings. According to band and regulation, RF parameters determine whether
TX shape needs to be restricted or not. So now, clear the corresponding
settings if it has no need to do.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260520123823.1792954-8-pkshih@realtek.com
Support of Large MRU (Multiple Resource Unit) starts from RTL8922D_CID7090,
i.e. RTL8922A and RTL8922D-VS variant do not support it. There are the new
corresponding control registers. So, configure them.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260520123823.1792954-6-pkshih@realtek.com
Because base settings of digital power compensation can be shared across
all bands, the settings are divided into two parts -- base and individual
values per bands. Refactor the code to be reuse with new format.
No change logic at all.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260520123823.1792954-3-pkshih@realtek.com
RF parameters has different TX power track table for different AID.
FW elements may include multiple TX power track tables for different
AID. So, load the corresponding one.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260520123823.1792954-2-pkshih@realtek.com
When arch_init() fails in ath12k_pci_probe(), the code jumps to
err_pci_msi_free, leaking resources in teardown.
Redirect the failure path to err_free_irq so teardown matches the setup order.
Compile-tested only.
Fixes: 614c23e24e ("wifi: ath12k: Support arch-specific DP device allocation")
Signed-off-by: Ripan Deuri <ripan.deuri@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260519192815.3911324-1-ripan.deuri@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Add functions to be able to do memory read under NIC access,
in order to use them later during firmware dump. These may
drop and re-acquire the spinlock, but will not acquire and
release the NIC access.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260517100550.7bb1ea51c347.I91420a24fb0c481c75a2600d60e1365c15c1c5a9@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
There are two dump paths: new "ini" style, and the old,
more driver-centric, way. Separate out the code for the
old way into a separate dbg-old.c file, to simplify.
Fix a typo ('trasport') along the way.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260517100550.1de0f1110d5a.I4faebe15192a1f27cb4b7270fb52154f06eb2a10@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The iwl_{read,write}_prph_no_grab() functions will trace each
access, but in debug dump a lot of accesses already use the
transport versions of these functions directly. Since the data
(register addresses and their content) is going into the dump
file, tracing isn't really needed. Use the transport functions
in all places.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260517100550.bbc7623a0348.I827729916da8f264befbcb90ac6509c359ee97a3@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
This is all fairly manual, with the shifts etc., and
the documentation has to call out the specific bits
(which also isn't usable for our tracing data). Add
an enum that directly declares the bit masks for it
and then use the more modern u8_encode_bits().
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260517100550.bc09f4f6fd29.I315f15856eb36f0490b8f5008537d3e0ffc215f2@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The iwl_txq, iwl_pcie_first_tb_buf and iwl_pcie_txq_entry don't need to
be exported to the op_mode in iwl-trans.h. Declare those in the
transport's internal header file to avoid pollution.
iwl_trans_pcie_send_hcmd can also be moved to the internal header file.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260517100550.208921548b4b.I76b1ac8499275e6d231880861e3843278f278c34@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
When EMLSR exits due to beacon loss on the current link, the driver
should keep the link that is still receiving beacons. The previous
code always called get_primary_link(), keeping the primary link
regardless of which link is actually losing beacons. If the primary
link is the one losing beacons, the driver exits EMLSR onto the
degraded link and the connection is lost eventually.
When both links lose beacons, keep the primary link. When only the
current link loses beacons -- whether due to signal loss or a BSS
parameter change -- keep the other link.
Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
Link: https://patch.msgid.link/20260517100550.b2d700f7775e.I8e9189ce6cf4388878beab14e56341becd5f427c@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
When FW PHY statistics report high channel load (MCLM), the driver
triggers an internal MLO scan to find a better link. However, link grade
computation uses the QBSS Load IE from AP beacons, not MCLM data. If
the AP does not broadcast a QBSS Load IE, the scan produces no benefit
as the grade falls back to static band defaults regardless, and the same
bad link will be selected anyway as the active link.
Skip the MLO scan trigger when the AP does not advertise a QBSS Load IE.
Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
Link: https://patch.msgid.link/20260517100550.621538e20244.I7fdccb759508f32991cc06774cc7621725a58bd3@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
This fixes a kernel panic in reconfig failure:
1. we have a BSS connection
2. we have a NAN connection
3. FW error occurs
4. reconfig restores the BSS connection
5. however, restoring the NAN connection fails due to a FW error.
6. erroneously, ieee80211_handle_reconfig_failure is called and marks all
interfaces as not-in-driver (will be fixed in a different patch).
7. mac80211 frees the links of the BSS connection but doesn't tell the
driver about that, as it thinks that this vif is not in the driver.
8. in ieee80211_stop_device, *ALL* wiphy works are getting flushed
(erroneously?)
9. Therefore, async_handlers_wk is being executed, processing the
statistics notification that was received after we restored the BSS
connection.
10. the notification handler dereferences fw_id_to_bss_conf[id], which is
now a dangling pointer, as mac80211 already freed this link in (7).
11. On the first access to one of the links fields, we panic.
While this can and should be fixed by removing the call to
ieee80211_handle_reconfig_failure in (6), it is also not a good idea to
carry and maybe handle notifications from a dead FW.
We do purge the notifications when we stop the FW, but in reconfig
failure we stop the FW too late, after the notifications are processed.
In addition, async_handlers_wk can always be scheduled before the
reconfig work.
Purge the notifications immediately when transport notifies about a nic
error.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260517100550.4414228bf1d1.I1926a2b2e7827eaac22882699880ec04a3cb95f0@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
iwl_mld_cancel_async_notifications does 2 things: it purges the list of
notifications and flushes the async_handlers_wk.
We call iwl_mld_cancel_async_notifications after we stopped or suspended
the fw. So in that stage we don't expect any new notification coming,
and if erroneously there are new notifications coming, the work will be
queued again anyway, so the flush is pretty much pointless.
iwl_mld_cancel_async_notifications will need to be called in a context
w/o the wiphy lock held, and the only reason why this function requires
the lock being held is for flushing the work.
Remove the flush.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260517100550.70dddca96191.I06d3c6433ec22f81f2fb3fb2ee43881e662c5212@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
FM continues to follow the BIOS/MCC policy, while WH sets
DISALLOW_PUNCTURING for US/CA and clears it for other MCC values.
Update the MCC handling accordingly.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260515150751.df1f1fdd141f.I900c9e2e3dd722619db12ba10d0879a56a2a55f2@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Store beacon_average_energy from per-link FW statistics and expose it
via station_info as rx_beacon_signal_avg in sta statistics.
This fixes missing beacon average signal reporting to upper layers.
Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com>
Link: https://patch.msgid.link/20260515150751.a74a22d90890.I74d596359c5b69364fb977fdf31396eb57ca0927@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
When a GTK is configured for a station, it can only be used for Rx
and never for Tx. In such a case, set the IWL_SEC_KEY_FLAG_NO_TX
flag when the key is installed, so the FW will not use it for Tx.
Specifically, this is needed for per-station GTK installed on NAN
NDI stations associated with NAN Data interfaces.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260515150751.b004744087cb.I25fb83f9e3dc563d122a160da150d793155513fa@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The FW API doesn't allow a station (of certain types, including
STATION_TYPE_PEER) to not be correlated to any link. Therefore,
when switching links, mac80211 first adds the new link and then
removes the old one.
In case we have a NAN interface that operates on 3 links and a
BSS interface that operates on the 4th link, there won't be any
room to perform a link switch that temporarily needs two links
for the BSS interface, but the firmware only has four total.
To mitigate this, try to evacuate a NAN channel in this scenario:
First try to evacuate a NAN channel using the same phy as the BSS
link being deactivated, since we expect NAN to follow the BSS
channel configuration. If that doesn't work, try to evacuate any
NAN channel.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260515150751.a193c0f41b1f.I1d56c8d8d61d110422271971843b71a93f5ec354@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
For multi-link power management, the driver really only needs
to advertise the capability and tell the firmware that the AP
has it. Implement this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260515150751.a28557532e2b.Id35c7f7c319c36daf8ef35fec28940d4db6fc253@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The firmware needs to know whether or not DUO (assisting) is
supported by the AP, and we should claim DUO support ourselves.
Implement this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260515150751.c006eda0139a.I2b1b540c256d29b3b6af21f7eacbe1f549734e9f@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Add the availability attribute to the schedule config command. The
firmware needs to add this attribute to schedule update frames
(e.g. when ULW changed or the local schedule changed).
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Link: https://patch.msgid.link/20260515150751.97809376508e.Ie7f00f97992016c6bb2f4a5c9fc201ac58eed8ce@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
For NAN data, the supplicant may derive and install GTKs to
transmit with. As multicast data encryption is supported only
with firmware versions that support adding NAN multicast
data station, allow GTK installation only with such FW
versions. Otherwise, do not install the GTK to the device.
For NAN management, there are no GTKs, but there are IGTKs
and BIGTKs, which need to be installed for the NAN broadcast
and NAN management stations. This is supported only with
firmware versions that allow adding NAN broadcast station
and NAN management station.
Handle both of these cases by adjusting the station mask
appropriately, returning a zero station mask for the GTK
and allowing that to not be an error/warning message.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Co-developed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20260513084215.7e18e0718d22.Icbf4204a9f1190eb4102016ad5f1c5bdab49635b@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The FW added a new station type to allow NAN multicast
data to be transmitted. The queue of the station is
opened by the firmware when all the NAN Peer NDI stations
associated with the NDI are scheduled at the same time.
Add the corresponding support in iwlmld:
- When a NAN data interface is added, add a NAN multicast
data station and allocate a queue to it.
- When a NAN data interface is removed, remove the NAN
multicast station.
- On the Tx path, when a multicast data frame is received
on a NAN data interface, direct it to the NAN multicast
data queue.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20260513084215.1d8e3463717d.I57deaea42bce9afee63f284a57eb8755485e7ea8@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Replace static declarations of IWL_MLD_ALLOC_FN with a new macro
IWL_MLD_ALLOC_FN_STATIC that declares the static.
This is needed to resolve issues with spatch, which fails to handle
functions after "static IWL_MLD_ALLOC_FN".
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20260513084215.861e4554157d.Id07d4037c75f3ebc8a57ac95b14286369fb3467b@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
A firmware API of a mix and match (MAC + RF) is the lower one of the
two. But the MODULE_FIRMWARE of QU/QUZ/SO/MA/TY with GF/HR, was defined
using the max API of GF/HR, which is 100, instead of the max API of
QU/QUZ/SO/MA/TY, which are API 77/89.
Therefore, the wrong firmware files were published in the modinfo,
leading to missing firmware files.
Fix this by using the right API when declaring MODULE_FIRMWARE.
While at it, add a IWL_FW_AND_PNVM entry for SO and GF4, that was
missing.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260513084215.c8dcacbeb616.I3d51a9daeda6fb7f52b3014101db79fdc98295d5@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Replace single RSSI-to-grade table with separate tables for each
operational bandwidth. Grade selection now depends on both RSSI and
the link's operational bandwidth.
Improve puncturing penalty calculation to apply proportional reduction
based on unusable spectrum percentage rather than absolute channel count.
Update existing KUnit tests with RSSI values for new grading tables.
Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
Tested-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260513084215.9f848b0da851.Id239216fda62e25d343495696cc60742e57d56ea@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
APs operating in PSD mode increase transmit power with bandwidth,
requiring RSSI compensation for accurate link grading.
Parse TPE elements to determine power mode and apply RSSI adjustment
based on operational bandwidth and power constraints.
Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
Link: https://patch.msgid.link/20260513084215.ff1c5ba7491f.I2403678e34625809a7edf02f18760eda16a2c906@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The generated data structures and function names used are
just the debugfs filename, which is a shared namespace and
could lead to confusion. Prefix these with "link_sta_" to
disambiguate.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260513084215.4421f114bb33.I0de78b6b184935bc2a3d77fa649888da31b5a0fb@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
For UHR, implement dynamic power save (DPS). Since the firmware
handles most of it, simply advertise DPS capability and set the
corresponding link flag when the AP has advertised that it is a
DPS assisting AP.
DPS assisting is currently not supported.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260513084215.69c5657f2b0c.I0e0dfcd2e2641a5656a14f01ce696443ae10bc4a@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Add a KUnit test suite for iwl_mld_chan_load_requires_scan,
covering level-up, level-down, and no-change transitions.
The test directly sets channel-load values, validating
scan-trigger decisions and updated load levels
Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
Link: https://patch.msgid.link/20260512222731.4dd3ccaffc46.I9c1f210e5ef25248097a226f4b3a2af5fbcf3c87@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The following limitations arise from the current FW support for NAN:
- While NAN synchronization and discovery beacons are sent
internally by the firmware, the BIGTK is configured to the
auxiliary station associated with the NAN operation. Thus,
the beacons are transmitted unprotected.
- The auxiliary station cannot be configured with support for
management frame protection as this is not supported by the
firmware. Thus, there is no way to protect the SDFs and the
NAFs.
To overcome the above limitations the firmware introduced the
following new station types:
- NAN broadcast station: Used for NAN synchronization and
discovery. i.e., used for beacon transmissions. A BIGTK
can be configured to this station and thus beacons can
be transmitted with protection.
- NAN management station: Used for sending SDFs and NAFs.
This station can be configured with support for management
frame protection etc.
Modify the iwlmld logic to support the older and the newer
firmware designs. As no Tx queue is needed for the NAN
broadcast station, modify the internal station support
to allow adding/removing a station without a queue. In
addition, since no links are associated with these stations,
modify the internal station support to allow adding a station
without a link mask.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20260512222731.692bf627811d.I7170dbaa28a74519c012e2d7818e2999819dc478@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Version 2 of the NAN schedule config command adds support for deferred
schedule update and passing the availability attribute blob to
firmware.
Add support for the new command version. Currently the new
functionality is not supported.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Link: https://patch.msgid.link/20260512222731.422e4bc47f84.I04b7dec6f3e48cfd950e7ff6f13484d0881d832e@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
For 6 GHz duplicated beacons, the RSSI is measured only on the 20 MHz
primary channel while the actual beacon energy spans the full
operational bandwidth. This leads to underestimated link quality.
Detect duplicated beacons and apply bandwidth-based RSSI adjustments.
Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
Link: https://patch.msgid.link/20260512222731.a4c873e63054.Iea8e8a5f3b384622308dd8d03c5881ff75f1908c@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Add support for a new RSC notification that arrives on DATA queues.
The same RSC handling previously done in the WOWLAN flow is now done
through this notification, with backward compatibility maintained.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260512222731.2c0cd8b43e67.I7cfee4b57e7f84b0d38667290f45ed5be4cdd270@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
iwl_mld_stop_nan() calls iwl_mld_flush_link_sta_txqs() without checking
that aux_sta.sta_id is valid. The DW end handler correctly guards this
with a WARN_ON check. Add the same defensive check to stop_nan for
consistency and to avoid sending a flush command with an invalid sta_id.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20260512222731.76b3db062a5e.I0567cfeb915c38c517eb6e1829d78c9fa8653c1f@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
ieee80211_get_channel() can return NULL if the frequency is not
registered in the wiphy (e.g. due to regulatory domain restrictions).
The returned channel pointer is passed directly to
cfg80211_next_nan_dw_notif() which dereferences it unconditionally
in both the tracepoint and the netlink message, causing a NULL
pointer dereference.
Add a NULL check before using the channel pointer.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20260512222731.a250203cd1c6.I1d807aab415da30a55dd89a974c3226adc547ebb@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Use IWL_DEBUG_INFO instead of IWL_INFO for logging the DW end
notification, as this is a recurring event during NAN operation
and should not spam the kernel log.
Also fix a coding style issue - missing space after 'if'.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Link: https://patch.msgid.link/20260512222731.0fd880fb80f9.Iacd459d0e2df28444bb6ccf8730e2f50440e6e32@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
uAPSD is transitioning to a certification-only feature. The new
firmware API version 3 removes advanced uAPSD fields, keeping only
basic parameters needed for certification testing.
Support the new VER_3 API in the MLD driver while maintaining
backward compatibility with VER_1/2. The MVM driver continues
using VER_2 only. Remove the obsolete PSM_UAPSD_AP_MISBEHAVING_NOTIFICATION
notification from the MLD driver
Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
Link: https://patch.msgid.link/20260512222731.96b6f53c8708.I4f01b97b25d91ebb1561845d7925103e274574fa@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The driver supports intalling IGTK on a NAN device interface. When
the IGTK is removed, iwl_mld_free_ap_early_key() is called which
results in a warning since no links are attached to this interface.
The iwl_mld_free_ap_early_key() function should be called for AP or
IBSS interfaces only. Check the interface type before calling it.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Link: https://patch.msgid.link/20260512222731.d67d658b421d.Ife2d1f3b17119ce696582ce6a2a69026d368d8af@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
On debugfs reset, set the transport FW state to NO_FW
so that the restart won't attempt to send commands,
which of course fails because the FW was killed during
the error dump.
Use iwl_trans_fw_error() now since that's effectively
the same as the old code plus setting the state.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260512222731.cdebf264f5e1.Ia31783c74df0d4b66816a1b34d3771b9a717048b@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Some firmware files can be used for different MACs, for example
for sc2/sc2f, yet might have different FSEQ versions. The files
will then contain multiple bigger FSEQ TLVs indicating the MAC
ID in addition to the version.
For now, since we don't parse this, define only the new format.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260512222731.f31ffbff36b0.I227e5c94d4da79a32058d71539b190384caba03e@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The only flags that could reasonably be used here are
CMD_WANT_SKB and CMD_ASYNC, CMD_SEND_IN_RFKILL doesn't
really make sense and CMD_BLOCK_TXQS just triggers a
warning, as does CMD_WANT_SKB | CMD_ASYNC.
Clear CMD_WANT_SKB since the response SKB isn't used
anyway, and refuse flags other than CMD_ASYNC to avoid
the warnings or other issues.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260512222731.71b8cda9c4e8.I0cccfd67675989b48d003833f5813c8fbded45a6@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
FW has a limitation of how many multicast management keys it supports.
Until today we just assumed this limitation. But now as it is changing,
due to NAN, we need a clear indication from the FW so we know how many
we can install.
Read and store this indication from the FW's TLV.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260512082114.f171962abd2e.Ic678616c7d574de257e5923d56258043a5261674@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
This was needed only to check the NVM for devices that had a specific
firmware image to run the initial calibrations.
Remove this field from newer devices that no longer have a specific
image for those.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260512082114.261b04a1b8f2.I5834a3efd0ae7e601a02cc0582287ced405a0aef@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Advertise UHR capabilities for devices supporting UHR
(i.e. devices with some, but not all, PE RFs.)
For correct support it's also needed to plumb through
the regulatory flags the firmware might have/enforce.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260512082114.ef9ebeb41889.I85b67f4973752bcf62416dabb943b9ddf1e63f16@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The acpi_check_dsm() function expects a bitmap of function
IDs to check for, not a single value. Evidently, on many
platforms function 1 exists so checking for 2 succeeded,
but it's wrong, we need to check correctly for function 2.
Fix that.
Reported-by: Jeremy Compostella <jeremy.compostella@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260512082114.81c4022ae602.Id3f575944ee6b87634cfb976d7334eac227d18a6@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
On parsing NVM in setting country code, if firmware reports 0 channels,
buffer is allocated for 0 rules but a dummy rule is added for cfg80211
compatibility, causing kmemdup() to read 128 bytes from a 32-byte buffer.
Allocate regd buffer for one rule addition when reported
channels are 0.
Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
Link: https://patch.msgid.link/20260511203428.e03cd831bc96.I8260d881eebe3e83d3208959b525c51af26414e6@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The field being reported here is part of the EHT union, and not
valid in EHT TB. Don't report it there. We could probably report
the station ID we're following, but for now just don't, since it
appears nobody really cared.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260511203428.b23984f12a46.Ia25014392129d5815facaacec78ea8ba7f35d9a0@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Due to FW/HW limitations and the MME being at the end of the
frame, the devices only support a single IGTK for RX. For TX
multiple aren't needed, only the latest will be used, but in
the device there are space restrictions, so we can also only
install one.
For NAN, however, we will have one for RX for each peer, and
one for ourselves to transmit with.
Separate out the tracking of IGTK: instead of being per link
make the TX ones per link and the RX ones per (link) station.
Note that we currently hardcode that the FW can only have two
(IWL_MAX_NUM_IGTKS) IGTKs, which won't be sufficient for NAN
with security, concurrently with BSS.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260511203428.8fa6859b185d.I584e8b9d238f0b9ef6b65f95114c255209d1c2a3@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
In order to support NAN, TLC now has a station bitmap. Use this
and update TLC for the NAN stations accordingly whenever links
(and thus PHYs) change, and whenever else mac80211 might update
the rate scale information.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Co-developed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260511203428.ea4112d28331.Ie11049c12a4765a97f3e6dfd1ea4afb265c93817@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The internal key APIs, when called with group keys where mac80211
doesn't pass the (AP) station pointer, are still sometimes called
with the AP station pointer on internal calls. This is confusing.
Clean it up and always call them with the AP STA when it exists,
even when coming in from mac80211, by looking it up immediately.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260511203428.0efcbac3e96e.I5b78af51df283d452fc4f1366b04b4769f60f24e@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
We should stick to mac80211's flow to start / stop beaconing. This
allows to stop beaconing before we remove the BIGTK.
Note that the start and stop beaconing flows are not exactly symmetric.
When we start beaconing, we just update the beacon template. We assume
that mac80211 won't update the beacons, if we're not supposed to be
sending it.
Also note that we now send the beacon template after the broadcast
station was added to the firmware: the broadcast station is added in
the start_ap() flow, while the beacon template is now added in the
link_changed() flow which happens later. This is not what we did
before this patch, but this sequence is supported by the firmware as
well.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260511203428.cf10e5754171.I8022517c6c5aedb4b56fba30a5545de8f62dddbe@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The max_channel_switch_time in wiphy_nan_capa is in microseconds, but
the value was set to 4, which is only 4 microseconds instead of the
intended 4 milliseconds.
Fix by using 4 * USEC_PER_MSEC.
Signed-off-by: Israel Kozitz <israel.kozitz@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20260510234534.cb3c05e5d334.I89d9f336aaf388c6e48769de5fe1e5db19295057@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Frames that are sent to an NMI station are always NAN management frames.
Therefore there is no need to configure TLC for such a station.
Always use host rate for the frames going to that station.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260510234534.fb7272ddbb45.I843dba36f52363bc7e9c81f937547ead12147539@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The firmware requires links for NAN which mac80211 doesn't use,
so introduce a new NAN link data structure that the driver has
for itself only, and handle the link command sending code for
NAN using this data structure, most of the bss_conf data isn't
used for NAN anyway, so those structures aren't useful.
With that, add, activate, deactivate or remove links depending
on the local NAN schedule updates.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Co-developed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260510234534.39ee3533ef30.I81ff6dc02e912396040f922e21888fd94b3c26e6@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Until now we maintained the NAN vif in the driver only. The fw used the
AUX MAC for sync and discovery operations.
But when we want to configure a local schedule, we need to add the MAC
first.
NAN_DATA interfaces are not added to the FW. Instead, the local
address of these interfaces are configured to the FW via the NAN MAC.
Add the add/remove/update operations for the NAN interface, and fill the
NAN special parameters in it.
Note that this doesn't fully implement the schedule change, but only the
addition/removal of the NAN MAC. The full schedule management
implementation will come in a later patch.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Co-developed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260510234534.dd12944c140b.I3578198660a533faf9f6a94432ef2114f4a9dfae@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
While NAN stations have the deflink link STA and that even
carries their information, having link STAs mostly implies
having real links, and NAN muddies that by having stations
with deflink carrying their capabilities and links at the
NAN level, but no link stations corresponding to NAN links.
Separate out the data needed to build TLC commands into a
new struct iwl_mld_tlc_sta_capa data structure so that the
whole data usage in the TLC code is clarified and we won't
make assumptions, say about being able to look up the link
of an interface from the (NAN) link sta correctly, which
would result in a link but not with a chanctx.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260510234534.2c6589aab9db.I01729ec8be4687884831fc8761bf3fd8bba83056@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Copy the HT, VHT and HE capabilities from the sbands:
- The HT capabilities from the 2.4 GHz sband (there is no difference
between the bands anyway).
- The VHT capabilities from the 5 GHz sband, obviously.
- The HE capabilities from the 2.4 GHz and for NL80211_IFTYPE_STATION.
Fix it up to include also the needed 5 GHz bits.
For HE, there are bits that are band-dependent and iftype-dependent. For
those set to what makes most sense, and leave a comment to re-visit.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260510234534.3a5e5251dbaf.I566e1749cd17baa672bdd43712114e434f810a69@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Three BA session handlers use ffs(ba_data->sta_mask) - 1 to derive a
station ID without checking that sta_mask is non-zero. When sta_mask is
zero, ffs() returns 0 and the subtraction wraps to 0xFFFFFFFF, causing
an out-of-bounds access on fw_id_to_link_sta[].
Add WARN_ON_ONCE(!ba_data->sta_mask) guards before each ffs() call,
consistent with the existing check in iwl_mld_ampdu_rx_start().
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
Link: https://patch.msgid.link/SYBPR01MB788115C6CE873271A9A15A25AF51A@SYBPR01MB7881.ausprd01.prod.outlook.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Remove header files that are included but provide no symbols,
types, or macros used by the including translation unit.
In iwl-trans.c, fw/api/tx.h defines TX command structures
(iwl_tx_cmd, iwl_tx_resp, TX_CMD_* flags) used by the PCIe TX
path, not by the transport core itself. Similarly, iwl-fh.h
defines Flow Handler register addresses and DMA-related constants
(FH_*, RFH_*, TFD_*) that are consumed by PCIe-specific code,
none of which are referenced in iwl-trans.c.
In iwl-nvm-parse.c, fw/acpi.h defines ACPI/SAR/GEO/PPAG
interfaces (iwl_acpi_*, iwl_sar_*, iwl_geo_*). No references to
any of these interfaces exist in this file.
Signed-off-by: Jay Ng <jayng9663@gmail.com>
Link: https://patch.msgid.link/20260408034413.1875915-1-jayng9663@gmail.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
iwl_mvm_ptp_remove() calls cancel_delayed_work_sync() only after
ptp_clock_unregister() and clearing ptp_data state (ptp_clock,
ptp_clock_info, last_gp2).
This creates a race where the delayed work iwl_mvm_ptp_work() can
execute between ptp_clock_unregister() and cancel_delayed_work_sync(),
observing partially cleared PTP state.
Move cancel_delayed_work_sync() before ptp_clock_unregister() to
ensure the delayed work is fully stopped before any PTP cleanup
begins.
Cc: stable@vger.kernel.org
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Signed-off-by: Junjie Cao <junjie.cao@intel.com>
Link: https://patch.msgid.link/20260212125035.1345718-1-junjie.cao@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
iwl_mld_ptp_remove() calls cancel_delayed_work_sync() only after
ptp_clock_unregister() and clearing ptp_data state (ptp_clock,
last_gp2, wrap_counter).
This creates a race where the delayed work iwl_mld_ptp_work() can
execute between ptp_clock_unregister() and cancel_delayed_work_sync(),
observing partially cleared PTP state.
Move cancel_delayed_work_sync() before ptp_clock_unregister() to
ensure the delayed work is fully stopped before any PTP cleanup
begins.
Cc: stable@vger.kernel.org
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Signed-off-by: Junjie Cao <junjie.cao@intel.com>
Link: https://patch.msgid.link/20260212125035.1345718-2-junjie.cao@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
When rtw_usb_write_port() fails to submit a USB Request Block (URB)
(e.g., due to device disconnect or ENOMEM), the completion callback is
never executed.
Currently, the driver ignores the return value of rtw_usb_write_port()
in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these
functions rely on the completion callback to free the socket buffers
(skbs) and the transaction control block (txcb), a submission failure
results in:
1. A memory leak of the allocated skb in rtw_usb_write_data().
2. A memory leak of the txcb structure and all aggregated skbs in
rtw_usb_tx_agg_skb().
Fix this by checking the return value of rtw_usb_write_port(). If it
fails, explicitly free the skb in rtw_usb_write_data(), and properly
purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb().
The issue was discovered in practice during device disconnect/reconnect
scenarios and memory pressure conditions. Tested by verifying normal TX
operation continues after the fix without regressions.
Fixes: a82dfd33d1 ("wifi: rtw88: Add common USB chip support")
Cc: stable@vger.kernel.org
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Luka Gejak <luka.gejak@linux.dev>
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260518142311.10328-2-luka.gejak@linux.dev
The driver expects the firmware to report TX status within 500ms.
However, a timeout can be triggered when the hardware performs
background scans while under TX load. During these scans, the firmware
stays off-channel for periods exceeding 500ms, delaying the delivery of
TX reports back to the driver.
When this occurs, the purge timer fires prematurely and drops the
tracking skbs from the queue. This results in the host stack
interpreting the missing status as packet loss, leading to TCP window
collapse. In testing with iperf3, this causes throughput to drop from
~90 Mbps to near-zero for approximately 2 seconds until the connection
recovers.
Increase RTW_TX_PROBE_TIMEOUT to 2500ms for RTL8723DU. This duration is
sufficient to accommodate off-channel dwell time during full background
scans, ensuring the purge timer only trips during genuine firmware
lockups and preventing unnecessary TCP retransmission cycles.
Fixes: a82dfd33d1 ("wifi: rtw88: Add common USB chip support")
Cc: stable@vger.kernel.org
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Luka Gejak <luka.gejak@linux.dev>
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260518142311.10328-1-luka.gejak@linux.dev
A user with MLO-capable router reports:
[ 753.080409] rtw89_8922au_git 2-2:1.0: Cannot map qsel to dma v2: 26
[ 753.080417] rtw89_8922au_git 2-2:1.0: Cannot map qsel to dma v2: 26
[ 813.649426] rtw89_8922au_git 2-2:1.0: Cannot map qsel to dma v2: 26
[ 813.649445] rtw89_8922au_git 2-2:1.0: Cannot map qsel to dma v2: 26
[ 813.855983] rtw89_8922au_git 2-2:1.0: Cannot map qsel to dma v2: 26
Map RTW89_TX_QSEL_B1_MGMT and RTW89_TX_QSEL_B1_HI to RTW89_TXCH_CH10.
This is probably the right channel for these queues.
This function is also used for RTL8852AU and RTL8852CU, but those
currently aren't used in DBCC mode with rtw89 so it makes no difference
for them.
Link: https://github.com/morrownr/rtw89/issues/83#issuecomment-4314735734
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/0c8e0cf1-13e9-4c67-a67f-5f6f79fd0658@gmail.com
The existing quota set is for RTL8922DE-VS, so rename the existing tables.
Add new quota set for RTL8922DE, containing more memory to yield better
performance, so rearrange quota accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260515014433.16168-14-pkshih@realtek.com
RTL8922D has many variants, using different quota tables. Consolidate the
quota data into a struct, and then select corresponding table for the
chip variant.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260515014433.16168-13-pkshih@realtek.com
The previous commit aims to fix issue caused by malformed AMPDU frames.
But the drop logic fails to deal with the first AMPDU packet paired with
certain range of sequence number, and leads to unexpected packet drop.
It is more likely to encounter this failure when there are busy traffic
during rekey process and could lead to disconnection from the AP.
Fix this by adding a initial state judgement and only reset status
during pairwise rekey.
Fixes: bda294ed0e ("wifi: rtw89: Drop malformed AMPDU frames with abnormal PN")
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260515014433.16168-10-pkshih@realtek.com
In WoWLAN mode, the firmware periodically sends Null packets to the AP
to keep the connection alive and prevent the AP from disconnecting the
client due to inactivity. However, it was observed that certain APs,
such as TP-Link Archer BE800, do not recognize Null packets as
valid activity and still drop the connection. Replacing Null packets
with ARP reply packets effectively resolves this compatibility issue
and maintains the connection.
Specifically, while the firmware typically handles standard ARP
offloads by dynamically modifying target IP/MAC fields, these
keep-alive ARP reply packets are pre-filled by the driver with the
DUT's own MAC and IP addresses for both sender and target fields.
In this case, the firmware transmits the packets as-is without
further modification. This approach ensures compatibility with APs
that require valid Layer 3 traffic for activity monitoring while
simplifying the firmware's processing logic during WoWLAN mode.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260515014433.16168-9-pkshih@realtek.com
Originally, driver always transmits LTR (Latency Tolerance Reporting) to
pcie host, but it may cause pcie link down on some platforms because
LTR is not supported. As a result, driver will check the control
register of LTR setting to decide whether to enable LTR feature.
This applies to Wi-Fi 6 chips only. For Wi-Fi 7 chips, although the
driver still issues LTR, the hardware has its own internal logic
to determine whether to actually transmit it to pcie host.
Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260515014433.16168-5-pkshih@realtek.com
When SER (system error recovery) happens, there may be some handshake
between FW and SW, e.g. SER Level 1. These handshake are based on H2C
commands and C2H events. Dump the status of them to enhance SER debug.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260515014433.16168-4-pkshih@realtek.com
Wi-Fi 7 FW fixes support of triggering SER L0/L1 simulation via halt H2C
command on v0.35.108.0. After that, the halt H2C command trigger for
Wi-Fi 6 and Wi-Fi 7 can be the same. Update FW feature table and share the
halt H2C command trigger function between Wi-Fi 6 and Wi-Fi 7.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260515014433.16168-3-pkshih@realtek.com
Wi-Fi 7 has dedicated HW register to count SER L0 simulation, i.e.
manually triggered by users. Show count of it in dbgfs ser_counters.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260515014433.16168-2-pkshih@realtek.com
- mac80211/hwsim:
- some NAN related things
- MCS/NSS rate issues with S1G
- p54: port SPI version to device-tree
- (a few other random things)
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEpeA8sTs3M8SN2hR410qiO8sPaAAFAmoPJbIACgkQ10qiO8sP
aAAaPw/+N1dZbDbayDy2sA9oniqpiCJEWspfaK3fnkh1qdpit84tGxEbZtCUIeNB
WYsvvce25qNifWH+xSoma0v+F70eLdlWf6cvjL+dtpf3ITX9HkL055vRtpR+t+vL
/hTtLL8q4OXdu4I/UuCw47ftXzV2zPcHh3+VQK1uR0aM3kXpJhewCAYC3TY1tDVe
+YiUynbidG/893sGnXPG0KMDT92TF/N6sIQLcVw7Yn3d+GjPPP1M0W89FfZzCO5+
ngi529r4VQ8z/XDAWUFzK8SzCNbaVqZtAZt0/NuhfCWOCIXq76qYkJq3L4MxMQRg
MPHDkgKQI5cZB6/zHq1DEdhEcu8f0zo7gTFnSrXbq4I3DkYVpFaOo9JVjcHLKE9f
O6M4fr/a59Zi/jMFPvGDuSItOrR4fERD9H9y+U0DmV6fk4PxXYgE7qWcWDdHdKeD
rtwp5FUHrNZxujKvxR2CPzW0JfCh4IZnb4IFLgloGI79SBJ6JL4WgriHavKGCihq
7JDo3TEn1oh9hcbIytXIZ6ZD8PkGZk93f7HeRuCSDo27SfLOvAR0KKpC1opX0zQw
dWEbTpz4jhmgskb0SM8BmuD+XxhNHPojzMmPdyjtrA7pDRfZfM255/F5++etmgQm
ToS93CEPU4rCZsy7O2NoLQGVZSfXc2y5fCZwTJoBZdUDYRviG7A=
=XLqG
-----END PGP SIGNATURE-----
Merge tag 'wireless-next-2026-05-21' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Johannes Berg says:
====================
Not much going on here right now:
- mac80211/hwsim:
- some NAN related things
- MCS/NSS rate issues with S1G
- p54: port SPI version to device-tree
- (a few other random things)
* tag 'wireless-next-2026-05-21' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next:
ARM: dts: omap2: add stlc4560 spi-wireless node
p54spi: convert to devicetree
dt-bindings: net: add st,stlc4560/p54spi binding
wifi: mac80211: allow cipher change on NAN_DATA interfaces
wifi: mac80211_hwsim: Do not declare NAN support for Extended Key ID
wifi: cfg80211: add a function to parse UHR DBE
wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not needed
wifi: mac80211: Allow per station GTK for NAN Data interfaces
wifi: mac80211_hwsim: advertise NPCA capability
wifi: mac80211_hwsim: reject NAN on multi-radio wiphys
wifi: plfxlc: use module_usb_driver() macro
wifi: mac80211: don't recalc min def for S1G chan ctx
wifi: mac80211: skip NSS and BW init for S1G sta
wifi: mac80211: check stations are removed before MLD change
wifi: rt2x00: allocate anchor with rt2x00dev
====================
Link: https://patch.msgid.link/20260521153519.380276-3-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The function ieee80211_tx_status() was renamed to
ieee80211_tx_status_skb() by commit 2703bc8513
("wifi: mac80211: rename ieee80211_tx_status() to
ieee80211_tx_status_skb()"). Update the stale reference
in ath10k_htt_tx_hl().
Assisted-by: unnamed:deepseek-v3.2 coccinelle
Signed-off-by: Kexin Sun <kexinsun@smail.nju.edu.cn>
Link: https://patch.msgid.link/20260321110011.8556-1-kexinsun@smail.nju.edu.cn
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
If there is an error during some initialization related to firmware,
the buffers dp->tx_ring[i].tx_status are released.
However this is released again when the device is unbinded (ath11k_pci),
and we get:
WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90
Call Trace:
free_large_kmalloc
ath11k_dp_free
ath11k_core_deinit
ath11k_pci_remove
...
The issue is always reproducible from a VM because the MSI addressing
initialization is failing.
In order to fix the issue, just set the buffers to NULL after releasing in
order to avoid the double free.
Fixes: d5c65159f2 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Cc: stable@vger.kernel.org
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260420110130.509670-1-jtornosm@redhat.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Switch from sign_extend32(FIELD_GET()) to the dedicated
FIELD_GET_SIGNED() and don't calculate the fields length explicitly.
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yury Norov <ynorov@nvidia.com>
The Prism54 SPI driver hardcodes GPIO numbers and expects users to
pass them as module parameters, apparently a relic from its life as a
staging driver. This works because there is only one user, the Nokia
N8x0 tablet.
Convert this to the gpio descriptor interface and DT based probing
to improve this and simplify the code at the same time.
Acked-by: Christian Lamparter <chunkeey@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260507212451.3333185-3-arnd@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Do not declare support for Extended Key ID for NAN, as defined in
section 7.4 in the WiFi Aware specification v4.0 (in order to support
security association upgrade).
Fixes: eaa7ce66c3 ("wifi: mac80211_hwsim: Fix possible NULL dereference")
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260515141442.365ca3ab29f9.Ib435168dcc1d7d8719a5612109035ca1950967ed@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This doesn't really do anything, but we can advertise it and then
check that the AP can be configured and client can connect, etc.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260512224724.abfd51f480b7.I2024d7fc8067a0fca26234f312937cc764b660f4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When userspace creates a new hwsim radio with both
HWSIM_ATTR_MULTI_RADIO and HWSIM_ATTR_SUPPORT_NAN_DEVICE,
hwsim_new_radio_nl() sets BIT(NL80211_IFTYPE_NAN_DATA) in
wiphy->interface_modes while configuring the wiphy with
n_radio > 1. This violates the invariant checked in
wiphy_register():
(interface_modes & BIT(NL80211_IFTYPE_NAN_DATA)) &&
(!nan_capa.phy.ht.ht_supported || n_radio > 1)
triggering a WARN reachable from userspace via genetlink.
With panic_on_warn this becomes a denial of service.
Refuse the combination at parse time with -EINVAL and an
extack message, matching the cfg80211 constraint that NAN
is not supported on multi-radio wiphys.
Reported-by: syzbot+2002864e6c6895cb0ac3@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=2002864e6c6895cb0ac3
Fixes: 2c7c70ee7c ("wifi: mac80211_hwsim: enable NAN_DATA interface simulation support")
Tested-by: syzbot+2002864e6c6895cb0ac3@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
Link: https://patch.msgid.link/20260509004628.79446-1-kartikey406@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
init and exit do nothing interesting that module_usb_driver doesn't
already handle. Just use module_usb_driver to simplify the code.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260507015457.239807-1-rosenp@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of being creative with devm, allocate with rt2x00dev by using a
flexible array member. Simplifies code slightly.
It's worth noting that in 25369b2222 , the
proper device was set to the devm call as it seems there was confusion
there.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Link: https://patch.msgid.link/20260430232206.141461-1-rosenp@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ath10k:
- avoid sending any commands to firmware when it is wedged
ath11k:
- fix WMI buffer leaks on error conditions
- fix UAF in RX MSDU coalesce path
- allow peer ID 0 on RX path (legal for mobile devices)
- reinitialize shared SRNG pointers on restart
ath12k:
- fix 20 MHz-only parsing of EHT-MCS map
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ/mtSHzPUi16IfDEksFbugiYzLewUCagxz9AAKCRAsFbugiYzL
e3AAAQCeNy0XjAPSMZp0vqlMZkCIXSOy03/BNLTk0o5fT4NE3QD+IRa0coCLXlf1
eQRObBHnzKMA/y5oSEKdS4/5b+ExEgE=
=Xvqo
-----END PGP SIGNATURE-----
Merge tag 'ath-current-20260519' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
Jeff Johnson says:
==================
ath.git update for v7.1-rc5
ath10k:
- avoid sending any commands to firmware when it is wedged
ath11k:
- fix WMI buffer leaks on error conditions
- fix UAF in RX MSDU coalesce path
- allow peer ID 0 on RX path (legal for mobile devices)
- reinitialize shared SRNG pointers on restart
ath12k:
- fix 20 MHz-only parsing of EHT-MCS map
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
wilc_wlan_firmware_download() allocates dma_buffer with kmalloc() at
the top of the function and uses a 'fail:' label to free it via
kfree(dma_buffer) on error.
All later error paths correctly use 'goto fail' to route through this
cleanup. However, the early failure path after the first acquire_bus()
call uses a bare 'return ret;', which leaks dma_buffer whenever the bus
acquire fails.
Replace the early return with goto fail so the existing cleanup path
runs.
Found via a custom Coccinelle semantic patch hunting for kmalloc'd
locals leaked on early-return error paths in driver firmware-download
code.
Fixes: 1241c5650f ("wifi: wilc1000: Fill in missing error handling")
Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260511042732.998311-1-shitalkumar.gandhi@cambiumnetworks.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add debugfs support to simulate incumbent signal interference from the
host for testing purposes. The debugfs entry is created only for 6 GHz
radio when firmware advertises the support through
WMI_TLV_SERVICE_DCS_INCUMBENT_SIGNAL_INTERFERENCE_SUPPORT flag.
Debugfs command:
echo <interference_bitmap> > /sys/kernel/debug/ath12k/pci-000X/macX/simulate_incumbent_signal_interference
Each bit in the interference_bitmap represents a 20 MHz segment. Bit 0
corresponds to the primary 20 MHz segment, regardless of its position
within the operating bandwidth. Bit 1 represents the next adjacent 20 MHz
segment, bit 2 the lower 20 MHz segment of the adjacent 40 MHz segment,
and so on-progressing sequentially across the bandwidth..
Example:
echo 0xF0 > /sys/kernel/debug/ath12k/pci-0002:01:00.0/mac0/simulate_incumbent_signal_interference
This indicates that all the subchannels in the secondary 80 MHz segment
were affected.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1
Signed-off-by: Aishwarya R <aishwarya.r@oss.qualcomm.com>
Signed-off-by: Amith A <amith.a@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260511040242.1351792-3-amith.a@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
When incumbent signal interference is detected by an AP/mesh interface
operating in the 6 GHz band, as mandated by the FCC, it is expected to
vacate the affected channels. The firmware indicates the interference to
the host using the WMI_DCS_INTERFERENCE_EVENT.
To handle the new WMI event, first parse it to retrieve the interference
information. Next, validate the interference-detected channel and
the interference bitmap. The interference bitmap received from the
firmware uses a mapping where bit 0 corresponds to the primary
20 MHz segment, regardless of its position within the operating
bandwidth. Bit 1 represents the next adjacent 20 MHz segment, bit 2
the lower 20 MHz segment of the adjacent 40 MHz segment, and so
on, progressing sequentially across the bandwidth. However, for userspace
consumption via mac80211, this bitmap must be transformed into a
standardized format such that each bit position directly maps to the
corresponding sub-channel index within the operating bandwidth.
Finally, indicate the transformed interference bitmap to mac80211, which
then notifies userspace of the interference. Once the incumbent signal
interference is detected, firmware suspends TX internally on the affected
operating channel while userspace decides the mitigation action. Userspace
is expected to trigger a channel switch or bandwidth reduction to mitigate
the interference. Also, add a flag handling_in_progress to indicate that
handling of interference is in progress. Set it to true after
indicating to mac80211 about the interference. Reset the flag to false
after the operating channel is switched by userspace. This prevents
processing any further interference events when there is already a
previous event being handled. Hence, further events are processed only
after a channel switch request is received from userspace for the
previous event.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1
Signed-off-by: Aishwarya R <aishwarya.r@oss.qualcomm.com>
Co-developed-by: Hari Chandrakanthan <quic_haric@quicinc.com>
Signed-off-by: Hari Chandrakanthan <quic_haric@quicinc.com>
Signed-off-by: Amith A <amith.a@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260511040242.1351792-2-amith.a@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
The settings of control options are predefined per RFSI band (2GHz band or
not 5/6GHz band) and used for fine-tuning transmit power. Calculate and set
the RFSI band once creating channel context, and use it by BB wrapper
configurations.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260511070148.25257-11-pkshih@realtek.com
The BB wrap is a hardware block to control TX power. Since RTL8922D has
many variants with different CID and RFE types, prepare flow and dummy
struct adopt to configuration functions for coming patches.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260511070148.25257-2-pkshih@realtek.com
When connecting to an AP configured for EHT 20 MHz with a full EHT
MCS/NSS map (supporting MCS 0-13)
Supported EHT-MCS and NSS Set
EHT-MCS Map (BW <= 80MHz): 0x444444
.... .... .... .... .... 0100 = Rx Max Nss That Supports EHT-MCS 0-9: 4
.... .... .... .... 0100 .... = Tx Max Nss That Supports EHT-MCS 0-9: 4
.... .... .... 0100 .... .... = Rx Max Nss That Supports EHT-MCS 10-11: 4
.... .... 0100 .... .... .... = Tx Max Nss That Supports EHT-MCS 10-11: 4
.... 0100 .... .... .... .... = Rx Max Nss That Supports EHT-MCS 12-13: 4
0100 .... .... .... .... .... = Tx Max Nss That Supports EHT-MCS 12-13: 4
TX throughput is observed to be significantly lower than expected.
Investigation shows that TX rates are limited to EHT MCS 11, even though
the AP advertises support for EHT MCS 12/13.
The root cause is an incorrect parsing of the Supported EHT-MCS and NSS
Set element in ath12k_peer_assoc_h_eht().
IEEE Std 802.11be-2024 Figure 9-1074as describes the format for 20
MHz-Only Non-AP STAs.
IEEE Std 802.11be-2024 Figure 9-1074at describes the format for all
other AP and non-AP STAs.
Currently the first format is parsed when the peer advertises no wider
HE channel width support, without considering whether it is an AP or a
non-AP STA. This is incorrect: the peer AP's capabilities must be parsed
using Figure 9-1074at even when it operates on 20 MHz only. Parsing it
as Figure 9-1074as causes rx_tx_mcs13_max_nss to be interpreted as zero,
which is then passed to firmware, leading firmware to assume the peer
does not support MCS 13 and to limit TX rates at MCS 11.
Fix this by parsing the Figure 9-1074as format only when the peer is a
20 MHz-Only non-AP STA, i.e. when the local interface operates as AP or
mesh point.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Fixes: 6c95151e2e ("wifi: ath12k: Add EHT MCS/NSS rates to Peer Assoc")
Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260514-ath12k-fix-20mhz-only-mcs-map-v1-1-a38d4a9b21a2@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
LMAC rings reuse the shared rdp/wrp pointer buffers without going
through the normal SRNG hw-init path that zeros non-LMAC ring
pointers. After restart, ath11k_hal_srng_clear() can therefore hand
stale hp/tp state from the previous firmware instance back to the new
one.
Clear the shared pointer buffers while keeping the allocations in
place so restart still avoids reallocating SRNG DMA memory, but starts
with fresh ring-pointer state.
Fixes: 32be3ca4cf ("wifi: ath11k: HAL SRNG: don't deinitialize and re-initialize again")
Cc: stable@vger.kernel.org
Closes: https://lore.kernel.org/all/CAOPSVF04q6uvVdq8GTRLHBrVMdpt9=o9wVcFMc6f-yhmSBcZqQ@mail.gmail.com/
Signed-off-by: Kyle Farnung <kfarnung@gmail.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260513-kfarnung-ath11k-srng-clear-pointer-state-v1-1-bc700dd8b333@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
In ath11k_dp_rx_msdu_coalesce() the loop uses ->is_continuation after
the dev_kfree_skb_any(). This can cause a use after free kfence.
Use flag for caching is_continuation for use after the
dev_kfree_skb_any().
Fixes: d5c65159f2 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Willmar Knikker <willmar@met-dubbel-l.nl>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260505171709.547274-1-willmar@met-dubbel-l.nl
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
It has been observed that on certain chipsets a peer can be assigned
peer_id=0. For reception of non-aggregated MPDUs this is fine as
ath11k_dp_rx_h_find_peer() has a fallback case where it locates the peer
based upon the source MAC address. On an aggregated link, the mpdu_start
header is only populated by hardware on the first sub-MSDU. This causes
the peer resolution to be skipped for the subsequent MSDUs and the
encryption type of these frames to be set to an incorrect value,
resulting in these MSDUs being dropped by ieee80211.
ath11k_pci 0000:03:00.0: data rx skb 000000002f4b704d len 1534 peer xx:xx:xx:xx:xx:xx 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 1 last_msdu 0
ath11k_pci 0000:03:00.0: data rx skb 0000000038acd580 len 1534 peer (null) 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d00 fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 0 last_msdu 1
Remove the null peer_id checks in ath11k_dp_rx_h_find_peer() and
ath11k_hal_rx_parse_mon_status_tlv(), allowing peers with an assigned ID
of 0 to be resolved.
Tested-on: QCA2066 hw2.1 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.9
Fixes: 2167fa606c ("ath11k: Add support for RX decapsulation offload")
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Signed-off-by: Matthew Leach <matthew.leach@collabora.com>
Reviewed-by: P Praneesh <praneesh.p@oss.qualcomm.com>
Link: https://patch.msgid.link/20260424-ath11k-null-peerid-workaround-v4-1-252b224d3cf6@collabora.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
After 4 missed beacons since last Rx, the firmware will send an NDP to the
AP. If the NDP is ACK'ed, it'll reset the missed_beacons_since_last_rx
counter.
Disconnecting after 4 beacons doesn't give enough time to the firmware
to send the NDP.
Wait until we get 6 missed beacons since last Rx before disconnecting.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260515151352.c4ed0d849f98.Iefa2e8be9edfc74683997eea60bb53c2002f31f0@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Clearly, from a user perspective, it must be valid to configure
WoWLAN (which can include network detection) and then suspend
while not connected to a network, or even without an interface
at all (WoWLAN config is handled on a per-wiphy basis). Since
mac80211 doesn't distinguish these cases and simply calls the
driver to suspend whenever WoWLAN is configured, the driver has
to cleanly handle the case where it's called for WoWLAN but no
(BSS) interface exists.
Remove the WARN_ON(), move the print so it doesn't get done in
this case, and keep returning 1 to disconnect everything.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260515151352.0c55d1135409.I54f8be0e2aa28cfb1cb1dcf3b2d2d8fe75b4397b@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
CNVI_PMU_STEP_FLOW is a PRPH register, not a UMAC PRPH register.
Use iwl_read_prph() instead of iwl_read_umac_prph() to read it
correctly.
Signed-off-by: Moriya Itzchaki <moriya.itzchaki@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260515151352.3a69fa2dbda7.I8d96635a9c06a835b05a10b6d66c8a9299676246@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
On old devices such as 7265D, rates are still encoded in version 1
format, which doesn't use the CCK/OFDM rate index (0-3/0-7) but
rather their PLCP value (e.g. 10 for 1 Mbps CCK rate.)
While introducing v3 rates, I changed the driver from internally
handling v1 rates and converting to v2, to internally handling v3
and converting to v1 or v2 according to the firmware. I accordingly
changed the code in iwl_mvm_mac80211_idx_to_hwrate() to no longer
have different values for different APIs. This was correct.
However, I later reverted this part of the change, because it was
reported that I had broken beacon rates, causing a FW assert/crash.
This caused TX_CMD rates to be set incorrectly, potentially causing
a warning when reported back from the device as having been used.
Fix this (hopefully correctly now) by handling beacon rates in the
TX_CMD that's embedded in the beacon template command separately.
Restore iwl_mvm_mac80211_idx_to_hwrate() to return only the rate
index, not PLCP value, fixing the real TX_CMD.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260515151351.7407e293dff7.I4ea1a17f8fe99c933d3f3e30d077cf4246125c3e@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
In iwl_mld_remove_link, the link->fw_id is saved at the beginning of the
function so we have it after we freed the link.
But the link pointer can be NULL, and is not checked when the fw_id is
stored.
Fix it by simply freeing the link at the end of the function.
fFixes: 0e66a39f4f0e ("wifi: iwlwifi: fix potential use after free in iwl_mld_remove_link()")
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260515151351.371f40fc6711.I6a82cfe9655564e9c5731af91c36493b26b1208e@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
When iwlwifi firmware crashes (e.g., NMI_INTERRUPT_UNKNOWN on Intel
BE201/Wi-Fi 7), iwl_mld_nic_error() sets mld->fw_status.in_hw_restart
to true. However, iwl_mld_tx_from_txq() does not check this flag before
dequeuing frames from mac80211 and pushing them to the transport layer.
Since the firmware is dead, iwl_trans_tx() returns -EIO for each frame,
which then gets freed immediately. Under high-throughput conditions
(e.g., Tailscale UDP traffic or active SSH sessions), this creates a
tight dequeue-send-fail-free loop that wastes CPU cycles and generates
rapid skb allocation churn, leading to memory pressure from slab
fragmentation.
The RX path already has this guard (iwl_mld_rx_mpdu checks
in_hw_restart at rx.c:1906), and so does the TXQ allocation worker
(iwl_mld_add_txqs_wk at tx.c:156). Add the same guard to
iwl_mld_tx_from_txq() to stop all TX during firmware restart.
Frames left in mac80211's TXQs are naturally drained after restart
completes, when queue reallocation triggers iwl_mld_tx_from_txq()
via iwl_mld_add_txq_list(), or when new upper-layer traffic invokes
wake_tx_queue.
Tested on ASUS Zenbook 14 UX3405CA with Intel BE201 (Wi-Fi 7) on
kernel 6.19.5 where the firmware crashes approximately every 10-15
minutes under Tailscale traffic.
Fixes: d1e879ec60 ("wifi: iwlwifi: add iwlmld sub-driver")
Cc: stable@vger.kernel.org
Signed-off-by: Sheroz Juraev <goodmartiandev@gmail.com>
Link: https://patch.msgid.link/20260315081221.2678478-1-goodmartiandev@gmail.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
When the TLC notification disables AMSDU for a TID, the MLD driver sets
max_tid_amsdu_len to the sentinel value 1. The TSO segmentation path in
iwl_mld_tx_tso_segment() checks for zero but not for this sentinel,
allowing it to reach the num_subframes calculation:
num_subframes = (max_tid_amsdu_len + pad) / (subf_len + pad)
= (1 + 2) / (1534 + 2) = 0
This zero propagates to iwl_tx_tso_segment() which sets:
gso_size = num_subframes * mss = 0
Calling skb_gso_segment() with gso_size=0 creates over 32000 tiny
segments from a single GSO skb. This floods the TX ring with ~1024
micro-frames (the rest are purged), creating a massive burst of TX
completion events that can lead to memory corruption and a subsequent
use-after-free in TCP's retransmit queue (refcount underflow in
tcp_shifted_skb, NULL deref in tcp_rack_detect_loss).
The MVM driver is immune because it checks mvmsta->amsdu_enabled before
reaching the num_subframes calculation. The MLD driver has no equivalent
bitmap check and relies solely on max_tid_amsdu_len, which does not
catch the sentinel value.
Fix this by detecting the sentinel value (max_tid_amsdu_len == 1) at the
existing check and falling back to non-AMSDU TSO segmentation. Also add
a WARN_ON_ONCE guard after the num_subframes division as defense-in-depth
to catch any future code paths that produce zero through a different
mechanism.
Suggested-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Fixes: d1e879ec60 ("wifi: iwlwifi: add iwlmld sub-driver")
Signed-off-by: Cole Leavitt <cole@unwrap.rs>
Link: https://patch.msgid.link/20260405054145.1064152-3-cole@unwrap.rs
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Remove the rtw_txq_dequeue helper. It's a wrapper around
ieee80211_tx_dequeue with just one caller.
Call ieee80211_tx_dequeue directly in rtw_txq_push. There's no need to
fetch txq for every frame, we can do this once outside of the rcu lock.
Make the loop variable i unsigned long, it should have the same type as
frames.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260507082238.889656-1-martin@kaiser.cx
The radiotap headroom is allocated only if IEEE80211_CONF_MONITOR is set.
However, it is potentially racing that SKB allocation without radiotap
headroom but adding radiotap from matched PPDU status of another SKB.
Add a check to avoid the case.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260506131000.1706298-15-pkshih@realtek.com
The format of PHY status IE-10 for RTL8922D is different from earlier
chips. Fortunately only starting bit is different, but the layout is the
same. Get the VHT/HE SIG-A value by corresponding mask accordingly.
The IE-09 format of generation 0 and 1 are totally the same.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260506131000.1706298-14-pkshih@realtek.com
Hardware reports a list of PHY status IE. In monitor mode, IE-09 of
PHY status is enabled, and the report contains trailing 8-byte zeros,
causing failed to parse and drop all IE information.
The 8 zeros are recognize as IE type 0, but length of type 0 must be
not 8 (reference to rtw89_phy_gen_def::physt_ie_len[0]).
Check and skip them.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260506131000.1706298-13-pkshih@realtek.com
To capture HE-MU packets, set BSS color and AID for specific connected
station.
The writing format: <bss color> <aid>
For example,
$ echo 0x4 0x16 > monitor_opts
Read this entry to get current setting:
bss_color=0x4 aid=0x16
By the way, add another sec2() function to create debugfs entries to
prevent running smatch timeout.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260506131000.1706298-11-pkshih@realtek.com
Fill HE radiotap by PHY status IE-09/IE-10 which contains HE SIG-A/SIG-B
respectively.
The IE-10 may contain two content channels (if bandwidth is larger than
40MHz), and starting address of second content channel can be calculated by
length of first content channel containing up to 15 user fields with 8-byte
alignment.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260506131000.1706298-9-pkshih@realtek.com
