summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/intel
AgeCommit message (Collapse)AuthorFilesLines
2021-12-08iwlwifi: mvm: retry init flow if failedMordechay Goodstein5-8/+47
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>
2021-11-18iwlwifi: mvm: disable RX-diversity in powersaveJohannes Berg1-0/+3
[ Upstream commit e5322b9ab5f63536c41301150b7ce64605ce52cc ] Just like we have default SMPS mode as dynamic in powersave, we should not enable RX-diversity in powersave, to reduce power consumption when connected to a non-MIMO AP. 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.20211017113927.fc896bc5cdaa.I1d11da71b8a5cbe921a37058d5f578f1b14a2023@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13iwlwifi: pcie: add configuration of a Wi-Fi adapter on Dell XPS 15Vladimir Zapolskiy1-0/+2
[ Upstream commit fe5c735d0d47b495be6753d6aea4f8f78c909a0a ] There is a Killer AX1650 2x2 Wi-Fi 6 and Bluetooth 5.1 wireless adapter found on Dell XPS 15 (9510) laptop, its configuration was present on Linux v5.7, however accidentally it has been removed from the list of supported devices, let's add it back. The problem is manifested on driver initialization: Intel(R) Wireless WiFi driver for Linux iwlwifi 0000:00:14.3: enabling device (0000 -> 0002) iwlwifi: No config found for PCI dev 43f0/1651, rev=0x354, rfid=0x10a100 iwlwifi: probe of 0000:00:14.3 failed with error -22 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=213939 Fixes: 3f910a25839b ("iwlwifi: pcie: convert all AX101 devices to the device tables") Cc: Julien Wajsberg <felash@gmail.com> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Acked-by: Luca Coelho <luca@coelho.fi> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210924122154.2376577-1-vladimir.zapolskiy@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18iwlwifi: mvm: Fix scan channel flags settingsIlan Peer1-1/+1
[ Upstream commit 090f1be3abf3069ef856b29761f181808bf55917 ] The iwl_mvm_scan_ch_n_aps_flag() is called with a variable before the value of the variable is set. Fix it. 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.20210826224715.f6f188980a5e.Ie7331a8b94004d308f6cbde44e519155a5be91dd@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18iwlwifi: fw: correctly limit to monitor dumpJohannes Berg1-1/+1
[ Upstream commit e6344c060209ef4e970cac18adeac1676a2a73cd ] In commit 79f033f6f229 ("iwlwifi: dbg: don't limit dump decisions to all or monitor") we changed the code to pass around a bitmap, but in the monitor_only case, one place accidentally used the bit number, not the bit mask, resulting in CSR and FW_INFO getting dumped instead of monitor data. 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.20210805141826.774fd8729a33.Ic985a787071d1c0b127ef0ba8367da896ee11f57@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18iwlwifi: mvm: fix access to BSS elementsJohannes Berg1-2/+6
[ Upstream commit 6c608cd6962ebdf84fd3de6d42f88ed64d2f4e1b ] BSS elements are protected using RCU, so we need to use RCU properly to access them, 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.20210805130823.fd8b5791ab44.Iba26800a6301078d3782fb249c476dd8ac2bf3c6@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18iwlwifi: mvm: avoid static queue number aliasingJohannes Berg2-16/+38
[ Upstream commit c6ce1c74ef2923b8ffd85f7f8b486f804f343b39 ] When TVQM is enabled (iwl_mvm_has_new_tx_api() is true), then queue numbers are just sequentially assigned 0, 1, 2, ... Prior to TVQM, in DQA, there were some statically allocated queue numbers: * IWL_MVM_DQA_AUX_QUEUE == 1, * both IWL_MVM_DQA_INJECT_MONITOR_QUEUE and IWL_MVM_DQA_P2P_DEVICE_QUEUE == 2, and * IWL_MVM_DQA_AP_PROBE_RESP_QUEUE == 9. Now, these values are assigned to the members mvm->aux_queue, mvm->snif_queue, mvm->probe_queue and mvm->p2p_dev_queue by default. Normally, this doesn't really matter, and if TVQM is in fact available we override them to the real values after allocating a queue for use there. However, this allocation doesn't always happen. For example, for mvm->p2p_dev_queue (== 2) it only happens when the P2P Device interface is started, if any. If it's not started, the value in mvm->p2p_dev_queue remains 2. This wouldn't really matter all that much if it weren't for iwl_mvm_is_static_queue() which checks a queue number against one of those four static numbers. Now, if no P2P Device or monitor interface is added then queue 2 may be dynamically allocated, yet alias mvm->p2p_dev_queue or mvm->snif_queue, and thus iwl_mvm_is_static_queue() erroneously returns true for it. If it then gets full, all interface queues are stopped, instead of just backpressuring against the one TXQ that's really the only affected one. This clearly can lead to issues, as everything is stopped even if just a single TXQ filled its corresponding HW queue, if it happens to have an appropriate number (2 or 9, AUX is always reassigned.) Due to a mac80211 bug, this also led to a situation in which the queues remained stopped across a deauthentication and then attempts to connect to a new AP started failing, but that's fixed separately. Fix all of this by simply initializing the queue numbers to the invalid value until they're used, if TVQM is enabled, and also setting them back to that value when the queues are later freed again. 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.20210802172232.2e47e623f9e2.I9b0830dafbb68ef35b7b8f0f46160abec02ac7d0@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18iwlwifi: mvm: fix a memory leak in iwl_mvm_mac_ctxt_beacon_changedZhang Qilong1-1/+3
[ Upstream commit 0f5d44ac6e55551798dd3da0ff847c8df5990822 ] If beacon_inject_active is true, we will return without freeing beacon. Fid that by freeing it before returning. Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> [reworded the commit message] Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210802172232.d16206ca60fc.I9984a9b442c84814c307cee3213044e24d26f38a@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18iwlwifi: pcie: free RBs during configureJohannes Berg2-1/+7
[ Upstream commit 6ac5720086c8b176794eb74c5cc09f8b79017f38 ] When switching op-modes, or more generally when reconfiguring, we might switch the RB size. In _iwl_pcie_rx_init() we have a comment saying we must free all RBs since we might switch the size, but this is actually too late: the switch has been done and we'll free the buffers with the wrong size. Fix this by always freeing the buffers, if any, at the start of configure, instead of only after the size may have changed. 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.20210802170640.42d7c93279c4.I07f74e65aab0e3d965a81206fcb289dc92d74878@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-15iwlwifi Add support for ax201 in Samsung Galaxy Book Flex2 AlphaJustin M. Forbes1-0/+1
commit 2f32c147a3816d789722c0bd242a9431332ec3ed upstream. The Samsung Galaxy Book Flex2 Alpha uses an ax201 with the ID a0f0/6074. This works fine with the existing driver once it knows to claim it. Simple patch to add the device. Signed-off-by: Justin M. Forbes <jforbes@fedoraproject.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210702223155.1981510-1-jforbes@fedoraproject.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-15iwlwifi: skip first element in the WTAS ACPI tableAbhishek Naik1-7/+7
[ Upstream commit 19426d54302e199b3fd2d575f926a13af66be2b9 ] By mistake we were considering the first element of the WTAS wifi package as part of the data we want to rid, but that element is the wifi package signature (always 0x07), so it should be skipped. Change the code to read the data starting from element 1 instead. Signed-off-by: Abhishek Naik <abhishek.naik@intel.com> Fixes: 28dd7ccdc56f ("iwlwifi: acpi: read TAS table from ACPI and send it to the FW") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210805141826.ff8148197b15.I70636c04e37b2b57a5df3ce611511f62203d27a7@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-15iwlwifi: follow the new inclusive terminologyEmmanuel Grumbach11-54/+55
[ Upstream commit cdaba917268d7b58bf02fcc587cb2a7a277dc931 ] The new inclusive terminology requires to change a few terms that were used in iwlwifi. 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.20201209231352.1eb4c8625f36.I1b17b68d4a8e77071da3e15ffbd902d15c1d4938@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-03iwlwifi: pnvm: accept multiple HW-type TLVsJohannes Berg1-9/+16
[ Upstream commit 0f673c16c850250db386537a422c11d248fb123c ] Some products (So) may have two different types of products with different mac-type that are otherwise equivalent, and have the same PNVM data, so the PNVM file will contain two (or perhaps later more) HW-type TLVs. Accept the file and use the data section that contains any matching entry. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210719140154.a6a86e903035.Ic0b1b75c45d386698859f251518e8a5144431938@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19iwlwifi: pcie: fix context info freeingJohannes Berg1-1/+2
[ Upstream commit 26d18c75a7496c4c52b0b6789e713dc76ebfbc87 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19iwlwifi: pcie: free IML DMA memory allocationJohannes Berg2-5/+13
[ Upstream commit 310f60f53a86eba680d9bc20a371e13b06a5f903 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19iwlwifi: mvm: fix error print when session protection endsShaul Triebitz1-0/+4
[ Upstream commit 976ac0af7ba2c5424bc305b926c0807d96fdcc83 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19iwlwifi: mvm: don't change band on bound PHY contextsJohannes Berg1-6/+18
[ Upstream commit 8835a64f74c46baebfc946cd5a2c861b866ebcee ] When we have a P2P Device active, we attempt to only change the PHY context it uses when we get a new remain-on-channel, if the P2P Device is the only user of the PHY context. This is fine if we're switching within a band, but if we're switching bands then the switch implies a removal and re-add of the PHY context, which isn't permitted by the firmware while it's bound to an interface. Fix the code to skip the unbind/release/... cycle only if the band doesn't change (or we have old devices that can switch the band on the fly as well.) 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.20210612142637.e9ac313f70f3.I713b9d109957df7e7d9ed0861d5377ce3f8fccd3@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14iwlwifi: increase PNVM load timeoutLuca Coelho1-2/+2
[ Upstream commit 5cc816ef9db1fe03f73e56e9d8f118add9c6efe4 ] The FW has a watchdog of 200ms in the PNVM load flow, so the driver should have a slightly higher timeout. Change the timeout from 100ms to 250ms. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Fixes: 70d3ca86b025 ("iwlwifi: mvm: ring the doorbell and wait for PNVM load completion") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210612142637.ba22aec1e2be.I36bfadc28c480f4fc57266c075a79e8ea4a6934f@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14mac80211: remove iwlwifi specific workaround that broke sta NDP txFelix Fietkau1-0/+3
commit e41eb3e408de27982a5f8f50b2dd8002bed96908 upstream. Sending nulldata packets is important for sw AP link probing and detecting 4-address mode links. The checks that dropped these packets were apparently added to work around an iwlwifi firmware bug with multi-TID aggregation. Fixes: 41cbb0f5a295 ("mac80211: add support for HE") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20210619101517.90806-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19iwlwifi: pcie: make cfg vs. trans_cfg more robustJohannes Berg1-7/+28
[ Upstream commit 48a5494d6a4cb5812f0640d9515f1876ffc7a013 ] If we (for example) have a trans_cfg entry in the PCI IDs table, but then don't find a full cfg entry for it in the info table, we fall through to the code that treats the PCI ID table entry as a full cfg entry. This obviously causes crashes later, e.g. when trying to build the firmware name string. Avoid such crashes by using the low bit of the pointer as a tag for trans_cfg entries (automatically using a macro that checks the type when assigning) and then checking that before trying to use the data as a full entry - if it's just a partial entry at that point, fail. Since we're adding some macro magic, also check that the type is in fact either struct iwl_cfg_trans_params or struct iwl_cfg, failing compilation ("initializer element is not constant") if it isn't. 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.20210330162204.6f69fe6e4128.I921d4ae20ef5276716baeeeda0b001cf25b9b968@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14ipw2x00: potential buffer overflow in libipw_wx_set_encodeext()Dan Carpenter1-2/+4
commit 260a9ad9446723d4063ed802989758852809714d upstream. The "ext->key_len" is a u16 that comes from the user. If it's over SCM_KEY_LEN (32) that could lead to memory corruption. Fixes: e0d369d1d969 ("[PATCH] ieee82011: Added WE-18 support to default wireless extension handler") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Stanislav Yakovlev <stas.yakovlev@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/YHaoA1i+8uT4ir4h@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-02iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_gen2_enqueue_hcmd()Jiri Kosina1-3/+4
commit e7020bb068d8be50a92f48e36b236a1a1ef9282e upstream. Analogically to what we did in 2800aadc18a6 ("iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd()"), we must apply the same fix to iwl_pcie_gen2_enqueue_hcmd(), as it's being called from exactly the same contexts. Reported-by: Heiner Kallweit <hkallweit1@gmail.com Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2104171112390.18270@cbobk.fhfr.pm Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-21iwlwifi: add support for Qu with AX201 deviceMatt Chen1-0/+1
[ Upstream commit 97195d3cad852063208a1cd4f4d073459547a415 ] Add this specific Samsung AX201 sku to driver so it can be detected and initialized successfully. Signed-off-by: Matt Chen <matt.chen@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.20210326125611.30b622037714.Id9fd709cf1c8261c097bbfd7453f6476077dcafc@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-21iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd()Jiri Kosina1-3/+4
[ Upstream commit 2800aadc18a64c96b051bcb7da8a7df7d505db3f ] It's possible for iwl_pcie_enqueue_hcmd() to be called with hard IRQs disabled (e.g. from LED core). We can't enable BHs in such a situation. Turn the unconditional BH-enable/BH-disable code into hardirq-disable/conditional-enable. This fixes the warning below. WARNING: CPU: 1 PID: 1139 at kernel/softirq.c:178 __local_bh_enable_ip+0xa5/0xf0 CPU: 1 PID: 1139 Comm: NetworkManager Not tainted 5.12.0-rc1-00004-gb4ded168af79 #7 Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017 RIP: 0010:__local_bh_enable_ip+0xa5/0xf0 Code: f7 69 e8 ee 23 14 00 fb 66 0f 1f 44 00 00 65 8b 05 f0 f4 f7 69 85 c0 74 3f 48 83 c4 08 5b c3 65 8b 05 9b fe f7 69 85 c0 75 8e <0f> 0b eb 8a 48 89 3c 24 e8 4e 20 14 00 48 8b 3c 24 eb 91 e8 13 4e RSP: 0018:ffffafd580b13298 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000201 RCX: 0000000000000000 RDX: 0000000000000003 RSI: 0000000000000201 RDI: ffffffffc1272389 RBP: ffff96517ae4c018 R08: 0000000000000001 R09: 0000000000000000 R10: ffffafd580b13178 R11: 0000000000000001 R12: ffff96517b060000 R13: 0000000000000000 R14: ffffffff80000000 R15: 0000000000000001 FS: 00007fc604ebefc0(0000) GS:ffff965267480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055fb3fef13b2 CR3: 0000000109112004 CR4: 00000000003706e0 Call Trace: ? _raw_spin_unlock_bh+0x1f/0x30 iwl_pcie_enqueue_hcmd+0x5d9/0xa00 [iwlwifi] iwl_trans_txq_send_hcmd+0x6c/0x430 [iwlwifi] iwl_trans_send_cmd+0x88/0x170 [iwlwifi] ? lock_acquire+0x277/0x3d0 iwl_mvm_send_cmd+0x32/0x80 [iwlmvm] iwl_mvm_led_set+0xc2/0xe0 [iwlmvm] ? led_trigger_event+0x46/0x70 led_trigger_event+0x46/0x70 ieee80211_do_open+0x5c5/0xa20 [mac80211] ieee80211_open+0x67/0x90 [mac80211] __dev_open+0xd4/0x150 __dev_change_flags+0x19e/0x1f0 dev_change_flags+0x23/0x60 do_setlink+0x30d/0x1230 ? lock_is_held_type+0xb4/0x120 ? __nla_validate_parse.part.7+0x57/0xcb0 ? __lock_acquire+0x2e1/0x1a50 __rtnl_newlink+0x560/0x910 ? __lock_acquire+0x2e1/0x1a50 ? __lock_acquire+0x2e1/0x1a50 ? lock_acquire+0x277/0x3d0 ? sock_def_readable+0x5/0x290 ? lock_is_held_type+0xb4/0x120 ? find_held_lock+0x2d/0x90 ? sock_def_readable+0xb3/0x290 ? lock_release+0x166/0x2a0 ? lock_is_held_type+0x90/0x120 rtnl_newlink+0x47/0x70 rtnetlink_rcv_msg+0x25c/0x470 ? netlink_deliver_tap+0x97/0x3e0 ? validate_linkmsg+0x350/0x350 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x1b2/0x280 netlink_sendmsg+0x336/0x450 sock_sendmsg+0x5b/0x60 ____sys_sendmsg+0x1ed/0x250 ? copy_msghdr_from_user+0x5c/0x90 ___sys_sendmsg+0x88/0xd0 ? lock_is_held_type+0xb4/0x120 ? find_held_lock+0x2d/0x90 ? lock_release+0x166/0x2a0 ? __fget_files+0xfe/0x1d0 ? __sys_sendmsg+0x5e/0xa0 __sys_sendmsg+0x5e/0xa0 ? lockdep_hardirqs_on_prepare+0xd9/0x170 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fc605c9572d Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 da ee ff ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 2e ef ff ff 48 RSP: 002b:00007fffc83789f0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000055ef468570c0 RCX: 00007fc605c9572d RDX: 0000000000000000 RSI: 00007fffc8378a30 RDI: 000000000000000c RBP: 0000000000000010 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00007fffc8378b80 R14: 00007fffc8378b7c R15: 0000000000000000 irq event stamp: 170785 hardirqs last enabled at (170783): [<ffffffff9609a8c2>] __local_bh_enable_ip+0x82/0xf0 hardirqs last disabled at (170784): [<ffffffff96a8613d>] _raw_read_lock_irqsave+0x8d/0x90 softirqs last enabled at (170782): [<ffffffffc1272389>] iwl_pcie_enqueue_hcmd+0x5d9/0xa00 [iwlwifi] softirqs last disabled at (170785): [<ffffffffc1271ec6>] iwl_pcie_enqueue_hcmd+0x116/0xa00 [iwlwifi] Signed-off-by: Jiri Kosina <jkosina@suse.cz> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v12.0.0-rc3 Acked-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2103021125430.12405@cbobk.fhfr.pm Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-14iwlwifi: fix 11ax disabled bit in the regulatory capability flagsLuca Coelho1-1/+1
[ Upstream commit 07cc40fec9a85e669ea12e161a438d2cbd76f1ed ] When version 2 of the regulatory capability flags API was implemented, the flag to disable 11ax was defined as bit 13, but this was later changed and the bit remained as bit 10, like in version 1. This was never changed in the driver, so we were checking for the wrong bit in newer devices. Fix it. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Fixes: e27c506a985c ("iwlwifi: regulatory: regulatory capabilities api change") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.6d28516b59cd.Id0248d5e4662695254f49ce37b0268834ed52918@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-14iwlwifi: pcie: properly set LTR workarounds on 22000 devicesJohannes Berg3-32/+37
commit 25628bc08d4526d3673ca7d039eb636aa9006076 upstream. As the context info gen3 code is only called for >=AX210 devices (from iwl_trans_pcie_gen2_start_fw()) the code there to set LTR on 22000 devices cannot actually do anything (22000 < AX210). Fix this by moving the LTR code to iwl_trans_pcie_gen2_start_fw() where it can handle both devices. This then requires that we kick the firmware only after that rather than doing it from the context info code. Note that this again had a dead branch in gen3 code, which I've removed here. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: ed0022da8bd9 ("iwlwifi: pcie: set LTR on more devices") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.675486178ed1.Ib61463aba6920645059e366dcdca4c4c77f0ff58@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-07iwlwifi: pcie: don't disable interrupts for reg_lockJohannes Berg3-22/+16
[ Upstream commit 874020f8adce535cd318af1768ffe744251b6593 ] The only thing we do touching the device in hard interrupt context is, at most, writing an interrupt ACK register, which isn't racing in with anything protected by the reg_lock. Thus, avoid disabling interrupts here for potentially long periods of time, particularly long periods have been observed with dumping of firmware memory (leading to lockup warnings on some devices.) 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.20210210135352.da916ab91298.I064c3e7823b616647293ed97da98edefb9ce9435@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-25iwlwifi: Add a new card for MA familyMatti Gottlieb3-0/+19
[ Upstream commit ac1a98e1e924e7e8d7c7e5b1ca8ddc522e10ddd0 ] Add a PCI ID for snj with mr in AX family. Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201209231352.101ac3058c04.Idd28706b122cdc8103956f8e72bb062fe4adb54e@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04iwlwifi: pnvm: increment the pointer before checking the TLVLuca Coelho1-3/+3
[ Upstream commit ff11a8ee2d2d0f78514ac9b42fb50c525ca695c7 ] If the SKU_ID doesn't match, we don't increment the pointer and keep checking the same TLV over and over again. We need to increment the pointer in all situtations, namely if the TLV is not a SKU_ID, if the SKU_ID matched or if the SKU_ID didn't match. So we can increment the pointer already before checking for these conditions to solve the problem. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Fixes: 6972592850c0 ("iwlwifi: read and parse PNVM file") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210210172142.de94d366f3ff.I9a5a54906cf0f4ec8af981d6066bfd771152ffb9@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04iwlwifi: pnvm: set the PNVM again if it was already loadedLuca Coelho2-10/+18
[ Upstream commit 4a81598f0f39cffbf1c29c4a184063d513661c4a ] When the interface goes up, we have already loaded the PNVM during init, so we don't load it anymore. But we still need to set the PNVM values in the context so that the FW can load it again. Call set_pnvm when the PNVM is already loaded and change the trans_pcie implementation to accept a second call to set_pnvm when we have already allocated and, in this case, only set the values without allocating again. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Fixes: 6972592850c0 ("iwlwifi: read and parse PNVM file") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210210172142.622546a3566f.I659a8b9aa944d213c4ba446e142d74f3f6db9c64@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04iwlwifi: mvm: don't check if CSA event is running before removingSara Sharon1-3/+0
[ Upstream commit b8a86164454aa745ecb534d7477d50d440ea05b6 ] We may want to remove it before it started (i.e. before the actual switch time). Signed-off-by: Sara Sharon <sara.sharon@intel.com> Fixes: 58ddd9b6d194 ("iwlwifi: mvm: don't send a CSA command the firmware doesn't know") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210210171218.835db8987b8a.Ic6c5d28d744302db1bc6c4314bd3138ba472f834@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04iwlwifi: mvm: assign SAR table revision to the command laterLuca Coelho1-2/+10
[ Upstream commit 28db1862067cb09ebfdccfbc129a52c6fdb4c4d7 ] The call to iwl_sar_geo_init() was moved to the end of the iwl_mvm_sar_geo_init() function, after the table revision is assigned to the FW command. But the revision is only known after iwl_sar_geo_init() is called, so we were always assigning zero to it. Fix that by moving the assignment code after the iwl_sar_geo_init() function is called. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Fixes: 45acebf8d6a6 ("iwlwifi: fix sar geo table initialization") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210210135352.cef55ef3a065.If96c60f08d24c2262c287168a6f0dbd7cf0f8f5c@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04iwlwifi: mvm: send stored PPAG command instead of localLuca Coelho1-6/+3
[ Upstream commit 659844d391826bfc5c8b4d9a06869ed51d859c76 ] Some change conflicts apparently cause a confusion between a local variable being used to send the PPAG command and the introduction of a union for this command. Most parts of the local command were never copied from the stored data, so the FW was getting garbage in the tables instead of getting valid values. Fix this by completely removing the local and using only the union that we have stored in fwrt. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Fixes: f2134f66f40e ("iwlwifi: acpi: support ppag table command v2") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210210135352.d090e0301023.I7d57f4d7da9a3297734c51cf988199323c76916d@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04iwlwifi: mvm: store PPAG enabled/disabled flag properlyLuca Coelho1-4/+3
[ Upstream commit 551d793f65364c904921ac168d4b4028bb51be69 ] When reading the PPAG table from ACPI, we should store everything in our fwrt structure, so it can be accessed later. But we had a local ppag_table variable in the function and were erroneously storing the enabled/disabled flag in it instead of storing it in the fwrt. Fix this by removing the local variable and storing everything directly in fwrt. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Fixes: f2134f66f40e ("iwlwifi: acpi: support ppag table command v2") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210210135352.889862e6d393.I8b894c1b2b3fe0ad2fb39bf438273ea47eb5afa4@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04iwlwifi: mvm: fix the type we use in the PPAG table validity checksLuca Coelho1-6/+13
[ Upstream commit 5a6842455c113920001df83cffa28accceeb0927 ] The value we receive from ACPI is a long long unsigned integer but the values should be treated as signed char. When comparing the received value with ACPI_PPAG_MIN_LB/HB, we were doing an unsigned comparison, so the negative value would actually be treated as a very high number. To solve this issue, assign the value to our table of s8's before making the comparison, so the value is already converted when we do so. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210210135352.b0ec69f312bc.If77fd9c61a96aa7ef2ac96d935b7efd7df502399@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04iwlwifi: mvm: set enabled in the PPAG command properlyLuca Coelho1-0/+2
[ Upstream commit efaa85cf2294d5e10a724e24356507eeb3836f72 ] When version 2 of the PER_PLATFORM_ANT_GAIN_CMD was implemented, we started copying the values from the command that we have stored into a local instance. But we accidentally forgot to copy the enabled flag, so in practice PPAG is never really enabled. Fix this by copying the flag from our stored data a we should. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Fixes: f2134f66f40e ("iwlwifi: acpi: support ppag table command v2") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210131201908.24d7bf754ad5.I0e8abc2b8747508b6118242533d68c856ca6dffb@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-13iwlwifi: queue: bail out on invalid freeingJohannes Berg1-4/+2
[ Upstream commit 0bed6a2a14afaae240cc431e49c260568488b51c ] If we find an entry without an SKB, we currently continue, but that will just result in an infinite loop since we won't increment the read pointer, and will try the same thing over and over again. Fix this. Signed-off-by: Johannes Berg <johannes.berg@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.20210122144849.abe2dedcc3ac.Ia6b03f9eeb617fd819e56dd5376f4bb8edc7b98a@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-13iwlwifi: mvm: guard against device removal in reprobeJohannes Berg1-1/+2
[ Upstream commit 7a21b1d4a728a483f07c638ccd8610d4b4f12684 ] If we get into a problem severe enough to attempt a reprobe, we schedule a worker to do that. However, if the problem gets more severe and the device is actually destroyed before this worker has a chance to run, we use a free device. Bump up the reference count of the device until the worker runs to avoid this situation. Signed-off-by: Johannes Berg <johannes.berg@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.20210122144849.871f0892e4b2.I94819e11afd68d875f3e242b98bef724b8236f1e@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-13iwlwifi: pcie: add rules to match Qu with Hr2Luca Coelho3-0/+38
[ Upstream commit 16062c12edb8ed2dfb15e6a914ff4edf858ab9e0 ] Until now we have been relying on matching the PCI ID and subsystem device ID in order to recognize Qu devices with Hr2. Add rules to match these devices, so that we don't have to add a new rule for every new ID we get. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210122144849.591ce253ddd8.Ia4b9cc2c535625890c6d6b560db97ee9f2d5ca3b@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-13iwlwifi: mvm: invalidate IDs of internal stations at mvm startGregory Greenman2-0/+10
[ Upstream commit e223e42aac30bf81f9302c676cdf58cf2bf36950 ] Having sta_id not set for aux_sta and snif_sta can potentially lead to a hard to debug issue in case remove station is called without an add. In this case sta_id 0, an unrelated regular station, will be removed. In fact, we do have a FW assert that occures rarely and from the debug data analysis it looks like sta_id 0 is removed by mistake, though it's hard to pinpoint the exact flow. The WARN_ON in this patch should help to find it. Signed-off-by: Gregory Greenman <gregory.greenman@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.20210122144849.5dc6dd9b22d5.I2add1b5ad24d0d0a221de79d439c09f88fcaf15d@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-13iwlwifi: pcie: fix context info memory leakJohannes Berg1-2/+9
[ Upstream commit 2d6bc752cc2806366d9a4fd577b3f6c1f7a7e04e ] If the image loader allocation fails, we leak all the previously allocated memory. Fix this. Signed-off-by: Johannes Berg <johannes.berg@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.20210115130252.97172cbaa67c.I3473233d0ad01a71aa9400832fb2b9f494d88a11@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-13iwlwifi: pcie: add a NULL check in iwl_pcie_txq_unmapEmmanuel Grumbach1-0/+5
[ Upstream commit 98c7d21f957b10d9c07a3a60a3a5a8f326a197e5 ] I hit a NULL pointer exception in this function when the init flow went really bad. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@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.20210115130252.2e8da9f2c132.I0234d4b8ddaf70aaa5028a20c863255e05bc1f84@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-13iwlwifi: mvm: take mutex for calling iwl_mvm_get_sync_time()Johannes Berg1-0/+3
[ Upstream commit 5c56d862c749669d45c256f581eac4244be00d4d ] We need to take the mutex to call iwl_mvm_get_sync_time(), do it. Signed-off-by: Johannes Berg <johannes.berg@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.20210115130252.4bb5ccf881a6.I62973cbb081e80aa5b0447a5c3b9c3251a65cf6b@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-13iwlwifi: mvm: skip power command when unbinding vif during CSASara Sharon1-0/+3
[ Upstream commit bf544e9aa570034e094a8a40d5f9e1e2c4916d18 ] In the new CSA flow, we remain associated during CSA, but still do a unbind-bind to the vif. However, sending the power command right after when vif is unbound but still associated causes FW to assert (0x3400) since it cannot tell the LMAC id. Just skip this command, we will send it again in a bit, when assigning the new context. Signed-off-by: Sara Sharon <sara.sharon@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.20210115130252.64a2254ac5c3.Iaa3a9050bf3d7c9cd5beaf561e932e6defc12ec3@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-04iwlwifi: pcie: reschedule in long-running memory readsJohannes Berg1-1/+7
[ Upstream commit 3d372c4edfd4dffb7dea71c6b096fb414782b776 ] If we spin for a long time in memory reads that (for some reason in hardware) take a long time, then we'll eventually get messages such as watchdog: BUG: soft lockup - CPU#2 stuck for 24s! [kworker/2:2:272] This is because the reading really does take a very long time, and we don't schedule, so we're hogging the CPU with this task, at least if CONFIG_PREEMPT is not set, e.g. with CONFIG_PREEMPT_VOLUNTARY=y. Previously I misinterpreted the situation and thought that this was only going to happen if we had interrupts disabled, and then fixed this (which is good anyway, however), but that didn't always help; looking at it again now I realized that the spin unlock will only reschedule if CONFIG_PREEMPT is used. In order to avoid this issue, change the code to cond_resched() if we've been spinning for too long here. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: 04516706bb99 ("iwlwifi: pcie: limit memory read spin time") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210115130253.217a9d6a6a12.If964cb582ab0aaa94e81c4ff3b279eaafda0fd3f@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-04iwlwifi: pcie: use jiffies for memory read spin time limitJohannes Berg1-6/+2
[ Upstream commit 6701317476bbfb1f341aa935ddf75eb73af784f9 ] There's no reason to use ktime_get() since we don't need any better precision than jiffies, and since we no longer disable interrupts around this code (when grabbing NIC access), jiffies will work fine. Use jiffies instead of ktime_get(). This cleanup is preparation for the following patch "iwlwifi: pcie: reschedule in long-running memory reads". The code gets simpler with the weird clock use etc. removed before we add cond_resched(). Signed-off-by: Johannes Berg <johannes.berg@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.20210115130253.621c948b1fad.I3ee9f4bc4e74a0c9125d42fb7c35cd80df4698a1@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-04iwlwifi: pcie: set LTR on more devicesJohannes Berg2-17/+28
[ Upstream commit ed0022da8bd9a3ba1c0e1497457be28d52afa7e1 ] To avoid completion timeouts during device boot, set up the LTR timeouts on more devices - similar to what we had before for AX210. This also corrects the AX210 workaround to be done only on discrete (non-integrated) devices, otherwise the registers have no effect. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: edb625208d84 ("iwlwifi: pcie: set LTR to avoid completion timeout") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210115130252.fb819e19530b.I0396f82922db66426f52fbb70d32a29c8fd66951@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-04iwlwifi: pnvm: don't try to load after failuresJohannes Berg1-1/+7
[ Upstream commit 82a08d0cd7b503be426fb856a0fb73c9c976aae1 ] If loading the PNVM file failed on the first try during the interface up, the file is unlikely to show up later, and we already don't try to reload it if it changes, so just don't try loading it again and again. This also fixes some issues where we may try to load it at resume time, which may not be possible yet. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: 6972592850c0 ("iwlwifi: read and parse PNVM file") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210115130252.5ac6828a0bbe.I7d308358b21d3c0c84b1086999dbc7267f86e219@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-04iwlwifi: pnvm: don't skip everything when not reloadingJohannes Berg1-25/+25
[ Upstream commit 1c58bed4b7f7551239b9005ad0a9a6566a3d9fbe ] Even if we don't reload the file from disk, we still need to trigger the PNVM load flow with the device; fix that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: 6972592850c0 ("iwlwifi: read and parse PNVM file") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210115130252.85ef56c4ef8c.I3b853ce041a0755d45e448035bef1837995d191b@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-04iwlwifi: pcie: avoid potential PNVM leaksJohannes Berg1-0/+3
[ Upstream commit 34b9434cd0d425330a0467e767f8d047ef62964d ] If we erroneously try to set the PNVM data again after it has already been set, we could leak the old DMA memory. Avoid that and warn, we shouldn't be doing this. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: 6972592850c0 ("iwlwifi: read and parse PNVM file") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210115130252.929c2d680429.I086b9490e6c005f3bcaa881b617e9f61908160f3@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-09 14:22:19 +0300