We don't need the CORES() match nor jacket (which really doesn't
even make sense to match to the RF anyway), and since the subdevice
masks we care about are contiguous, we can encode them as highest
and lowest bit set (automatically.) By encoding whether to match or
not as separate flags and taking advantage of the limited range of
the RF type, step and ID we can reduce the amount of memory needed
for the table, while also making the logic (apart perhaps from the
subdevice mask) easier to understand.
This reduces the size of the module by about 1.5KiB on x86-64.
Johannes Berg [Sun, 11 May 2025 16:53:09 +0000 (19:53 +0300)]
wifi: iwlwifi: cfg: clean up dr/br configs
We don't need the configs that won't end up being used, such as
the "br" config for discrete devices, remove them. Also remove
the module firmware for test chips, that's never needed.
For now keep the iwl_dr_mac_cfg even if it's unused, we'll add
platforms with it once we have their PCI IDs.
Pagadala Yesu Anjaneyulu [Sun, 11 May 2025 16:53:08 +0000 (19:53 +0300)]
wifi: iwlwifi: Add helper function to extract device ID
Add iwl_trans_get_device_id() to extract the device ID
from the hw_id member in the iwl_trans structure.
hw_id member contains both sub-device ID and device ID,
with the device ID occupying bits 16 to 31.
Johannes Berg [Sun, 11 May 2025 16:53:07 +0000 (19:53 +0300)]
wifi: iwlwifi: cfg: mark Ty devices as discrete
Looks like these were never marked discrete, since they always
used the iwl_so_mac_cfg (earlier iwl_so_trans_cfg). Mark them
as discrete since they are.
Johannes Berg [Sat, 10 May 2025 18:48:27 +0000 (21:48 +0300)]
wifi: iwlwifi: cfg: remove MAC type/step matching
Now that it's all split into MAC and RF configs, remove
the matching on MAC type and step. If we ever need to do
something based on the MAC step, we'll have to find some
new mechanism (since the MAC type is known already from
the PCI IDs table, but not the step), or just handle the
(likely small) differences in code.
Johannes Berg [Sat, 10 May 2025 18:48:26 +0000 (21:48 +0300)]
wifi: iwlwifi: cfg: add a couple of older devices
There are some devices that are misidentified, such as 7265-N
and Killer 1435 variants. Add their names, and for some of them
also add the PCI IDs to match at all.
Johannes Berg [Sat, 10 May 2025 18:48:22 +0000 (21:48 +0300)]
wifi: iwlwifi: cfg: clean up JF device matching
This really only needs to be distinguished based on the
RF type, bandwidth limit and possibly diversity (JF1).
Some of the names that are defined don't even exist.
Johannes Berg [Sat, 10 May 2025 18:48:19 +0000 (21:48 +0300)]
wifi: iwlwifi: cfg: unify and add some Killer devices
Unify a number of Killer devices now that we no longer
need to distinguish the MAC type, and add a few more
that wouldn't have gotten the right name before.
Pagadala Yesu Anjaneyulu [Fri, 9 May 2025 10:44:50 +0000 (13:44 +0300)]
wifi: iwlwifi: mld: move aux_sta member from iwl_mld_link to iwl_mld_vif
This change reflects the correct ownership of aux_sta,
as it is not a property of the link but rather of the virtual interface.
Updated the initialization, cleanup and access logic for the aux_sta member
to align with its new location within iwl_mld_vif.
Pagadala Yesu Anjaneyulu [Fri, 9 May 2025 10:44:49 +0000 (13:44 +0300)]
wifi: iwlwifi: mld: Fix ROC activity cleanup in iwl_mld_vif
The roc_activity member in the iwl_mld_vif structure was previously
set to zero during cleanup as was present in struct_group, which
incorrectly indicated ROC_ACTIVITY_HOTSPOT.
To fix this issue, remove roc_activity member from struct_group.
Notify mac80211 of ROC expiration during vif cleanup to maintain
synchronization between the driver and mac80211.
While on it, update it's type to enum iwl_roc_activity.
Johannes Berg [Fri, 9 May 2025 10:44:47 +0000 (13:44 +0300)]
wifi: iwlwifi: rename iwl_cfg to iwl_rf_cfg
With all the cleanups now, we can rename the structure to
better indicate the functionality. For older devices this
isn't quite accurate, of course, but it's better to have a
name that reflects future use for maintenance.
Johannes Berg [Fri, 9 May 2025 10:44:46 +0000 (13:44 +0300)]
wifi: iwlwifi: cfg: clean up Sc/Dr/Br configs
For now, the WH and PE radios require the same config as
FM, so just add a #define for those instead of copying
the data. Since this is true, Sc/Dr/Br all used the same
configs for all RF types, but that's confusing, so now
use the defined WH/PE names for the correct combinations.
We can also now enable the unit test that ensures we have
no duplicate RF configs.
Johannes Berg [Fri, 9 May 2025 10:44:42 +0000 (13:44 +0300)]
wifi: iwlwifi: cfg: unify JF configs
Unify the JF configs to just one JF RF config. This can be
done because the differing fields (thermal and DCCM offsets)
won't be used for Qu MACs (and up) due to firmware support.
Johannes Berg [Fri, 9 May 2025 10:44:41 +0000 (13:44 +0300)]
wifi: iwlwifi: cfg: unify num_rbds config
This should depend on both the RF (VHT/HE/EHT support) and
the MAC (<=22000 can put multiple frames into one buffer),
so unify the config in the struct iwl_cfg to just have it
sized according to the RF, and then double it for all the
MACs starting from AX210 (So/Ty).
Johannes Berg [Fri, 9 May 2025 10:44:40 +0000 (13:44 +0300)]
wifi: iwlwifi: cfg: add ucode API min/max to MAC config
In some older devices, the min/max firmware API supported by
the driver depends on the specific device, when sharing the
the same MAC (config). For most newer devices, it really is
dependent on the MAC instead, since the firmware was frozen
for certain MAC types. However, in the future we expect also
freezes for RF types there.
To handle this most generally, add an API min/max to the MAC
config and then use the narrowest range prescribed by both,
if set.
For the newer MACs since 9000, move the configuration, there
was only a freeze on MAC+RF lines so far.
Johannes Berg [Thu, 8 May 2025 12:13:05 +0000 (15:13 +0300)]
wifi: iwlwifi: cfg: move MAC parameters to MAC data
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.
Johannes Berg [Thu, 8 May 2025 12:13:02 +0000 (15:13 +0300)]
wifi: iwlwifi: rename struct iwl_base_params
These are (going to be) base MAC parameters that are identical
even for different platforms with the same MAC, so rename the
structure accordingly, calling it iwl_family_base_params.
Also rename the pointer to it so the dereferencing is a bit
shorter.
Johannes Berg [Thu, 8 May 2025 12:12:59 +0000 (15:12 +0300)]
wifi: iwlwifi: rename cfg_trans_params to mac_cfg
Since 9000 series devices, the devices are split into MAC and
CRF parts. Currently, "struct iwl_cfg" reflects some MAC and
some RF parameters, but we want to clean this up and move the
MAC data to what's now "struct iwl_cfg_trans_params". As the
first step, to reflect the intent, rename this structure.
Johannes Berg [Thu, 8 May 2025 12:12:53 +0000 (15:12 +0300)]
wifi: iwlwifi: cfg: remove QuZ/JF special cases
Since JF RF always uses b0 step and QuZ MAC always uses
a0 step for firmware, there's no need for these configs
that just force the steps to those values. Remove them.
Johannes Berg [Thu, 8 May 2025 12:12:52 +0000 (15:12 +0300)]
wifi: iwlwifi: build 9000 series FW filenames dynamically
This is more maintainable than the fw_name_pre prefix, and
requires fewer duplicate structs as well. Since only b0 FW
exists, override the MAC/RF steps for these devices.
Johannes Berg [Tue, 6 May 2025 19:41:01 +0000 (22:41 +0300)]
wifi: iwlwifi: pcie: remove 0x2726 devices
These are test chips, not available to users, and not even listed
in the PCI IDs table (so the driver won't bind them). There's no
reason to list specific devices with them in the driver.
Johannes Berg [Tue, 6 May 2025 19:40:59 +0000 (22:40 +0300)]
wifi: iwlwifi: cfg: remove 6 GHz from ht40_bands
Since there's no HT on 6 GHz, only HE, the HT capabilities
are never initialized, and so the ht40_bands value is never
checked for the 6 GHz band. Remove the misleading value.
Benjamin Berg [Tue, 6 May 2025 19:40:58 +0000 (22:40 +0300)]
wifi: iwlwifi: mld: call thermal exit without wiphy lock held
The driver must not hold the wiphy mutex when unregistering the thermal
devices. Do not hold the lock for the call to iwl_mld_thermal_exit and
only do a lock/unlock to cancel the ct_kill_exit_wk work.
The problem is that iwl_mld_tzone_get_temp needs to take the wiphy lock
while the thermal code is holding its own locks already. When
unregistering the device, the reverse would happen as the driver was
calling thermal_cooling_device_unregister with the wiphy mutex already
held.
It is not likely to trigger this deadlock as it can only happen if the
thermal code is polling the temperature while the driver is being
unloaded. However, lockdep reported it so fix it.
Miri Korenblit [Tue, 6 May 2025 19:40:57 +0000 (22:40 +0300)]
wifi: iwlwifi: mld: avoid init-after-queue
rx_omi::finished_work is initialized when the containing link is.
If the worker was queued and then an error happened, we will get to
iwl_mld_init_link from the reconfig and initialize the work after it was
queued.
Benjamin Berg [Tue, 6 May 2025 19:40:56 +0000 (22:40 +0300)]
wifi: iwlwifi: mld: use a radio/system specific power budget
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.
Benjamin Berg [Tue, 6 May 2025 19:40:55 +0000 (22:40 +0300)]
wifi: iwlwifi: mvm: use a radio/system specific power budget
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.
Benjamin Berg [Tue, 6 May 2025 19:40:54 +0000 (22:40 +0300)]
wifi: iwlwifi: fix thermal code compilation with -Werror=cast-qual
The compare_temps function in both mvm and mld dropped the const
qualifier in a cast in a way that makes -Werror=cast-qual unhappy. Add
the const to the cast to fix this.
Yedidya Benshimol [Tue, 6 May 2025 19:40:50 +0000 (22:40 +0300)]
wifi: iwlwifi: Add a new version for sta config command
Add a new version of sta configuration command
which includes these wifi8 features:
1. LDPC X2 CW size support indication
2. Indication if ICF frame is needed instead of RTS
3. support for MIC padding delays for protected control frames
Miri Korenblit [Tue, 6 May 2025 19:40:48 +0000 (22:40 +0300)]
wifi: iwlwifi: mld: remove one more error in unallocated BAID
Since the FW is the one to assign an ID to a BA, it can happen that
the FW sends a bar_frame_release_notif before the driver had the chance to
allocate the BAID.
Convert the IWL_FW_CHECK into a regular debug print.
Johannes Berg [Mon, 5 May 2025 18:56:51 +0000 (21:56 +0300)]
wifi: iwlwifi: make iwl_uefi_get_uats_table() return void
This sets both fwrt->uats_valid and returns 0, but in the
static inline it returns 0 without setting uats_valid,
which is confusing and the iwlmvm code misbehaves in this
case.
Since it already sets uats_valid, just remove the extra
return value.
Miri Korenblit [Mon, 5 May 2025 18:56:48 +0000 (21:56 +0300)]
wifi: iwlwifi: debug: set CDB indication from CSR
In order to set the CDB indication in the dump meta data, we read it from
a specific prph register.
There is a known issue with that register in Xnj setups - in that case it
will always indicate CDB.
Instead of detecting the jacket case and then hardcode whether the CDB
indication should or shouldn't be set (according the CRF),
we can retrieve the CDB bit from the hw_rf_id (CSR_HW_RF_ID).
There is also no reason to do it conditionally only for ax210 / BnJ.
Cleanup the code a bit.
Johannes Berg [Mon, 5 May 2025 18:56:46 +0000 (21:56 +0300)]
wifi: iwlwifi: remove NVM C step override
This was used for debug/bringup of 8000 devices, to be able to
unify between all 8000 devices with NVM override. However, this
is really no longer used, those are ancient devices by now, so
we can remove the logic.
Avraham Stern [Mon, 5 May 2025 18:56:44 +0000 (21:56 +0300)]
wifi: iwlwifi: mld: add debugfs for using ptp clock time for monitor interface
Add a debugfs option to use the ptp clock time for Rx device
timestamps on a monitor interface. This can be useful for e.g.
synchronizing multiple NICs or reporting the timestamp in the
system clock instead of the GP2.
Miri Korenblit [Mon, 5 May 2025 18:56:42 +0000 (21:56 +0300)]
wifi: iwlwifi: mld: don't check the TPT counters when scanning
If there is an ongoing scan that lasts long, the MPDU counters may not
increase enough due the device being busy with scanning and not
because we are in a low throughput scenario.
In that case we don't want to block EMLSR.
Instead, stop checking the counters from the moment we started
scanning, and when the scan ends - clear the counters and schedule a
check in 5 seconds, as usual.
Note that this is only done for regular scan since MLO scan is too short
to affect the counters, and scheduled scan is mainly used when we are
not connected.
Also note that we only stop checking whether to block EMLSR, and not if to
unblock.
There's no need to build a list of individual configs
first and then compare them, we can just go through all
of them and compare if the pointers aren't the same.
The complexity (in terms of number of comparisons) is a
bit higher that way, but it's just a test and the code
complexity is much lower without that.
Johannes Berg [Sun, 4 May 2025 10:26:27 +0000 (13:26 +0300)]
wifi: iwlwifi: tests: allow same config for different MACs
For different MACs we maintain the configs in different
files, and while it's a small waste of space, this is a
worthwhile trade-off for maintenance and simplicity. So
allow different MAC types to have the same config. This
could allow the same config for two MACs in the same MAC
family, but that's not hugely important. Also simplify
the test to not build a config list, there's no good
reason to do that.
Johannes Berg [Sun, 4 May 2025 10:26:25 +0000 (13:26 +0300)]
wifi: iwlwifi: mvm: remove HT greenfield support
No hardware that uses iwlmvm actually supports HT greenfield.
Remove the support and then clean up the v1 rate API by doing
a conversion to v2 rate API, the only thing v1 covered that
couldn't be done in v2 was HT greenfield.
Johannes Berg [Sun, 4 May 2025 10:26:17 +0000 (13:26 +0300)]
wifi: iwlwifi: move STEP config into trans->conf
This really belongs there, it's needed early, so move it. Remove
the related but dead iwl_trans_pcie_ctx_info_gen3_set_step() while
at it. In iwlmld move the calls since they do part of the trans
configuration.
Johannes Berg [Sun, 4 May 2025 10:26:16 +0000 (13:26 +0300)]
wifi: iwlwifi: rework transport configuration
Instead of having a trans_configure method that copies all
the data, just have the users set up the configuration in
the transport directly. This simplifies the code on both
sides. While doing so also move some value from the trans
struct into the conf struct because they are configuration.
Johannes Berg [Sat, 3 May 2025 19:44:33 +0000 (22:44 +0300)]
wifi: iwlwifi: trans: remove SCD base address validation
We pass this parameter around a lot of places just to
validate what the firmware told us against the hardware
with a warning, which seems to never trigger. Remove it.
Ilan Peer [Sat, 3 May 2025 19:44:32 +0000 (22:44 +0300)]
wifi: iwlfiwi: mvm: Fix the rate reporting
The rate validation in mac80211 considers a rate to be valid iff both
the rate index and the count are positive. When the rate scaling is
managed in the driver and not enough traffic passed to set the actual
rate, the driver set the rate to be the optimal rate. However, the rate
count is not set and thus the rate is considered not valid. Fix it by
setting the count to 1.
projects / users / jedix / linux-maple.git / log