summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/intel/iwlwifi
AgeCommit message (Collapse)AuthorFilesLines
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>
2019-07-26iwlwifi: pcie: don't service an interrupt that was maskedEmmanuel Grumbach1-6/+21
commit 3b57a10ca14c619707398dc58fe5ece18c95b20b upstream. Sometimes the register status can include interrupts that were masked. We can, for example, get the RF-Kill bit set in the interrupt status register although this interrupt was masked. Then if we get the ALIVE interrupt (for example) that was not masked, we need to *not* service the RF-Kill interrupt. Fix this in the MSI-X interrupt handler. 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: mvm: Drop large non sta framesAndrei Otcheretianski1-0/+3
[ Upstream commit ac70499ee97231a418dc1a4d6c9dc102e8f64631 ] In some buggy scenarios we could possible attempt to transmit frames larger than maximum MSDU size. Since our devices don't know how to handle this, it may result in asserts, hangs etc. This can happen, for example, when we receive a large multicast frame and try to transmit it back to the air in AP mode. Since in a legal scenario this should never happen, drop such frames and warn about it. 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-07-14iwlwifi: Fix double-free problems in iwl_req_fw_callback()Jia-Ju Bai1-1/+0
[ Upstream commit a8627176b0de7ba3f4524f641ddff4abf23ae4e4 ] In the error handling code of iwl_req_fw_callback(), iwl_dealloc_ucode() is called to free data. In iwl_drv_stop(), iwl_dealloc_ucode() is called again, which can cause double-free problems. To fix this bug, the call to iwl_dealloc_ucode() in iwl_req_fw_callback() is deleted. This bug is found by a runtime fuzzing tool named FIZZER written by us. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.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-05-31iwlwifi: pcie: don't crash on invalid RX interruptJohannes Berg1-1/+6
[ Upstream commit 30f24eabab8cd801064c5c37589d803cb4341929 ] If for some reason the device gives us an RX interrupt before we're ready for it, perhaps during device power-on with misconfigured IRQ causes mapping or so, we can crash trying to access the queues. Prevent that by checking that we actually have RXQs and that they were properly allocated. 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-05-25iwlwifi: mvm: check for length correctness in iwl_mvm_create_skb()Luca Coelho1-4/+24
[ Upstream commit de1887c064b9996ac03120d90d0a909a3f678f98 ] We don't check for the validity of the lengths in the packet received from the firmware. If the MPDU length received in the rx descriptor is too short to contain the header length and the crypt length together, we may end up trying to copy a negative number of bytes (headlen - hdrlen < 0) which will underflow and cause us to try to copy a huge amount of data. This causes oopses such as this one: BUG: unable to handle kernel paging request at ffff896be2970000 PGD 5e201067 P4D 5e201067 PUD 5e205067 PMD 16110d063 PTE 8000000162970161 Oops: 0003 [#1] PREEMPT SMP NOPTI CPU: 2 PID: 1824 Comm: irq/134-iwlwifi Not tainted 4.19.33-04308-geea41cf4930f #1 Hardware name: [...] RIP: 0010:memcpy_erms+0x6/0x10 Code: 90 90 90 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe RSP: 0018:ffffa4630196fc60 EFLAGS: 00010287 RAX: ffff896be2924618 RBX: ffff896bc8ecc600 RCX: 00000000fffb4610 RDX: 00000000fffffff8 RSI: ffff896a835e2a38 RDI: ffff896be2970000 RBP: ffffa4630196fd30 R08: ffff896bc8ecc600 R09: ffff896a83597000 R10: ffff896bd6998400 R11: 000000000200407f R12: ffff896a83597050 R13: 00000000fffffff8 R14: 0000000000000010 R15: ffff896a83597038 FS: 0000000000000000(0000) GS:ffff896be8280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff896be2970000 CR3: 000000005dc12002 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iwl_mvm_rx_mpdu_mq+0xb51/0x121b [iwlmvm] iwl_pcie_rx_handle+0x58c/0xa89 [iwlwifi] iwl_pcie_irq_rx_msix_handler+0xd9/0x12a [iwlwifi] irq_thread_fn+0x24/0x49 irq_thread+0xb0/0x122 kthread+0x138/0x140 ret_from_fork+0x1f/0x40 Fix that by checking the lengths for correctness and trigger a warning to show that we have received wrong data. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-08iwlwifi: fix driver operation for 5350Emmanuel Grumbach1-1/+2
commit 5c9adef9789148d382d7d1307c3d6bfaf51d143d upstream. We introduced a bug that prevented this old device from working. The driver would simply not be able to complete the INIT flow while spewing this warning: CSR addresses aren't configured WARNING: CPU: 0 PID: 819 at drivers/net/wireless/intel/iwlwifi/pcie/drv.c:917 iwl_pci_probe+0x160/0x1e0 [iwlwifi] Cc: stable@vger.kernel.org # v4.18+ Fixes: a8cbb46f831d ("iwlwifi: allow different csr flags for different device families") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Fixes: c8f1b51e506d ("iwlwifi: allow different csr flags for different device families") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-05iwlwifi: mvm: fix RFH config command with >=10 CPUsJohannes Berg1-6/+14
[ Upstream commit dbf592f3d14fb7d532cb7c820b1065cf33e02aaa ] If we have >=10 (logical) CPUs, our command size exceeds the internal buffer size and the command fails; fix that by using IWL_HCMD_DFL_NOCOPY for the command that's allocated anyway. While at it, also fix the leak of cmd, and use struct_size() to calculate its size. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: 8edbfaa19835 ("iwlwifi: mvm: configure multi RX queue") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-04-05iwlwifi: pcie: fix emergency pathSara Sharon1-3/+8
[ Upstream commit c6ac9f9fb98851f47b978a9476594fc3c477a34d ] Allocator swaps the pending requests with 0 when it starts working. This means that relying on it n RX path to decide if to move to emergency is not always a good idea, since it may be zero, but there are still a lot of unallocated RBs in the system. Change allocator to decrement the pending requests on real time. It is more expensive since it accesses the atomic variable more times, but it gives the RX path a better idea of the system's status. Reported-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Sara Sharon <sara.sharon@intel.com> Fixes: 868a1e863f95 ("iwlwifi: pcie: avoid empty free RB queue") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-02-12iwlwifi: mvm: fix setting HE ppe FW configNaftali Goldstein2-2/+8
[ Upstream commit 189b8d441b0f7825f0b4278851c52afaa0515ed2 ] The FW expects to get the ppe value for each NSS-BW pair in the same format as in the he phy capabilities IE, which means that a value of 0 implies ppe should be used for BPSK (mcs 0). If there are no PPE thresholds in the IE, or if for some NSS-RU pair there's no threshold set for it (this could happen because it's a variable-sized field), it means no PPE should not be used for that pair, so the value sent to FW should be 7 which corresponds to "none". Fixes: 514c30696fbc ("iwlwifi: add support for IEEE802.11ax") Signed-off-by: Naftali Goldstein <naftali.goldstein@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-02-12iwlwifi: fw: do not set sgi bits for HE connectionNaftali Goldstein1-0/+4
[ Upstream commit 5c2dbebb446539eb9640bf59a02756d6e7f1fc53 ] If the association supports HE, HT/VHT rates will never be used for Tx and therefore there's no need to set the sgi-per-channel-width-support bits, so don't set them in this case. Fixes: 110b32f065f3 ("iwlwifi: mvm: rs: add basic implementation of the new RS API handlers") 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>
2019-01-26iwlwifi: mvm: Send LQ command as async when necessaryAvraham Stern5-18/+17
commit 3baf7528d6f832b28622d1ddadd2e47f6c2b5e08 upstream. The parameter that indicated whether the LQ command should be sent as sync or async was removed, causing the LQ command to be sent as sync from interrupt context (e.g. from the RX path). This resulted in a kernel warning: "scheduling while atomic" and failing to send the LQ command, which ultimately leads to a queue hang. Fix it by adding back the required parameter to send the command as sync only when it is allowed. Fixes: d94c5a820d10 ("iwlwifi: mvm: open BA session only when sta is authorized") Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-29iwlwifi: add new cards for 9560, 9462, 9461 and killer seriesIhab Zhaika1-0/+50
commit f108703cb5f199d0fc98517ac29a997c4c646c94 upstream. add few PCI ID'S for 9560, 9462, 9461 and killer series. Cc: stable@vger.kernel.org Signed-off-by: Ihab Zhaika <ihab.zhaika@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-29iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT to old firmwaresEmmanuel Grumbach1-0/+9
commit eca1e56ceedd9cc185eb18baf307d3ff2e4af376 upstream. Old firmware versions don't support this command. Sending it to any firmware before -41.ucode will crash the firmware. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201975 Fixes: 66e839030fd6 ("iwlwifi: fix wrong WGDS_WIFI_DATA_SIZE") CC: <stable@vger.kernel.org> #4.19+ 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-01iwlwifi: mvm: don't use SAR Geo if basic SAR is not usedLuca Coelho1-8/+28
commit 5d041c46ccb9b48acc110e214beff5e2789311df upstream. We can't use SAR Geo if basic SAR is not enabled, since the SAR Geo tables define offsets in relation to the basic SAR table in use. To fix this, make iwl_mvm_sar_init() return one in case WRDS is not available, so we can skip reading WGDS entirely. Fixes: a6bff3cb19b7 ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for geographic tx power table") Cc: stable@vger.kernel.org # 4.12+ Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-01iwlwifi: mvm: fix regulatory domain update when the firmware startsEmmanuel Grumbach2-5/+8
commit 82715ac71e6b94a2c2136e31f3a8e6748e33aa8c upstream. When the firmware starts, it doesn't have any regulatory information, hence it uses the world wide limitations. The driver can feed the firmware with previous knowledge that was kept in the driver, but the firmware may still not update its internal tables. This happens when we start a BSS interface, and then the firmware can change the regulatory tables based on our location and it'll use more lenient, location specific rules. Then, if the firmware is shut down (when the interface is brought down), and then an AP interface is created, the firmware will forget the country specific rules. The host will think that we are in a certain country that may allow channels and will try to teach the firmware about our location, but the firmware may still not allow to drop the world wide limitations and apply country specific rules because it was just re-started. In this case, the firmware will reply with MCC_RESP_ILLEGAL to the MCC_UPDATE_CMD. In that case, iwlwifi needs to let the upper layers (cfg80211 / hostapd) know that the channel list they know about has been updated. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201105 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>
2018-12-01iwlwifi: mvm: support sta_statistics() even on older firmwareEmmanuel Grumbach1-4/+0
commit ec484d03ef0df8d34086b95710e355a259cbe1f2 upstream. The oldest firmware supported by iwlmvm do support getting the average beacon RSSI. Enable the sta_statistics() call from mac80211 even on older firmware versions. Fixes: 33cef9256342 ("iwlwifi: mvm: support beacon statistics for BSS client") Cc: stable@vger.kernel.org # 4.2+ 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>
2018-12-01iwlwifi: fix wrong WGDS_WIFI_DATA_SIZEMatt Chen2-2/+4
commit 66e839030fd698586734e017fd55c4f2a89dba0b upstream. From coreboot/BIOS: Name ("WGDS", Package() { Revision, Package() { DomainType, // 0x7:WiFi ==> We miss this one. WgdsWiFiSarDeltaGroup1PowerMax1, // Group 1 FCC 2400 Max WgdsWiFiSarDeltaGroup1PowerChainA1, // Group 1 FCC 2400 A Offset WgdsWiFiSarDeltaGroup1PowerChainB1, // Group 1 FCC 2400 B Offset WgdsWiFiSarDeltaGroup1PowerMax2, // Group 1 FCC 5200 Max WgdsWiFiSarDeltaGroup1PowerChainA2, // Group 1 FCC 5200 A Offset WgdsWiFiSarDeltaGroup1PowerChainB2, // Group 1 FCC 5200 B Offset WgdsWiFiSarDeltaGroup2PowerMax1, // Group 2 EC Jap 2400 Max WgdsWiFiSarDeltaGroup2PowerChainA1, // Group 2 EC Jap 2400 A Offset WgdsWiFiSarDeltaGroup2PowerChainB1, // Group 2 EC Jap 2400 B Offset WgdsWiFiSarDeltaGroup2PowerMax2, // Group 2 EC Jap 5200 Max WgdsWiFiSarDeltaGroup2PowerChainA2, // Group 2 EC Jap 5200 A Offset WgdsWiFiSarDeltaGroup2PowerChainB2, // Group 2 EC Jap 5200 B Offset WgdsWiFiSarDeltaGroup3PowerMax1, // Group 3 ROW 2400 Max WgdsWiFiSarDeltaGroup3PowerChainA1, // Group 3 ROW 2400 A Offset WgdsWiFiSarDeltaGroup3PowerChainB1, // Group 3 ROW 2400 B Offset WgdsWiFiSarDeltaGroup3PowerMax2, // Group 3 ROW 5200 Max WgdsWiFiSarDeltaGroup3PowerChainA2, // Group 3 ROW 5200 A Offset WgdsWiFiSarDeltaGroup3PowerChainB2, // Group 3 ROW 5200 B Offset } }) When read the ACPI data to find out the WGDS, the DATA_SIZE is never matched. From the above format, it gives 19 numbers, but our driver is hardcode as 18. Fix it to pass then can parse the data into our wgds table. Then we will see: iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init Sending GEO_TX_POWER_LIMIT iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[0] Band[0]: chain A = 68 chain B = 69 max_tx_power = 54 iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[0] Band[1]: chain A = 48 chain B = 49 max_tx_power = 70 iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[1] Band[0]: chain A = 51 chain B = 67 max_tx_power = 50 iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[1] Band[1]: chain A = 69 chain B = 70 max_tx_power = 68 iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[2] Band[0]: chain A = 49 chain B = 50 max_tx_power = 48 iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[2] Band[1]: chain A = 52 chain B = 53 max_tx_power = 51 Cc: stable@vger.kernel.org # 4.12+ Fixes: a6bff3cb19b7 ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for geographic tx power table") Signed-off-by: Matt Chen <matt.chen@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-13iwlwifi: mvm: check return value of rs_rate_from_ucode_rate()Luca Coelho1-5/+19
commit 3d71c3f1f50cf309bd20659422af549bc784bfff upstream. The rs_rate_from_ucode_rate() function may return -EINVAL if the rate is invalid, but none of the callsites check for the error, potentially making us access arrays with index IWL_RATE_INVALID, which is larger than the arrays, causing an out-of-bounds access. This will trigger KASAN warnings, such as the one reported in the bugzilla issue mentioned below. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=200659 Cc: stable@vger.kernel.org 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>
2018-11-13iwlwifi: mvm: fix BAR seq ctrl reportingSara Sharon1-4/+5
[ Upstream commit 941ab4eb66c10bc5c7234e83a7a858b2806ed151 ] There is a bug in FW where the sequence control may be incorrect, and the driver overrides it with the value of the ieee80211 header. However, in BAR there is no sequence control in the header, which result with arbitrary sequence. This access to an unknown location is bad and it makes the logs very confusing - so fix it. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-13iwlwifi: mvm: check for n_profiles validity in EWRD ACPILuca Coelho1-2/+6
[ Upstream commit 2e1976bb75263fbad918e82184b16a23bd721546 ] When reading the profiles from the EWRD table in ACPI, we loop over the data and set it into our internal table. We use the number of profiles specified in ACPI without checking its validity, so if the ACPI table is corrupted and the number is larger than our array size, we will try to make an out-of-bounds access. Fix this by making sure the value specified in the ACPI table is valid. Fixes: 6996490501ed ("iwlwifi: mvm: add support for EWRD (Dynamic SAR) ACPI table") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-13iwlwifi: mvm: clear HW_RESTART_REQUESTED when stopping the interfaceEmmanuel Grumbach1-3/+6
[ Upstream commit 155f7e0441cd121b1e673d465a35e99f4b9b2f0b ] Fix a bug that happens in the following scenario: 1) suspend without WoWLAN 2) mac80211 calls drv_stop because of the suspend 3) __iwl_mvm_mac_stop deallocates the aux station 4) during drv_stop the firmware crashes 5) iwlmvm: * sets IWL_MVM_STATUS_HW_RESTART_REQUESTED * asks mac80211 to kick the restart flow 6) mac80211 puts the restart worker into a freezable queue which means that the worker will not run for now since the workqueue is already frozen 7) ... 8) resume 9) mac80211 runs ieee80211_reconfig as part of the resume 10) mac80211 detects that a restart flow has been requested and that we are now resuming from suspend and cancels the restart worker 11) mac80211 calls drv_start() 12) __iwl_mvm_mac_start checks that IWL_MVM_STATUS_HW_RESTART_REQUESTED clears it, sets IWL_MVM_STATUS_IN_HW_RESTART and calls iwl_mvm_restart_cleanup() 13) iwl_fw_error_dump gets called and accesses the device to get debug data 14) iwl_mvm_up adds the aux station 15) iwl_mvm_add_aux_sta() allocates an internal station for the aux station 16) iwl_mvm_allocate_int_sta() tests IWL_MVM_STATUS_IN_HW_RESTART and doesn't really allocate a station ID for the aux station 17) a new queue is added for the aux station Note that steps from 5 to 9 aren't really part of the problem but were described for the sake of completeness. Once the iwl_mvm_mac_stop() is called, the device is not accessible, meaning that step 12) can't succeed and we'll see the following: drivers/net/wireless/intel/iwlwifi/pcie/trans.c:2122 iwl_trans_pcie_grab_nic_access+0xc0/0x1d6 [iwlwifi]() Timeout waiting for hardware access (CSR_GP_CNTRL 0x080403d8) Call Trace: [<ffffffffc03e6ad3>] iwl_trans_pcie_grab_nic_access+0xc0/0x1d6 [iwlwifi] [<ffffffffc03e6a13>] iwl_trans_pcie_dump_regs+0x3fd/0x3fd [iwlwifi] [<ffffffffc03dad42>] iwl_fw_error_dump+0x4f5/0xe8b [iwlwifi] [<ffffffffc04bd43e>] __iwl_mvm_mac_start+0x5a/0x21a [iwlmvm] [<ffffffffc04bd6d2>] iwl_mvm_mac_start+0xd4/0x103 [iwlmvm] [<ffffffffc042d378>] drv_start+0xa1/0xc5 [iwl7000_mac80211] [<ffffffffc045a339>] ieee80211_reconfig+0x145/0xf50 [mac80211] [<ffffffffc044788b>] ieee80211_resume+0x62/0x66 [mac80211] [<ffffffffc0366c5b>] wiphy_resume+0xa9/0xc6 [cfg80211] The station id of the aux station is set to 0xff in step 3 and because we don't really allocate a new station id for the auxliary station (as explained in 16), we end up sending a command to the firmware asking to connect the queue to station id 0xff. This makes the firmware crash with the following information: 0x00002093 | ADVANCED_SYSASSERT 0x000002F0 | trm_hw_status0 0x00000000 | trm_hw_status1 0x00000B38 | branchlink2 0x0001978C | interruptlink1 0x00000000 | interruptlink2 0xFF080501 | data1 0xDEADBEEF | data2 0xDEADBEEF | data3 Firmware error during reconfiguration - reprobe! FW error in SYNC CMD SCD_QUEUE_CFG Fix this by clearing IWL_MVM_STATUS_HW_RESTART_REQUESTED in iwl_mvm_mac_stop(). We won't be able to collect debug data anyway and when we will brought up again, we will have a clean state from the firmware perspective. Since we won't have IWL_MVM_STATUS_IN_HW_RESTART set in step 12) we won't get to the 2093 ASSERT either. Fixes: bf8b286f86fc ("iwlwifi: mvm: defer setting IWL_MVM_STATUS_IN_HW_RESTART") 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-13iwlwifi: pcie: avoid empty free RB queueShaul Triebitz1-11/+21
[ Upstream commit 868a1e863f95183f00809363fefba6d4f5bcd116 ] If all free RB queues are empty, the driver will never restock the free RB queue. That's because the restocking happens in the Rx flow, and if the free queue is empty there will be no Rx. Although there's a background worker (a.k.a. allocator) allocating memory for RBs so that the Rx handler can restock them, the worker may run only after the free queue has become empty (and then it is too late for restocking as explained above). There is a solution for that called 'emergency': If the number of used RB's reaches half the amount of all RB's, the Rx handler will not wait for the allocator but immediately allocate memory for the used RB's and restock the free queue. But, since the used RB's is per queue, it may happen that the used RB's are spread between the queues such that the emergency check will fail for each of the queues (and still run out of RBs, causing the above symptom). To fix it, move to emergency mode if the sum of *all* used RBs (for all Rx queues) reaches half the amount of all RB's Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-10-03Merge tag 'wireless-drivers-for-davem-2018-10-01' of ↵David S. Miller1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for 4.19 First, and also hopefully the last, set of fixes for 4.19. All small but still important fixes mt76x0 * fix a bug when a virtual interface is removed multiple times b43 * fix DMA error related regression with proprietary firmware iwlwifi * fix an oops which was a regression in v4.19-rc1 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-27 14:30:15 +0300