summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-02-23mt76: mt7615: introduce SAR supportLorenzo Bianconi2-4/+27
Add SAR spec support to mt7615 driver to allow configuring SAR power limitations on the frequency ranges from the userland. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-23mt76: mt7915: fix injected MPDU transmission to not use HW A-MSDUJohan Almbladh1-0/+1
Before, the hardware would be allowed to transmit injected 802.11 MPDUs as A-MSDU. This resulted in corrupted frames being transmitted. Now, injected MPDUs are transmitted as-is, without A-MSDU. The fix was verified with frame injection on MT7915 hardware, both with and without the injected frame being encrypted. If the hardware cannot do A-MSDU aggregation on MPDUs, this problem would also be present in the TX path where mac80211 does the 802.11 encapsulation. However, I have not observed any such problem when disabling IEEE80211_HW_SUPPORTS_TX_ENCAP_OFFLOAD to force that mode. Therefore this fix is isolated to injected frames only. The same A-MSDU logic is also present in the mt7921 driver, so it is likely that this fix should be applied there too. I do not have access to mt7921 hardware so I have not been able to test that. Signed-off-by: Johan Almbladh <johan.almbladh@anyfinetworks.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-22rtw88: change rtw_info() to proper message levelPing-Ke Shih9-19/+20
Larry reported funny log entries [1] when he used rtl8821ce. These messages are not harmless, but not useful for users, so change them to rtw_dbg() level. By the way, I review all rtw_info() and change others to rtw_warn(). [1] https://lore.kernel.org/linux-wireless/c356d5ae-a7b3-3065-1121-64c446e70333@lwfinger.net/ Reported-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220218035527.9835-1-pkshih@realtek.com
2022-02-22rtw89: Limit the CFO boundaries of x'tal valueYi-Tang Chiu3-0/+26
Set the boundaries of x'tal value to avoid extremely adjusted results, causing severely unexpected CFO. Signed-off-by: Yi-Tang Chiu <chiuyitang@realtek.com> Signed-off-by: Yuan-Han Zhang <yuanhan1020@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220218034537.9338-1-pkshih@realtek.com
2022-02-22rtw89: phy: handle txpwr lmt/lmt_ru of 160M bandwidthZong-Zhe Yang2-7/+110
Add handling to fill struct rtw89_txpwr_limit and rtw89_txpwr_limit_ru for 160Mhz bandwidth case. And enlarge RTW89_5G_BW_NUM because the chip under planning can support 160Mhz bandwidth on 5G band. Moreover, refine the filling of OFDM entry of struct rtw89_txpwr_limit by using the value corresponding to primary channel. E.g. center channel 38 (40Mhz bandwidth case) Originally OFDM entry was filled by value corresponding to 'ch - 2' (36) Now, we consider that it could be 36 or 40. E.g. cneter channel 42 (80Mhz bandwidth case) Originally OFDM entry was filled by value corresponding to 'ch - 6' (36) Now, we consider that it could be 36, 40, 44, or 48. 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@kernel.org> Link: https://lore.kernel.org/r/20220218034042.9218-1-pkshih@realtek.com
2022-02-22rtw89: phy: handle txpwr lmt/lmt_ru of 6G bandZong-Zhe Yang2-3/+68
Add declarations of 6G stuff and extend rtw89_channel_to_idx() to map 6G's channels to 6G channel indexes. While 6G, correspondingly read 6G's entry for tx power limit and limit_ru. After this, we should pay attention to chip_info::support_bands. If a chip declares 6G support, it must configure txpwr_lmt_6g and txpwr_lmt_ru_6g in case accessing NULL pointer while setting tx power limit/limit_ru on 6G band. 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@kernel.org> Link: https://lore.kernel.org/r/20220218034017.9160-2-pkshih@realtek.com
2022-02-22Merge tag 'iwlwifi-next-for-kalle-2022-02-18' of ↵Kalle Valo79-945/+2315
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next iwlwifi patches for v5.18 * Support UHB TAS enablement via BIOS; * Remove a bunch of W=1 warnings; * Add support for channel switch offload; * Support a new FW API command version; * Support 32 Rx AMPDU sessions in newer devices; * Support a few new FW API command versions; * Some debugging infra fixes; * A few fixes in the HE functionality; * Add a few new devices; * A bunch of fixes for W=1 and W=3 warnings; * Add support for a couple of new devices; * Fix a potential buffer underflow; * W=1 warnings clean up continues; * Some improvements and fixes in scanning; * More work on the Bz family of devices; * Add support for band disablement via BIOS; * Bump FW API version; * Fix config structure for one device; * Support a new FW API command version; * Support new queue allocation command; * Some more debugging improvements; * Some other small fixes, clean-ups and improvements.
2022-02-21rtw89: core.h: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/78 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220216195047.GA904198@embeddedor
2022-02-21brcmfmac: Replace zero-length arrays with flexible-array membersGustavo A. R. Silva2-2/+2
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/78 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220216194935.GA904103@embeddedor
2022-02-21bcma: cleanup commentsTom Rix5-11/+11
Remove the second 'info'. Replacements 'adventages' with 'advantages' 'strenth' with 'strength' 'atleast' with 'at least' 'thr'u'' with 'through' 'capabilty' with 'capability' 'controll' with 'control' 'ourself' with 'ourselves' 'noone' with 'no one' 'cores' to 'core's' and 'core' Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220213213121.2806376-1-trix@redhat.com
2022-02-21rtw89: fix RCU usage in rtw89_core_txq_push()Jiri Kosina1-1/+4
ieee80211_tx_h_select_key() is performing a series of RCU dereferences, but rtw89_core_txq_push() is calling it (via ieee80211_tx_dequeue_ni()) without RCU read-side lock held; fix that. This addresses the splat below. ============================= WARNING: suspicious RCU usage 5.17.0-rc4-00003-gccad664b7f14 #3 Tainted: G E ----------------------------- net/mac80211/tx.c:593 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by kworker/u33:0/184: #0: ffff9c0b14811d38 ((wq_completion)rtw89_tx_wq){+.+.}-{0:0}, at: process_one_work+0x258/0x660 #1: ffffb97380cf3e78 ((work_completion)(&rtwdev->txq_work)){+.+.}-{0:0}, at: process_one_work+0x258/0x660 stack backtrace: CPU: 8 PID: 184 Comm: kworker/u33:0 Tainted: G E 5.17.0-rc4-00003-gccad664b7f14 #3 473b49ab0e7c2d6af2900c756bfd04efd7a9de13 Hardware name: LENOVO 20UJS2B905/20UJS2B905, BIOS R1CET63W(1.32 ) 04/09/2021 Workqueue: rtw89_tx_wq rtw89_core_txq_work [rtw89_core] Call Trace: <TASK> dump_stack_lvl+0x58/0x71 ieee80211_tx_h_select_key+0x2c0/0x530 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365] ieee80211_tx_dequeue+0x1a7/0x1260 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365] rtw89_core_txq_work+0x1a6/0x420 [rtw89_core b39ba493f2e517ad75e0f8187ecc24edf58bbbea] process_one_work+0x2d8/0x660 worker_thread+0x39/0x3e0 ? process_one_work+0x660/0x660 kthread+0xe5/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> ============================= WARNING: suspicious RCU usage 5.17.0-rc4-00003-gccad664b7f14 #3 Tainted: G E ----------------------------- net/mac80211/tx.c:607 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by kworker/u33:0/184: #0: ffff9c0b14811d38 ((wq_completion)rtw89_tx_wq){+.+.}-{0:0}, at: process_one_work+0x258/0x660 #1: ffffb97380cf3e78 ((work_completion)(&rtwdev->txq_work)){+.+.}-{0:0}, at: process_one_work+0x258/0x660 stack backtrace: CPU: 8 PID: 184 Comm: kworker/u33:0 Tainted: G E 5.17.0-rc4-00003-gccad664b7f14 #3 473b49ab0e7c2d6af2900c756bfd04efd7a9de13 Hardware name: LENOVO 20UJS2B905/20UJS2B905, BIOS R1CET63W(1.32 ) 04/09/2021 Workqueue: rtw89_tx_wq rtw89_core_txq_work [rtw89_core] Call Trace: <TASK> dump_stack_lvl+0x58/0x71 ieee80211_tx_h_select_key+0x464/0x530 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365] ieee80211_tx_dequeue+0x1a7/0x1260 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365] rtw89_core_txq_work+0x1a6/0x420 [rtw89_core b39ba493f2e517ad75e0f8187ecc24edf58bbbea] process_one_work+0x2d8/0x660 worker_thread+0x39/0x3e0 ? process_one_work+0x660/0x660 kthread+0xe5/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2202152037000.11721@cbobk.fhfr.pm
2022-02-21rtw88: coex: Update rtl8822c COEX version to 22020720Ching-Te Ku1-2/+2
Enable Wi-Fi/BT mailbox 0x45 handshake and Wi-Fi MIMO power save mechanism for Bluetooth gaming controller. BTCOEX Version: 22020720-2020 Desired_BT_Coex_Ver: 0x20 Desired_WL_FW_Ver: 9.9.11 Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220215004855.4098-7-pkshih@realtek.com
2022-02-21rtw88: coex: Add C2H/H2C handshake with BT mailbox for asking HID InfoChing-Te Ku6-11/+206
In order to recognize the gaming controller HID, make a C2H/H2C/Mailbox handshake to collect all the connected information from BT. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220215004855.4098-6-pkshih@realtek.com
2022-02-21rtw88: coex: Add WLAN MIMO power saving for Bluetooth gaming controllerChing-Te Ku7-11/+148
To keep high sensitivity reaction, Bluetooth gaming controller will send packet very frequently, it will make WLAN performance very poor. To solve this situation, MIMO PS mechanism makes WLAN/BT own an antenna itself, WLAN quits 2SS performance but it can get a stable 1SS performance and Bluetooth gaming controller can keep sensitivity reaction at the same time. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220215004855.4098-5-pkshih@realtek.com
2022-02-21rtw88: coex: update BT PTA counter regularlyChing-Te Ku3-12/+37
If BT PTA counter can not update regularly, it will lead coex mechanism run into some unexpected state. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220215004855.4098-4-pkshih@realtek.com
2022-02-21rtw88: coex: Improve WLAN throughput when HFP COEXChing-Te Ku1-7/+2
Disable power save TDMA mechanism under HFP COEX, so WLAN can TX/RX full time. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220215004855.4098-3-pkshih@realtek.com
2022-02-21rtw88: 8822ce: add support for TX/RX 1ss modeChin-Yen Lee5-4/+41
In some case, wifi chip need to be configed to be TX/RX 1ss mode. For this mode, wifi components, such as MAC/BB/RF, need to be specially set, and driver need to send SMPS action frame to inform AP. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220215004855.4098-2-pkshih@realtek.com
2022-02-18iwlwifi: dbg_ini: Split memcpy() to avoid multi-field writeKees Cook2-2/+3
To avoid a run-time false positive in the stricter FORTIFY_SOURCE memcpy() checks, split the memcpy() into the struct and the data. Additionally switch the data member to a flexible array to follow modern language conventions. Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210727205855.411487-64-keescook@chromium.org Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: mvm: Fix an error code in iwl_mvm_up()Dan Carpenter1-1/+3
Return -ENODEV instead of success on this error path. Fixes: dd36a507c806 ("iwlwifi: mvm: look for the first supported channel when add/remove phy ctxt") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20210816183930.GA2068@kili Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: Fix -EIO error code that is never returnedColin Ian King1-1/+1
Currently the error -EIO is being assinged to variable ret when the READY_BIT is not set but the function iwlagn_mac_start returns 0 rather than ret. Fix this by returning ret instead of 0. Addresses-Coverity: ("Unused value") Fixes: 7335613ae27a ("iwlwifi: move all mac80211 related functions to one place") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210907104658.14706-1-colin.king@canonical.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: mvm: rfi: use kmemdup() to replace kzalloc + memcpyBixuan Cui1-3/+1
Fix memdup.cocci warning: ./drivers/net/wireless/intel/iwlwifi/mvm/rfi.c:110:8-15: WARNING opportunity for kmemdup Signed-off-by: Bixuan Cui <cuibixuan@linux.alibaba.com> Link: https://lore.kernel.org/r/1635317920-84725-1-git-send-email-cuibixuan@linux.alibaba.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: Fix syntax errors in commentsXiang wangx1-1/+1
Delete the redundant word 'the'. Signed-off-by: Xiang wangx <wangxiang@cdjrlc.com> Link: https://lore.kernel.org/r/20211216085756.11053-1-wangxiang@cdjrlc.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: dvm: use struct_size over open coded arithmeticMinghao Chi (CGEL ZTE)1-1/+1
Replace zero-length array with flexible-array member and make use of the struct_size() helper in kmalloc(). For example: struct iwl_wipan_noa_data { ... u8 data[]; }; Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi (CGEL ZTE) <chi.minghao@zte.com.cn> Link: https://lore.kernel.org/r/20220210060926.1608378-1-chi.minghao@zte.com.cn Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi/fw: use struct_size over open coded arithmeticMinghao Chi (CGEL ZTE)1-1/+1
Replace zero-length array with flexible-array member and make use of the struct_size() helper in kzalloc(). Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi (CGEL ZTE) <chi.minghao@zte.com.cn> Link: https://lore.kernel.org/r/20220216030841.1839666-1-chi.minghao@zte.com.cn Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: Make use of the helper macro LIST_HEAD()Cai Huoqing1-1/+1
Replace "struct list_head head = LIST_HEAD_INIT(head)" with "LIST_HEAD(head)" to simplify the code. Signed-off-by: Cai Huoqing <cai.huoqing@linux.dev> Link: https://lore.kernel.org/r/20220209032322.37472-1-cai.huoqing@linux.dev Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: mvm: fix off by one in iwl_mvm_stat_iterator_all_macs()Dan Carpenter1-1/+1
Change the comparison from ">" to ">=" to avoid accessing one element beyond the end of the ->per_mac_stats[] array. Fixes: 6324c173ff4a ("iwlwifi: mvm: add support for statistics update version 15") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220106071825.GA5836@kili Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: yoyo: send hcmd to fw after dump collection completes.Mukesh Sisodiya5-3/+58
Send a command to FW once the driver completes the dump collection for the timepoint which requires the command to be send. Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220210181930.b8c1228a0c0a.I71da6a799253650f3d0b181315de388cb9360e30@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: mvm: move only to an enabled channelMiri Korenblit1-9/+22
During disassociation we're decreasing the phy's ref count. If the ref count becomes 0, we're configuring the phy ctxt to the default channel (the lowest channel which the device can operate on). Currently we're not checking whether the the default channel is enabled or not. Fix it by configuring the phy ctxt to the lowest channel which is enabled. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220210181930.03f281b6a6bc.I5b63d43ec41996d599e6f37ec3f32e878b3e405e@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: mvm: update BAID allocation command againJohannes Berg2-10/+27
Due to some issues found in integration, the command now has the (old) station mask and TID in modify/remove instead of the BAID, adjust accordingly. Since we don't use modify yet (and never will with v1 of the API), just add v1 remove inside the existing union, and use that, this way we don't have to duplicate everything, only the remove code. 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.20220210181930.bc424f15cc4b.I06d9acae11dc69b2500666f497017a3fd4e2acd5@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: api: remove ttl field from TX commandJohannes Berg1-4/+3
This doesn't really exist in the firmware, it's just some leftover from older versions. Remove it. 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.20220210181930.b8190c27dc87.Ie5b5f8c68ecafd1b51d197fc1273b024bc1575a4@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: support new queue allocation commandJohannes Berg8-24/+142
Newer firmware versions will support a new queue allocation command, in order to deal with MLD where multiple stations are used for a single queue. Add support for the new command. This requires some refactoring of the queue allocation API, which now gets - the station mask instead of the station ID - the flags without the "enable" flag, since that's no longer used in the new API Additionally, this new API now requires that we remove queues before removing a station, the firmware will no longer do that internally. Also add support for 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.20220210181930.acbf22ac2b66.I2bf38578c5ca1f7ffb2011a782f772db92fc4965@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: yoyo: support dump policy for the dump sizeMukesh Sisodiya3-14/+61
Support dump size limitation based on the TLV by firmware. This is needed for limited memory systems so only the most important dumps are sent by driver. Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220210181930.d7e1ff264766.If2327fd890a453cdc9069d26220394d0b4e79743@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: pcie: iwlwifi: fix device id 7F70 structYaara Baruch1-3/+5
The device was defined under Ma instead of So, and add 2 missing killer devices from the 211 family. Signed-off-by: Yaara Baruch <yaara.baruch@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220210181930.02142c6f0579.Ic480a0cc08625e74a8449262aeebb1813edf9979@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: tlc: Add logs in rs_fw_rate_init func to print TLC configurationAbhishek Naik3-5/+17
Add logs in rs_fw_rate_init function. It helps in verifying TLC Configuration while debuging TLC related bugs. Update kernel doc for TLC_MNG_CONFIG_CMD with correct version of struct iwl_tlc_config_cmd. Signed-off-by: Abhishek Naik <abhishek.naik@intel.com> Fixes: ae4c1bb06b66 ("iwlwifi: rs: add support for TLC config command ver 4") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220210181930.1fd6adfb6f1e.Icc8f5fd517735fcc10db098999ff1272da291298@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: mvm: remove iwl_mvm_disable_txq() flags argumentJohannes Berg1-11/+10
It's always zero, just remove it. 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.20220210181930.dc67b3c04d0f.I5fbc552812ab91f2c4b158eee39f63c44575db1b@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: remove command ID argument from queue allocationJohannes Berg4-14/+11
The command ID here is always hard-coded to the same, so we can remove it. In the future we actually need to make this configurable, but that doesn't need to be on each call, it can be done through the transport configuration. 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.20220210181930.8b352828f767.Ice4c91d8ea3e207914104e72801b87cd7f409ba7@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: make iwl_txq_dyn_alloc_dma() return the txqJohannes Berg1-14/+12
Use the ERR_PTR() machinery to return the queue or an error, instead of having a separate out parameter. 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.20220210181930.1f0c5d72fb89.Iefca56d535558b7a8d23204fd16129c17b6704b6@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: fix small doc mistake for iwl_fw_ini_addr_valLuca Coelho1-3/+2
There was a small copy and paste mistake in the doc declaration of iwl_fw_ini_addr_val. Fix it. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220205112029.aeec71c397b3.I0ba3234419eb8c8c7512a2ca531a6dbb55046cf7@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: mvm: add additional info for boot info failuresMordechay Goodstein2-0/+6
This info helps for additional info in case we have issues with HPM state at boot time. 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.20220205112029.e3530bf30f1f.Ib354675937352f6e4a992f1d5d49f2f38acfe2e5@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: mvm: always remove the session protection after associationEmmanuel Grumbach1-4/+1
The firmware will soon stop removing the session protection for us after association. While this was convenient, it was not symmetric. Always remove the session protection after association, even for devices that support the new API. 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.20220205112029.9fd32da15220.Ia88357dcf9f7ec7860f6111e41411868739cc9aa@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: mvm: make iwl_mvm_reconfig_scd() staticJohannes Berg3-38/+35
There's no need to have this in a different place, it's only used in a single C file (sta.c). 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.20220205112029.699b4b9c2232.I0d7970d800a51fee5135946ee03a7d9e8a811893@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: mvm: refactor setting PPE thresholds in STA_HE_CTXT_CMDMiri Korenblit2-91/+114
We are setting the PPE Thresholds in STA_HE_CTXT_CMD according to HE PHY Capabilities IE. As EHT is introduced, we will have to set this thresholds according to EHT PHY Capabilities IE if we're in an EHT connection. Some parts of the code can be used for both HE and EHT. Put this parts in functions which will be used in the patch which adds support for EHT PPE. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220205112029.48a508dfffef.If392e44d88f96ebed7fadf827e327194d4bd97b1@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: mvm: Disable WiFi bands selectively with BIOSAyala Barazani3-12/+57
The BIOS can contain data about sets of disabled channels. Pass the bitmap to the firmware if present. Signed-off-by: Ayala Barazani <ayala.barazani@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220205112029.9e6d9209293d.If5b22a9afe5f9dac9c7c45e68e494ffce4df8910@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: mvm: add additional info for boot info failuresMordechay Goodstein2-2/+23
This info helps for additional info in case we have issues with OTP at boot time. 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.20220205112029.7971a6d70653.Icb3ee1e5d52e5437531dadeda63e32719b44b645@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: mvm: don't send BAID removal to the FW during hw_restartLuca Coelho1-3/+6
With the new ML API, we can't send the BAID removal command to firmware during hw_restart because it will cause an assertion failure 0x350D because the BAID doesn't exist at that point. So avoid sending the command if we are performing a hw_restart. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220205112029.7b363457e1aa.Ie4634222e6a33451b88e1042c83e9ea28775bd9f@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: don't dump_stack() when we get an unexpected interruptEmmanuel Grumbach1-3/+6
It is yet unclear if the WARNING really points to a real problem, but for sure the stack dump doesn't help fixing it. Just use a regular error print instead. 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.20220205112029.a79e733a12f7.I8189344294222be0589fa43cc70fdf38e3057045@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: mvm: rfi: handle deactivation notificationGregory Greenman5-1/+31
Sometimes RFIm can be deactivated in FW due to internal errors. In this case, FW will send a notification to the driver about that. Add a log message in this case since FW logs are not always available. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220205112029.48d0a1624fec.I8f9271959fc53223fa329ab097b12fd69b498b71@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: mvm: Consider P2P GO operation during scanIlan Peer1-3/+129
A scan during active P2P GO operation, i.e., data traffic with clients, can impact the throughput and latency of such traffic. Thus, when scan is requested while there is an active P2P GO and low latency is asserted: - Ask the FW scan logic to respect the P2P GO activity during the scheduling of the scan operation to minimize the impact on the throughput and latency. - Force scan to perform EBS before starting the scan to reduce the number of scanned channels. 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.20220205112029.4412036f4889.Ied677fdd31765437e19905787708bd05f62663ba@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: bump FW API to 70 for AX devicesGolan Ben Ami1-1/+1
Start supporting API version 70 for AX devices. Signed-off-by: Golan Ben Ami <golan.ben.ami@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220205112029.a861ff3e5541.I77447cab0e944ec9e9e72e25bfd9cd59b9111f73@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2022-02-18iwlwifi: mvm: Unify the scan iteration functionsIlan Peer1-42/+32
As there is not real need to iterate the active interfaces twice. 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.20220204122220.940e45167283.I99ddfeda3d4a50d21cb18b826ccf84b21a76c487@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>