Currently ieee80211_csa_finish() function finalizes CSA by scheduling a
finalizing worker using the deflink. With MLO, there is a need to do it
on a given link basis.
Pass link ID of the link on which CSA needs to be finalized.
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Link: https://msgid.link/20240130140918.1172387-6-quic_adisi@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, function to update beacon counter uses deflink to fetch
the beacon and then update the counter. However, with MLO, there is
a need to update the counter for the beacon in a particular link.
Add support to use link_id in order to fetch the beacon from a particular
link data during beacon update counter.
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Link: https://msgid.link/20240130140918.1172387-3-quic_adisi@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Aloka originally suggested that puncturing should be part of
the chandef, so that it's treated correctly. At the time, I
disagreed and it ended up not part of the chandef, but I've
now realized that this was wrong. Even for clients, the RX,
and perhaps more importantly, CCA configuration needs to take
puncturing into account.
Move puncturing into the chandef, and adjust all the code
accordingly. Also add a few tests for puncturing in chandef
compatibility checking.
Link: https://lore.kernel.org/linux-wireless/20220214223051.3610-1-quic_alokad@quicinc.com/
Suggested-by: Aloka Dixit <quic_alokad@quicinc.com>
Link: https://msgid.link/20240129194108.307183a5d2e5.I4d7fe2f126b2366c1312010e2900dfb2abffa0f6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
A DoS tool that injects loads of authentication frames made our AP
crash. The iwl_mvm_is_dup() function couldn't find the per-queue
dup_data which was not allocated.
The root cause for that is that we ran out of stations in the firmware
and we didn't really add the station to the firmware, yet we didn't
return an error to mac80211.
Mac80211 was thinking that we have the station and because of that,
sta_info::uploaded was set to 1. This allowed
ieee80211_find_sta_by_ifaddr() to return a valid station object, but
that ieee80211_sta didn't have any iwl_mvm_sta object initialized and
that caused the crash mentioned earlier when we got Rx on that station.
Cc: stable@vger.kernel.org
Fixes: 57974a55d9 ("wifi: iwlwifi: mvm: refactor iwl_mvm_mac_sta_state_common()")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240206175739.1f76c44b2486.I6a00955e2842f15f0a089db2f834adb9d10fbe35@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The code walking trip points in iwl_mvm_send_temp_report_ths_cmd()
reads the trip table passed to thermal_zone_device_register_with_trips()
in order to get the current trip temperatures, but this is not
guaranteed to work in the future, because the thermal zone will store
trip points information internally.
For this reason, make iwl_mvm_send_temp_report_ths_cmd() use
for_each_thermal_trip() as appropriate for walking trip points in a
given thermal zone.
No intentional functional impact, but it is requisite for future thermal
core improvements.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Miri Korenblit <Miriam.rachel.korenblit@intel.com>
The trip table in iwl_mvm_thermal_zone_register() is populated after
passing it to thermal_zone_device_register_with_trips(), so it may be
accessed (for instance, via sysfs) before it is ready.
To prevent that from happening, modify the function to populate the
trip table before calling thermal_zone_device_register_with_trips().
Also make the code use THERMAL_TEMP_INVALID as the "invalid temperature"
value which is also meaningful for the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Miri Korenblit <Miriam.rachel.korenblit@intel.com>
The fw_trips_index[] array in struct iwl_mvm_thermal_device is only
populated, but never read, so drop it.
Note that the iwl_mvm_send_temp_report_ths_cmd() code populating
fw_trips_index[] is questionable, because it accesses a trips table
of a thermal zone directly, which is not guaranteed to work in the
future.
No functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Miri Korenblit <Miriam.rachel.korenblit@intel.com>
Before sending a SESSION PROTECTION cmd the driver checks if
the link_id indicated in the time event (and for which the cmd will be
sent) is valid and exists.
Clear the te_data::link_id when FW notifies that a session protection
ended, so the check will actually fail when it should.
Fixes: 1350658373 ("wifi: iwlwifi: support link_id in SESSION_PROTECTION cmd")
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240204235836.c64a6b3606c2.I35cdc08e8a3be282563163690f8ca3edb51a3854@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As described in IEEE sta 802.11-2020, table 9-30 (Address
field contents), A-MSDU address 3 should contain the BSSID
address.
In TX_CMD we copy the MAC header from skb, and skb address 3
holds the destination address, but it may not be identical to
the BSSID.
Using the wrong destination address appears to work with (most)
receivers without MLO, but in MLO some devices are checking for
it carefully, perhaps as a consequence of link to MLD address
translation.
Replace address 3 in the TX_CMD MAC header with the correct
address while retaining the skb address 3 unchanged.
This ensures that skb address 3 will be utilized later for
constructing the A-MSDU subframes.
Note that we fill in the MLD address, but the firmware will do the
necessary translation to link address after encryption.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240204235836.4583a1bf9188.I3f8e7892bdf8f86b4daa28453771a8c9817b2416@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For channel contexts, mac80211 currently uses the cfg80211
chandef struct (control channel, center freq(s), width) to
define towards drivers and internally how these behave. In
fact, there are _two_ such structs used, where the min_def
can reduce bandwidth according to the stations connected.
Unfortunately, with EHT this is longer be sufficient, at
least not for all hardware. EHT requires that non-AP STAs
that are connected to an AP with a lower bandwidth than it
(the AP) advertises (e.g. 160 MHz STA connected to 320 MHz
AP) still be able to receive downlink OFDMA and respond to
trigger frames for uplink OFDMA that specify the position
and bandwidth for the non-AP STA relative to the channel
the AP is using. Therefore, they need to be aware of this,
and at least for some hardware (e.g. Intel) this awareness
is in the hardware. As a result, use of the "same" channel
may need to be split over two channel contexts where they
differ by the AP being used.
As a first step, introduce a concept of a channel request
('chanreq') for each interface, to control the context it
requests. This step does nothing but reorganise the code,
so that later the AP's chandef can be added to the request
in order to handle the EHT case described above.
Link: https://msgid.link/20240129194108.2e88e48bd2e9.I4256183debe975c5ed71621611206fdbb69ba330@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are some changes coming to wireless-next that will
otherwise cause conflicts, pull wireless in first to be
able to resolve that when applying the individual changes
rather than having to do merge resolution later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
dmi_get_system_info() will statically return NULL when the
kernel is compiled without CONFIG_DMI, leading to compiler
warnings. Fix that by printing "<unknown>" in that case.
Fixes: c3f40c3e02 ("iwlwifi: mvm: add US/CA to TAS block list if OEM isn't allowed")
Fixes: 9457077df4 ("wifi: iwlwifi: mvm: Add debugfs to get TAS status")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In the following patch, iwl_mvm_roc_duration_and_delay and
iwl_mvm_roc_add_cmd will be called also from time-event.c.
Move then there (where they more belong) and make then
public.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240201155157.3edafc4d59aa.Ic68e90758bcad9ae00e0aa602101842dac60e1a1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
AX210 and above have this logic offloaded in the firmware and it just
ignores the command coming from the driver.
Stop sending it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240201155157.4e3e0b52f98b.I7e9481050921d95c38f5a21ccc47112b3698e859@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For each DSM function, try to first read it from the UEFI.
If the UEFI WIFI GUID is unclocked, or the DSM function in
UEFI is invalid/unavailable - read it from ACPI.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240201155157.27dd626ce2bd.Ib90bab74a9d56deb2362edb712294360e4ddae5b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Move all the common items (functions, enumerations and mcaros)
to regulatory.h/c files, and rename it to a common name.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240201155157.eae9bcbc0023.If1175f3143d6369076669ddd5d6ad4df0ee00659@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As DSMs are going to be read from UEFI too, we need a unified API
to get DSMs for both ACPI and UEFI.
The difference in getting DSM in each one of these methods (ACPI, UEFI)
is in the GUID, revision (0 for ACPI, 4 for UEFI), and size of the DSM
values (8 or 32 for ACPI, 32 for UEFI).
Therefore, change the iwl_acpi_get_dsm_x() to iwl_acpi_get_dsm() which
determines the GUID, revision (these two are the same for all WiFi DSMs),
and size (based on a func-to-size mapping) internally.
While at it, fix DSM_FUNC_RFI_CONFIG to expect a 32-bit value
(as defined in Intel BIOS spec) and not a 8-bit one.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240201155157.1bcd7072a7a5.I344ee0a11abbc27da0c693187d1b8bee653aaeef@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
These functions shouldn't be ACPI_CONFIG dependent, as they don't
access the ACPI. The functions that really access ACPI -
already handle the case that CONFIG_ACPI is not set.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240201155157.1412e6d561f8.I84f67478d01b576457e1bf489fbcb044adfda6fe@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Try to read the ECKV table from UEFI first,
and if the WIFI UEFI tables are unlocked or the
table doesn't exist - try to read it from ACPI.
Change iwl_acpi_get_eckv() to receive fwrt as argument so
it will be the same as all iwl_acpi_get_x() functions,
so it could be generated by the macro.
While at it - move the reading of ECKV to INIT stage. There is no
reason to read it each time we load the FW.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240201155157.d4937cc00727.I36e5fc7f7850229b9b377c80b5203aa47137c97c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Try to read the WRDD table from UEFI first,
and if the WIFI UEFI tables are unlocked or the
table doesn't exist - try to read it from ACPI.
Change iwl_acpi_get_mcc() to receive fwrt as argument so
it will be the same as all iwl_acpi_get_x() functions,
so it could be generated by the macro.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240201155157.5d52eeb109f7.I4d81700a7ae7fe2dfee14e363de358be59de7823@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Set fast balance scan in case of active P2P GO, regardless of the
BSS DTIM interval.
This will increase the chances of scheduler to successfully schedule
out-of-channel events.
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240201155157.310a00388e11.Ib136140dffa8704e68ff14e8fb69d35b97057171@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
New tx devices may have issues sending NDPs from the host.
Send a CQM event instead. If the AP is really gone, we will get a beacon
loss and disconnect.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Reviewed-by: Berg, Johannes <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240201155157.e95d53448e94.I0ec92f1ca56a62cd8c13390b9fe60e9a7e9411c7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Try to read the SPLC table from UEFI first,
and if the WIFI UEFI tables are unlocked or the
table doesn't exist - try to read it from ACPI
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240201155157.3d9d835b6edb.I7ea262df9431ced787b77c87149c6d7bddb7e7d6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As the iwl_bios_get_x() functions are now generated using a macro,
and this macro requires the all iwl_acpi_get_x() to have the same
prototype, change iwl_acpi_get_pwr_limit() to return a int
and the actuall power limit will be filled in a pointer function
parameter.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240201155157.4cce81198afe.Ice8b1b97a68da9ec7b5a4799ddb668642198e1af@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently the driver exits eSR by calling
iwl_mvm_esr_mode_inactive() before updating the FW
(by deactivating one of the links), and therefore before
sending the EML frame notifying that we are no longer in eSR.
This is wrong for several reasons:
1. The driver sends SMPS activation frames when we are still in eSR
and SMPS should be disabled when in eSR
2. The driver restores RLC configuration as it was before eSR
entering, and RLC command shouldn't be sent in eSR
Fix this by calling iwl_mvm_esr_mode_inactive() after FW update
Fixes: 12bacfc2c0 ("wifi: iwlwifi: handle eSR transitions")
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240201155157.d8d9dc277d4e.Ib5aee0fd05e35b1da7f18753eb3c8fa0a3f872f3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Try to read the WTAS table from UEFI first,
and if the WIFI UEFI tables are unlocked or the
table doesn't exist - try to read it from ACPI.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240131091413.45e6ff7b5063.Id3aec70887e14533b10d564f32c0cf5f2a14b792@changeid
[move uefi_tables_lock_status outside ifdef to fix build errors]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently the TAS 'read-from-BIOS' flow receives the command struct
and the version of it as read from FW TLVs, and fills the command
accordingly.
This seems wrong, we should have the 'read-from-BIOS' flow
(iwl_acpi_get_tas in iwlwifi) reading/parsing/validating the table from
BIOS, and the 'send-to-FW' flow (iwl_mvm_tas_init) doing
all the FW versioning checks and cmd filling.
Move the cmd filling to the 'send-to-fw' flow.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240131091413.24df27772a71.I57b702af4feb3f38dc21d52593c25de4b1999e4b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We are going to support reading BIOS tables from UEFI
too, Refactor the TAS table flow:
1. Rename and move the common code to the regulatory.h/c files.
2. Remove the IWL_TAS_BLOCK_LIST_MAX, as we can use IWL_WTAS_BLACK_LIST_MAX
instead.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240131091413.0c2197cf1feb.Ib0e83d5bd3f4d5cfa9c3d2925317ba49377d257f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Try to read the PPAG table from UEFI first,
and if the WIFI UEFI tables are unlocked or the
table doesn't exist - try to read it from ACPI
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240131091413.6516da09aec1.I0dcaf0b6d8857417ba1318467a28da5d0d7d7f27@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As PPAG table is going to be read from UEFI, there are some
cleanups required:
Move functions/definitions that are common to both UEFI and ACPI to
regulatory.h/c.
In addition, rename the functions/macros names so it will be clear which
one is ACPI specific, and which is common for ACPI and UEFI.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240131091413.25623670b422.I8132af7517e4faf0ea8cbeb2efe9651edd319b98@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
1. The name of iwl_read_ppag_table is misleading, as this function only
fills the command structure from the previously read table. Rename it.
2. Don't initialize fwrt::ppag_flags to 0 as the entire fwrt is zeroed
in the INIT stage anyway.
3. Don't filter out the reserved bits from fwrt::ppag_flags when printing
it, as it is already done in 'read-from-bios' flow.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240131091413.48acf340e817.I810e457b80015c1931d96d3e13c849f0339723c3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
All the regulatory tables will be read from UEFI, and
only if it doesn't exist - they will be read from ACPI.
Read SAR tables (WRDS, EWRD and WGDS) from UEFI.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240131091413.533b687e1efb.Icb316291e593c8d53f41fdea2d083367dc97e3c4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
iwl_geo_tx_power_profiles_cmd::table_revision indicates whether
to use South Korea scheme or not.
We use South Korea scheme if the revision of WGDS table is 1.
We used to read the WGDS table from ACPI inside iwl_sar_geo_fill_table(),
so we had to set table_revision only after the call to it.
This added an extra if...else for each cmd version.
But it has been a while since we moved the BIOS tables reading to
INIT stage, and iwl_sar_geo_fill_table() is now only copying the
previously stored table to the cmd structure.
Set the table_revision before the call to iwl_sar_geo_fill_table()
and avoid that extra if...else.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240131091413.17a2384d4535.I306570874f1da0c6345066ebbf74a04b6c8aeb37@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The driver will support reading BIOS tables from UEFI
too. Refactor the SAR tables (WRDS, EWRD, WGDS) flows:
1. Move all the SAR logic/definitions that is common to both
UEFI and ACPI to a new file - regulatory.h/c.
2. Rename the relevant functions/definitions
so it will be clear which is ACPI specific and which is
for both ACPI and UEFI
3. Rename the function that copies the stored tables into the different
commands structures, so will be clear what these functions do.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240131091413.429a9baff34a.I040460348aa1b43609be3a317b86722d6be71c28@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Before using EMLSR check the AP actually advertises
support for it, otherwise reject the link activation.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240131091413.edaac352488d.Ic3533afc6848591e8977391ae39c144d5e794d26@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When using MLO, we need to have only a single link active
when entering suspend and of course most of the code also
needs to be adjusted to not use deflink, apart from older
code that's not used with MLO-capable firmware. Implement
that.
Note that the link selection currently prefers the "best"
link, which might really not be the best for D3, but that
can be fixed later once we agree.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240131091413.38f0fd4d2db0.I27c7a1d08aecc5da0af2c351212f22e92ed70219@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Refactor the check for using a chanctx's def vs. min_def,
to have the same in both places and reuse it later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240129211905.6fcde4051adf.I343934874612d21727ed167accaa967958b2c25b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When we drop frames due to MIC error we want to have something
printed in the logger (this won't be printed by default).
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240129211905.41b0abbf1fd2.Ib6ec6a48ec7bebe769d1e1c1df96380a758a0975@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the firmware has the necessary support, enable SPP A-MSDUs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240129211905.15e4570e471f.I87cf284d3b19bb9f5558f0f33afaace6d6492acb@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ADD_STA resets the link quality data inside the firmware. This is not
supposed to happen and has been fixed for newer devices. For older
devices (AX201 and down), this makes us send frames with rates that are
not in the TLC table.
Fixes: 5a86dcb4a9 ("wifi: iwlwifi: mvm: update station's MFP flag after association")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240129211905.1deca7eaff14.I597abd7aab36fdab4aa8311a48c98a3d5bd433ba@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
With MLO connections we need to let the firmware pick the rate
as we don't know the link the frame might be transmitted on
(in some cases we do know, but we'd rather always use the FW
and find bugs.) We _did_ end up finding bugs and fixing them,
but older devices likely won't get fixed as we don't have a
need for this there, they cannot support MLO.
Thus, go back to picking a rate on the host for the relevant
frames on older (pre-Bz) devices.
Fixes: 499d027904 ("wifi: iwlwifi: Use FW rate for non-data frames")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240129211905.e59056d0a8cc.Iccc4c5c1753921d3d85241ede812a150fb05b898@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When secure LTF is used MFP must also be set.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Avraham Stern <avraham.stern@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240129211905.6cad71069e87.I7f9fd5239cfd2244f155f88419980e6e91d00ff2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There is a spelling mistake in a WARN message. Fix it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240129211905.ff31e9385d29.I3a224e6a9294fdec431919fb4ec9315801e77454@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The IPN is reported by the firmware in 6 bytes little endian,
but mac80211 expects big endian so it can do memcmp() on it.
We used to store this as a u64 which was filled in the right
way, but never used. When implementing that it's used, we
changed it to just be 6 bytes, but lost the conversion. Add
it back.
Fixes: 04f78e242f ("wifi: iwlwifi: mvm: Add support for IGTK in D3 resume flow")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240129211905.138ed8a698e3.I1b66c386e45b5392696424ec636474bff86fd5ef@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add support for handling TID to link mapping negotiation
request and decide whether to accept it or not.
Accept the request if all TIDs are mapped to the same link set,
otherwise reject it.
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240129211905.aab9819c378d.Icf6b79a362763e2e8b85959471f303b586617242@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
All the regulatory tables from BIOS are going to be loaded
(preferably) from the UEFI instead of the ACPI.
There is a security issue with the fact that anyone can
add these UEFI variables.
The solution for that is to have a lock for all WIFI GUID UEFI
variables, and only if the UEFI variables are locked then we can
read it.
The status of the lock (unlocked, locked, test mode) is indicated
in a ACPI table: Guid Lock ACPI Indicator.
Load this table so the driver knows whether to read from UEFI or
not
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240128084842.53994809fbdd.I1bd10aafc387bc04f375e386861ee2bcb82f0a61@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When connecting to an AP, we currently initialize the rate
control only after associating. Since we now use firmware
to assign rates to auth/assoc frames rather than using the
data in the station and the firmware doesn't know, they're
transmitted using low mandatory rates. However, if the AP
advertised only higher supported rates we want to use them
to be nicer (it still must receive mandatory rates though),
so send the information to the firmware earlier to have it
know about it and be able to use it.
Fixes: 499d027904 ("wifi: iwlwifi: Use FW rate for non-data frames")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240128084842.ed7ab1c859c2.I4b4d4fc3905c8d8470fc0fee4648f25c950c9bb7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This will allow to reconnect immediately instead of leaving the
connection in a limbo state.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240128084842.e90531cd3a36.Iebdc9483983c0d8497f9dcf9d79ec37332a5fdcc@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
