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 still surprisingly many non-chanctx drivers, but in
mac80211 that code is a bit awkward. Simplify this by having
those drivers assign 'emulated' ops, so that the mac80211 code
can be more unified between non-chanctx/chanctx drivers. This
cuts the number of places caring about it by about 15, which
are scattered across - now they're fewer and no longer in the
channel context handling.
Link: https://msgid.link/20240129194108.6d0ead50f5cf.I60d093b2fc81ca1853925a4d0ac3a2337d5baa5b@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>
When the system is compiled without CONFIG_DMI, the function
here statically returns NULL, leading to a compiler warning.
Catch that and print "<unknown>" in that case.
While at it, fix some indentation in the function.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202402030641.zUTuACYV-lkp@intel.com/
Fixes: 09059c6764 ("wifi: iwlwifi: prepare for reading PPAG table from UEFI")
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>
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>
We used to check enablement/validity of the PPAG table while reading
it from BIOS.
For newer FWs this checks were offloaded, and the driver needs
to send the PPAG table anyway.
The desicion whether the table needs to be validated before sending it
is FW related and shouln't be in 'read-from-bios' flow.
Move it to 'send-to-fw' flow instead.
This will also help to avoid code duplication of checking validity in
both ACPI and UEFI caes.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240131091413.7043b4087dda.I5a189f9a349556b84a79597fe1e46ffa93664df9@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>
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>
