summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/intel/iwlwifi
AgeCommit message (Collapse)AuthorFilesLines
2020-04-29iwlwifi: mvm: beacon statistics shouldn't go backwardsMordechay Goodstein1-0/+9
commit 290d5e4951832e39d10f4184610dbf09038f8483 upstream. We reset statistics also in case that we didn't reassoc so in this cases keep last beacon counter. Cc: stable@vger.kernel.org # v4.19+ 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.20200417100405.1f9142751fbc.Ifbfd0f928a0a761110b8f4f2ca5483a61fb21131@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-29iwlwifi: pcie: actually release queue memory in TVQMJohannes Berg1-0/+3
commit b98b33d5560a2d940f3b80f6768a6177bf3dfbc0 upstream. The iwl_trans_pcie_dyn_txq_free() function only releases the frames that may be left on the queue by calling iwl_pcie_gen2_txq_unmap(), but doesn't actually free the DMA ring or byte-count tables for the queue. This leads to pretty large memory leaks (at least before my queue size improvements), in particular in monitor/sniffer mode on channel hopping since this happens on every channel change. This was also now more evident after the move to a DMA pool for the byte count tables, showing messages such as BUG iwlwifi:bc (...): Objects remaining in iwlwifi:bc on __kmem_cache_shutdown() This fixes https://bugzilla.kernel.org/show_bug.cgi?id=206811. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: 6b35ff91572f ("iwlwifi: pcie: introduce a000 TX queues management") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20200417100405.f5f4c4193ec1.Id5feebc9b4318041913a9c89fc1378bb5454292c@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18iwlwifi: mvm: Do not require PHY_SKU NVM section for 3168 devicesDan Moulding1-1/+2
commit a9149d243f259ad8f02b1e23dfe8ba06128f15e1 upstream. The logic for checking required NVM sections was recently fixed in commit b3f20e098293 ("iwlwifi: mvm: fix NVM check for 3168 devices"). However, with that fixed the else is now taken for 3168 devices and within the else clause there is a mandatory check for the PHY_SKU section. This causes the parsing to fail for 3168 devices. The PHY_SKU section is really only mandatory for the IWL_NVM_EXT layout (the phy_sku parameter of iwl_parse_nvm_data is only used when the NVM type is IWL_NVM_EXT). So this changes the PHY_SKU section check so that it's only mandatory for IWL_NVM_EXT. Fixes: b3f20e098293 ("iwlwifi: mvm: fix NVM check for 3168 devices") Signed-off-by: Dan Moulding <dmoulding@me.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-05iwlwifi: pcie: fix rb_allocator workqueue allocationJohannes Berg1-4/+11
commit 8188a18ee2e48c9a7461139838048363bfce3fef upstream We don't handle failures in the rb_allocator workqueue allocation correctly. To fix that, move the code earlier so the cleanup is easier and we don't have to undo all the interrupt allocations in this case. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> [Ajay: Modified to apply on v4.19.y and v4.14.y] Signed-off-by: Ajay Kaher <akaher@vmware.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-02-24iwlwifi: mvm: Fix thermal zone registrationAndrei Otcheretianski1-1/+3
[ Upstream commit baa6cf8450b72dcab11f37c47efce7c5b9b8ad0f ] Use a unique name when registering a thermal zone. Otherwise, with multiple NICS, we hit the following warning during the unregistration. WARNING: CPU: 2 PID: 3525 at fs/sysfs/group.c:255 RIP: 0010:sysfs_remove_group+0x80/0x90 Call Trace: dpm_sysfs_remove+0x57/0x60 device_del+0x5a/0x350 ? sscanf+0x4e/0x70 device_unregister+0x1a/0x60 hwmon_device_unregister+0x4a/0xa0 thermal_remove_hwmon_sysfs+0x175/0x1d0 thermal_zone_device_unregister+0x188/0x1e0 iwl_mvm_thermal_exit+0xe7/0x100 [iwlmvm] iwl_op_mode_mvm_stop+0x27/0x180 [iwlmvm] _iwl_op_mode_stop.isra.3+0x2b/0x50 [iwlwifi] iwl_opmode_deregister+0x90/0xa0 [iwlwifi] __exit_compat+0x10/0x2c7 [iwlmvm] __x64_sys_delete_module+0x13f/0x270 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-02-11iwlwifi: don't throw error when trying to remove IGTKLuca Coelho1-3/+7
commit 197288d5ba8a5289f22d3aeb4fca3824bfd9b4af upstream. The IGTK keys are only removed by mac80211 after it has already removed the AP station. This causes the driver to throw an error because mac80211 is trying to remove the IGTK when the station doesn't exist anymore. The firmware is aware that the station has been removed and can deal with it the next time we try to add an IGTK for a station, so we shouldn't try to remove the key if the station ID is IWL_MVM_INVALID_STA. Do this by removing the check for mvm_sta before calling iwl_mvm_send_sta_igtk() and check return from that function gracefully if the station ID is invalid. Cc: stable@vger.kernel.org # 4.12+ Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-11iwlwifi: mvm: fix NVM check for 3168 devicesLuca Coelho1-1/+1
[ Upstream commit b3f20e098293892388d6a0491d6bbb2efb46fbff ] We had a check on !NVM_EXT and then a check for NVM_SDP in the else block of this if. The else block, obviously, could only be reached if using NVM_EXT, so it would never be NVM_SDP. Fix that by checking whether the nvm_type is IWL_NVM instead of checking for !IWL_NVM_EXT to solve this issue. Reported-by: Stefan Sperling <stsp@stsp.name> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-02-05iwlwifi: Don't ignore the cap field upon mcc updateHaim Dreyfuss3-6/+51
[ Upstream commit 2763bba6328c53c455d8f7f5302b80030551c31b ] When receiving a new MCC driver get all the data about the new country code and its regulatory information. Mistakenly, we ignored the cap field, which includes global regulatory information which should be applies to every channel. Fix it. Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27iwlwifi: mvm: fix RSS config commandSara Sharon1-6/+6
[ Upstream commit 608dce95db10b8ee1a26dbce3f60204bb69812a5 ] The hash mask is a bitmap, so we should use BIT() on the enum values. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Fixes: 43413a975d06 ("iwlwifi: mvm: support rss queues configuration command") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27iwlwifi: mvm: fix A-MPDU reference assignmentJohannes Berg1-1/+1
[ Upstream commit 1f7698abedeeb3fef3cbcf78e16f925df675a179 ] The current code assigns the reference, and then goes to increment it if the toggle bit has changed. That way, we get Toggle 0 0 0 0 1 1 1 1 ID 1 1 1 1 1 2 2 2 Fix that by assigning the post-toggle ID to get Toggle 0 0 0 0 1 1 1 1 ID 1 1 1 1 2 2 2 2 Reported-by: Danny Alexander <danny.alexander@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: fbe4112791b8 ("iwlwifi: mvm: update mpdu metadata API") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27iwlwifi: mvm: avoid possible access out of array.Mordechay Goodstein1-6/+13
[ Upstream commit b0d795a9ae558209656b18930c2b4def5f8fdfb8 ] The value in txq_id can be out of array scope, validate it before accessing the array. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Fixes: cf961e16620f ("iwlwifi: mvm: support dqa-mode agg on non-shared queue") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27iwlwifi: nvm: get num of hw addresses from firmwareNaftali Goldstein2-8/+16
[ Upstream commit e7eeee08434873c2f781dc1afaa42b03a014b95d ] With NICs that don't read the NVM directly and instead rely on getting the relevant data from the firmware, the number of reserved MAC addresses was not added to the API. This caused the driver to assume there is only one address which results in all interfaces getting the same address. Update the API to fix this. While at it, fix-up the comments with firmware api names to actually match what we have in the firmware. Fixes: e9e1ba3dbf00 ("iwlwifi: mvm: support getting nvm data from firmware") Signed-off-by: Naftali Goldstein <naftali.goldstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-17iwlwifi: pcie: fix memory leaks in iwl_pcie_ctxt_info_gen3_initNavid Emamdoost1-11/+25
commit 0f4f199443faca715523b0659aa536251d8b978f upstream. In iwl_pcie_ctxt_info_gen3_init there are cases that the allocated dma memory is leaked in case of error. DMA memories prph_scratch, prph_info, and ctxt_info_gen3 are allocated and initialized to be later assigned to trans_pcie. But in any error case before such assignment the allocated memories should be released. First of such error cases happens when iwl_pcie_init_fw_sec fails. Current implementation correctly releases prph_scratch. But in two sunsequent error cases where dma_alloc_coherent may fail, such releases are missing. This commit adds release for prph_scratch when allocation for prph_info fails, and adds releases for prph_scratch and prph_info when allocation for ctxt_info_gen3 fails. Fixes: 2ee824026288 ("iwlwifi: pcie: support context information for 22560 devices") Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-17iwlwifi: dbg_ini: fix memory leak in alloc_sgtableNavid Emamdoost1-0/+1
commit b4b814fec1a5a849383f7b3886b654a13abbda7d upstream. In alloc_sgtable if alloc_page fails, the alocated table should be released. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-31iwlwifi: check kasprintf() return valueJohannes Berg2-0/+6
[ Upstream commit 5974fbb5e10b018fdbe3c3b81cb4cc54e1105ab9 ] kasprintf() can fail, we should check the return value. Fixes: 5ed540aecc2a ("iwlwifi: use mac80211 throughput trigger") Fixes: 8ca151b568b6 ("iwlwifi: add the MVM driver") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31iwlwifi: mvm: fix unaligned read of rx_pkt_statusWang Xuerui1-1/+2
[ Upstream commit c5aaa8be29b25dfe1731e9a8b19fd91b7b789ee3 ] This is present since the introduction of iwlmvm. Example stack trace on MIPS: [<ffffffffc0789328>] iwl_mvm_rx_rx_mpdu+0xa8/0xb88 [iwlmvm] [<ffffffffc0632b40>] iwl_pcie_rx_handle+0x420/0xc48 [iwlwifi] Tested with a Wireless AC 7265 for ~6 months, confirmed to fix the problem. No other unaligned accesses are spotted yet. Signed-off-by: Wang Xuerui <wangxuerui@qiniu.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-13iwlwifi: fix cfg structs for 22000 with different RF modulesLuca Coelho3-4/+21
[ Upstream commit b1bbc1a636505ebdd6336ff781e417123226d4f7 ] We have to choose different configuration and different firmwares depending on the external RF module that is installed. Since the external module is not represented in the PCI IDs, we need to change the configuration at runtime, after checking the RF ID of the module installed. We have a bit of a mess in the code that does this, because it applies cfg's according to the RF ID only, ignoring the integrated module that is in use. Fix that for some devices by adding correct configurations for them and not ignoring the integrated module's type when making the decision. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-13iwlwifi: mvm: Send non offchannel traffic via AP staAndrei Otcheretianski1-0/+15
[ Upstream commit dc1aca22f8f38b7e2ad7b118db87404d11e68771 ] TDLS discovery response frame is a unicast direct frame to the peer. Since we don't have a STA for this peer, this frame goes through iwl_tx_skb_non_sta(). As the result aux_sta and some completely arbitrary queue would be selected for this frame, resulting in a queue hang. Fix that by sending such frames through AP sta instead. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-13iwlwifi: trans: Clear persistence bit when starting the FWShahar S Matityahu2-0/+19
[ Upstream commit 8954e1eb2270fa2effffd031b4839253952c76f2 ] In D3 suspend flow in 9260 gen2 HW, the NIC receives two PERST signals. The first PERST is expected and indicates the device on coming resume flow. The second PERST causes FW restart FW restart. In order to avoid this issue, the FW set the persistence bit on. Once this bit is set, the FW ignores reset attempts. The problem is when the FW gets assert during D3 and then the persistence bit is set and causes the FW to ignore reset. To handle this issue, the FW opens the preg bit which allows access to the persistence bit, so that the driver clear the persistence bit and reset the NIC. The flow is as follows: the driver checks if the persistence bit is set. If the bit is set, the driver checks if he can clear the bit. If the driver can not clear the bit then there is no point to continue configuring the NIC since it will fail. The fix was added is in start HW flow instead of the resume flow since in general, if the persistence bit is set, the driver can not start the FW. So it is good to check it when we start configuring the NIC. The driver does not need to close the preg bit since the FW close it during the start flow. Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-13iwlwifi: mvm: synchronize TID queue removalJohannes Berg1-0/+10
[ Upstream commit 06bc6f6ed4ae0246a5e52094d1be90906a1361c7 ] When we mark a TID as no longer having a queue, there's no guarantee the TX path isn't using this txq_id right now, having accessed it just before we reset the value. To fix this, add synchronize_net() when we change the TIDs from having a queue to not having one, so that we can then be sure that the TX path is no longer accessing that queue. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-13iwlwifi: pcie: don't consider IV len in A-MSDUMordechay Goodstein1-13/+7
[ Upstream commit cb1a4badf59275eb7221dcec621e8154917eabd1 ] From gen2 PN is totally offloaded to hardware (also the space for the IV isn't part of the skb). As you can see in mvm/mac80211.c:3545, the MAC for cipher types CCMP/GCMP doesn't set IEEE80211_KEY_FLAG_PUT_IV_SPACE for gen2 NICs. This causes all the AMSDU data to be corrupted with cipher enabled. 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-05iwlwifi: pcie: set cmd_len in the correct placeSara Sharon1-12/+12
[ Upstream commit 956343a61226e1af3d146386f70a059feb567d0c ] command len is set too early in the code, since when building AMSDU, the size changes. This causes the byte count table to have the wrong size. Fixes: a0ec0169b7a9 ("iwlwifi: support new tx api") Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-05iwlwifi: pcie: fix erroneous printSara Sharon1-5/+5
[ Upstream commit 0916224eaa77bff0fbbc747961d550ff8db45457 ] When removing the driver, the following flow can happen: 1. host command is in progress, for example at index 68. 2. RX interrupt is received with the response. 3. Before it is processed, the remove flow kicks in, and calls iwl_pcie_txq_unmap. The function cleans all DMA, and promotes the read pointer to 69. 4. RX thread proceeds with the processing, and is calling iwl_pcie_cmdq_reclaim, which will print this error: iwl_pcie_cmdq_reclaim: Read index for DMA queue txq id (0), index 4 is out of range [0-256] 69 69. Detect this situation, and avoid the print. Change it to warning while at it, to make such issues more noticeable in the future. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-05iwlwifi: mvm: force TCM re-evaluation on TCM resumeAvraham Stern1-0/+14
[ Upstream commit 7bc2468277033e05401d5f8fd48a772f407338c2 ] When traffic load is not low or low latency is active, TCM schedules re-evaluation work so in case traffic stops TCM will detect that traffic load has become low or that low latency is no longer active. However, if TCM is paused when the re-evaluation work runs, it does not re-evaluate and the re-evaluation work is no longer scheduled. As a result, TCM will not indicate that low latency is no longer active or that traffic load is low when traffic stops. Fix this by forcing TCM re-evaluation when TCM is resumed in case low latency is active or traffic load is not low. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-05iwlwifi: move iwl_nvm_check_version() into dvmLuca Coelho4-23/+22
[ Upstream commit 64866e5da1eabd0c52ff45029b245f5465920031 ] This function is only half-used by mvm (i.e. only the nvm_version part matters, since the calibration version is irrelevant), so it's pointless to export it from iwlwifi. If mvm uses this function, it has the additional complexity of setting the calib version to a bogus value on all cfg structs. To avoid this, move the function to dvm and make a simple comparison of the nvm_version in mvm instead. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-24iwlwifi: mvm: don't send keys when entering D3Sara Sharon1-1/+3
[ Upstream commit 8c7fd6a365eb5b2647b2c01918730d0a485b9f85 ] In the past, we needed to program the keys when entering D3. This was since we replaced the image. However, now that there is a single image, this is no longer needed. Note that RSC is sent separately in a new command. This solves issues with newer devices that support PN offload. Since driver re-sent the keys, the PN got zeroed and the receiver dropped the next packets, until PN caught up again. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20iwlwifi: mvm: Allow TKIP for AP modeIlan Peer1-4/+0
[ Upstream commit 6f3df8c1192c873a6ad9a76328920f6f85af90a8 ] Support for setting keys for TKIP cipher suite was mistakenly removed for AP mode. Fix this. Fixes: 85aeb58cec1a ("iwlwifi: mvm: Enable security on new TX API") Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20iwlwifi: mvm: use correct FIFO lengthSara Sharon2-15/+36
[ Upstream commit 7126b6f2bbdf8e25f85e7ca6d91d49ea4ce9f6a6 ] Current FIFO size calculation is wrong for two reasons: - We access lmac 0 by default - We don't take 11ax into consideration. Fix both. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20iwlwifi: pcie: fit reclaim msg to MAX_MSG_LENGolan Ben Ami1-1/+1
[ Upstream commit 81f0c66187e1ebb7b63529d82faf7ff1e0ef428a ] Today, the length of a debug message in iwl_trans_pcie_reclaim may pass the MAX_MSG_LEN, which is 110. An example for this kind of message is: 'iwl_trans_pcie_reclaim: Read index for DMA queue txq id (2), last_to_free 65535 is out of range [0-65536] 2 2.' Cut the message a bit so it will fit the allowed MAX_MSG_LEN. Signed-off-by: Golan Ben Ami <golan.ben.ami@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20iwlwifi: pcie: gen2: build A-MSDU only for GSOJohannes Berg1-1/+6
[ Upstream commit 53f474e6a8d74d5dc0c3a015d889471f9a157685 ] If the incoming frame should be an A-MSDU, it may already be one, for example in the case of NAN multicast being encapsulated in an A-MSDU. Thus, use the GSO algorithm to build A-MSDU only if the skb actually contains GSO data. Fixes: 6ffe5de35b05 ("iwlwifi: pcie: add AMSDU to gen2") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20iwlwifi: api: annotate compressed BA notif array sizesJohannes Berg1-3/+3
[ Upstream commit 6f68cc367ab6578a33cca21b6056804165621f00 ] Annotate the compressed BA notification array sizes and make both of them 0-length since the length of 1 is just confusing - it may be different than that and the offset to the second one needs to be calculated in the C code anyhow. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20iwlwifi: pcie: read correct prph address for newer devicesSara Sharon1-2/+14
[ Upstream commit 84fb372c892e231e9a2ffdaa5c2df52d94aa536c ] For newer devices we have higher range of periphery addresses. Currently it is masked out, so we end up reading another address. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20iwlwifi: fix non_shared_ant for 22000 devicesErel Geron1-1/+1
[ Upstream commit a40287727d9b737e183959fd31a4e0c55f312853 ] The non-shared antenna was wrong for 22000 device series. Fix it to ANT_B for correct antenna preference by coex in MVM driver. Fixes: e34d975e40ff ("iwlwifi: Add a000 HW family support") Signed-off-by: Erel Geron <erelx.geron@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20iwlwifi: dbg: don't crash if the firmware crashes in the middle of a debug dumpEmmanuel Grumbach1-1/+1
[ Upstream commit 79f25b10c9da3dbc953e47033d0494e51580ac3b ] We can dump data from the firmware either when it crashes, or when the firmware is alive. Not all the data is available if the firmware is running (like the Tx / Rx FIFOs which are available only when the firmware is halted), so we first check that the firmware is alive to compute the required size for the dump and then fill the buffer with the data. When we allocate the buffer, we test the STATUS_FW_ERROR bit to check if the firmware is alive or not. This bit can be changed during the course of the dump since it is modified in the interrupt handler. We hit a case where we allocate the buffer while the firmware is sill working, and while we start to fill the buffer, the firmware crashes. Then we test STATUS_FW_ERROR again and decide to fill the buffer with data like the FIFOs even if no room was allocated for this data in the buffer. This means that we overflow the buffer that was allocated leading to memory corruption. To fix this, test the STATUS_FW_ERROR bit only once and rely on local variables to check if we should dump fifos or other firmware components. Fixes: 04fd2c28226f ("iwlwifi: mvm: add rxf and txf to dump data") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20iwlwifi: mvm: avoid sending too many BARsSara Sharon1-0/+8
[ Upstream commit 1a19c139be18ed4d6d681049cc48586fae070120 ] When we receive TX response, we may release a few packets due to a hole that was closed in the transmission window. However, if that frame failed, we will mark all the released frames as failed and will send multiple BARs. This affects statistics badly, and cause unnecessary frames transmission. Instead, mark all the following packets as success, with the desired result of sending a bar for the failed frame only. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20iwlwifi: don't WARN on trying to dump dead firmwareJohannes Berg1-4/+3
[ Upstream commit 84f260251ed8153e84c64eb2c5278ab18d3ddef6 ] There's no point in warning here, the user will just get an error back to the debugfs file write, and warning just makes it seem like there's an internal consistency problem when in reality the user just happened to hit this at a bad time. Remove the warning. Fixes: f45f979dc208 ("iwlwifi: mvm: disable dbg data collect when fw isn't alive") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20iwlwifi: drop packets with bad status in CDSara Sharon4-62/+70
[ Upstream commit 7891965d74bc48fb42b5068033192f97c9aa2090 ] We need to drop packets with errors (such as replay, MIC, ICV, conversion, duplicate and so on). Drop invalid packets, put the status bits in the metadata and move the enum definition to the correct place (FW API header). Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-06iwlwifi: exclude GEO SAR support for 3168Luca Coelho1-7/+9
[ Upstream commit 12e36d98d3e5acf5fc57774e0a15906d55f30cb9 ] We currently support two NICs in FW version 29, namely 7265D and 3168. Out of these, only 7265D supports GEO SAR, so adjust the function that checks for it accordingly. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Fixes: f5a47fae6aa3 ("iwlwifi: mvm: fix version check for GEO_TX_POWER_LIMIT support") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-05iwlwifi: fw: don't send GEO_TX_POWER_LIMIT command to FW version 36Luca Coelho1-3/+5
commit fddbfeece9c7882cc47754c7da460fe427e3e85b upstream. The intention was to have the GEO_TX_POWER_LIMIT command in FW version 36 as well, but not all 8000 family got this feature enabled. The 8000 family is the only one using version 36, so skip this version entirely. If we try to send this command to the firmwares that do not support it, we get a BAD_COMMAND response from the firmware. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=204151. Cc: stable@vger.kernel.org # 4.19+ Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-01iwlwifi: mvm: always init rs_fw with 20MHz bandwidth ratesNaftali Goldstein3-4/+5
commit 2859de7637b541dc7191f4d3fce4a1adba80fb3e upstream. As with the non-offloaded rs case, during assoc on the ap side the phy context is set to 20MHz until authorization of a client that supports wider channel-widths. Support this by sending the initial tlc_config_cmd with max supported channel width of 20MHz until authorization succeeds. Fixes: 6b7a5aea71b3 ("iwlwifi: mvm: always init rs with 20mhz bandwidth rates") Signed-off-by: Naftali Goldstein <naftali.goldstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-01iwlwifi: mvm: send BCAST management frames to the right stationEmmanuel Grumbach1-1/+1
commit 65c3b582ecab7a403efdf08babbf87fdbe27369c upstream. Probe responses were sent to the multicast station while they should be routed to the broadcast station. This has no negative effect since the frame was still routed to the right queue, but it looked very fishy to send a frame to a (queue, station) tuple where 'queue' is not mapped to 'station'. Fixes: 7c305de2b954 ("iwlwifi: mvm: Direct multicast frames to the correct station") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-16iwlwifi: add new card for 9260 seriesIhab Zhaika1-0/+1
[ Upstream commit 3941310cf665b8a7965424d2a185c80782faa030 ] Add one PCI ID for 9260 series. CC: <stable@vger.kernel.org> # 4.14+ Signed-off-by: Ihab Zhaika <ihab.zhaika@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-09-16iwlwifi: fix devices with PCI Device ID 0x34F0 and 11ac RF modulesLuca Coelho3-32/+97
[ Upstream commit ab27926d9e4ae23df4f4d98e31f067c8b486bb4f ] The devices with PCI device ID 0x34F0 are part of the SoC and can be combined with some different external RF modules. The configuration for these devices should reflect that, but are currently mixed up. To avoid confusion with discrete devices, add part of the firmware to be used and the official name of the device to the cfg structs. This is least reorganization possible (without messing things even more) that could be done as a bugfix for this SoC. Further reorganization of this code will be done separately. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-08-16iwlwifi: mvm: fix version check for GEO_TX_POWER_LIMIT supportLuca Coelho1-2/+7
commit f5a47fae6aa3eb06f100e701d2342ee56b857bee upstream. We erroneously added a check for FW API version 41 before sending GEO_TX_POWER_LIMIT, but this was already implemented in version 38. Additionally, it was cherry-picked to older versions, namely 17, 26 and 29, so check for those as well. Cc: stable@vger.kernel.org Fixes: eca1e56ceedd ("iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT to old firmwares") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-16iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT on version < 41Luca Coelho1-7/+15
commit 39bd984c203e86f3109b49c2a2e20677c4d3ab65 upstream. Firmware versions before 41 don't support the GEO_TX_POWER_LIMIT command, and sending it to the firmware will cause a firmware crash. We allow this via debugfs, so we need to return an error value in case it's not supported. This had already been fixed during init, when we send the command if the ACPI WGDS table is present. Fix it also for the other, userspace-triggered case. Cc: stable@vger.kernel.org Fixes: 7fe90e0e3d60 ("iwlwifi: mvm: refactor geo init") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-16iwlwifi: mvm: fix an out-of-bound accessEmmanuel Grumbach1-1/+1
commit ba3224db78034435e9ff0247277cce7c7bb1756c upstream. The index for the elements of the ACPI object we dereference was static. This means that if we called the function twice we wouldn't start from 3 again, but rather from the latest index we reached in the previous call. This was dutifully reported by KASAN. Fix this. Cc: stable@vger.kernel.org Fixes: 6996490501ed ("iwlwifi: mvm: add support for EWRD (Dynamic SAR) ACPI table") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-16iwlwifi: don't unmap as page memory that was mapped as singleEmmanuel Grumbach1-0/+2
commit 87e7e25aee6b59fef740856f4e86d4b60496c9e1 upstream. In order to remember how to unmap a memory (as single or as page), we maintain a bit per Transmit Buffer (TBs) in the meta data (structure iwl_cmd_meta). We maintain a bitmap: 1 bit per TB. If the TB is set, we will free the memory as a page. This bitmap was never cleared. Fix this. Cc: stable@vger.kernel.org Fixes: 3cd1980b0cdf ("iwlwifi: pcie: introduce new tfd and tb formats") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-26iwlwifi: fix RF-Kill interrupt while FW load for gen2 devicesEmmanuel Grumbach5-2/+43
commit ed3e4c6d3cd8f093a3636cb05492429fe2af228d upstream. Newest devices have a new firmware load mechanism. This mechanism is called the context info. It means that the driver doesn't need to load the sections of the firmware. The driver rather prepares a place in DRAM, with pointers to the relevant sections of the firmware, and the firmware loads itself. At the end of the process, the firmware sends the ALIVE interrupt. This is different from the previous scheme in which the driver expected the FH_TX interrupt after each section being transferred over the DMA. In order to support this new flow, we enabled all the interrupts. This broke the assumption that we have in the code that the RF-Kill interrupt can't interrupt the firmware load flow. Change the context info flow to enable only the ALIVE interrupt, and re-enable all the other interrupts only after the firmware is alive. Then, we won't see the RF-Kill interrupt until then. Getting the RF-Kill interrupt while loading the firmware made us kill the firmware while it is loading and we ended up dumping garbage instead of the firmware state. Re-enable the ALIVE | RX interrupts from the ISR when we get the ALIVE interrupt to be able to get the RX interrupt that comes immediately afterwards for the ALIVE notification. This is needed for non MSI-X only. Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-26iwlwifi: don't WARN when calling iwl_get_shared_mem_conf with RF-KillEmmanuel Grumbach1-3/+9
commit 0d53cfd0cca3c729a089c39eef0e7d8ae7662974 upstream. iwl_mvm_send_cmd returns 0 when the command won't be sent because RF-Kill is asserted. Do the same when we call iwl_get_shared_mem_conf since it is not sent through iwl_mvm_send_cmd but directly calls the transport layer. Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-26iwlwifi: pcie: fix ALIVE interrupt handling for gen2 devices w/o MSI-XEmmanuel Grumbach1-18/+16
commit ec46ae30245ecb41d73f8254613db07c653fb498 upstream. We added code to restock the buffer upon ALIVE interrupt when MSI-X is disabled. This was added as part of the context info code. This code was added only if the ISR debug level is set which is very unlikely to be related. Move this code to run even when the ISR debug level is not set. Note that gen2 devices work with MSI-X in most cases so that this path is seldom used. Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-08 22:30:36 +0300