When connected to an AP, the PHY will typically be tuned to
a higher bandwidth than the beacons are transmitted on, as
they are normally only transmitted on 20 MHz. This can mean
that another STA is simultaneously transmitting on another
channel of the higher bandwidth, and apparently this energy
may be taken into account by the PHY, resulting in elevated
energy readings.
To work around this, track the firmware's corrected beacon
energy data and replace the RSSI in beacons by that. The
replacement happens for all beacons received in the context
of the current MAC or link (depending on FW version), in
which case the filters will drop all else. For a scan, which
is only tuning to 20 MHz channels, the MAC/link ID will be
one that isn't found (the AUX ID 4), and no correction will
be done (nor is it needed.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250711183056.324bfe7027ff.I160f947e7aab30e0110a7019ed46186e57c3de14@changeid
Since the iwlmvm driver now only supports pre-MLO devices,
we no longer need to maintain an extra explicit link ID;
valid MAC IDs and link IDs are both in the range 0-3 and
the driver always has a 1:1 MAC/link correspondence. Thus,
simply use the MAC ID as the link ID as well.
This simplifies some further work because on RX the ID is
given but there is some confusion about which versions of
the firmware report MAC and which report link ID.
While at it, clarify iwl_mvm_handle_missed_beacons_notif()
code a bit so it doesn't look like an invalid vif pointer
is being used.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250711183056.005aa5fe34fe.Ib0c1187453f46ce49dc0f9f58907ee21f5b52634@changeid
In the current code, if there was a rekey, we remove all the existing keys
from mac80211, then re-add the ones that the FW sent with
ieee80211_gtk_rekey_add, (newer FW will send also the existing GTKs/BIGTKs)
and then update the sequence number.
Instead of removing and re-adding the existing keys for no good reason,
we can just update the sequence of all keys, also of the ones that are
going to be replaced, and update again after the replace.
This change is required because ieee80211_gtk_rekey_add is going to be
changed to lookup the cipher from the old key instead of receiving it as an
argument, and for this it will need the old key(s), so we can't remove all
keys.
Note that with this change, in case that a key that existed before wowlan
is replaced, mac80211 will now call the driver to remove the old key and
add the new one (as opposed the previous behaviour, in which the key was
removed by the driver itself).
Of course we don't want to run the set_key callbacks in this case, so just
return early.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250710212632.10091484e38e.I45daf089189f606f3879ca4538fb46303d761710@changeid
Miri Korenblit says:
====================
iwlwifi-next - iwlwifi features
Mostly cleanups. A few fixes and small features.
====================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, per-radio attributes are set on per-phy basis, i.e., all the
radios present in a wiphy will take attributes values sent from user. But
each radio in a wiphy can get different values from userspace based on
its requirement.
To extend support to set per-radio attributes, add support to get radio
index from userspace. Add an NL attribute - NL80211_ATTR_WIPHY_RADIO_INDEX,
to get user specified radio index for which attributes should be changed.
Pass this to individual drivers, so that the drivers can use this radio
index to change per-radio attributes when necessary. Currently, per-radio
attributes identified are:
NL80211_ATTR_WIPHY_TX_POWER_LEVEL
NL80211_ATTR_WIPHY_ANTENNA_TX
NL80211_ATTR_WIPHY_ANTENNA_RX
NL80211_ATTR_WIPHY_RETRY_SHORT
NL80211_ATTR_WIPHY_RETRY_LONG
NL80211_ATTR_WIPHY_FRAG_THRESHOLD
NL80211_ATTR_WIPHY_RTS_THRESHOLD
NL80211_ATTR_WIPHY_COVERAGE_CLASS
NL80211_ATTR_TXQ_LIMIT
NL80211_ATTR_TXQ_MEMORY_LIMIT
NL80211_ATTR_TXQ_QUANTUM
By default, the radio index is set to -1. This means the attribute should
be treated as a global configuration. If the user has not specified any
index, then the radio index passed to individual drivers would be -1. This
would indicate that the attribute applies to all radios in that wiphy.
Signed-off-by: Roopni Devanathan <quic_rdevanat@quicinc.com>
Link: https://patch.msgid.link/20250615082312.619639-2-quic_rdevanat@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Unfortunately, FWs of some devices don't have the version of the
iwl_mac_config_cmd defined in the TLVs. We send 0 as the 'def argument
to iwl_fw_lookup_cmd_ver, so for such FWs, the return value will be 0,
leading to a warning, and to not sending the command.
Fix this by assuming that the default version is 1.
Fixes: 83f3ac2848 ("wifi: iwlwifi: Fix incorrect logic on cmd_ver range checking")
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250624071427.2662621-1-miriam.rachel.korenblit@intel.com
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Use the `DEFINE_RAW_FLEX()` helper for on-stack definitions of
a flexible structure where the size of the flexible-array member
is known at compile-time, and refactor the rest of the code,
accordingly.
So, with these changes, fix the following warnings:
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:124:52: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2067:51: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2162:43: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2225:43: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <kees@kernel.org>
Acked-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/Z_FxXjiMvG5u73fi@kspp
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
We have iwl_tx_cmd for devices older than 22000, iwl_tx_cmd_gen2 for
22000 devices, and iwl_tx_cmd_gen3 ax210 and up.
But the convention for all other APIs is to have the latest version
without any prefix and the older ones - with a _vX prefix,
where X is the highest version that this struct support.
The term 'gen' was introduced as the name of the (back then) new
transport, and should not be used as a device name (for that we have the
actual names: 22000, ax210, etc.)
Now as a new transport, called 'gen3', is going to be written and it can
be confused with this API.
Move iwl_tx_cmd to use the regular versioning convention.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250511195137.806e40c8f767.Ibc0e95e43a6fa6d47f72823bf804314d5db84618@changeid
There are a number of MAC parameters that are in the iwl_cfg
(which is the last config matched to the MAC/RF combination).
This isn't necessary, there are many more of those than MACs,
so move (most of) the data into the MAC family config struct.
Note that DCCM information remains for use by older devices,
and on 9000 series it'll be in struct iwl_cfg but be ignored
when the CRF is in a Qu/So platform.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250508121306.1277801-15-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Different hardware has a different maximum power consumption and the
BIOS can also define a power limit for the device. Add code to select
an appropriate maximum power budget for the device and configure that
instead of using a hardcoded table.
This removes the old table. It does not work with the variable upper
limit and the there should be no consumer that requires these exact step
values.
This considerably increases the power budget for some devices and can
prevent throttling in high traffic situations.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20250506194102.3407967-9-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
