- 21 Jun, 2023 40 commits
-
-
Johannes Berg authored
Again, they're all the same except for the radio and steps, so use the new logic to unify them. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230621130443.676887cc8180.I29994dec43bfb29aad5e4ab0126c06a9ea4670cb@changeidSigned-off-by:
-
Johannes Berg authored
Again, they're all the same except for the radio and steps, so use the new logic to unify them. Signed-off-by:
-
Johannes Berg authored
All the configurations for the various Bz/Gl devices are basically identical, except for Gl A-step and the firmware filename prefixes. Add some infrastructure to auto-generate the firmware filename prefix based on the detected MAC step and RF name/step, and remove all the unneeded configs. This reduces the size of the iwlwifi module by ~9k: 517582 27111 560 545253 851e5 drivers/net/wireless/intel/iwlwifi/iwlwifi.ko 526885 27083 560 554528 87620 drivers/net/wireless/intel/iwlwifi/iwlwifi.ko Signed-off-by:
-
Johannes Berg authored
We don't need this here anymore, ANY is just fine. Still keep the rest of the infrastructure so we can more easily add back support for testing. Signed-off-by:
-
Johannes Berg authored
These are test chips that will never reach anyone outside of Intel, so remove support for them. Signed-off-by:
-
Johannes Berg authored
The earliest firmware released for these products is with API version 50, so there's no point in trying to load any versions before that. Signed-off-by:
-
Johannes Berg authored
The earliest firmware released for these products is with API version 59 (for 'ty' only), so no point trying to go back in time even further than that. Signed-off-by:
-
Johannes Berg authored
This is a future product, don't try to load ancient firmware images for it, they don't exist anyway. Signed-off-by:
-
Johannes Berg authored
This is a future product, don't try to load ancient firmware images for it, they don't exist anyway. Signed-off-by:
-
Johannes Berg authored
They're not the same as Bz or any prior ones, and there's already one place in the driver that would erroneously assign a workaround to A-step Sc devices if they're just treated as a version of Bz. Fix that. Signed-off-by:
-
Johannes Berg authored
Split the configuration list in 22000.c into four new files, per new device family, so we don't have this huge unusable file. Yes, this duplicates a few small things, but that's still much better than what we have now. Signed-off-by:
-
Mukesh Sisodiya authored
Add support for the new Integrated Connectivity (CNVi) and Companion RF (CRF) versions and their combinations to handle new devices. Signed-off-by:
Mukesh Sisodiya <mukesh.sisodiya@intel.com> Signed-off-by:
-
Mukesh Sisodiya authored
Add support for the new version of the Bz CNVI device. Signed-off-by:
-
Ilan Peer authored
Add support for scan request command version 17, which supports specifying the maximal EIRP PSD value that can be used for probe request transmission on a given channel. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Johannes Berg authored
The current formula can skip both too much and not enough time, given the +1 (where the comment about firmware is wrong). Adjust the formula accordingly. Signed-off-by:
-
Johannes Berg authored
When hostapd starts up, it may start up with only one link while the other is still scanning for overlapping BSSes. A station might start to connect at this point, but we run into this warning instead. Since there's no need to check for _all_ links, restrict the check to just the affected links that the STA will be using. Fixes: 57974a55 ("wifi: iwlwifi: mvm: refactor iwl_mvm_mac_sta_state_common()") Reported-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by:
-
Johannes Berg authored
Roee reported various hard-to-debug crashes with pings in EHT aggregation scenarios. Enabling KASAN showed that we access the BAID allocation out of bounds, and looking at the code a bit shows that since the reorder buffer entry (struct iwl_mvm_reorder_buf_entry) is 128 bytes if debug such as lockdep is enabled, then staring from an agg size 512 we overflow the size calculation, and allocate a much smaller structure than we should, causing slab corruption once we initialize this. Fix this by simply using u32 instead of u16. Reported-by:
Roee Goldfiner <roee.h.goldfiner@intel.com> Signed-off-by:
-
Johannes Berg authored
We've already done the 'decryption' here, so tell mac80211 it need not do it again. Fixes: b1fdc250 ("iwlwifi: mvm: advertise BIGTK client support if available") Signed-off-by:
-
Johannes Berg authored
For iwlwifi this is simple to implement, and on newer hardware it's an improvement since we have per-station queues. Signed-off-by:
-
Mukesh Sisodiya authored
Add support for the PCI Id 51F1 without IMR support. Signed-off-by:
-
Benjamin Berg authored
Sending the LARI configuration may trigger calibration, which can have undesired side effects. Move the command to be send earlier (before the phy contexts are registered) to avoid unintended side effects. Signed-off-by:
Benjamin Berg <benjamin.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
This struct member is read-only, so can never change away from the default value of zero. Remove the code that's in an if on the value, since it's effectively dead code. Signed-off-by:
-
Johannes Berg authored
If a discrete NIC is connected to a PCIe link hat isn't at least Gen3 (8.0 GT/s), then we cannot sustain 320 MHz traffic, so remove that from EHT capabilities in that case. While at it, also move setting 320 MHz beamformee to the right place in the code so it's not set while not supporting 320 MHz. Signed-off-by:
-
Johannes Berg authored
Add support for reading the EHT MAC capabilities A-MPDU size exponent field, as indicated by the draft spec. Also clarify the existing code a bit and add comments so it's clearer to understand what's going on here. Signed-off-by:
-
Johannes Berg authored
We can use min_t() for the agg_size and avoid spelling out the (firmware) limit twice. Signed-off-by:
-
Johannes Berg authored
On 2.4 GHz there's no VHT, so EHT defines its own bits for the maximum MPDU length. Use them when telling firmware about the maximum. Signed-off-by:
-
Johannes Berg authored
Handle the regulatory EHT/320 MHz flags from firmware just like any other flags before it. Signed-off-by:
-
Emmanuel Grumbach authored
We need to work on the right link there. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Miri Korenblit authored
This is needed to sync the times in the FW and driver logs Signed-off-by:
-
Emmanuel Grumbach authored
When the firmware says that the channel switch is happening, we check that we know about that switch by checking the csa_active bit. Until now, we checked the bss_conf from the vif instead of taking the bss_conf of the link. Fix that. Signed-off-by:
-
Johannes Berg authored
Ensure that the TX command scratch fits into the buffer provided by the first TB. It does, of course, but add some build-time validations in case we touch this code. Signed-off-by:
-
Johannes Berg authored
We have three places doing this check, and even in slightly different ways (with/without an intermediate). Refactor that to a new small inline function. Signed-off-by:
-
Johannes Berg authored
This just propagates to the channel flags, like no-HE and similar other flags before it. Signed-off-by:
-
Ilan Peer authored
Retrieve the Power Spectral Density (PSD) value from RNR AP information entry and store it so it could be used by the drivers. PSD value is explained in Section 9.4.2.170 of Draft P802.11Revme_D2.0. Signed-off-by:
-
Johannes Berg authored
For extended elements, we currently only calculate the CRC for some of them, but really we should do it also for the rest that we care about, such as EHT operation and multi- link. Also, while at it, it seems we should do it even if they aren't well-formed, so we notice if that changes. Signed-off-by:
-
Benjamin Berg authored
struct sta_info may be removed without holding sta_mtx if it has not yet been inserted. To support this, only assert that the lock is held for links other than the deflink. This fixes lockdep issues that may be triggered in error cases. Signed-off-by:
-
Johannes Berg authored
Due to all the multi-link handling, we now expose the fact that the sdata/vif is locked to drivers, e.g. when the driver uses ieee80211_set_monitor_channel(). This was true when a chanctx is added to or removed from a link, _except_ in monitor mode with the virtual sdata/vif. Change that, so that drivers can make that assumption. Signed-off-by:
-
Johannes Berg authored
When receiving a multi-link association response, make sure to track the BSS parameter change count for each link, including the assoc link. Signed-off-by:
-
Johannes Berg authored
We should not receive/handle unicast protected dual or public action frames that aren't protected, so drop them - in the latter case of course only if MFP is used. Signed-off-by:
-
Johannes Berg authored
We'd like to add more checks to the function here for action frames, so move up the length check from the action processing. Signed-off-by:
-
