This command is getting a new field for UNII-9 and ieee80211bn
enablement.
We must read the relevant DSM values and pass them to the firmware,
Remember whether we have ACPI or UEFI available in the firmware runtime
object and remember the DSM function revision.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260111193638.9577f0cade21.I82b26f082f152a83eb9990dddf68d7dcc549f227@changeid
Instead of reading the DSM functions on demand, just read them all
when the first DSM function is called and cache the values for all
the other DSM functions. This simplifies the flow.
Since the same will be done for UEFI in the next patch, remove the
ifdef CONFIG_ACPI around the relevant variables.
Once UEFI's cache will be implemented, we'll be able to change
iwl_bios_get_dsm to access the cache directly.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260111193638.732ff6856796.Iff844bfbb0fea3c3d9654a53254a5b14dbaec8c1@changeid
iwlmvm is the only op_mode that uses the lari helper functions. iwlmld
has its own version to avoid introducing regressions.
Move all those functions to iwlmvm, as they are more related to the
op_mode.
iwl_get_lari_config_bitmap will move in the next patch.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260111193638.4bb241e436cb.I3d80796d4722376ce24a847419d34723083baaa8@changeid
When assigning emlsr.primary with emlsr.selected_primary
we are checking if BIT(mld_vif->emlsr.selected_links) are
a part of vif->active_links. This is incorrect as
emlsr.selected_links is a bitmap of possibly two selected links.
Therefore, performing the BIT() operation on it does not
yield any meaningful result and almost always leads to
incorrect primary link selection.
Additionally, we cannot rely on vif->active_links at this
stage of the link switch flow because it contains both the
removed links and also the newly added links.
For example, if we had selected links in the past (0x11)
and we now select links because of TTLM/debugfs (0x100),
vif->active_links will now be (0x111) and primary link
will be 0, while 0 is not even an active link. Thus,
we create our own bitmap of final active links.
Signed-off-by: Nidhish A N <nidhish.a.n@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260111193638.38b2e14e3a20.Ie81a88dfff0c5d2becedabab8398702808f6b1bf@changeid
A link pair in which both links are in 5 GHz can be used for EMLSR only
if they are separated enough.
To check this condition we calculate the start and the end of the
chandefs of both links in the pair and do some checks.
But the calculation of the start/end of the chandef is currently done
by subtracting/adding half the bandwidth from/to the control channel's
center frequency, when it should really be subtracted/added from/to the
center frequency of the entire chandef.
Fix the wrong calculation.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260111193638.2138fdb99bd5.I4d2e5957b22482a57b1d6ca444e90fcf73bf2cab@changeid
These values should be taken from SIG-A, indicating how SIG-B
is encoded. The values taken from SIG-B (the corresponding
register) indicate how the data portion (for that user) is
encoded. For the SIG-B compression value the correct mask was
applied to the wrong value.
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/20251110150012.4d625e05dece.If295eb9382fc681d63b0853261d884cd1a833ba5@changeid
Add the necessary data definitions for the sniffer-related fields
reported for the various UHR frame formats by the firmware/hardware
to be able to later add the necessary sniffer code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251110150012.358b51dd8cb2.I16178416dd7019cb88a45e55f81eb28510982028@changeid
Fix unsafe power type mapping for iwl_txpower_constraints_cmd
that breaks if enum values change. Replace "power_type - 1" with
explicit case handling for each power type.
While on it, Add debug logging to show configured power type.
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/20251110150012.f3b15566dac8.I31b900ab161fb627158dc1b3e2fc4ab35d84fddf@changeid
If the firmware were to report three LMACs (which doesn't
exist in hardware) then using "fwrt->smem_cfg.lmac[2]" is
an overrun of the array. Reject such and use IWL_FW_CHECK
instead of WARN_ON in this function.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251110150012.16e8c2d70c26.Iadfcc1aedf43c5175b3f0757bea5aa232454f1ac@changeid
In version 6, a phy id is added to the tlc command and the sta_id
becomes a sta_mask.
This change is required for NAN:
- in NAN we can have 2 logical stations of the same physical
station and with the same channel/band (2 NDIs with the same peer) -
hence the sta_mask.
- In NAN we can have more than one TLC configuration for a single
station (for example if it operates on more than one channel) - so the
FW needs to be able to find the right TLC context, based on the phy id.
Populate the new version (for now with a single station id only. The
other ones will be added later when NAN is implemented).
In case the FW has a lower version than that - convert it to the FW
version.
Note that there is some code duplicantion in the conversions to v5
and to v4, but this is intentional since v5 will be removed as soon as
v6 is supported.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251110150012.64220c6b292b.I2f5d195ce2bf9d35398f0f6f2d5faf9e90ae45a4@changeid
The firmware can request us to trigger a dump upon specific
notifications. In order for that flow to work, we need to call the
firmware debug infra when we get a notification from the firmware.
This was missing.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251110150012.d6d7e69c7da6.I40f891ece6f98983e0fd2cd0c6863f8620ca08aa@changeid
Fix the documentation comment for the ap_type field
in AP_TX_POWER_CONSTRAINTS_CMD to reference the correct
enum iwl_6ghz_ap_type.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251110150012.d70f56dd24b0.I82956bd93a36c7fa5585f014c197afea0610a076@changeid
- iwl_mvm_scan_umac_chan_flags_v2() computes channel params flags
that are only relevant for 2.4/5 GHz scan, explicitly clear
the flags for 6 GHz scan.
- n_aps_override[0] and n_aps_override[1] are not relevant for
6 GHz scan, remove them.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251110150012.3b4f8ed30498.I014c098e64118fe3adaf6db07816e7df8ea4f79e@changeid
Erroneously, the channel flags in the scan command for 6 GHz scan
were mistakenly set using iwl_mld_scan_get_cmd_gen_flags, which
actually calculates a different field (the general flags) in the
command.
However, these flags are not relevant for 6 GHz scan part, except for
IWL_SCAN_CHANNEL_FLAG_6G_PSC_NO_FILTER, which is already set
correctly. Since the incorrect flags are only applied in the
6 GHz scan part and are ignored by the firmware, this has no
adverse effect. Therefore, we can simply remove this helper
function call and explicitly clear the flags.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251110150012.a8a931e1abef.I8f7dc66b23198b83083685ef76dec59cfb407f57@changeid
While this is not needed for configuring Rx filters, without setting
it some multicast action frame registrations from user space would
fail, specifically, NAN multicast action frame registration (SDFs).
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251110180612.640fb5a99470.If6f423bcf0a426e662041a4b310ce81485f1af03@changeid
- Add firmware API definitions related to NAN.
- Indicate support for NAN Device interface operation, if supported
by the firmware.
- Add support for starting and stopping NAN cluster functionality.
The NAN cluster operation is offloaded to the FW, which notifies
the driver on:
- cluster events: Start/Join cluster.
- Discovery Window (DW) end, which allows the driver to flush the
HW queues and update the higher layers
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251110180612.76dd4d45b91e.I5abfab64b4f27bed442aeca6231ffebad979cad6@changeid
After NAN was started, cluster id updates from the user space should not
happen, since the device already started a cluster with the
previousely provided id.
Since NL80211_CMD_CHANGE_NAN_CONFIG requires to set the full NAN
configuration, we can't require that NL80211_NAN_CONF_CLUSTER_ID won't
be included in this command, and keeping the last confgiured value just
to be able to compare it against the new one seems a bit overkill.
Therefore, just ignore cluster id in this command and clarify the
documentation.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260107142229.fb55e5853269.I10d18c8f69d98b28916596d6da4207c15ea4abb5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
A driver that declared that it has userspace DE should not call NAN func
related APIs such as cfg80211_nan_match and cfg80211_nan_func_terminated
Check and warn in such a case, as this indicates a driver bug.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260107141549.86fa96c75211.I8fbb0506377170dd7b41234f20bcba057951dd1e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Seems that there is an assumption that this function should be called
only for netdev interfaces, but it can also be called in suspend, or
from nl80211_netlink_notify (indirectly).
Note that the documentation of NL80211_ATTR_SOCKET_OWNER explicitly
says that NAN interfaces would be destroyed as well in the
nl80211_netlink_notify case.
Fix this by also stopping P2P and NAN.
Fixes: cb3b7d8765 ("cfg80211: add start / stop NAN commands")
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260107140430.dab142cbef0b.I290cc47836d56dd7e35012ce06bec36c6da688cd@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
According to Wi-Fi Aware (TM) 4.0 specification 2.8, A NAN device can
have one NAN management interface. This applies also to multi radio
devices.
The current code allows a driver to support more than one NAN interface,
if those are not in the same radio.
Fix it.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260107135129.fdaecec0fe8a.I246b5ba6e9da3ec1481ff197e47f6ce0793d7118@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This change re-applies commit 2b7aadd3b9 ("wlcore: Adding suppoprt for IGTK key in
wlcore driver") (sic), but only enables WLAN_CIPHER_SUITE_AES_CMAC with modern
firmware. This patch is required to support WPA3 connections.
Signed-off-by: Peter Åstrand <astrand@lysator.liu.se>
Link: https://patch.msgid.link/0d3df7ab-6c41-c3cc-83cc-5ba55fe4e4bd@lysator.liu.se
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Main changes are to prepare to support RTL8922DE, including refactor/add
register settings in common flow, and add newly firmware command/event
handlers.
Others are some random fixes and improvements across all drivers.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuyEnvMdOsBl1WjpdjlvZYmhshd8FAmloRxkACgkQjlvZYmhs
hd+++hAA2s/FNMKhxoTcKL/5d+H/UMWY4Ust1c6ilIxNTTGCOOXD0f5YV/gyZ+XD
MXrFHqMl11EJn85iy6EfRRX6np+sFeizpM0hUBEYerolZqaKkdPhoS7wVxJwaEMw
udlnJk03Q6t29M0FWYlp+HAJ2GF1aDzEqE8I+ZYN4gEWMKvFARUojYBzegYRIRnT
pnFrifQWzANHi6Ynjtj6YNMsCJnqtfXW0rRZvk/xy4Kb+gwKev3DiJ7t182QJUbT
10qUh+5tmJtW828teTeAXJGwsD0pcqm6GaUbGNg1hfCVo0iLHyCM0R5DVVYjksgW
5NNaKbIvcpamk4miiz2+k7ng237zsNQnUGU5abA9C68IT+UDR8gg/DFieHxEqg7O
q17QgvU6/JPcBvtAAFeGCjGb2rRow4Fezc/QnEo/IT1sU3T2lATKRPz7+4ao1ebW
5v2M8Dg0HrBJ2FzCo0lbBY7Lxbw7GGhaT8nF0/eMyiflkXG9QX1I5fw3by9hnxmy
3hwRR++5XfR6KZstfIySQa7ALybnZ7C1EGsdT9WNnLJQc0FeL93uBYZK3u5qRvmv
rgWT+wGbaRjit0zeSybyxTMqeoMAlVJKkhAFhUIEHUABaxkYUy9F7O0p91AB3Vfd
4eOtfhq/qPBiqiDhb5anGGFe2U92e9/0C/3kMuzAtJd9wsQc2LQ=
=DKtY
-----END PGP SIGNATURE-----
Merge tag 'rtw-next-2026-01-15' of https://github.com/pkshih/rtw
Ping-Ke Shih says:
==================
rtw-next patches for -next release.
Main changes are to prepare to support RTL8922DE, including refactor/add
register settings in common flow, and add newly firmware command/event
handlers.
Others are some random fixes and improvements across all drivers.
==================
Link: https://patch.msgid.link/006be16d-61ba-4af8-b76a-bc94100c3555@RTKEXHMBS03.realtek.com.tw
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The MAC settings are different from RTL8922A to RTL8922D, including
scheduler, DLE, DCPU, MLO, NAV, TMAC, TX/RX protocol, RMAC, IMR, host RPT,
AMSDU. Update them accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260110022019.2254969-8-pkshih@realtek.com
Some APs disconnect clients by sending a Disassociation frame
rather than a Deauthentication frame. Since these frames use
different reason codes in WoWLAN mode, this commit adds support
for handling Disassociation to prevent missed disconnection events.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260110022019.2254969-3-pkshih@realtek.com
