summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
AgeCommit message (Collapse)AuthorFilesLines
2024-03-01iwlwifi: mvm: do more useful queue sync accountingJohannes Berg1-1/+1
[ Upstream commit 2f7a04c7b03b7fd63b7618e29295fc25732faac1 ] We're currently doing accounting on the queue sync with an atomic variable that counts down the number of remaining notifications that we still need. As we've been hitting issues in this area, modify this to track a bitmap of queues, not just the number of queues, and print out the remaining bitmap in the warning. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201209231352.0a3fa177cd6b.I7c69ff999419368266279ec27dd618eb450908b3@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Stable-dep-of: 5f8a3561ea8b ("iwlwifi: mvm: write queue_sync_state only for sync") Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-08iwlwifi: mvm: retry init flow if failedMordechay Goodstein1-0/+3
commit 5283dd677e52af9db6fe6ad11b2f12220d519d0c upstream. In some very rare cases the init flow may fail. In many cases, this is recoverable, so we can retry. Implement a loop to retry two more times after the first attempt failed. This can happen in two different situations, namely during probe and during mac80211 start. For the first case, a simple loop is enough. For the second case, we need to add a flag to prevent mac80211 from trying to restart it as well, leaving full control with the driver. Cc: <stable@vger.kernel.org> Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20211110150132.57514296ecab.I52a0411774b700bdc7dedb124d8b59bf99456eb2@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-08iwlwifi: mvm: prepare roc_done_wk to work syncNathan Errera1-1/+1
As part of changes made to properly support auxiliary activities in CDB NICs, an aux sta will be added when using hot spot 2.0 and will need to be removed when roc flow is done. In order to do so, prepare the roc_done_wk to work synchronously as the rm_aux_sta is a SYNC command. Since now all of th iwl_mvm_flush_sta function are using it sync, removed the flag argument from the function. Signed-off-by: Nathan Errera <nathan.errera@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20201008180656.71b441c8b682.Ia1d216cb680308b91d6da9f73e23ae9f4baac79f@changeid
2020-10-08iwlwifi: mvm: get number of stations from TLVNathan Errera1-3/+3
FW is changing the max number of supported stations. To adapt to the change we get the max number from the TLV and act according to the new number. Signed-off-by: Nathan Errera <nathan.errera@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20201008180656.863ab470babc.I393223392f36436663c4e66add03fefe77b74e60@changeid
2020-10-01iwlwifi: mvm: support more GTK rekeying algorithmsNathan Errera1-1/+5
add and use new API version for GTK rekeying. This will allow our firmware to do GTK rekeying for more algorithms (GCMP 128, GCMP 256, SAE). Signed-off-by: Nathan Errera <nathan.errera@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200930161256.be16c51fef3c.If4fac0fbc5bede4679b5f875b60c4e9a6ea7ca7c@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-10-01iwlwifi: mvm: initiator: add option for adding a PASN responderAvraham Stern1-0/+5
Add an option for adding a PASN responder, specifying the HLTK and TK (if not associated). When a receiving a range request for a PASN responder, the driver will ask for a secured measurement with the specified HLTK and TK. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200930161256.28c5f5266000.I2d58b72ff92c47ac33a6aacc27fbf3790b6dfc51@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-10-01iwlwifi: mvm: location: set the HLTK when PASN station is addedAvraham Stern1-0/+15
When a PASN station is added, set the HLTK to FW. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200930161256.1c7a59fd3164.I68005f0015ad04e53d0239e2d2ee85d5ffdeaa37@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-10-01iwlwifi: mvm: Add FTM initiator RTT smoothing logicIlan Peer1-0/+5
The overcome instabilities in the RTT results add smoothing logic to the reported results. In short, the smoothing logic tracks the RTT average of each responder for a period of time, and in case a new RTT results is found to be a spur, the tracked RTT average is reported instead of the current RTT measurement. Smooth logic debug configuration using iwl-dbg-cfg.ini: - MVM_FTM_INITIATOR_ENABLE_SMOOTH: Set to 1 to enable smoothing logic (default=0). - MVM_FTM_INITIATOR_SMOOTH_ALPHA: A value between 0 - 100, defining the weight of the current RTT results vs. the RTT average tracked based on the previous results. A value of 100 means use only the current RTT results. - MVM_FTM_INITIATOR_SMOOTH_AGE_SEC: The maximal time in seconds in which the RTT average tracked based on previous results is considered valid. - MVM_FTM_INITIATOR_SMOOTH_UNDERSHOOT: if the current RTT is positive and below the RTT average by at least this value, report the average RTT instead of the current one. In units of picoseconds. - MVM_FTM_INITIATOR_SMOOTH_OVERSHOOT: if the current RTT is positive and above the RTT average by at least this value, report the average RTT instead of the current one. In units of picoseconds. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200930161256.48a9cec2081b.Iaec1e29f738232adfe9e2ea8e9eb9b6ff0323ae1@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-10-01iwlwifi: mvm: add support for range request command ver 11Avraham Stern1-0/+1
Version 11 of the range request command adds support for setting the PN for secure ranging. For now, this is not yet supported. The same functions that are used for version 9 and 10 are also used for version 11 as the common part is the same. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200928121852.6f9ed4140e8c.I046e0d9f6dfaafda9794e5eb2ee1f02fcad2851a@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-10-01iwlwifi: fw: add default value for iwl_fw_lookup_cmd_verMordechay Goodstein1-1/+2
For new APIs this avoids checking every return if it's IWL_FW_CMD_VER_UNKNOWN (99) or it's lower than the new API value Done with spatch: -iwl_fw_lookup_cmd_ver(E1, E2, E3) +iwl_fw_lookup_cmd_ver(E1, E2, E3, IWL_FW_CMD_VER_UNKNOWN) Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200928121852.70bec6eb8008.I6ea78553801d33f7ed10fcd2e4be4ba781fe469a@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-10-01iwlwifi: acpi: rename geo structs to contain versioningLuca Coelho1-5/+0
Add the version number to the iwl_geo_tx_power_profile_cmd structs and move the union into a common place. Additionally, reuse the code that sets elements that are at the same place in the struct across different versions. While at it remove an unused variable, add a comment and move the v2 specific element setting to inside the if statement. Additionally, invert the if for slightly more readability. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200928121852.23ec241f16cd.I8cd21fc5a2498e820b50e1f49a4cbfe545afe30e@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-10-01iwlwifi: mvm: remove redundant support_umac_log fieldMordechay Goodstein1-1/+0
Currently we have the same info in two variables, If umac_error_event_table is 0, we know that UMAC log is not supported, so we don't need the support_umac_log field. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200926002540.299959eeb47b.Ie1f3eecc06e3620098dda74f674f6409b90fe7fa@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-10-01iwlwifi: mvm: add an option to add PASN stationAvraham Stern1-0/+10
A FTM responder may do PASN authentication with unassociated stations to allow secure ranging. In this case, the driver will add an internal station and install the TK so the FW will accept protected FTM request frames from this station and will send a protected FTM response frame. In addition, the driver needs to configure the HLTK to the FW so the FW can derive the secure LTF bits. This is left for a later patch since it is not yet supported by the FW. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200911204056.c915b44ad7dd.I72ef7f9753964555561c27ec503241105eddb14e@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-05-08iwlwifi: mvm: remove iwlmvm's tfd_q_hang_detect module parameterEmmanuel Grumbach1-6/+2
This should be controlled by the firmware debugging mechanism and not by a module parameter. This has always been true. Remove it and assume it is set. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200424182644.b6e4982e62ae.I7f7352f79c40ada2f221bd4b41449a40821e833f@changeid
2020-04-24iwlwifi: move API version lookup to common codeMordechay Goodstein1-2/+2
The API version lookup is parsed from a TLV and should be in shared code make make it reusable across all opmodes. Also change the function names from mvm to fw, since this is not mvm-specific anymore. Additionally, since this function is not just a single line of code, it shouldn't be inline. Convert them to actual functions. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200421133326.cf94672dfcdb.I5ede9cc25ee8de7b8d2b5c574f917a18971da734@changeid
2020-03-27iwlwifi: scan: support FW APIs with variable number of profilesTova Mussai1-0/+7
The FW changed the maximum number of scan offload profiles to 8 in new APIs. Support it by changing the scan_offload_profile_cfg struct to be more dynamic, so we can reuse most of the code and only change size of the profiles array. Change-Id: I65210cf541af46e2675a8c764d5871f7f5b070d6 Signed-off-by: Tova Mussai <tova.mussai@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-01-27Merge tag 'wireless-drivers-next-2020-01-26' of ↵David S. Miller1-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for v5.6 Second set of patches for v5.6. Nothing special standing out, smaller new features and fixes allover. Major changes: ar5523 * add support for SMCWUSBT-G2 USB device iwlwifi * support new versions of the FTM FW APIs * support new version of the beacon template FW API * print some extra information when the driver is loaded rtw88 * support wowlan feature for 8822c * add support for WIPHY_WOWLAN_NET_DETECT brcmfmac * add initial support for monitor mode qtnfmac * add module parameter to enable DFS offloading in firmware * add support for STA HE rates * add support for TWT responder and spatial reuse ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-24iwlwifi: remove lar_disable module parameterLuca Coelho1-3/+0
This is an old parameter that was used supposed to be used only when LAR was still under development. It should not be used anymore, but, since it's available, end-users have been mangling with it unnecessarily. In some cases it can cause problems because when LAR is supported the driver and the firmware do not expect it to be disabled. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-24iwlwifi: mvm: fix potential SKB leak on TXQ TXJohannes Berg1-2/+2
When we transmit after TXQ dequeue, we aren't paying attention to the return value of the transmit functions, leading to a potential SKB leak. Refactor the code a bit (and rename ..._tx to ..._tx_sta) to check for this happening. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: cfbc6c4c5b91 ("iwlwifi: mvm: support mac80211 TXQs model") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-20iwlwifi: mvm: update powersave correctly for D3Johannes Berg1-0/+2
This fixes a long-standing bug - we haven't been able to check the firmware image that was loaded for D3/not-D3 since the introduction of the unified image... Fix this by keeping a status flag for D3 instead of checking for the firmware image that's loaded. This reduces occurrences of checks for IWL_UCODE_WOWLAN to just the code that actually loads the image or deals with it in other ways. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-11-15iwlwifi: refactor the SAR tables from mvm to acpiIhab Zhaika1-16/+5
Refactored the SAR related functions from iwlmvm to acpi in order to make it shared between different opmodes in addition to removing unused variable ppag_rev. Signed-off-by: Ihab Zhaika <ihab.zhaika@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-15iwlwifi: scan: make new scan req versioning flowShahar S Matityahu1-9/+0
Implement a new versioning handling flow supported from version 11 onwards. Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-15iwlwifi: scan: adapt the code to use api ver 11Tova Mussai1-0/+9
FW scan api ver 11 adds support for some new features, in this version the fw did also some cleanup in the api, which causes the driver not to be able to use the current scan req struct. Therefore, in this patch the driver has new version for the scan command code Signed-off-by: Tova Mussai <tova.mussai@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-06Merge tag 'wireless-drivers-next-2019-11-05' of ↵David S. Miller1-4/+31
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 5.5 First set of patches for 5.5. The most active driver here clearly is rtw88, lots of patches for it. More quiet on other drivers, smaller fixes and cleanups all over. This pull request also has a trivial conflict, the report and example resolution here: https://lkml.kernel.org/r/20191031111242.50ab1eca@canb.auug.org.au Major changes: rtw88 * add deep power save support * add mac80211 software tx queue (wake_tx_queue) support * enable hardware rate control * add TX-AMSDU support * add NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 support * add power tracking support * add 802.11ac beamformee support * add set_bitrate_mask support * add phy_info debugfs to show Tx/Rx physical status * add RFE type 3 support for 8822b ath10k * add support for hardware rfkill on devices where firmware supports it rtl8xxxu * add bluetooth co-existence support for single antenna iwlwifi * Revamp the debugging infrastructure ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-30iwlwifi: fw api: support new API for scan config cmdAyala Beker1-0/+6
The API was reduced to include only knowledge currently needed by the FW scan logic, the rest is legacy. Support the new, reduced version. Using the old API with newer firmwares (starting from iwlwifi-*-50.ucode, which implements and requires the new API version) causes an assertion failure similar to this one: [ 2.854505] iwlwifi 0000:00:14.3: 0x20000038 | BAD_COMMAND Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-25iwlwifi: rx: use new api to get band from rx mpduTova Mussai1-0/+6
The FW introduce new API to get the band from the rx mpdu, use this new API. Signed-off-by: Tova Mussai <tova.mussai@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-10-25iwlwifi: mvm: create function to convert nl80211 band to phy bandTova Mussai1-4/+18
Create the function and use it. Signed-off-by: Tova Mussai <tova.mussai@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-10-25iwlwifi: mvm: add notification for missed VAPLior Cohen1-0/+2
A missed VAP notification will be sent from umac when the station is out of sync with its associated non-transmitted BSSID. The notification will be sent only if the transmitted BSSID is an EMA-AP one. The driver will consider this notification as connection loss. Signed-off-by: Lior Cohen <lior2.cohen@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-10-25iwlwifi: mvm: add support for new version for D0I3_END_CMDHaim Dreyfuss1-0/+4
During D3 state there are some flows which requires FW reset. Add new API to support it. Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: mvm: handle BAR_FRAME_RELEASE (0xc2) notificationJohannes Berg1-0/+2
In prior hardware generations (e.g. 9000 series), we received the BAR frame with fake NSSN information to handle releasing frames from the reorder buffer for the default queue, the other queues were getting the FRAME_RELEASE notification in this case. With multi-TID block-ack, the firmware no longer sends us the BAR frame because the fake RX is quite big (just the metadata is around 48 bytes or so). Instead, it now sends us one (or multiple) special release notifications (0xc2). The hardware consumes these as well, but only generates the FRAME_RELEASE (0xc3) for queues other than the default queue. We thus need to handle them in the same way we handle the normal FRAME_RELEASE. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: mvm: drop BA sessions on too many old-SN framesJohannes Berg1-0/+9
Certain APs (I think a certain Broadcom model) interact badly with our full state BA bitmap handling, and if triggered badly with many powersave transitions they keep sending frames from before the window, which our hardware then doesn't appear to ACK (to them) since it has moved on and is sending ACKs for higher SNs now. Try to detect this situation and if this keeps happening, disable the aggregation session. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: always access the trans configuration via transLuca Coelho1-1/+1
Stop accessing the trans configuration via the iwl_cfg structure and always access it via the iwl_trans structure. This completes the requirements to disassociate the trans-specific configuration from the rest of the configuration. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: add a pointer to the trans_cfg directly in transLuca Coelho1-3/+3
Add a pointer to the iwl_trans structure and point it to the trans part of the cfg. This is the first step in disassociating the trans configuration from the rest of the configuration. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: separate elements from cfg that are needed by trans_allocLuca Coelho1-4/+4
In order to be able to select the cfg depending on the HW revision or on the RF ID, we need to set up the trans before selecting the cfg. To do so, move the elements from cfg that are needed by iwl_trans_alloc() to a separate struct at the top of the cfg, so it can be used by other cfg types as well, before selecting the rest of the configuration. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: support per-platform antenna gainGil Adam1-0/+3
TX power limits as defined in the OTP assume the worst case scenario in terms of the platform's atenna gain, but most platforms are below that value so they can use more TX power without passing the regulatory limit. If the platform indicates in the BIOS that it indeed has lower gain, and the geographic location allows it, higher TX power can be used. The driver reads the PPAG (Per-Platform Antenna Gain) data from BIOS (if it exists), validates it and sends the appropriate command to the FW. This flow happens once at FW init, in case of suspend/resume there is no need to read again from BIOS as we save those values during init, so just send the PPAG command again to FW. Signed-off-by: Gil Adam <gil.adam@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: Set w-pointer upon resume according to SNAlex Malamud1-0/+1
During D3 state, FW may send packets. As a result, "write" queue pointer will be incremented by FW. Upon resume from D3, driver should adjust its shadows of "write" and "read" pointers to the value reported by FW. 1. Keep TID used during wowlan configuration. 2. Upon resume, set driver's "write" and "read" queue pointers to the value reported by FW. Signed-off-by: Alex Malamud <alex.malamud@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: mvm: use FW thermal monitoring regardless of CONFIG_THERMALJohannes Berg1-4/+0
It doesn't make sense to use the FW thermal monitoring only if we have CONFIG_THERMAL, because then we use the default thresholds etc. which may be different from what the firmware implements, as we don't maintain them in the driver now. Only the CTDP code needs to actually be under CONFIG_THERMAL. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: scan: add support for new scan request command versionAyala Beker1-0/+6
Scan API was changed to support 6Ghz channels as well. Support the new version. Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: mvm: remove last leftovers of d0i3Emmanuel Grumbach1-7/+0
We're now left with a status bit that is never set and a few other leftovers. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: mvm: remove iwl_mvm_update_d0i3_power_modeEmmanuel Grumbach1-3/+0
Also change the signature of the power functions that won't receive d0i3=true anymore. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: mvm: remove d0i3_ap_sta_idEmmanuel Grumbach1-3/+0
This variable read, but never set. Remove it. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: mvm: iwl_mvm_wowlan_config_key_params is for wowlan onlyEmmanuel Grumbach1-12/+0
Now that d0i3 is dead, this function can't be called from d0i3 flows. Change its signature and make it static. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: mvm: remove the d0i3 entry/exit flowEmmanuel Grumbach1-34/+1
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: mvm: remove the tx defer for d0i3Emmanuel Grumbach1-4/+0
This is not needed anymore Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: remove all the d0i3 referencesEmmanuel Grumbach1-49/+0
As part of the d0i3 removal. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: dbg: move debug recording stop from trans to op modeShahar S Matityahu1-1/+2
The op mode should stop the debug recording and not the transport layer. Rename iwl_fwrt_stop_device into iwl_fw_dbg_stop_sync and move the debug stop recording to it. Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-09-06iwlwifi: mvm: Block 26-tone RU OFDMA transmissionsIlan Peer1-0/+3
In case that there are OBSS that do not know how to properly interpret 26-tone RU OFDMA transmissions, instruct the FW not to use such transmissions. The check is currently only performed upon association. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-07-30iwlwifi: mvm: send LQ command always ASYNCGregory Greenman1-1/+1
The only place where the command was sent as SYNC is during init and this is not really critical. This change is required for replacing RS mutex with a spinlock (in the subsequent patch), since SYNC comamnd requres sleeping and thus the flow cannot be done when holding a spinlock. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-30iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queuesEmmanuel Grumbach1-1/+1
In order to support MSI-X efficiently, we want to avoid communication across Rx queues. Each Rx queue should have all the data it needs to process a packet. The reordering buffer is a challenge in the MSI-X world since we can have a single BA session whose packets are directed to different queues. This is why each queue has its own reordering buffer. The hardware is able to hint the driver whether we have a hole or not, which allows the driver to know whether it can release a packet or not. This indication is called NSSN. Roughly, if the packet's SN is lower than the NSSN, we can release the packet to the stack. The NSSN is the SN of the newest packet received without any holes + 1. This is working as long as we don't have packets that we release because of a timeout. When that happens, we could have taken the decision to release a packet after we have been waiting for its predecessor for too long. If this predecessor comes later, we have to drop it because we can't release packets out of order. In that case, the hardware will give us an indication that we can we release the packet (SN < NSSN), but the packet still needs to be dropped. This is why we sometimes need to ignore the NSSN and we track the head_sn in software. Here is a specific example of this: 1) Rx queue 1 got packets: 480, 482, 483 2) We release 480 to to the stack and wait for 481 3) NSSN is now 481 4) The timeout expires 5) We release 482 and 483, NSSN is still 480 6) 481 arrives its NSSN is 484. We need to drop 481 even if 481 < 484. This is why we'll update the head_sn to 484 at step 2. The flow now is: 1) Rx queue 1 got packets: 480, 482, 483 2) We release 480 to to the stack and wait for 481 3) NSSN is now 481 / head_sn is 481 4) The timeout expires 5) We release 482 and 483, NSSN is still 480 but head_sn is 484. 6) 481 arrives its NSSN is 484, but head_sn is 484 and we drop it. This code introduces another problem in case all the traffic goes well (no hole, no timeout): Rx queue 1: 0 -> 483 (head_sn = 484) Rx queue 2: 501 -> 4095 (head_sn = 0) Rx queue 2: 0 -> 480 (head_sn = 481) Rx queue 1: 481 but head_sn = 484 and we drop it. At this point, the SN of queue 1 is far behind: more than 4040 packets behind. Queue 1 will consider 481 "old" because 481 is in [501-64:501] whereas it is a very new packet. In order to fix that, send an Rx notification from time to time (twice across the full set of 4096 packets) to make sure no Rx queue is lagging too far behind. What will happen then is: Rx queue 1: 0 -> 483 (head_sn = 484) Rx queue 2: 501 -> 2047 (head_sn = 2048) Rx queue 1: Sync nofication (head_sn = 2048) Rx queue 2: 2048 -> 4095 (head_sn = 0) Rx queue 1: Sync notification (head_sn = 0) Rx queue 2: 1 -> 481 (head_sn = 482) Rx queue 1: 481 and head_sn = 0. In queue 1's data, head_sn is now 0, the packet coming in is 481, it'll understand that the new packet is new and it won't be dropped. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-30iwlwifi: mvm: add a new RSS sync notification for NSSN syncEmmanuel Grumbach1-2/+2
We will soon be using a new notification that will be initiated by the driver, sent to the firmware and sent back to all the RSS queues by the firmware. This new notification will be useful to synchronize the NSSN across all the queues. For now, don't send the notification, just add the code to handle it. Later patch will add the code to actually send it. While at it, validate the baid coming from the firmware to avoid accessing an array with a bad index in the driver. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-22 22:17:51 +0300