summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)AuthorFilesLines
2021-06-23mac80211_hwsim: record stats in non-netlink pathNguyen Dinh Phi1-0/+2
The data go through mac80211_hwsim_tx_frame_no_nl() wasn't counted. Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com> Link: https://lore.kernel.org/r/20210622152429.881230-1-phind.uet@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211_hwsim: add concurrent channels scanning support over virtioWeilun Du1-10/+38
This fixed the crash when setting channels to 2 or more when communicating over virtio. Signed-off-by: Weilun Du <wdu@google.com> Link: https://lore.kernel.org/r/20210506180530.3418576-1-wdu@google.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23cfg80211: remove CFG80211_MAX_NUM_DIFFERENT_CHANNELSJohannes Berg1-5/+0
We no longer need to put any limits here, hardware will and mac80211-hwsim can do whatever it likes. The reason we had this was some accounting code (still mentioned in the comment) but that code was deleted in commit c781944b71f8 ("cfg80211: Remove unused cfg80211_can_use_iftype_chan()"). Link: https://lore.kernel.org/r/20210506221159.d1d61db1d31c.Iac4da68d54b9f1fdc18a03586bbe06aeb9515425@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-22wcn36xx: Avoid memset() beyond end of struct fieldKees Cook1-16/+5
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memset(), avoid intentionally writing across neighboring array fields. Instead of writing past the end of the header to reach the rest of the body, replace the redundant function with existing macro to wipe struct contents and set field values. Additionally adjusts macro to add missing parens. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210617171058.3410494-1-keescook@chromium.org
2021-06-22ath11k: Avoid memcpy() over-reading of he_capKees Cook1-4/+10
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring array fields. Since peer_he_cap_{mac,phy}info and he_cap_elem.{mac,phy}_cap_info are not the same sizes, memcpy() was reading beyond field boundaries. Instead, correctly cap the copy length and pad out any difference in size (peer_he_cap_macinfo is 8 bytes whereas mac_cap_info is 6, and peer_he_cap_phyinfo is 12 bytes whereas phy_cap_info is 11). Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210616195410.1232119-1-keescook@chromium.org
2021-06-22mt7601u: add USB device ID for some versions of XiaoDu WiFi Dongle.Wei Mingzhi1-0/+1
USB device ID of some versions of XiaoDu WiFi Dongle is 2955:1003 instead of 2955:1001. Both are the same mt7601u hardware. Signed-off-by: Wei Mingzhi <whistler@member.fsf.org> Acked-by: Jakub Kicinski <kubakici@wp.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210618160840.305024-1-whistler@member.fsf.org
2021-06-22mwifiex: Avoid memset() over-write of WEP key_materialKees Cook2-5/+12
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memset(), avoid intentionally writing across neighboring array fields. When preparing to call mwifiex_set_keyparamset_wep(), key_material is treated very differently from its structure layout (which has only a single struct mwifiex_ie_type_key_param_set). Instead, add a new type to the union so memset() can correctly reason about the size of the structure. Note that the union ("params", 196 bytes) containing key_material was not large enough to hold the target of this memset(): sizeof(struct mwifiex_ie_type_key_param_set) == 60, NUM_WEP_KEYS = 4, so 240 bytes, or 44 bytes past the end of "params". The good news is that it appears that the command buffer, as allocated, is 2048 bytes (MWIFIEX_SIZE_OF_CMD_BUFFER), so no neighboring memory appears to be getting clobbered. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210617171522.3410951-1-keescook@chromium.org
2021-06-22rtlwifi: rtl8192de: Fully initialize curvecount_valKees Cook1-1/+1
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring array fields. The size argument to memset() is bytes, but the array element size of curvecount_val is u32, so "CV_CURVE_CNT * 2" was only 1/4th of the contents of curvecount_val. Adjust memset() to wipe full buffer size. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210617171317.3410722-1-keescook@chromium.org
2021-06-22mwl8k: Avoid memcpy() over-reading of mcs.rx_maskKees Cook1-2/+2
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally reading across neighboring array fields. Use the sub-structure address directly. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210617041431.2168953-1-keescook@chromium.org
2021-06-22orinoco: Avoid field-overflowing memcpy()Kees Cook3-10/+15
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring array fields. Validate the expected key size and introduce a wrapping structure to use as the multi-field memcpy() destination so that overflows can be correctly detected. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210616203952.1248910-1-keescook@chromium.org
2021-06-22rtw88: coex: remove unnecessary variable and labelwengjianfeng1-30/+10
In some funciton, the variable ret just used as return value,and out label just return ret,so ret and out label are unnecessary, we should delete these and use return true/false to replace. Signed-off-by: wengjianfeng <wengjianfeng@yulong.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210520005545.31272-1-samirweng1979@163.com
2021-06-22rtw88: add quirks to disable pci capabilitiesPing-Ke Shih1-0/+32
8821CE with ASPM cannot work properly on Protempo Ltd L116HTN6SPW. Add a quirk to disable the cap. The reporter describes the symptom is that this module (driver) causes frequent freezes, randomly but usually within a few minutes of running (thus very soon after boot): screen display remains frozen, no response to either keyboard or mouse input. All I can do is to hold the power button to power off, then reboot. Reported-by: Paul Szabo <psz2036@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210607012254.6306-1-pkshih@realtek.com
2021-06-22rtw88: refine unwanted h2c commandPo-Hao Huang1-5/+2
Don't send beacon filter h2c when there is no valid context. Return early instead of printing out warning messages, so others won't get confused. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210528032901.12927-3-pkshih@realtek.com
2021-06-22rtw88: dump FW crash via devcoredumpZong-Zhe Yang4-64/+201
Use device coredump framework instead of print_hex_dump to support FW crash dump. Pass data to the framework if preparing and dumping are successful. The framework will take the ownership of the data. The data will be freed after the framework determines its lifetime is over. A new coredump will not work if the previous one still exists. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210528032901.12927-2-pkshih@realtek.com
2021-06-22rtw88: notify fw when driver in scan-period to avoid potential problemChin-Yen Lee5-1/+58
It is found that driver scan could be affected by dynamic mechanism of firmware, so we notify firmware to stop it in the scan period. Another, firmware will detect the background noise and report to driver for further use. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210514075517.14216-3-pkshih@realtek.com
2021-06-22rtw88: add rtw_fw_feature_check apiChin-Yen Lee5-8/+12
add api to check if a certain feature is supported. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210514075517.14216-2-pkshih@realtek.com
2021-06-22rtw88: 8822c: update RF parameter tables to v62Po-Hao Huang1-504/+504
Update RTL8822C devices' RF tables to v62. This fixes higher than expected spur in 2400 MHz under CCK mask. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210506083643.18317-1-pkshih@realtek.com
2021-06-22rtw88: Remove duplicate include of coex.hWan Jiabing1-1/+0
In commit fb8517f4fade4 ("rtw88: 8822c: add CFO tracking"), "coex.h" was added here which caused the duplicate include. Remove the later duplicate include. Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210430024951.33406-1-wanjiabing@vivo.com
2021-06-22rtw88: 8822c: fix lc calibration timingPo-Hao Huang1-10/+12
Before this patch, we use value from 2 seconds ago to decide whether we should do lc calibration. Although this don't happen frequently, fix flow to the way it should be. Fixes: 7ae7784ec2a8 ("rtw88: 8822c: add LC calibration for RTL8822C") Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210426013252.5665-3-pkshih@realtek.com
2021-06-22rtw88: add path diversityPo-Hao Huang5-6/+131
This feature chooses to transmit with antenna that has better signal strength periodically under 1ss rate. It can benefit connection quality in the following cases: 1. User is far away from the AP. 2. The far-field pattern of the antenna showed significant signal strength difference. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210426013252.5665-2-pkshih@realtek.com
2021-06-22rtw88: add beacon filter supportPo-Hao Huang5-1/+141
Adding this supports beacon filter and CQM. Let firmware perform connection quality monitor and beacon processing. This make host CPU wakeup less under power save mode. To make mechanisms work as usual, fw will notify driver events such as signal change and beacon loss. This feature needs firmware 9.9.8 or newer to support it, and driver is compatible with older firmware. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210426013252.5665-1-pkshih@realtek.com
2021-06-22iwlwifi: bump FW API to 64 for AX devicesLuca Coelho1-2/+2
Start supporting API version 64 for AX devices. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210621103449.8144a5b7d9a7.Ibf77fd7daa7d22f7c46d1c4a572ab9441a761299@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: fw: dump TCM error table if presentJohannes Berg4-0/+79
If the TCM is present in the hardware (as advertised in the firmware file TLV data), dump its error log table during firmware error dumps. 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.20210621103449.2d2149f6654f.Id831f8fbca59900ba7efc623ffca0ca938b664d3@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: add 9560 killer deviceybaruch3-1/+9
add new killer devices configurations. Signed-off-by: ybaruch <yaara.baruch@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210621103449.4179f7191531.I3d5ed6b2b39fcd42863a679e21bda23a6c14253e@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: move error dump to fw utilsJohannes Berg6-351/+368
Conceptually, this belongs more into the firmware utils rather than the mvm opmode, so move the collection and output there. Note that this slightly changes the format of the Status line. 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.20210621103449.b82b60d81346.Ide3b688107f6a59c7fc7eb1d8f2002b0a5c1f2d2@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: support loading the reduced power table from UEFILuca Coelho9-14/+318
This new feature allows OEMs to set a special reduced power table in a UEFI variable, which we use to tell the firmware to change the TX power tables. Read the variable and store it in a dram block to pass it to the firmware. We do this as part of the PNVM loading flow. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210621103449.259a33ba5074.I2e0bb142d2a9c412547cba89b62dd077b328fdc4@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: move UEFI code to a separate fileLuca Coelho4-81/+114
We are going to read more variables from UEFI, so it's cleaner to have all the code that handles UEFI variables in a separate file. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210621103449.c705ac86f2e9.Ia7421c17fe52929e4098b4f0cf070809ed3ef906@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: mvm: introduce iwl_wowlan_get_status_cmdEmmanuel Grumbach3-8/+28
We need to pass the station id to teach the firmware on which station id we want to get the status. 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.20210621103449.45218d913d07.I61a086936508230d86b454636945ceb0b9ea09fd@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: mvm: introduce iwl_wowlan_kek_kck_material_cmd_v4Emmanuel Grumbach2-9/+34
We need to pass the station id to teach the firmware on which station id we want to configure the key material. 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.20210621103449.13417410e9ea.I140c16e70f8ac91cec7e8189e182e2f672c39258@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: mvm: update iwl_wowlan_patterns_cmdEmmanuel Grumbach2-5/+22
We need to pass the station id to tell the firmware on which station we want to configure the patterns. 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.20210621103449.73eceb822890.I37347afbc01497a8a9e4d4afe4fa9a965abd31ac@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: mvm: introduce iwl_proto_offload_cmd_v4Emmanuel Grumbach3-11/+42
We need to pass the station id to tell the firmware on which station we want to configure the protocol offload. 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.20210618105614.c25913d2c08c.Ic0fefac81afb9a2fe396d73528e30e09a8c5eae0@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: fix NUM_IWL_UCODE_TLV_* definitions to avoid sparse errorsLuca Coelho1-6/+8
We were assigning these macros manually when sparse is running, but with newer versions of sparse, it started causing other warnings. Fix it by making it a macro when sparse is running. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618105614.dc658639e07f.I69ab6d59ff10c55c8517621eb20a52194dc4783a@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: pcie: free some DMA memory earlierJohannes Berg3-12/+21
In gen3, after firmware is alive, we no longer need the firmware and image loader images, only the context info itself and PRPH info/scratch need to remain. Call iwl_pcie_ctxt_info_gen3_free() appropriately in the alive callback (iwl_trans_pcie_gen2_fw_alive()) with a new argument indicating whether it can free everything or only partially. The context info and PRPH scratch are also not needed after PNVM load, but we don't have a good hook for freeing after that, so keep them for now. 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.20210618105614.8230d91a46c1.Ia7db71e5e6265ca87363f1481eac1bc3bbebb15c@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: mvm: fill phy_data.d1 for no-data RXJohannes Berg1-6/+4
We don't fill in phy_data.d1 in no-data RX, and thus we pretend some data is actually filled in radiotap when it isn't or has default (zero) values. Fill in phy_data.d1 appropriately, and while at it also move the info_type initialization into the initializer. 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.20210618105614.3d488885f77c.Ib97a2bc57c1e9fb98927dc6f802568db313abe3b@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: pcie: fix context info freeingJohannes Berg1-1/+2
After firmware alive, iwl_trans_pcie_gen2_fw_alive() is called to free the context info. However, on gen3 that will then free the context info with the wrong size. Since we free this allocation later, let it stick around until the device is stopped for now, freeing some of it earlier is a separate change. 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.20210618105614.afb63fb8cbc1.If4968db8e09f4ce2a1d27a6d750bca3d132d7d70@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: pcie: free IML DMA memory allocationJohannes Berg2-5/+13
In the case of gen3 devices with image loader (IML) support, we were leaking the IML DMA allocation and never freeing it. Fix that. 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.20210618105614.07e117dbedb7.I7bb9ebbe0617656986c2a598ea5e827b533bd3b9@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: mvm: support LONG_GROUP for WOWLAN_GET_STATUSES versionEmmanuel Grumbach1-2/+5
It's been a while that the firmware uses LONG_GROUP by default and not LEGACY_GROUP. Until now the firmware wrongly advertise the WOWLAN_GET_STATUS command's version with LEGACY_GROUP, but it is now being fixed. In order to support both firmwares, first try to get the version number of the command with the LONG_GROUP and if the firmware didn't advertise the command version with LONG_GROUP, try to get the command version with LEGACY_GROUP. 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.20210618105614.cd6f4e421430.Iec07c746c8e65bc267e4750f38e4f74f2010ca45@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: support ver 6 of WOWLAN_CONFIGURATION and ver 10 of WOWLAN_GET_STATUSESNaftali Goldstein2-15/+23
These two version updates deprecate the need to set/get the nonqos sequence counter during suspend/resume flow respectively; NICs supporting this version maintain this counter internally and don't lose it during the suspend/resume flow. Note that this means that for such NICs the NON_QOS_TX_COUNTER_CMD is no longer ever sent. Signed-off-by: Naftali Goldstein <naftali.goldstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618105614.dd25dd667798.I8db9adcdbb133304b58cf417f8698611138c83b4@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: mvm: don't request mac80211 to disable/enable sta's queuesNaftali Goldstein1-2/+6
When operating in AP mode with NICs supporting the AP_LINK_PS hw flag, mac80211 doesn't need to start/stop queueing tx for connected stations because the FW already handles that. Signed-off-by: Naftali Goldstein <naftali.goldstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618105614.64df994c8fbb.I0fa5cda3a5f893a396eef30a01522422be359e69@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: mvm: Explicitly stop session protection before unbindingIlan Peer2-12/+30
In case of unbinding, the FW would remove the session protection time events without sending a notification, so explicitly cancel the session protection, so future requests for mgd_prepare_tx() would not assume that the session protection is running. 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.20210618105614.7c30f85ed241.Ibc19fdbefca7135f2c4ea83d0aef6b81b5033dcd@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: mvm: Read acpi dsm to get unii4 enable/disable bitmap.Abhishek Naik3-3/+37
Read the UNII4 setting from the ACPI table and use it in the LARI_CONFIG_CHANGE_CMD accordingly. This setting allows OEMs to enable or disable UNII4, bypassing the FW defaults. Signed-off-by: Abhishek Naik <abhishek.naik@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210617100544.223090c509c4.If03cb5393607ae494041b6187bcec134d6a1e06d@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: pcie: remove TR/CR tail allocationsJohannes Berg3-59/+14
The TR/CR tail data are meant to be per-queue-arrays, however, we allocate them completely wrong (we have a separate allocation per queue). Looking at this more closely, it turns out that the hardware never uses these - we have a separate free list per RX queue and maintain a write pointer for that in a register, and the RX itself is indicated in the RB status (rb_stts) DMA region. Despite nothing using the tail pointers, the hardware will unconditionally access them to write updates, even when we aren't using CRs/TRs. Give it dummy values that we never use/update so it can do that without causing trouble. 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.20210617110647.5f5764e04c46.I4d5de1929be048085767f1234a1e07b517ab6a2d@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: pcie: fix some kernel-doc commentsJohannes Berg1-2/+2
"ubd" is really called "used_bd", fix that. 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.20210617100544.2d4b46c656bb.Iff9ee6a7e65d439169202911dad2cbea626fb887@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: advertise broadcast TWT supportShaul Triebitz2-10/+21
If the firmware supports broadcast TWT (know by TLV), add the broadcast TWT HE MAC capability. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210617100544.80fee3171b53.Idfb69643f4044ec26865d023d0c2a1d6466694aa@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: mvm: support LMR feedbackAvraham Stern1-0/+4
If the LMR feedback is set in the ranging request, set the corresponding flag in the fw command. 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.20210617100544.0c00dd724f5c.I8283b95c26f4226deaea42e7be35aa9d41eb7580@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: correct HE capabilitiesJohannes Berg1-48/+66
The (default) HE capabilities for our devices weren't handled correctly, adjust them to match the correct capabilities of the devices. Since the device regulatory will not allow 160 MHz on 5 GHz, don't advertise this capability by default; do it only if an NVM file is being loaded that might change the regulatory parameters. 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.20210617100544.e8d0b02ec86b.Ia6ef8cc0480d38af25e6ac45fad9fb15bdfcbc2c@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: mvm: Call NMI instead of REPLY_ERRORHarish Mitty1-1/+3
For IWL_DEVICE_FAMILY_22000 & greater, driver will call NMI instead of REPLY_ERROR as FW->Infra does not support this command for this family onwards. Signed-off-by: Harish Mitty <harish.mitty@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210617100544.597f4246c79d.Ia0a1bbc2e66b4e849174db685208fc2b8bd5732e@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: mvm: fix error print when session protection endsShaul Triebitz1-0/+4
When the session protection ends and the Driver is not associated or a beacon was not heard, the Driver prints "No beacons heard...". That's confusing for the case where not associated. Change the print when not associated to "Not associated...". Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210617100544.41a5a5a894fa.I9eabb76e7a3a7f4abbed8f2ef918f1df8e825726@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: mvm: honour firmware SMPS requestsJohannes Berg4-0/+80
The firmware can now request SMPS (due to thermal conditions), add some code to honour such requests and bubble them up through the stack, subject to our other SMPS constraints, e.g. from Bluetooth. Then, if the firmware requests SMPS, then we know that it supports a small extension to the PHY configuration API where a chain mask of 0 means "use 1 but pick which one yourself", so in this case we use that extension. During firmware restart, we stay in the previous state, and the FW will send us a notification at startup (only) if the temperature is below the lower or above the high threshold, to sync the state. 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.20210617100544.85656b7684b9.I7a661a0758d070a750d3a91874d1a0f5fab9febc@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-06-22iwlwifi: mvm: apply RX diversity per PHY contextJohannes Berg3-14/+32
SMPS requests may differ per interfaces due to e.g. Bluetooth only interfering on 2.4 GHz, so if that's the case we should, in the case of multiple PHY contexts, still allow RX diversity on PHY context that have no interfaces with SMPS requests. Fix the code to pass through the PHY context in question and skip interfaces with non-matching PHY context while iterating. 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.20210617100544.123c6b05809d.I992e3d1c6a29850d02eeec01712b5b685b963a87@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>