Johannes Berg [Mon, 29 Jan 2024 18:34:38 +0000 (19:34 +0100)]
wifi: mac80211: simplify non-chanctx drivers
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.
Johannes Berg [Mon, 29 Jan 2024 18:34:37 +0000 (19:34 +0100)]
wifi: mac80211: clean up HE 6 GHz and EHT chandef parsing
In the code we currently check for support 80+80, 160
and 320 channel widths, but really the way this should
be (and is otherwise) handled is that we compute the
highest channel bandwidth given there, and then cut it
down to what we support. This is also needed for wider
bandwidth OFDMA support.
Change the code to remove this limitation and always
parse the highest possible channel width.
Johannes Berg [Mon, 29 Jan 2024 18:34:36 +0000 (19:34 +0100)]
wifi: mac80211: clean up connection process
Rewrite the station-side connection handling. The connection
flags (IEEE80211_DISABLE_*) are rather confusing, and they're
not always maintained well. Additionally, for wider-bandwidth
OFDMA support we need to know the precise bandwidth of the AP,
which is currently somewhat difficult.
Rewrite this to have a 'mode' (S1G/legacy/HT/...) and a limit
on the bandwidth. This is not entirely clean because some of
those modes aren't completely sequenced (as this assumes in
some places), e.g. VHT doesn't exist on 2.4 GHz, but HE does.
However, it still simplifies things and gives us a good idea
what we're operating as, so we can parse elements accordingly
etc.
This leaves a FIXME for puncturing, this is addressed in a
later patch.
Johannes Berg [Mon, 29 Jan 2024 18:34:35 +0000 (19:34 +0100)]
wifi: mac80211: clean up band switch in duration
Most devices now do duration calculations, so we don't hit
this code at all any more. Clearly the approach of warning
at compile time here when new bands are added didn't work,
the new bands were just added with "TODO". Clean it up, it
won't matter for new bands since they'll just not have any
need to calculate durations in software.
While at it, also clean up and unify the code a bit.
Johannes Berg [Wed, 31 Jan 2024 15:49:04 +0000 (16:49 +0100)]
wifi: mac80211: remove extra shadowing variable
Not sure how this happened or how nothing complained, but
this variable already exists in the outer function scope
with the same value (and the SKB isn't changed either.)
Remove the extra one.
Johannes Berg [Thu, 8 Feb 2024 08:57:43 +0000 (09:57 +0100)]
Merge wireless into wireless-next
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.
Martin Kaistra [Mon, 5 Feb 2024 09:30:40 +0000 (10:30 +0100)]
wifi: rtl8xxxu: update rate mask per sta
Until now, rtl8xxxu_watchdog_callback() only fetches RSSI and updates
the rate mask in station mode. This means, in AP mode only the default
rate mask is used.
In order to have the rate mask reflect the actual connection quality,
extend rtl8xxxu_watchdog_callback() to iterate over every sta. Like in
the rtw88 driver, add a function to collect all currently present stas
and then iterate over a list of copies to ensure no RCU lock problems
for register access via USB. Remove the existing RCU lock in
rtl8xxxu_refresh_rate_mask().
Since the currently used ieee80211_ave_rssi() is only for 'vif', add
driver-level tracking of RSSI per sta.
Now that the driver core can properly handle constant struct bus_type,
move the bcma_bus_type variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.
Now that the driver core can properly handle constant struct bus_type,
move the ssb_bustype variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.
However, since the kernel is build optimized, it seems the stack is not
accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue
is obvious in this function: memory allocated by ieee80211_beacon_get()
is never released. Fixing this leak makes kmemleak happy.
Ping-Ke Shih [Sun, 4 Feb 2024 01:26:27 +0000 (09:26 +0800)]
wifi: rtw89: fw: download firmware with key data for secure boot
Since firmware header contains multiple secure sections, we need to trim
ignored sections, and then download firmware header with single one secure
section.
For secure boot, when downloading secure section, copy security key data
from MSS poll by key_idx read from efuse. If non-secure boot, no need this
extra copy.
+---------------------------+ -\
| firmware header | |
| | |
| +-----------------------+ | | only preserve single one secure
| | section type/size * N | | | section
| | ... | | |
| +-----------------------+ | |
+---------------------------+ -/
: :
+---------------------------+ -\
| secure section type (ID:9)| |
| | |
+----|-> [ security key data ] | |
| +---------------------------+ -/
| |MSS Pool for above section |
| | [ security key data 0 ] |
+----|- [ security key data 1 ] |
by key_idx | [ security key data 2 ] |
| ... |
+---------------------------+
Ping-Ke Shih [Sun, 4 Feb 2024 01:26:26 +0000 (09:26 +0800)]
wifi: rtw89: fw: parse secure section from firmware file
A firmware file can contains more than one section with secure type, so
use secure information from efuse to choose the one with matched
cryptography method. Then choose key data from MSS poll (multiple security
section pool; see below picture) according to key_index from efuse.
Note that the size of MSS pool isn't included in section size defined
in firmware header, so we also need to parse header of MSS pool to get
its size as shift to parse next section.
If secure boot isn't supported by current hardware, the first secure
section will be adopted, and no need additional process to key data.
Ping-Ke Shih [Sun, 4 Feb 2024 01:26:25 +0000 (09:26 +0800)]
wifi: rtw89: fw: read firmware secure information from efuse
To support firmware secure boot, read secure information from efuse to
know if current hardware module can support secure boot with certain
cryptography method.
This information should be prepared before downloading firmware, so read
efuse right after power on at probe stage. The secure information includes
secure cryptography method and secure key index that are used to choose
proper key material when downloading firmware.
Ping-Ke Shih [Sun, 4 Feb 2024 01:26:24 +0000 (09:26 +0800)]
wifi: rtw89: fw: consider checksum length of security data
The newer firmware file provides security data with checksum, so we need to
consider the length. Otherwise it will fail to validate total firmware
length resulting in failed to probe.
Ping-Ke Shih [Fri, 2 Feb 2024 03:06:41 +0000 (11:06 +0800)]
wifi: rtw89: 8922a: add chip_ops::rfk_init_late to do initial RF calibrations later
The RF calibrations are moved into firmware, so we trigger calibrations by
H2C commands and wait for C2H completion events. However, these events
can be received only after HCI (i.e. PCI for now) starts, so we should
do initial RF calibrations after that.
Ping-Ke Shih [Fri, 2 Feb 2024 03:06:40 +0000 (11:06 +0800)]
wifi: rtw89: 8922a: rfk: implement chip_ops to call RF calibrations
Calling RF calibrations when interface up, connection, switching bands and
going to scan.
For 8922AE, RF calibrations are moved to firmware, so use H2C commands to
trigger RF calibrations and wait for a C2H event to indicate completion.
Then, do next RF calibration.
Ping-Ke Shih [Fri, 2 Feb 2024 03:06:39 +0000 (11:06 +0800)]
wifi: rtw89: rfk: add H2C command to trigger TSSI
TSSI is short for transmitter signal strength indication, which is a
close-loop hardware circuit to feedback actual transmitting power as a
reference to adjust power for next transmission.
When connecting and switching bands or channels, do TSSI calibration and
reset hardware status to output expected power.
Ping-Ke Shih [Fri, 2 Feb 2024 03:06:36 +0000 (11:06 +0800)]
wifi: rtw89: rfk: add H2C command to trigger DPK
DPK is short for digital pre-distortion calibration. It can adjusts digital
waveform according to PA linear characteristics dynamically to enhance
TX EVM.
Ping-Ke Shih [Fri, 2 Feb 2024 03:06:35 +0000 (11:06 +0800)]
wifi: rtw89: rfk: add H2C command to trigger RX DCK
RX DCK is receiver DC calibration. This will calibrate DC offset to
reflect correct received signal strength indicator, so mechanisms like CCA
can have normalized values.
Ping-Ke Shih [Fri, 2 Feb 2024 03:06:34 +0000 (11:06 +0800)]
wifi: rtw89: rfk: add H2C command to trigger IQK
IQ signal calibration is a basic and important calibration to yield good RF
performance. Do this calibration on AP channel if we are going to connect.
During scanning phase, it transmits with low data rate, so without IQK
RF performance is still acceptable.
Ping-Ke Shih [Fri, 2 Feb 2024 03:06:33 +0000 (11:06 +0800)]
wifi: rtw89: rfk: send channel information to firmware for RF calibrations
We are going to do RF calibrations in firmware, so driver needs to provide
channel information for calibrations, which can do the same things as
they did in driver.
Ping-Ke Shih [Fri, 2 Feb 2024 03:06:32 +0000 (11:06 +0800)]
wifi: rtw89: rfk: add a completion to wait RF calibration report from C2H event
The RF calibrations should be executed one by one, so add a completion
to ensure one is finish before next. The report from C2H event contains
state and optional version, and we only check the state for now. We also
care about the time a RF calibration takes, so record start time before
asking firmware to do calibration and get the delta time when receiving
report.
Consider SER recovery, we can't receive C2H event, use half of argument
'ms' as fixed delay that is 2 times of measured maximum time of
calibrations.
David Lechner [Thu, 1 Feb 2024 20:12:47 +0000 (14:12 -0600)]
wifi: wilc1000: remove setting msg.spi
Calling spi_sync() unconditionally sets the spi field of struct
spi_message. Therefore setting msg.spi = spi before calling spi_sync()
has no effect and can be removed.
(spi_message_add_tail() does not access this field.)
Linus Walleij [Wed, 31 Jan 2024 22:37:25 +0000 (23:37 +0100)]
wifi: cw1200: Convert to GPIO descriptors
The CW1200 uses two GPIOs to control the powerup and reset
pins, get these from GPIO descriptors instead of being passed
as platform data from boardfiles.
The RESET line will need to be marked as active low as we will
let gpiolib handle the polarity inversion.
The SDIO case is a bit special since the "card" need to be
powered up before it gets detected on the SDIO bus and
properly probed. Fix this by using board-specific GPIOs
assigned to device "NULL".
Kalle Valo [Tue, 30 Jan 2024 15:15:55 +0000 (17:15 +0200)]
wifi: cw1200: fix __le16 sparse warnings
Sparse warns:
drivers/net/wireless/st/cw1200/cw1200_spi.c:83:17: got restricted __le16 [usertype]
drivers/net/wireless/st/cw1200/cw1200_spi.c:148:17: warning: incorrect type in assignment (different base types)
drivers/net/wireless/st/cw1200/cw1200_spi.c:148:17: expected unsigned short [addressable] [assigned] [usertype] regaddr
drivers/net/wireless/st/cw1200/cw1200_spi.c:148:17: got restricted __le16 [usertype]
These cpu_to_le16() calls are not really making any sense to me. On a big
endian system we first convert regaddr from big to little using cpu_to_le16()
but immediately after we convert them back to big endian? So just remove them.
Kalle Valo [Tue, 30 Jan 2024 15:15:54 +0000 (17:15 +0200)]
wifi: rsi: fix restricted __le32 degrades to integer sparse warnings
drivers/net/wireless/rsi/rsi_91x_usb.c:235:27: warning: restricted __le32 degrades to integer
drivers/net/wireless/rsi/rsi_91x_usb.c:236:27: warning: restricted __le32 degrades to integer
drivers/net/wireless/rsi/rsi_91x_usb.c:237:27: warning: restricted __le32 degrades to integer
drivers/net/wireless/rsi/rsi_91x_usb.c:238:27: warning: restricted __le32 degrades to integer
drivers/net/wireless/rsi/rsi_91x_usb.c:244:36: warning: restricted __le32 degrades to integer
drivers/net/wireless/rsi/rsi_91x_usb.c:245:35: warning: restricted __le32 degrades to integer
These cpu_to_le32() are not making sense. With usb_reg_buf we handle the values
byte at a time to make sure usb_reg_buf is in little endian so no need to
convert anything. And usb_control_msg() expects to have the values in native
endian anyway. So just remove these so they are not spamming our logs.
Kalle Valo [Tue, 30 Jan 2024 15:15:53 +0000 (17:15 +0200)]
wifi: zd1211rw: remove __nocast from zd_addr_t
Sparse warns:
drivers/net/wireless/zydas/zd1211rw/zd_usb.c:383:24: warning: implicit cast from nocast type
drivers/net/wireless/zydas/zd1211rw/zd_usb.c:419:24: warning: implicit cast from nocast type
This is an ancient driver which has not have any meaningfuli changes for a long
time and hopefully removed soon. So just remove the __nocast to get rid of the
sparse warnings.
Zhipeng Lu [Fri, 26 Jan 2024 07:53:34 +0000 (15:53 +0800)]
wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
In the for statement of lbs_allocate_cmd_buffer(), if the allocation of
cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to
be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().
Johannes Berg [Sun, 4 Feb 2024 10:03:39 +0000 (11:03 +0100)]
wifi: cfg80211: fix kunit exports
These can only be exported if cfg80211's kunit is enabled,
since they're otherwise static. kunit itself can be enabled
even if cfg80211's kunit isn't. Fix that by using the right
macro.
Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: 45d43937a44c ("wifi: cfg80211: add a kunit test for 6 GHz colocated AP parsing") Signed-off-by: Johannes Berg <[email protected]>
Johannes Berg [Sun, 4 Feb 2024 09:56:27 +0000 (10:56 +0100)]
wifi: iwlwifi: mvm: fix warnings from dmi_get_system_info()
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: c3f40c3e0273 ("iwlwifi: mvm: add US/CA to TAS block list if OEM isn't allowed") Fixes: 9457077df49e ("wifi: iwlwifi: mvm: Add debugfs to get TAS status") Signed-off-by: Johannes Berg <[email protected]>
Johannes Berg [Sun, 4 Feb 2024 09:53:18 +0000 (10:53 +0100)]
wifi: iwlwifi: fw: fix compiler warning for NULL string print
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 <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: 09059c6764a8 ("wifi: iwlwifi: prepare for reading PPAG table from UEFI") Signed-off-by: Johannes Berg <[email protected]>
Johannes Berg [Sun, 4 Feb 2024 09:48:18 +0000 (10:48 +0100)]
wifi: iwlwifi: fw: fix compile w/o CONFIG_ACPI
The user of this function passes a pointer to a value that
doesn't exist when compiled w/o CONFIG_ACPI. Since we don't
need the value then, make the non-ACPI version a macro to
allow it to still build.
Kees Cook [Fri, 26 Jan 2024 22:31:53 +0000 (14:31 -0800)]
wifi: brcmfmac: Adjust n_channels usage for __counted_by
After commit e3eac9f32ec0 ("wifi: cfg80211: Annotate struct
cfg80211_scan_request with __counted_by"), the compiler may enforce
dynamic array indexing of req->channels to stay below n_channels. As a
result, n_channels needs to be increased _before_ accessing the newly
added array index. Increment it first, then use "i" for the prior index.
Solves this warning in the coming GCC that has __counted_by support:
../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function 'brcmf_internal_escan_add_info':
../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:3783:46: warning: operation on 'req->
n_channels' may be undefined [-Wsequence-point]
3783 | req->channels[req->n_channels++] = chan;
| ~~~~~~~~~~~~~~~^~
Shaul Triebitz [Thu, 1 Feb 2024 14:17:41 +0000 (16:17 +0200)]
wifi: iwlwifi: mvm: make functions public
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.
Miri Korenblit [Thu, 1 Feb 2024 14:17:37 +0000 (16:17 +0200)]
wifi: iwlwifi: read DSM functions from UEFI
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.
Miri Korenblit [Thu, 1 Feb 2024 14:17:35 +0000 (16:17 +0200)]
wifi: iwlwifi: simplify getting DSM from ACPI
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.
Miri Korenblit [Thu, 1 Feb 2024 14:17:34 +0000 (16:17 +0200)]
wifi: iwlwifi: take send-DSM-to-FW flows out of ACPI ifdef
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.
Miri Korenblit [Thu, 1 Feb 2024 14:17:32 +0000 (16:17 +0200)]
wifi: iwlwifi: read ECKV table from UEFI
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.
Ayala Beker [Thu, 1 Feb 2024 14:17:28 +0000 (16:17 +0200)]
wifi: iwlwifi: mvm: use fast balance scan in case of an active P2P GO
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.
wifi: iwlwifi: mvm: don't send NDPs for new tx devices
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.
Miri Korenblit [Thu, 1 Feb 2024 14:17:25 +0000 (16:17 +0200)]
wifi: iwlwifi: prepare for reading SPLC from UEFI
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.
Benjamin Berg [Thu, 1 Feb 2024 14:17:30 +0000 (16:17 +0200)]
wifi: iwlwifi: do not announce EPCS support
mac80211 does not have proper support for EPCS currently as that would
require changing the ECDA parameters if EPCS (Emergency Preparedness
Communications Service) is in use. As such, do not announce support for
it in the capabilities.
Miri Korenblit [Thu, 1 Feb 2024 14:17:39 +0000 (16:17 +0200)]
wifi: iwlwifi: exit eSR only after the FW does
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
Johannes Berg [Mon, 29 Jan 2024 18:54:21 +0000 (19:54 +0100)]
wifi: nl80211: move WPA version validation to policy
For a contiguous mask (starting with bit 0) of allowed values
in a bitmap, it's equivalent to check "!(val & ~mask)" and
"val ∈ [0, mask]". Use that to move the WPA versions check to
the policy, for better error reporting.
Johannes Berg [Mon, 29 Jan 2024 18:57:39 +0000 (19:57 +0100)]
wifi: mac80211: clean up FILS discovery change flags handling
It doesn't make sense to return BSS change flags in an int, as
they're a bigger type. For this particular function it still
works OK, but clean it up to avoid future errors (or copying
this code in a broken way.)
Johannes Berg [Mon, 29 Jan 2024 18:54:35 +0000 (19:54 +0100)]
wifi: mac80211: trace SMPS requests from driver
Even if there are a lot of possible ways drivers might
call this, at least knowing when they do and with what
settings can be useful. Add tracing for it.
Johannes Berg [Mon, 29 Jan 2024 19:00:02 +0000 (20:00 +0100)]
wifi: mac80211_hwsim: add control to skip beacons
To test certain beacon loss scenarios it can be useful to
simply not send a couple of beacons. Add a simple debugfs
file (per vif) to skip sending the beacons. They're still
fully prepared etc. so their DTIM count etc. will appear
as if they were simply corrupt over the air or otherwise
not received.
Miri Korenblit [Wed, 31 Jan 2024 08:24:46 +0000 (10:24 +0200)]
wifi: iwlwifi: separate TAS 'read-from-BIOS' and 'send-to-FW' flows
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.
Miri Korenblit [Wed, 31 Jan 2024 08:24:42 +0000 (10:24 +0200)]
wifi: iwlwifi: validate PPAG table when sent to FW
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.
Miri Korenblit [Wed, 31 Jan 2024 08:24:41 +0000 (10:24 +0200)]
wifi: iwlwifi: prepare for reading PPAG table from UEFI
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.
Miri Korenblit [Wed, 31 Jan 2024 08:24:40 +0000 (10:24 +0200)]
wifi: iwlwifi: small cleanups in PPAG table flows
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.
Miri Korenblit [Wed, 31 Jan 2024 08:24:39 +0000 (10:24 +0200)]
wifi: iwlwifi: read SAR tables from UEFI
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.
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.
Miri Korenblit [Wed, 31 Jan 2024 08:24:37 +0000 (10:24 +0200)]
wifi: iwlwifi: prepare for reading SAR tables from UEFI
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.
Johannes Berg [Wed, 31 Jan 2024 08:24:35 +0000 (10:24 +0200)]
wifi: iwlwifi: mvm: d3: implement suspend with MLO
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.
Miri Korenblit [Wed, 31 Jan 2024 08:24:34 +0000 (10:24 +0200)]
wifi: iwlwifi: read BIOS PNVM only for non-Intel SKU
The driver is supposed to read the PNVM from BIOS only for non-Intel
SKUs. For Intel SKUs the OEM ID will be 0.
Read BIOS PNVM only when a non-Intel SKU is indicated.
wifi: iwlwifi: mvm: fix the TLC command after ADD_STA
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.
Johannes Berg [Mon, 29 Jan 2024 19:21:58 +0000 (21:21 +0200)]
wifi: iwlwifi: mvm: use FW rate for non-data only on new devices
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.
Johannes Berg [Mon, 29 Jan 2024 19:21:51 +0000 (21:21 +0200)]
wifi: iwlwifi: mvm: d3: fix IPN byte order
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.
Ayala Beker [Mon, 29 Jan 2024 19:21:50 +0000 (21:21 +0200)]
wifi: iwlwifi: mvm: add support for TID to link mapping neg request
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.
Miri Korenblit [Mon, 29 Jan 2024 19:21:49 +0000 (21:21 +0200)]
wifi: iwlwifi: fix EWRD table validity check
EWRD ACPI table contains up to 3 additional sar profiles.
According to the BIOS spec, the table contains a n_profile
variable indicating how many additional profiles exist in the
table.
Currently we check that n_profiles is not <= 0.
But according to the BIOS spec, 0 is a valid value,
and it can't be < 0 anyway because we receive that from ACPI as
an unsigned integer.
projects / linux.git / log