An error occurred fetching the project authors.
- 07 Dec, 2021 1 commit
-
-
Johannes Berg authored
If we happen to decide an NSSN queue sync (IWL_MVM_RXQ_NSSN_SYNC) for some remaining packets that are still on the queue, but just after we've decided to do a delBA (which causes its own queues sync with IWL_MVM_RXQ_NOTIF_DEL_BA) we can end up with a sequence of events like this: CPU 1 CPU 2 remove BA session with baid N send IWL_MVM_RXQ_NOTIF_DEL_BA send IWL_MVM_RXQ_NSSN_SYNC get IWL_MVM_RXQ_NOTIF_DEL_BA get IWL_MVM_RXQ_NOTIF_DEL_BA get IWL_MVM_RXQ_NSSN_SYNC complete IWL_MVM_RXQ_NOTIF_DEL_BA remove N from baid_map[] get IWL_MVM_RXQ_NSSN_SYNC WARN_ON(!baid_map[N]) Thus, there's a race that leads in hitting the WARN_ON, but more importantly, it's a race that potentially even results in a new aggregation session getting assigned to baid N. To fix this, remove the WARN_ON() in the NSSN_SYNC case, we can't completely protect against hitting this case, so we shouldn't be warning. However, guard ourselves against BAID reuse by doing yet another round of queue synchronization after the entry is removed from the baid_map, so that it cannot be reused with any in-flight IWL_MVM_RXQ_NSSN_SYNC messages. 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.20211204083237.44abbbc50f40.I5492600dfe513356555abe2d7df0e2835846e3d8@changeidSigned-off-by:
-
- 22 Oct, 2021 4 commits
-
-
Luca Coelho authored
Remove the unused csi parameter from iwl_mvm_pass_packet_to_mac80211(). It is not used anymore, but was accidentally left in. Signed-off-by:
-
Luca Coelho authored
As part of the new rate_n_flags this two APIs may use the new rate. Add support for the new rate. These two APIs were updated in one patch because both of them are using the same functions which were changed. Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by:
-
Miri Korenblit authored
As a part of preparing to the new rate & flags version Update the relevant definitions and use them. Signed-off-by:
-
Miri Korenblit authored
Since antenna c is not in use and won't be relevant after the new rate & flags, remove all it's references Signed-off-by:
-
- 26 Aug, 2021 2 commits
-
-
Johannes Berg authored
To check beacon protection had a mismatch of the key ID we currently use the key ID from the firmware, but firmware side we want to clean up the API to stop reporting this. Instead, check the IWL_RX_MPDU_STATUS_KEY_VALID bit that indicates that the firmware used the correct key, and if that's set but we get invalid MIC/replay use the key ID from the frame to look up the key and notify mac80211 of MIC error or replay. Since both keys must have the same cipher and thus MIC length, we can use either of them to look up the MIC length. Signed-off-by:
-
Avraham Stern authored
When a station is removed, the driver-mac80211 station mapping is removed before the station is actually deleted from the FW. As a result, it is reasonable that the FW will continue to pass frames although the driver doesn't have a station for them anymore. Thus change the message severity level from ERR to DEBUG_DROP. Signed-off-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
-
- 22 Jun, 2021 1 commit
-
-
Johannes Berg authored
We don't fill in phy_data.d1 in no-data RX, and thus we pretend some data is actually filled in radiotap when it isn't or has default (zero) values. Fill in phy_data.d1 appropriately, and while at it also move the info_type initialization into the initializer. Signed-off-by:
-
- 14 Apr, 2021 1 commit
-
-
Johannes Berg authored
When we do queue sync, it's confusing that we have the structures declared in the FW API header files that aren't really firmware, and the union is also confusing - especially now in the code that checks the size on the return. So rework this: change the type of sync and whether to do it in a synchronous fashion to arguments, and build the data structure in the function, so we don't need the union. Signed-off-by:
-
- 06 Apr, 2021 1 commit
-
-
Johannes Berg authored
Unfortunately, since beacon protection isn't fully available yet, we didn't notice that there are problems with it and that the replay detection isn't working correctly. We were relying only on mac80211, since iwl_mvm_rx_crypto() exits when !ieee80211_has_protected(), which is of course true for protected (but not encrypted) management frames. Fix this to properly detect protected (but not encrypted) management frames and handle them - we continue to only care about beacons since for others everything can and will be checked in mac80211. Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.23c990843369.I09c262a8f6f9852cc8f513cdcb31a7f8f87dd8af@changeid
-
- 05 Feb, 2021 3 commits
-
-
Emmanuel Grumbach authored
Once the all the stations completed the switch, we need to clear csa_tx_blocked_vif. This was missing. We also need to re-enable the broadcast / multicast stations. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Johannes Berg authored
If the firmware has support, then advertise it to the stack and send the key down. Since we re-check the protection in the host anyway, we don't really need to do anything on RX except that we should drop frames that the firmware _knows_ are replay errors, since beacon filtering might otherwise result in replays being possible. Signed-off-by:
-
Johannes Berg authored
Some notifications aren't handled by the general RX handler code, due to multi-queue. Add size checks for them explicitly. Signed-off-by:
-
- 11 Dec, 2020 1 commit
-
-
Gustavo A. R. Silva authored
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly using the fallthrough pseudo-keyword as a replacement for a number of "fall through" markings. Notice that Clang doesn't recognize "fall through" comments as implicit fall-through. Link: https://github.com/KSPP/linux/issues/115Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
- 09 Dec, 2020 7 commits
-
-
Johannes Berg authored
Previously, we added checks that the contained MPDU size is long enough, but really we should also check that the notification itself fits into the data. Add some checks for that. Also add unlikely() annotations on the previously added checks. Signed-off-by:
-
Johannes Berg authored
We send some data to the firmware and expect to get it back, but we shouldn't really trust the firmware on this. Check the size of all the data we send down to avoid using bad or just uninitialized data when the firmware doesn't respond right. Signed-off-by:
-
Johannes Berg authored
Use SPDX tags instead of the long copyright notices. Also cleanup some duplicate copyright notices and combine the years where possible. Signed-off-by:
-
Johannes Berg authored
We're currently doing accounting on the queue sync with an atomic variable that counts down the number of remaining notifications that we still need. As we've been hitting issues in this area, modify this to track a bitmap of queues, not just the number of queues, and print out the remaining bitmap in the warning. Signed-off-by:
-
Johannes Berg authored
The argument type to iwl_mvm_notify_rx_queue() is currently just a u8 *, but that's misleading because we actually need the inner data to be of type struct iwl_mvm_internal_rxq_notif, because we interpret it when we get it back from the device (to check the sync bool and possibly the cookie.) Therefore, clear up any potential confusion and require that the data passed is of type struct iwl_mvm_internal_rxq_notif *. Also, while at it, rename the "count" to "notif_size" as "count" doesn't really clearly say what it's counting. Signed-off-by:
-
Johannes Berg authored
The MPDU contained in a notification shouldn't be larger than the notification size itself is, validate this. Reported-by:
Haggai Abramovsky <haggai.abramovsky@intel.com> Signed-off-by:
-
Luca Coelho authored
Add support to the 6GHz band (aka. Ultra High Band or UHB). This allows us to scan and connect to channels in that band, including all the relevant features, such as preferred scan channels, colocated channels etc. Co-developed-by:
Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
Tova Mussai <tova.mussai@intel.com> Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by:
Tali Levi Rovinsky <Tali.Levi-rovinsky@intel.com> Signed-off-by:
Ayala Beker <ayala.beker@intel.com> Signed-off-by:
-
- 08 Oct, 2020 1 commit
-
-
Nathan Errera authored
FW is changing the max number of supported stations. To adapt to the change we get the max number from the TLV and act according to the new number. Signed-off-by:
Nathan Errera <nathan.errera@intel.com> Signed-off-by:
-
- 01 Oct, 2020 2 commits
-
-
Johannes Berg authored
There are some bits declared here that simply don't exist in the firmware, and some are missing (e.g. the key) from what the firmware has. Align this and move all the fields into a single one for this status word, which makes this a bit easier. Signed-off-by:
-
Johannes Berg authored
On newer hardware, we have the full checksum, so use it to report CHECKSUM_COMPLETE and avoid the protocol specific hardware parsing. Note that the hardware already parses/removes the SNAP header, so we actually literally get what we need to report to the stack, as we're expected to checksum everything after the L2 header (which is translated/added by mac80211). Signed-off-by:
-
- 22 Jan, 2020 1 commit
-
-
Emmanuel Grumbach authored
The purpose of this was to keep all the queues updated with the Rx sequence numbers because unlikely yet possible situations where queues can't understand if a specific packet needs to be dropped or not. Unfortunately, it was reported that this caused issues in our DMA engine. We don't fully understand how this is related, but this is being currently debugged. For now, just don't send this notification to the Rx queues. This de-facto reverts my commit 3c514bf8: iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues This issue was reported here: https://bugzilla.kernel.org/show_bug.cgi?id=204873 https://bugzilla.kernel.org/show_bug.cgi?id=205001 and others maybe. Fixes: 3c514bf8 ("iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues") CC: <stable@vger.kernel.org> # 5.3+ Signed-off-by:
-
- 20 Nov, 2019 1 commit
-
-
Johannes Berg authored
This email alias (ilw@linux.intel.com) hasn't been functional for probably closer to a decade than not, remove it. It's not really clear to me how this ended up in new code though. Signed-off-by:
-
- 15 Nov, 2019 1 commit
-
-
Johannes Berg authored
This is dead code, nothing uses the IWL_DEVICE_22560 macro and thus nothing every uses IWL_DEVICE_FAMILY_22560. Remove it all. While at it, remove some code and definitions used only in this case, and clean up some comments/names that still refer to it. Signed-off-by:
-
- 25 Oct, 2019 1 commit
-
-
Tova Mussai authored
The FW introduce new API to get the band from the rx mpdu, use this new API. Signed-off-by:
-
- 06 Sep, 2019 5 commits
-
-
Emmanuel Grumbach authored
Sometimes the firmware won't be able to decrypt frames because the keys were not installed yet or other scenarios. The firmware will soon stop dropping multicast frames when MAC_FILTER_ACCEPT_GRP is not set. The firmware will simply always pass multicast frame in. In order to avoid logging any such frame coming in when we don't have the keys, drop the print. Signed-off-by:
-
Johannes Berg authored
In prior hardware generations (e.g. 9000 series), we received the BAR frame with fake NSSN information to handle releasing frames from the reorder buffer for the default queue, the other queues were getting the FRAME_RELEASE notification in this case. With multi-TID block-ack, the firmware no longer sends us the BAR frame because the fake RX is quite big (just the metadata is around 48 bytes or so). Instead, it now sends us one (or multiple) special release notifications (0xc2). The hardware consumes these as well, but only generates the FRAME_RELEASE (0xc3) for queues other than the default queue. We thus need to handle them in the same way we handle the normal FRAME_RELEASE. Signed-off-by:
-
Johannes Berg authored
Certain APs (I think a certain Broadcom model) interact badly with our full state BA bitmap handling, and if triggered badly with many powersave transitions they keep sending frames from before the window, which our hardware then doesn't appear to ACK (to them) since it has moved on and is sending ACKs for higher SNs now. Try to detect this situation and if this keeps happening, disable the aggregation session. Signed-off-by:
-
Luca Coelho authored
Add a pointer to the iwl_trans structure and point it to the trans part of the cfg. This is the first step in disassociating the trans configuration from the rest of the configuration. Signed-off-by: -
Luca Coelho authored
In order to be able to select the cfg depending on the HW revision or on the RF ID, we need to set up the trans before selecting the cfg. To do so, move the elements from cfg that are needed by iwl_trans_alloc() to a separate struct at the top of the cfg, so it can be used by other cfg types as well, before selecting the rest of the configuration. Signed-off-by:
-
- 30 Jul, 2019 4 commits
-
-
Emmanuel Grumbach authored
An earlier patch made sure that the queues are not lagging too far behind. This means that iwl_mvm_release_frames should not be called with a head_sn too far behind NSSN. Don't take the risk to change completely the entry condition to iwl_mvm_release_frames, but don't update the head_sn is the NSSN is more than 2048 packets ahead of us. Since this just cannot be right. This means that the scenario described here happened. We are queue 0. Q:0 Q:1 head_sn: 0 -> 2047 head_sn: 2048 Lots of packets arrive: head_sn: 2047 -> 2150 send NSSN_SYNC notification Handle notification from the firmware and do NOT move the head_sn back to 2048 Signed-off-by:
-
Emmanuel Grumbach authored
In order to support MSI-X efficiently, we want to avoid communication across Rx queues. Each Rx queue should have all the data it needs to process a packet. The reordering buffer is a challenge in the MSI-X world since we can have a single BA session whose packets are directed to different queues. This is why each queue has its own reordering buffer. The hardware is able to hint the driver whether we have a hole or not, which allows the driver to know whether it can release a packet or not. This indication is called NSSN. Roughly, if the packet's SN is lower than the NSSN, we can release the packet to the stack. The NSSN is the SN of the newest packet received without any holes + 1. This is working as long as we don't have packets that we release because of a timeout. When that happens, we could have taken the decision to release a packet after we have been waiting for its predecessor for too long. If this predecessor comes later, we have to drop it because we can't release packets out of order. In that case, the hardware will give us an indication that we can we release the packet (SN < NSSN), but the packet still needs to be dropped. This is why we sometimes need to ignore the NSSN and we track the head_sn in software. Here is a specific example of this: 1) Rx queue 1 got packets: 480, 482, 483 2) We release 480 to to the stack and wait for 481 3) NSSN is now 481 4) The timeout expires 5) We release 482 and 483, NSSN is still 480 6) 481 arrives its NSSN is 484. We need to drop 481 even if 481 < 484. This is why we'll update the head_sn to 484 at step 2. The flow now is: 1) Rx queue 1 got packets: 480, 482, 483 2) We release 480 to to the stack and wait for 481 3) NSSN is now 481 / head_sn is 481 4) The timeout expires 5) We release 482 and 483, NSSN is still 480 but head_sn is 484. 6) 481 arrives its NSSN is 484, but head_sn is 484 and we drop it. This code introduces another problem in case all the traffic goes well (no hole, no timeout): Rx queue 1: 0 -> 483 (head_sn = 484) Rx queue 2: 501 -> 4095 (head_sn = 0) Rx queue 2: 0 -> 480 (head_sn = 481) Rx queue 1: 481 but head_sn = 484 and we drop it. At this point, the SN of queue 1 is far behind: more than 4040 packets behind. Queue 1 will consider 481 "old" because 481 is in [501-64:501] whereas it is a very new packet. In order to fix that, send an Rx notification from time to time (twice across the full set of 4096 packets) to make sure no Rx queue is lagging too far behind. What will happen then is: Rx queue 1: 0 -> 483 (head_sn = 484) Rx queue 2: 501 -> 2047 (head_sn = 2048) Rx queue 1: Sync nofication (head_sn = 2048) Rx queue 2: 2048 -> 4095 (head_sn = 0) Rx queue 1: Sync notification (head_sn = 0) Rx queue 2: 1 -> 481 (head_sn = 482) Rx queue 1: 481 and head_sn = 0. In queue 1's data, head_sn is now 0, the packet coming in is 481, it'll understand that the new packet is new and it won't be dropped. Signed-off-by:
-
Emmanuel Grumbach authored
Instead of allocating memory for which we have an upper limit, use a small buffer on stack. Signed-off-by:
-
Emmanuel Grumbach authored
We will soon be using a new notification that will be initiated by the driver, sent to the firmware and sent back to all the RSS queues by the firmware. This new notification will be useful to synchronize the NSSN across all the queues. For now, don't send the notification, just add the code to handle it. Later patch will add the code to actually send it. While at it, validate the baid coming from the firmware to avoid accessing an array with a bad index in the driver. Signed-off-by:
-
- 22 Jun, 2019 1 commit
-
-
Jason A. Donenfeld authored
This makes boot uniformly boottime and tai uniformly clocktai, to address the remaining oversights. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lkml.kernel.org/r/20190621203249.3909-2-Jason@zx2c4.com
-
- 28 Apr, 2019 1 commit
-
-
Luca Coelho authored
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:
-
- 22 Mar, 2019 1 commit
-
-
Johannes Berg authored
Report all NO_DATA events to mac80211 so they get captured in radiotap for usage in sniffer scenarios; map the info type to a reasonable radiotap type for this. Signed-off-by:
-
