#
e78d7877 |
|
20-Mar-2024 |
Benjamin Berg <benjamin.berg@intel.com> |
wifi: iwlwifi: mvm: include link ID when releasing frames When releasing frames from the reorder buffer, the link ID was not included in the RX status information. This subsequently led mac80211 to drop the frame. Change it so that the link information is set immediately when possible so that it doesn't not need to be filled in anymore when submitting the frame to mac80211. Fixes: b8a85a1d42d7 ("wifi: iwlwifi: mvm: rxmq: report link ID to mac80211") Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Tested-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240320232419.bbbd5e9bfe80.Iec1bf5c884e371f7bc5ea2534ed9ea8d3f2c0bf6@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
c82a950f |
|
05-Feb-2024 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: mvm: don't do duplicate detection for nullfunc packets For non-QoS nullfunc packets we currently do the duplicate detection, which seems a bit wrong. Fix the code to check for _any_ instead of just _qos_ nullfunc. Also remove setting the RX_FLAG_DUP_VALIDATED flag, we haven't done anything here; in particular, we haven't checked for multicast in an MLO scenario. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240205211151.4fea3bd2d4a6.Ib80764f4581d875cff08469016894f7c817c3828@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
066425b6 |
|
05-Feb-2024 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: mvm: combine condition/warning WARN() returns the value of the condition, so it's nicer to combine the warning and the if. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240205211151.44f63334760e.If0a2cf347a8676a3830c5c3183a257fe11f31419@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
f4eedfd8 |
|
05-Feb-2024 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: mvm: expand queue sync warning messages It's a bit tricky to understand what's going on here, add more data to the warning messages to make that clearer. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240205211151.1df82a509636.I2f71811569a5c48eb166c4caa779af2d6160ad33@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
65d3333e |
|
29-Jan-2024 |
Daniel Gabay <daniel.gabay@intel.com> |
wifi: iwlwifi: mvm: log dropped packets due to MIC error When we drop frames due to MIC error we want to have something printed in the logger (this won't be printed by default). Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240129211905.41b0abbf1fd2.Ib6ec6a48ec7bebe769d1e1c1df96380a758a0975@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
91380f76 |
|
27-Jan-2024 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: mvm: report beacon protection failures Andrei reports that we just silently drop beacons after we report the key counters, but never report to userspace, so wpa_supplicant cannot send the WNM action frame. Fix that. Fixes: b1fdc2505abc ("iwlwifi: mvm: advertise BIGTK client support if available") Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240128084842.7d855442cdce.Iba90b26f893dc8c49bfb8be65373cd0a138af12c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
b7198383 |
|
06-Feb-2024 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
wifi: iwlwifi: mvm: fix a crash when we run out of stations A DoS tool that injects loads of authentication frames made our AP crash. The iwl_mvm_is_dup() function couldn't find the per-queue dup_data which was not allocated. The root cause for that is that we ran out of stations in the firmware and we didn't really add the station to the firmware, yet we didn't return an error to mac80211. Mac80211 was thinking that we have the station and because of that, sta_info::uploaded was set to 1. This allowed ieee80211_find_sta_by_ifaddr() to return a valid station object, but that ieee80211_sta didn't have any iwl_mvm_sta object initialized and that caused the crash mentioned earlier when we got Rx on that station. Cc: stable@vger.kernel.org Fixes: 57974a55d995 ("wifi: iwlwifi: mvm: refactor iwl_mvm_mac_sta_state_common()") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240206175739.1f76c44b2486.I6a00955e2842f15f0a089db2f834adb9d10fbe35@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
ff8e3a40 |
|
16-Oct-2023 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
wifi: iwlwifi: mvm: simplify the reorder buffer The firmware / hardware of devices supporting RSS is able to report duplicates and packets that time out inside the reoder buffer. We can now remove all the complex logic that was implemented to keep all the Rx queues more the less synchronized: we used to send a message to all the queues through the firmware to teach the different queues about what is the current SSN every 2048 packets. Now that we rely on the firmware / hardware to detect duplicates, we can completely remove the code that did that in the driver and it has been reported that this code was spuriously dropping legit packets. Suggested-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231017115047.54cf4d3d5956.Ic06a08c9fb1e1ec315a4b49d632b78b8474dab79@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
29fa9a98 |
|
16-Oct-2023 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
wifi: iwlwifi: disable multi rx queue for 9000 Multi rx queue allows to spread the load of the Rx streams on different CPUs. 9000 series required complex synchronization mechanisms from the driver side since the hardware / firmware is not able to provide information about duplicate packets and timeouts inside the reordering buffer. Users have complained that for newer devices, all those synchronization mechanisms have caused spurious packet drops. Those packet drops disappeared if we simplify the code, but unfortunately, we can't have RSS enabled on 9000 series without this complex code. Remove support for RSS on 9000 so that we can make the code much simpler for newer devices and fix the bugs for them. The down side of this patch is a that all the Rx path will be routed to a single CPU, but this has never been an issue, the modern CPUs are just fast enough to cope with all the traffic. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231017115047.2917eb8b7af9.Iddd7dcf335387ba46fcbbb6067ef4ff9cd3755a7@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
88717def |
|
13-Sep-2023 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
wifi: iwlwifi: mvm: add a debug print when we get a BAR Getting a BAR can be an explanation if we're chasing packet loss. Add a print with the relevant debug level in that code path. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.913e989a1751.I6bff9020e339d91b61b5ad6aede27bcf8c7e6819@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
3dfbcf78 |
|
13-Sep-2023 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
wifi: iwlwifi: mvm: log dropped frames When we drop frames we want to have something printed in the logger. This won't be printed by default of course. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.c2f02fecf66f.Ib472f9fd92856c6e5b5a99b68fdca0f694a531e9@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
4831d19b |
|
30-Aug-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: mvm: move RU alloc B2 placement The firmware was trying to report the B2 RU allocation in the place previously used here as well, but there's a HW block that clears the lower 8 bits in this metadata word even in sniffer mode. Thus, firmware moved B2 to another place, follow that. There's no need to detect the version since moving it to the other place if firmware didn't just means that we'll continue to report the (erroneous) zero value, and it's not really something we can detect from the firmware now. While debugging this we realized that the comments about placement in the metadata dwords are wrong, update them. Reported-by: Youhan Kim <youhank@qti.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.dec7f1e07ff8.I623fee2d710cc7b6f392d65b708883ed58632b45@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
2db72b8a |
|
20-Jun-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: mvm: indicate HW decrypt for beacon protection We've already done the 'decryption' here, so tell mac80211 it need not do it again. Fixes: b1fdc2505abc ("iwlwifi: mvm: advertise BIGTK client support if available") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230620125813.a50cf68fbf2e.Ieceacbe3789d81ea02ae085ad8d1f8813a33c31b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
aedb2b38 |
|
13-Jun-2023 |
Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> |
wifi: iwlwifi: mvm: Validate tid is in valid range before using it Validate tid is less then MAX TID when it is used to access corresponding arrays. Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230614123447.cea75e1f57e7.I03bc0a81d2c1bdbf4784c12c4c62b8538892ccba@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
568db7fd |
|
13-Jun-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: add some FW misbehaviour check infrastructure When the firmware misbehaves (according to the driver), we often either ignore that, or WARN_ON, which is very noisy but doesn't really help. Add a little helper macro IWL_FW_CHECK() that can be used in place of WARN_ON() in conditions, and make it take a message that's printed in this case. We can also add more behaviour to this in the future. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230614123446.2e12ac670cea.Ia0198036b7a626876d836bd41a4b2d2b1e65c5ca@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
97110233 |
|
13-Jun-2023 |
Mukesh Sisodiya <mukesh.sisodiya@intel.com> |
wifi: iwlwifi: mvm: initialize the rx_vec before using it Initialize the phy_data.rx_vec for both version-3 and above where it is 4-byte data size and below version which has data size of 2-byte. The data will be sent uninitialized in called function if notification version is less than three. Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230613155501.a6bb856f04bc.I9a15075f3dad61dcabdcd1ed0d34cf3e8ec5453f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
557b56d5 |
|
13-Jun-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: mvm: support U-SIG EHT validate checks Support new firmware that can validate the validate bits in sniffer mode, and advertise that fact and the result of the checks in the U-SIG radiotap field. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230613155501.c20480aa1171.Icc0d077dae01d662ccb948823e196aa9c5c87976@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
0e394135 |
|
31-May-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: mvm: clarify EHT RU allocation bits Calling this IWL_RX_PHY_DATA1_EHT_B0 is just confusing, it's the RU allocation bit 0. Also then align the name for B1-B7 accordingly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230531194629.824edb28c0eb.Ia9f74573e3ac771911b679558984f1bfb36de674@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
68182662 |
|
13-May-2023 |
Gregory Greenman <gregory.greenman@intel.com> |
wifi: iwlwifi: mvm: fix access to fw_id_to_mac_id RCU protected fw_id_to_mac_id can be initialized with either an error code or NULL. Thus, after dereferencing need to check the value with IS_ERR_OR_NULL() and not only that it is not NULL. Fix it. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230514120631.ec5f2880e81c.Ifa8c0f451df2835bde800f5c3670cc46238a3bd8@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
c2d8b7f2 |
|
13-May-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: mvm: fix cancel_delayed_work_sync() deadlock Lockdep points out that we can deadlock here by calling cancel_delayed_work_sync() because that might be already running and gotten interrupted by the NAPI soft-IRQ. Even just calling something that can sleep is wrong in this context though. Luckily, it doesn't even really matter since the things we need to do are idempotent, so just drop the _sync(). Fixes: e5d153ec54f0 ("iwlwifi: mvm: fix CSA AP side") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230514120631.b1813c823b4d.I9d20cc06d24fa40b6774d3dd95ea5e2bf8dd015b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
0d255883 |
|
17-Apr-2023 |
Avraham Stern <avraham.stern@intel.com> |
wifi: iwlwifi: modify scan request and results when in link protection When CSME is connected and has link protection set, the driver must connect to the same AP CSME is connected to. When in link protection, modify scan request parameters to include only the channel of the AP CSME is connected to and scan for the same SSID. In addition, filter the scan results to include only results from the same AP. This will make sure the driver will connect to the same AP and will do it fast enough to keep the session alive. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.c1b55de3d704.I3895eebe18b3b672607695c887d728e113fc85ec@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
7b41a99c |
|
17-Apr-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: mvm: fix MIC removal confusion The RADA/firmware collaborate on MIC stripping in the following way: - the firmware fills the IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK value for how many words need to be removed at the end of the frame, CRC and, if decryption was done, MIC - if the RADA is active, it will - remove that much from the end of the frame - zero the value in IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK As a consequence, the only thing the driver should need to do is to - unconditionally tell mac80211 that the MIC was removed if decryption was already done - remove as much as IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK says at the end of the frame, since either RADA did it and then the value is 0, or RADA was disabled and then the value is whatever should be removed to strip both CRC & MIC However, all this code was historically grown and getting a bit confused. Originally, we were indicating that the MIC was not stripped, which is the version of the code upstreamed in commit 780e87c29e77 ("iwlwifi: mvm: add 9000 series RX processing") which indicated RX_FLAG_DECRYPTED in iwl_mvm_rx_crypto(). We later had a commit to change that to also indicate that the MIC was stripped, adding RX_FLAG_MIC_STRIPPED. However, this was then "fixed" later to only do that conditionally on RADA being enabled, since otherwise RADA didn't strip the MIC bytes yet. At the time, we were also always including the FCS if the RADA was not enabled, so that was still broken wrt. the FCS if the RADA isn't enabled - but that's a pretty rare case. Notably though, it does happen for management frames, where we do need to remove the MIC and CRC but the RADA is disabled. Later, in commit 40a0b38d7a7f ("iwlwifi: mvm: Fix calculation of frame length"), we changed this again, upstream this was just a single commit, but internally it was split into first the correct commit and then an additional fix that reduced the number of bytes that are removed by crypt_len. Note that this is clearly wrong since crypt_len indicates the length of the PN header (always 8), not the length of the MIC (8 or 16 depending on algorithm). However, this additional fix mostly canceled the other bugs, apart from the confusion about the size of the MIC. To fix this correctly, remove all those additional workarounds. We really should always indicate to mac80211 the MIC was stripped (it cannot use it anyway if decryption was already done), and also always actually remove it and the CRC regardless of the RADA being enabled or not. That's simple though, the value indicated in the metadata is zeroed by the RADA if it's enabled and used the value, so there's no need to check if it's enabled or not. Notably then, this fixes the MIC size confusion, letting us receive GCMP-256 encrypted management frames correctly that would otherwise be reported to mac80211 8 bytes too short since the RADA is turned off for them, crypt_len is 8, but the MIC size is 16, so when we do the adjustment based on IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK (which indicates 20 bytes to remove) we remove 12 bytes but indicate then to mac80211 the MIC is still present, so mac80211 again removes the MIC of 16 bytes, for an overall removal of 28 rather than 20 bytes. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.81345b6ab0cd.Ibe0348defb6cce11c99929a1f049e60b5cfc150c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
9aa3856d |
|
16-Apr-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: mvm: track station mask for BAIDs When we have MLO connections, a BAID applies to multiple firmware stations. Track the station mask instead of the station ID, getting rid of a few more deflink cases and preparing for handling link switching for BAIDs. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230416154301.c08523808c34.I719b7bba499648d1495ed3e3a90889d4732ef15d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
217f3c52 |
|
13-Apr-2023 |
Avraham Stern <avraham.stern@intel.com> |
wifi: iwlwifi: mvm: don't set CHECKSUM_COMPLETE for unsupported protocols On Bz devices, CHECKSUM_COMPLETE was set for unsupported protocols which results in a warning. Fix it. Fixes: b6f5b647f694 ("iwlwifi: mvm: handle RX checksum on Bz devices") Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230413102635.a2a35286f0ca.I50daa9445a6465514c44f5096c32adef64beba5f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
b8a85a1d |
|
29-Mar-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: mvm: rxmq: report link ID to mac80211 Add a fw_id_to_link_sta array in mvm to track the link STA for each firmware station ID, and then use that to report the link a frame was received on (since we know the station ID from firmware). Notably, this fixes beacon tracking for the correct link since mac80211 now queues and processes those on the one link identified by the link ID only. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230329100039.c7dd3ec18077.I12ef9eb4a5b8b5c2b9d6bcaa1fda73b59eba39d8@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
c8ee33e1 |
|
28-Mar-2023 |
Gregory Greenman <gregory.greenman@intel.com> |
wifi: iwlwifi: mvm: sta preparation for MLO Split iwl_mvm_sta into general and link specific parts. As a first step, all link dependent parameters reside in deflink. The change was done mostly using the spatch below with some manual adjustments. @iwl_mvm_sta@ struct iwl_mvm_sta *s; identifier var = {sta_id, lq_sta, avg_energy}; @@ ( s-> - var + deflink.var ) Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230328104948.34eace06d583.I1f8c5e919a71b21030460fbdd220d42401b688b1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
c7eca79d |
|
19-Mar-2023 |
Avraham Stern <avraham.stern@intel.com> |
wifi: iwlwifi: mvm: report hardware timestamps in RX/TX status For TM/FTM frames, report the hardware timestamps reported by the fw as part of the RX/TX status. Since the fw reports the timestamps in a dedicated notification (and not as part of the RX/TX status), hold the frame until the fw timestamps notification is received. Timestamping is enabled when a station is connected and disabled when disconnected. For AP interface, only the first station will have timestamping enabled since the fw only supports timestamping for one peer. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230320122330.e0392d498101.I9bf12c8ecfb3f17253a13dc48a48647ddd6e7855@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
da118544 |
|
05-Mar-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: mvm: fix EOF bit reporting In monitor mode, we try to report the EOF bit on the first MPDU of an A-MPDU (hardware duplicates this bit over all MPDUs, so it's only trustable on the first). However, due to reshuffling in an ealier commit, the toggle_bit != mvm->ampdu_toggle logic can no longer work since mvm->ampdu_toggle is now set before this code runs. Fix this by tracking the first_subframe status in the phy data struct and using that instead of checking. Fixes: f1490546bec9 ("wifi: iwlwifi: mvm: rxmq: refactor mac80211 rx_status setting") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230305124407.e273aa0d3fdc.I77db4cc247898eae8a98b80659386d6737052b95@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
b55c1f4e |
|
05-Mar-2023 |
Ilan Peer <ilan.peer@intel.com> |
wifi: iwlwifi: Do not include radiotap EHT user info if not needed Do not include user information in radtiotap EHT data for EHT sounding NDP as the frame doesn't include the user specific field. Instead, encode the NSS and the beamforming information in the EHT data. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230305124407.ac6474ded9bd.I9655589e9afbacc16820f35f6f5d90c6a91b8b05@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
7696c07b |
|
05-Mar-2023 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
wifi: iwlwifi: mvm: add EHT RU allocation to radiotap FW new API added the info missing for update RU allocation, so use the new API to update radiotap information. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230305124407.b16acaa4bad1.I53afa03058dbd2cd8afbaf5e82596c8ed501a476@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
5abf3154 |
|
05-Mar-2023 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
wifi: iwlwifi: mvm: add primary 80 known for EHT radiotap Calculate the position of the control channel in the wide channel based on the chandef, this is used to obtain the value of N in 802.11be D1.5 Table 9-53a in the column PHY MU/MRU index. To avoid the need to calculate every frame the value, do it once monitor vif is added. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230305124407.fe9a5b58e241.I291ee480252d098f62d9ec39040284d3e521d88e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
feb4a0e2 |
|
05-Mar-2023 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
wifi: iwlwifi: mvm: parse FW frame metadata for EHT sniffer mode In EHT sniffer mode DW4 is all used for sniffer data (unlike we have in HE mode), so move the full DW4 into a union, and we extract the new data5 used for parsing USIG info and set all to radiotap TLVs with the extracted data. Also parse OFDM_RX_VECTOR_USIG_A1_OUT and OFDM_RX_VECTOR_USIG_A2_OUT for rx_no_data notification. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230305124407.557d3870753b.I4e9fa4d21900a187753529d46956ba2a7ee75fda@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
e8c0a6fd |
|
05-Mar-2023 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
wifi: iwlwifi: mvm: decode USIG_B1_B7 RU to nl80211 RU width This is based on 802.11be D1.5 table 9-53a Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230305124407.0b720d6d6a48.I0034dd108696223494799d3ffe4f09685800b831@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
c0da321b |
|
05-Mar-2023 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
wifi: iwlwifi: mvm: rename define to generic name The type RX_NO_DATA_INFO_TYPE_HE_TB_UNMATCHED is applied to all TB frames including EHT mode, so rename accordingly. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230305124407.e4f51f347e48.I2d6ecb6eadc95666d2ef9794662ee779488ceac1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
4ec82585 |
|
05-Mar-2023 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
wifi: iwlwifi: mvm: add all EHT based on data0 info from HW Update all radiotap EHT TLVs that we can extract from data0 in HW. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230305124407.730f219e02ee.Ife3dd85c65758694d7602e8bc8660887d77faacf@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
24f7f6e3 |
|
05-Mar-2023 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
wifi: iwlwifi: mvm: add EHT radiotap info based on rate_n_flags rate_n_flags is always present in the data so at least give all of the information we can extract from rate_n_flags Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230305124407.b1c7d49ad35e.Ie2412ac6f88700aa3767ff95ffb52a806b13b7ce@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
056805bc |
|
05-Mar-2023 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
wifi: iwlwifi: mvm: add an helper function radiotap TLVs Add a helper function setting type, length, zeroing out TLV data and including adding padding if necessary. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230305124407.8ac5195bb3e6.I19ad99c1ad3108453aede64bddf6ef1a7c4a0b74@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
11a2638d |
|
05-Mar-2023 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
wifi: radiotap: separate vendor TLV into header/content To be able to use a general function later for any kind of TLV, separate the vendor TLV header/content in the structs. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230305124407.8ac5195bb3e6.I19ad99c1ad3108453aede64bddf6ef1a7c4a0b74@changeid [separate from the original combined patch] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
876882b5 |
|
05-Mar-2023 |
Golan Ben Ami <golan.ben.ami@intel.com> |
wifi: iwlwifi: reduce verbosity of some logging events These are cases in which we'd like to warn that something unexpected happened but they may not be errors. Reduce verbosity. Signed-off-by: Golan Ben Ami <golan.ben.ami@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230305124407.5eea0f58a74f.Ifb6b35903a5a452a757bfe50b6a7e58b3fd2ef23@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
f567b9b4 |
|
05-Mar-2023 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
wifi: iwlwifi: mvm: mark mac header with no data frames Although no data is presented in the skb, but upper layers need it for calculating where radio tap header are done, so we mark it. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230305124406.8f53cc8579bf.I8819c005b4953cea03346d0aff82b31d94f79fe5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
eccfe017 |
|
05-Mar-2023 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
wifi: iwlwifi: mvm: add LSIG info to radio tap info in EHT Nothing change with LSIG in EHT so just extend the switch case to include EHT standard. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230305124406.53edcfc049fb.Iec0401faead108aa5130c23c604cfb88ef2943de@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
9179dff8 |
|
28-Feb-2023 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
wifi: mac80211: add support for driver adding radiotap TLVs The new TLV format enables adding TLVs after the fixed fields in radiotap, as part of the radiotap header. Support this and move vendor data to the TLV format, allowing a reuse of the RX_FLAG_RADIOTAP_VENDOR_DATA as the new RX_FLAG_RADIOTAP_TLV_AT_END flag. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230301115906.b18fd5da8477.I576400ec40a7b35ef97a3b09a99b3a49e9174786@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
9387e359 |
|
26-Jan-2023 |
Mukesh Sisodiya <mukesh.sisodiya@intel.com> |
wifi: iwlwifi: mvm: Reset rate index if rate is wrong Setting rate index should not depend on net_ratelimit(). Fix that for the case of invalid rate. Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Link: https://lore.kernel.org/r/20230127002430.8eede67758bb.I585ab389e27d61153540b7cb5ebed66e21f765f0@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
|
#
3f7a9d57 |
|
26-Jan-2023 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
wifi: iwlwifi: mvm: simplify by using SKB MAC header pointer Instead of calculating the offset to the 802.11 header based on radiotap bits and length, shorten the code path by always setting the MAC header in the skb and using skb_mac_header(). Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Link: https://lore.kernel.org/r/20230127002430.3ec5493934a4.I1d41a2af28588b5899fcd2402f8c4bd8cc29a12e@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
|
#
0ac93c06 |
|
26-Jan-2023 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
wifi: iwlwifi: mvm: add sniffer meta data APIs We add TSF overwrite for EHT MU/TB high and low, and add definitions for EHT Data 5 meta data. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Link: https://lore.kernel.org/r/20230127002430.6729c0be66aa.I95ad94d5e137ec80010facd8ee57cd40461a0721@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
|
#
8dd51b5f |
|
26-Jan-2023 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
wifi: iwlwifi: rx: add sniffer support for EHT mode Start by adding a parsing option for all the new fields coming from FW and checking that we have the right version for parsing EHT. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Link: https://lore.kernel.org/r/20230127002430.ba9b364fbacf.I469af2a07b3ff51cbd8d67e572478f4c56ce22ba@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
|
#
23dcee94 |
|
09-Jan-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: mvm: add minimal EHT rate reporting Now with all the prework, this is fairly simple, just report the new bandwidth and RX_ENC_EHT type in RX, and for now just do a minimal report of the EHT TLC rate in iwl_mvm_set_sta_rate(). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20230109130329.5f34d73d1f74.Ib27ae7bd23bc152d61021fd73aabdc76679b9fe4@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
|
#
1174e8fc |
|
05-Dec-2022 |
Mordechay Goodstein <mordechay.goodstein@intel.com> |
wifi: iwlwifi: mvm: don't access packet before checking len Currently in sniffer mode we access pkt fields before checking that the frame has the length to access it. Fix this by moving the check to before the access. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20221205102808.934da230c698.Ib56f11bbc8978e15d38394336a929cb4996ba39e@changeid
|
#
b79d2219 |
|
02-Nov-2022 |
Luca Coelho <luciano.coelho@intel.com> |
wifi: iwlwifi: mvm: print an error instead of a warning on invalid rate In some rare occasions, the firmware may let some frames with invalid rates, such as CCK rates on the high band, come through. This causes the driver to issue a warning, but since this is a possible issue and it's not really a bug in the driver, convert the warning into an error. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20221102165239.3d3673c70556.I13464b11d405fd6021618b0a32404cecb7e9ac51@changeid
|
#
3d579204 |
|
06-Sep-2022 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: mvm: rxmq: further unify some VHT/HE code There's some duplication here, unify it so that adding EHT becomes easier. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.d1e8673b9443.I6d81fc9dd0856d75e3a799c23f0f8d212b077fca@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
|
#
f1490546 |
|
06-Sep-2022 |
Johannes Berg <johannes.berg@intel.com> |
wifi: iwlwifi: mvm: rxmq: refactor mac80211 rx_status setting There's a bunch of duplicated code in the normal data RX and the no-data RX paths, refactor that. Note that we're evidently not implementing the 6 GHz band in the no-data path correctly, need to fix that in firmware first. Also, we were setting the NSS differently, keep doing that, but just override the previous values. Note also that we used to drop frames with bad rate data, to simplify that just report rate 0 and continue. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.a81580d5e769.I3ee7a1fe1adf8684c48713dbbdc2cbc60bd24cd1@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
|
#
3827cb59 |
|
28-Jan-2022 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: avoid void pointer arithmetic Avoid void pointer arithmetic since it's technically undefined and causes warnings in some places that use our code. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220128153014.e349104ecd94.Iadc937f475158b9437becdfefb361a97e7eaa934@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
667aa742 |
|
02-Feb-2022 |
Johannes Berg <johannes.berg@intel.com> |
cfg80211/mac80211: assume CHECKSUM_COMPLETE includes SNAP There's currently only one driver that reports CHECKSUM_COMPLETE, that is iwlwifi. The current hardware there calculates checksum after the SNAP header, but only RFC 1042 (and some other cases, but replicating the exact hardware logic for corner cases in the driver seemed awkward.) Newer generations of hardware will checksum _including_ the SNAP, which makes things easier. To handle that, simply always assume the checksum _includes_ the SNAP header, which this patch does, requiring to first add it for older iwlwifi hardware, and then remove it again later on conversion. Alternatively, we could have: 1) Always assumed the checksum starts _after_ the SNAP header; the problem with this is that we'd have to replace the exact "what is the SNAP" check in iwlwifi that cfg80211 has. 2) Made it configurable with some flag, but that seemed like too much complexity. 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.20220202104617.230736e19e0e.I3e6745873585ad943c152fab9e23b5221f17a95f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
8ccb768c |
|
19-Dec-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: drop too short packets silently There's little value in this warning, we get a warning here if firmware passes us a short packet, particularly in monitor mode. 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.20211219132536.305d12cf51ac.I2e4e6874113b1e5d8ee467b8a2d90820cc6ddde9@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
40a0b38d |
|
18-Dec-2021 |
Ilan Peer <ilan.peer@intel.com> |
iwlwifi: mvm: Fix calculation of frame length The RADA might include in the Rx frame the MIC and CRC bytes. These bytes should be removed for non monitor interfaces and should not be passed to mac80211. Fix the Rx processing to remove the extra bytes on non monitor cases. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.098be12c801e.I1d81733d8a75b84c3b20eb6e0d14ab3405ca6a86@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
b6f5b647 |
|
18-Dec-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: handle RX checksum on Bz devices On Bz devices, the hardware checksums including the SNAP header, starting directly after the MAC header, so we don't need the extra checks and can just pass the checksum to mac80211. 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.20211219121514.8ef59da4e05e.Ide87c2dc8fa08eae55c013a625f4ece5184b1b63@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
18c11e2f |
|
10-Nov-2021 |
Dan Carpenter <dan.carpenter@oracle.com> |
iwlwifi: mvm: fix a stray tab This line was indented too far and was a bit confusing. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20211110080759.GE5176@kili Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
2438d430 |
|
03-Dec-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: fix delBA vs. NSSN queue sync race 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@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
544ab2a9 |
|
17-Oct-2021 |
Luca Coelho <luciano.coelho@intel.com> |
iwlwifi: mvm: remove csi from iwl_mvm_pass_packet_to_mac80211() 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 <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20211017132604.480251-2-luca@coelho.fi Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
ce712478 |
|
17-Oct-2021 |
Luca Coelho <luciano.coelho@intel.com> |
iwlwifi: mvm: Support new rate_n_flags for REPLY_RX_MPDU_CMD and RX_NO_DATA_NOTIF 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: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211017162352.7eb6240b8079.I1e804e70a8ebd23840a9431fc5d2a56ad8d5d1a2@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
48c6ebc1 |
|
16-Oct-2021 |
Miri Korenblit <miriam.rachel.korenblit@intel.com> |
iwlwifi: mvm: update definitions due to new rate & flags As a part of preparing to the new rate & flags version Update the relevant definitions and use them. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211017123741.5862bf4f14c4.Ib476b5443faa085539b79d49a0aebd81a213b42f@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
57b7b345 |
|
17-Oct-2021 |
Miri Korenblit <miriam.rachel.korenblit@intel.com> |
iwlwifi: mvm: Remove antenna c references 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: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211017113927.5e39106ec75b.I4281edc844f734bf9591396a5cc8009ad37ccda8@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
e257d969 |
|
26-Aug-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: don't use FW key ID in beacon protection 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: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210826224715.30e665d39b07.I78bf7d304ef5a80cecf5fa1c1fca0b51b956cceb@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
3df5c0dd |
|
05-Aug-2021 |
Avraham Stern <avraham.stern@intel.com> |
iwlwifi: mvm: silently drop encrypted frames for unknown station 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: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210805130823.a751177743c6.I5607504dade88ba461508643f58390dd661c05ba@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
fa331068 |
|
18-Jun-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: fill phy_data.d1 for no-data RX 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: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618105614.3d488885f77c.Ib97a2bc57c1e9fb98927dc6f802568db313abe3b@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
5e1688ce |
|
30-Mar-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: clean up queue sync implementation 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: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210331121101.f62833fd9893.I612d7ac1c655ec4880329360e15d207698c750bc@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
65db391d |
|
25-Mar-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: fix beacon protection checks 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: Johannes Berg <johannes.berg@intel.com> Fixes: b1fdc2505abc ("iwlwifi: mvm: advertise BIGTK client support if available") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.23c990843369.I09c262a8f6f9852cc8f513cdcb31a7f8f87dd8af@changeid
|
#
e5d153ec |
|
05-Feb-2021 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
iwlwifi: mvm: fix CSA AP side 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: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210205110447.f5b813753bdb.Id58979b678974c3ccf44d8b381c68165ac55a3d3@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
b1fdc250 |
|
05-Feb-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: advertise BIGTK client support if available 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 <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210205110447.f5a3d53301b3.I23e84c9bb0b039d9106a07e9d6847776757f9029@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
1e1a58be |
|
17-Jan-2021 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: check more notification sizes Some notifications aren't handled by the general RX handler code, due to multi-queue. Add size checks for them explicitly. 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.20210117130510.1370c776cb31.Ic536bd1aee5368969fbf65db85b9b9b5dc9c6034@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
5a2abdca |
|
17-Nov-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
iwlwifi: mvm: Fix fall-through warnings for Clang 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/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201117135053.GA13248@embeddedor
|
#
b8aba27c |
|
09-Dec-2020 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: tighten RX MPDU bounds checks 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 <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201209231352.51cc04cf1e3e.I7bfd6809f8f5feb75f79397646e6656e95688a0e@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
b570e5b0 |
|
09-Dec-2020 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: validate firmware sync response size 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 <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201209231352.a5a8173f16c7.I4fa68bb2b1c7dcc52ddd381c4042722d27c4a34d@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
8e99ea8d |
|
09-Dec-2020 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: use SPDX tags 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 <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201210000603.481bcb512a6f.I8146abe5a637079e7336209f23cb26af98b12b31@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
2f7a04c7 |
|
09-Dec-2020 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: do more useful queue sync accounting 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 <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201209231352.0a3fa177cd6b.I7c69ff999419368266279ec27dd618eb450908b3@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
e20a5c9f |
|
09-Dec-2020 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: clear up iwl_mvm_notify_rx_queue() argument type 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 <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201209231352.d28e14682bdc.I9ac366aa97db045be4daa4ba263267a3ac6a6a2f@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
efc0ec5a |
|
09-Dec-2020 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: validate MPDU length against notification length 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: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201209231352.7c721ad37014.Id5746874ecfa208b60baa62691b2d9dc5dd4d89c@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
eae94cf8 |
|
09-Dec-2020 |
Luca Coelho <luciano.coelho@intel.com> |
iwlwifi: mvm: add support for 6GHz 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: Haim Dreyfuss <haim.dreyfuss@intel.com> Co-developed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Ilan Peer <ilan.peer@intel.com> Co-developed-by: Tova Mussai <tova.mussai@intel.com> Signed-off-by: Tova Mussai <tova.mussai@intel.com> Co-developed-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Co-developed-by: Tali Levi Rovinsky <Tali.Levi-rovinsky@intel.com> Signed-off-by: Tali Levi Rovinsky <Tali.Levi-rovinsky@intel.com> Co-developed-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Avraham Stern <avraham.stern@intel.com> Co-developed-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201210000657.0fdbfc3d7352.Idb648536faf21716e2ab2c6d6890d3e49f719cd3@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
be9ae34e |
|
08-Oct-2020 |
Nathan Errera <nathan.errera@intel.com> |
iwlwifi: mvm: get number of stations from TLV 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: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20201008180656.863ab470babc.I393223392f36436663c4e66add03fefe77b74e60@changeid
|
#
e365e7de |
|
30-Sep-2020 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: align RX status flags with firmware 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 <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200930191738.0ba403d72e7c.I5fa3aa0538f3fbf8c3885b27a1204b5b0464c20a@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
59ca9572 |
|
25-Sep-2020 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: use CHECKSUM_COMPLETE 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: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200926002540.869e829c815d.I70f374865b0acafc675a8d7959912eeaeb595acf@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
d829229e |
|
03-Dec-2019 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
iwlwifi: mvm: don't send the IWL_MVM_RXQ_NSSN_SYNC notif to Rx queues 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 3c514bf831ac12356b695ff054bef641b9e99593: 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: 3c514bf831ac ("iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues") CC: <stable@vger.kernel.org> # 5.3+ Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
924f838b |
|
27-Sep-2019 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: remove left-over non-functional email alias 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: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
3681021f |
|
15-Nov-2019 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: remove IWL_DEVICE_22560/IWL_DEVICE_FAMILY_22560 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: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
65b9425c |
|
01-Aug-2019 |
Tova Mussai <tova.mussai@intel.com> |
iwlwifi: rx: use new api to get band from rx mpdu The FW introduce new API to get the band from the rx mpdu, use this new API. Signed-off-by: Tova Mussai <tova.mussai@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
94b952b5 |
|
22-Jul-2019 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
iwlwifi: mvm: don't log un-decrypted frames 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: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
fe69b7d1 |
|
04-Jul-2019 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: handle BAR_FRAME_RELEASE (0xc2) notification 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 <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
0968fbfa |
|
16-Jul-2019 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: drop BA sessions on too many old-SN frames 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: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
286ca8eb |
|
12-Jul-2019 |
Luca Coelho <luciano.coelho@intel.com> |
iwlwifi: add a pointer to the trans_cfg directly in trans 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 <luciano.coelho@intel.com>
|
#
79b6c8fe |
|
02-Aug-2018 |
Luca Coelho <luciano.coelho@intel.com> |
iwlwifi: separate elements from cfg that are needed by trans_alloc 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: Luca Coelho <luciano.coelho@intel.com>
|
#
ecd09ddc |
|
27-Jun-2019 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
iwlwifi: mvm: fix frame drop from the reordering buffer 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 <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
3c514bf8 |
|
24-Jun-2019 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues 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 <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
521dc6c7 |
|
25-Jun-2019 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
iwlwiif: mvm: refactor iwl_mvm_notify_rx_queue Instead of allocating memory for which we have an upper limit, use a small buffer on stack. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
c61b655a |
|
24-Jun-2019 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
iwlwifi: mvm: add a new RSS sync notification for NSSN sync 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: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
9285ec4c |
|
21-Jun-2019 |
Jason A. Donenfeld <Jason@zx2c4.com> |
timekeeping: Use proper clock specifier names in functions 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
|
#
de1887c0 |
|
15-Apr-2019 |
Luca Coelho <luciano.coelho@intel.com> |
iwlwifi: mvm: check for length correctness in iwl_mvm_create_skb() 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>
|
#
d47cdb88 |
|
02-Jan-2019 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: report all NO_DATA events to mac80211 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: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
a197e6d1 |
|
16-Jan-2019 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
iwlwifi: mvm: fix the spatial reuse parsing for HE_TRIG PPDUs The spatial reuse 4 words fields are fetched from the HE-SIGA by the firmware and propagated to the driver through the Rx info. This is useful to populate the radiotap header. We were looking at the wrong place in the firmware data and got bogus values. Fix that. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Fixes: bdf180c8d375 ("iwlwifi: mvm: change PHY data RX for HE radiotap") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
2286a99c |
|
11-Jan-2019 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: fix HE radiotap data4 for HE-TB PPDUs In HE-TB PPDUs (labeled HE-TRIG in radiotap), we were overwriting the data4.spatial_reuse_1 field with the spatial reuse data that the firmware gives us for SU/MU PPDUs. Fix that by moving that, we are already setting the data4.spatial_reuse_{1,2,3,4} fields in the TB PPDU case. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: 69f3ca8ed33d ("iwlwifi: mvm: show more HE radiotap data for TB PPDUs") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
ed714460 |
|
10-Dec-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: clean up NO_PSDU case We now no longer have any special code in iwl_mvm_pass_packet_to_mac80211(), so don't need to pass NO_PSDU packets through it. Stop doing so and clean up the code there. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
3619b088 |
|
10-Dec-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: don't hide HE radiotap data in SKB Hiding the HE radiotap data for further processing of the SKB just caused another bug when adding the L-SIG data. Simply stop doing this and adjust the skb->data pointer accordingly when we need to get the 802.11 header. While at it, also verify and fix the data alignment, we need to add 2 bytes padding with the vendor data to ensure the whole length of all radiotap headers is a multiple of 4. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: 6721039d5b8a ("iwlwifi: mvm: add L-SIG length to radiotap") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
74cf15cb |
|
03-Dec-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: add HE TB PPDU SIG-A BW to radiotap Expose the trigger-based PPDU SIG-A bandwidth to radiotap in the newly defined bits thereof. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
244726ec |
|
04-Dec-2018 |
Luca Coelho <luciano.coelho@intel.com> |
iwlwifi: mvm: add fall through comments where needed Some switch-cases were missing a fall through comment, so the compiler may warn. Fix that by adding the comments where needed. In other cases there was more text in the comment, which the compiler doesn't recognize, so either remove the extra text or move it to a separate comment line as appropriate. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
3864be55 |
|
30-Jan-2019 |
Luca Coelho <luciano.coelho@intel.com> |
iwlwifi: mvm: fix merge damage in iwl_mvm_rx_mpdu_mq() A call to iwl_mvm_add_rtap_sniffer_config() was missing due to a merge damage when I submitted the patch mentioned below. And this causes the following compilation warning: drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:195:13: warning: 'iwl_mvm_add_rtap_sniffer_config' defined but not used [-Wunused-function] static void iwl_mvm_add_rtap_sniffer_config(struct iwl_mvm *mvm, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fix it by adding the if block that calls this function. Fixes: 9bf13bee2d74 ("iwlwifi: mvm: include configured sniffer AID in radiotap") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
9bf13bee |
|
20-Nov-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: include configured sniffer AID in radiotap In order to make more sense out of the captured radiotap data e.g. when the configured AID changes, add the currently configured AID to the radiotap data as a vendor extension field. This is made race-free by updating the included value from inside the RX path (using a notification wait) for the command response from the firmware, which thus means it's serialized with frame RX. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
81444538 |
|
20-Nov-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: document monitor mode reorder buffer bypass The reorder buffer is bypassed because the firmware won't have any BA sessions, document this. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
5213e8a8 |
|
25-Oct-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: implement CSI reporting Implement CSI (channel estimation matrix) reporting in the mvm driver, if the firmware has the capability. Currently only a debugfs API is provided as the API is still under discussion. For now, RX aggregation must be disabled to use this feature on data frames as we haven't found a good way to attach the data to A-MPDUs, given complexities with multi-queue. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
1f7698ab |
|
08-Nov-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: fix A-MPDU reference assignment 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>
|
#
486af863 |
|
29-Oct-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: read IWL_RX_MPDU_PHY_SHORT_PREAMBLE only for CCK Due to a general shortage of RX API bits, the firmware is going to reuse this bit on non-CCK frames to mean something else. Use it only on CCK frames to prepare for that change. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
c97781d1 |
|
24-Oct-2018 |
Shaul Triebitz <shaul.triebitz@intel.com> |
iwlwifi: iwlmvm: in monitor NDP notif take the NSS from rx_vec Take the NSS value from 'rx_vec' rather than from 'rate_n_flags'. The rate_n_flags has only 2 bits for the NSS giving a max of 4SS (0 = 1SS etc.). Since there may be up to 8SS use the rx_vec which has 3 bits for the NSS. While at it, fix the rx_vec array to length of 2. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
937c2652 |
|
23-Oct-2018 |
Shaul Triebitz <shaul.triebitz@intel.com> |
iwlwifi: iwlmvm: ignore HE PPDU type regarding EOF When setting the EOF bit in Rx flags (propagated to radiotap) do not depend it on the PPDU type (SU/MU/TB) since it doesn't. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
bf9dfeda |
|
23-Jul-2018 |
Shaul Triebitz <shaul.triebitz@intel.com> |
iwlwifi: mvm: handle RX no data notification Handle RX no data notification, which is used for advertising NDP to radiotap. Signed-off-by: Golan Ben Ami <golan.ben.ami@intel.com> Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
7969454b |
|
25-Jul-2018 |
Shaul Triebitz <shaul.triebitz@intel.com> |
iwlwifi: mvm: radiotap: remove UL_DL bit in HE TRIG_BASED UL_DL is irrelevant to HE TRIG_BASED PPDU. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
6721039d |
|
02-Jul-2018 |
Shaul Triebitz <shaul.triebitz@intel.com> |
iwlwifi: mvm: add L-SIG length to radiotap We may have the L-SIG length depending on the phy_data info type; add it to radiotap when we do. Move getting the phy_data out one layer up and the info type into it so we can use this data more generically. We need to call the iwl_mvm_rx_he() function for other reasons as well, so can't just combine all of that into something like iwl_mvm_parse_phy_data(). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
bdf180c8 |
|
02-Jul-2018 |
Shaul Triebitz <shaul.triebitz@intel.com> |
iwlwifi: mvm: change PHY data RX for HE radiotap The firmware changed the PHY data API, so follow suit. Some data is now available even for HT/VHT frames, so the info type in the metadata was changed. This change isn't backwards compatible, but 1) the firmware with the old API was never released; 2) the only overlap in the info type field is from the old type of TB to the new of HT, so this basically just means that with older FW and newer driver the data will be considered missing. While at it, remove the extra code to set the LTF syms corresponding to the streams and use the data from the device instead - we don't really need this in any case other than when we have it from the device. As the new API gives use the spatial reuse 1-4 fields for trigger-based PPDUs, also expose that to radiotap. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
41c4588b |
|
05-Oct-2018 |
YueHaibing <yuehaibing@huawei.com> |
iwlwifi: mvm: remove set but not used variable 'he_phy_data' Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c: In function 'iwl_mvm_rx_mpdu_mq': drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:1386:7: warning: variable 'he_phy_data' set but not used [-Wunused-but-set-variable] u64 he_phy_data; 'he_phy_data' never used since be introduce in commit 18ead597daa1 ("iwlwifi: support new rx_mpdu_desc api") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
69f3ca8e |
|
19-Jun-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: show more HE radiotap data for TB PPDUs For trigger-based PPDUs, most values aren't part of the HE-SIG-A because they're preconfigured by the trigger frame. However, we still have this information since we used the trigger frame to configure the hardware, so we can (and do) read it back out and can thus show it in radiotap. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
8a07e8d4 |
|
19-Jun-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: decode HE information for MU (without ext info) When the info type is MU, we still have the data from the TSF overload words, so should decode that. When it's MU_EXT_INFO we additionally have the SIG-B common 0/1/2 fields. Also document the validity depending on the info type and fix the name of the regular TB PPDU info type accordingly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
fed3c4ea |
|
14-Jun-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: add more information to HE radiotap For SU/SU-ER/MU PPDUs we have spatial reuse. For those where it's relevant we also know the pre-FEC padding factor, PE disambiguity bit, beam change bit and doppler bit. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
750f4377 |
|
14-Jun-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: add LDPC-XSYM to HE radiotap data Add information about the LDCP extra symbol segment to the HE data when applicable (not for trigger-based PPDUs). While at it, clean up the code for UL/DL a bit. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
2b147634 |
|
14-Jun-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: add TXOP to HE radiotap data We have this data available, so add it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
42d8a9d5 |
|
14-Jun-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: move HE-MU LTF_NUM parsing to he_phy_data parsing This code gets shorter if it doesn't have to check all the conditions, so move it to an appropriate place that has all of them validated already. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
ffe9d734 |
|
14-Jun-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: clean up HE radiotap RU allocation parsing Split the code out into a separate routine, and move that to be called inside the previously introduced iwl_mvm_decode_he_phy_data() function. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
59b8cf0c |
|
14-Jun-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: pull some he_phy_data decoding into a separate function Pull some of the decoding of he_phy_data into a separate function so we don't need to check over and over again if it's valid. While at it, fix the UL/DL bit reporting to be for all but trigger- based frames. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
eb89c0fb |
|
15-Jun-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: put HE SIG-B symbols/users data correctly As detected by Luca during code review when I move this in the next patch, the code here is putting the data into the wrong field (flags1 instead of flags2). Fix that. Fixes: e5721e3f770f ("iwlwifi: mvm: add radiotap data for HE") Reported-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
f9fe5793 |
|
14-Jun-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: minor cleanups to HE radiotap code Remove a stray empty line, unbreak some lines that aren't really that long, and move on variable setting into the initializer to avoid initializing it twice. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
07f62bb9 |
|
14-Jun-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: remove unnecessary overload variable This is equivalent to checking he_phy_data != HE_PHY_DATA_INVAL, which is already done in a number of places, so remove the extra 'overload' variable entirely. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
6c042d75 |
|
12-Jun-2018 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: dbg: group trigger condition to helper function The triplet of get trigger, is trigger enabled and is trigger stopped repeats itself. Group them in a function to avoid code duplication. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
7f768ad5 |
|
07-Nov-2017 |
David Spinadel <david.spinadel@intel.com> |
iwlwifi: mvm: Support TKIP on gen2 data path Make the adjustments for gen2 TX and RX of TKIP packets. Strip MIC on RX. Don't add IV space and keep the MIC space zeroed on TX. Devices that support gen2 data path support TKIP only in station mode. In all other modes, fall back to SW encryption. Do this early in the set_key() callback so that the key flags would not be incorrectly set. Signed-off-by: David Spinadel <david.spinadel@intel.com> Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
a76938f3 |
|
23-May-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: report RU offset is known We already report the RU offset, so we'd better also report that we know the value. Fixes: e5721e3f770f ("iwlwifi: mvm: add radiotap data for HE") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
caf3216f |
|
22-May-2018 |
Shaul Triebitz <shaul.triebitz@intel.com> |
iwlwifi: iwlmvm: fix typo when checking for TX Beamforming Check the actual bit (mask) in Rx notification rate_n_flags. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
764f9de5 |
|
09-May-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: decode HE TB PPDU data Decode the HE TB PPDU data that we get in sniffer mode and use it to populate the HE radiotap information. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
317bc55f |
|
03-May-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: remove channel 2 from HE radiotap if not applicable If the bandwidth is only 20 MHz, then the second channel doesn't exist, but the hardware reports the CRC was OK. Suppress the data of the second channel in the HE radiotap in this case, by marking it as not known. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
925bc2b1 |
|
02-May-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: report # of LTF symbols for extended range SU PPDUs This is the same as for SU PPDUs, so it's easy to do. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
93cc712a |
|
02-May-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: properly decode HE GI duration The GI duration depends on the frame type in some cases, take that into account when decoding for radiotap. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
de8da230 |
|
02-May-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: put LTF symbol size into HE radiotap I evidently completely confused "number of LTF symbols" and "LTF size". Radiotap was reporting the former, while I thought it was the latter, and we really need both. Add the LTF symbol size into the newly defined field in radiotap. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
dabf9844 |
|
26-Apr-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: implement extended HE-MU sniffer API Implement the extended HE-MU info type decoding to show the HE-SIG-B common contents in the HE-MU radiotap field. The DW4 data is partially overwritten by the hardware in all cases, so only the higher 16 bits can be used. To be able to use it for the HE SIG-B common data anyway, move the bits around in the following way: SIG-B common 0: DW 4 -> DW 7 SIG-B common 1: DW 7 -> DW 8 SIG-B common 2: DW 8 -> DW 4 (upper half) Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
4799ea53 |
|
09-Apr-2018 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: move he RX handling to a separate function The HE code is bloating the RX handling, and makes it too big. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
c630b477 |
|
09-Apr-2018 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: move he RX handling to a separate function The HE code is bloating the RX handling, and makes it too big. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
621f3f57 |
|
01-Apr-2018 |
Liad Kaufman <liad.kaufman@intel.com> |
iwlwifi: mvm: add support for RX_AMPDU_EOF bit for HE SU Current implementation turns this bit on only for HE MU. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
bd6fc655 |
|
04-Mar-2018 |
Liad Kaufman <liad.kaufman@intel.com> |
iwlwifi: mvm: add bss color to radiotap Add BSS color to the HE radiotap. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
18ead597 |
|
04-Feb-2018 |
Golan Ben Ami <golan.ben.ami@intel.com> |
iwlwifi: support new rx_mpdu_desc api 22560 devices use a new rx_mpdu_desc api. Update the code to use the new api. Signed-off-by: Golan Ben Ami <golan.ben.ami@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
e5721e3f |
|
26-Jun-2018 |
Luca Coelho <luciano.coelho@intel.com> |
iwlwifi: mvm: add radiotap data for HE Add HE information to the radiotap data. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
514c3069 |
|
24-Jun-2018 |
Luca Coelho <luciano.coelho@intel.com> |
iwlwifi: add support for IEEE802.11ax Add support for the HE in the iwlwifi driver conforming with P802.11ax_D2.0. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
42116705 |
|
22-May-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: fix race in queue notification wait Initially in this code, the race didn't matter since it didn't do anything. Latest with the commit I marked this as fixing it started to matter as something got done here that needed other data that got freed as soon as the queue notification wait was returning. In the scenario we saw, apparently the IWL_MVM_RXQ_NOTIF_DEL_BA event was sent to all queues, but processing the last event we returned from iwl_mvm_sync_rx_queues_internal() and then from iwl_mvm_free_reorder() and continued some processing before wl_mvm_del_ba() was even invoked on the other CPU. Thus, when the latter finally ran, it found that mvm->baid_map[baid] was no longer valid. Correct the race by moving the counter decrement and wake_up() to be done only after all the per-event processing completed. Note that in the commit I marked as being fixed the wake_up() didn't exist yet (and the code was otherwise problematic) but this particular problem already existed in a way. Fixes: b915c10174fb ("iwlwifi: mvm: add reorder buffer per queue") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
fabdcc2e |
|
26-Mar-2018 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: drop UNKNOWN security type frames In some cases we may get from FW errored frames with UNKNOWN security type. This may happen in unsecured aggregation flow, where the first packet had a CRC error in the WEP bit, which was followed by a failure to decrypt and was dropped. The next frames in the aggregation "inherit" the bad metadata of the first packet. Make sure to drop such frames since RADA and other offloads will not operate correctly which may have unexpected results. In case of AP it also causes to TX AMSDU frames to the peers, resulting with assert 0x104B. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
1e5b7750 |
|
20-Feb-2018 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: move skb padding reservation earlier Future changes will require moving the HE radiotap data into the SKB head, but this means we need to have the alignment reservation done before that. To prepare, move the alignment reservation earlier here. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
8f66e064 |
|
17-Jan-2018 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: use the new get_tid function This saves some typing and is overall more readable. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
7d9d0d56 |
|
12-Apr-2018 |
Luca Coelho <luciano.coelho@intel.com> |
iwlwifi: mvm: add traffic condition monitoring (TCM) Traffic condition monitor gathers data about the traffic load and other conditions and can be used to make decisions regarding latency, throughput etc. This patch introduces the code and data structures to collect this data for future use. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
e4d72208 |
|
19-Dec-2017 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: flip AMSDU addresses only for 9000 family Hardware bug was fixed in later generation. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
5ab2ba93 |
|
29-Mar-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: fix security bug in PN checking A previous patch allowed the same PN for packets originating from the same AMSDU by copying PN only for the last packet in the series. This however is bogus since we cannot assume the last frame will be received on the same queue, and if it is received on a different ueue we will end up not incrementing the PN and possibly let the next packet to have the same PN and pass through. Change the logic instead to driver explicitly indicate for the second sub frame and on to be allowed to have the same PN as the first subframe. Indicate it to mac80211 as well for the fallback queue. Fixes: f1ae02b186d9 ("iwlwifi: mvm: allow same PN for de-aggregated AMSDU") Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
57df3839 |
|
06-Dec-2017 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: support RX flags API change Latest firmware calculates both phases of the TKIP field, so the TTAK ok flag is not needed and deprecated. Support this API change. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
ecaf71de |
|
31-Oct-2017 |
Gregory Greenman <gregory.greenman@intel.com> |
iwlwifi: mvm: rs: introduce new API for rate scaling New devices will have rate scaling algorithm running in the firmware. With this feature, the driver's responsiblity is to provide an initial configuration and to handle notifications regarding recent rates and some other parameters. Debugfs hooks will be still available for reading the current rate/statistics and setting a fixed rate. The old API is supported so far, though both APIs cannot be used simultaneously. This is the first patch in the series. It adds a new TLV specifying FW support for the new API and updates lq_sta to support two types of rate scaling. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
bf190370 |
|
08-Feb-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: mark MIC stripped MPDUs When RADA is active, the hardware decrypts the packets and strips off the MIC as it is useless after decryption. Indicate that to mac80211. Cc: stable@vger.kernel.org # 4.13+ [this is needed for the 9000-series HW to work properly] Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
9d0fc5a5 |
|
21-Nov-2016 |
David Spinadel <david.spinadel@intel.com> |
iwlwifi: mvm: enable RX offloading with TKIP and WEP Set the flag that indicates that ICV was stripped on if this option was enabled in the HW. Cc: stable@vger.kernel.org # 4.13+ [this is needed for the 9000-series HW to work properly] Signed-off-by: David Spinadel <david.spinadel@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
4c59ff5a |
|
29-Oct-2017 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: check for short GI only for OFDM This bit will be used in CCK to indicate short preamble. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
c4e45c84 |
|
30-Oct-2017 |
Shaul Triebitz <shaul.triebitz@intel.com> |
iwlwifi: mvm: set correct chains in Rx status ieee80211_rx_status::chains was always set to zero. That caused rate scaling to always start with the lowest rate possible (rs_get_initial_rate). Set it correctly according to the MPDU response. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
364a1ab9 |
|
25-Oct-2017 |
Shahar S Matityahu <shahar.s.matityahu@intel.com> |
iwlwifi: drop RX frames during hardware restart In case of a hardware restart the BA session data in HW is lost so the reorder buffer simply passes the frames to mac80211 as is as there is no NSSN set. Instead, we will drop these frames before they reach the reorder buffer. mac80211 drops such frames anyway, but we shouldn't rely on that. In addition it saves some processing time Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
8cef5344 |
|
24-Oct-2017 |
Kees Cook <keescook@chromium.org> |
iwlwifi: mvm: Convert timers to use timer_setup() In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. The RCU lifetime on baid_data is unclear, so this adds a direct copy of the rcu_ptr passed to the original callback. It may be possible to improve this to just use baid_data->mvm->baid_map[baid_data->baid] instead. Cc: Johannes Berg <johannes.berg@intel.com> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Cc: Luca Coelho <luciano.coelho@intel.com> Cc: Intel Linux Wireless <linuxwifi@intel.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: Sara Sharon <sara.sharon@intel.com> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
14a1f85b |
|
16-Oct-2017 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: improve latency when there is a reorder timeout When there is a reorder timeout, we may get to a situation where we have the timeout latency for all the next 64 frames. This happens since NSSN is behind for a while, and the driver won't release the frames, since it is not allowed by NSSN. As a result the frame is stored in the reorder buffer although there is no hole, and released 100 ms later. Add a direct comparison to the reorder buffer head, and release immediately if possible. For example: Frame 0 is missed. We receive frame 1, and store it in the buffer. After 100 ms, frame 1 is released and reorder buffer head is 2. We then receive frame 2, with NSSN 0, and store it instead of releasing it. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
76f4a85e |
|
02-Oct-2017 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: pass baid_data to iwl_mvm_release_frames() All callers of iwl_mvm_release_frames() already have the baid_data pointer, so we don't need to (re)calculate it inside the function. Just pass it instead. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
3f1c4c58 |
|
01-Oct-2017 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: remove duplicated fields in mvm reorder buffer The reason station id and tid fields are both in baid data and in the reorder buffer per queue is that we couldn't access the baid_data in the reorder timer functions. Now that we do some pointer math and access it anyway, those fields can be removed. This save some space and some code. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
dfdddd92 |
|
25-Sep-2017 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: allocate reorder buffer according to need Now that we may have up to 256 entries per reorder buffer, and possibly up to 16 queues, we can use a LOT of memory for this (64k for each station). Allocate it according to what we need, which is of course much less for HT stations (only 16k at a max of 16 queues). However, this comes at the expense of complicating the code a bit to calculate the right entry structure to use for each frame. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
417795a3 |
|
28-Sep-2017 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: change warning to warn_once() In case there is a FW bug where the BAID value in the metadata is not properly initialized we hit the warning for every RX packet. Change it to warn once and add elaborate message. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
528a542a |
|
31-Aug-2017 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
iwlwifi: mvm: support firmware debug trigger on frame reorder timeout The trigger that collects data when a frame is released because of the timer of the reordering buffer was not implemented for 9000 devices. Fix this. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
baf41bc3 |
|
13-Sep-2017 |
Shaul Triebitz <shaul.triebitz@intel.com> |
iwlwifi: mvm: do not print security error in monitor mode In monitor mode we are not expected to decrypt encrypted packets (not having the keys). Hence we are expected to get an unknown rx security status. Keeping the print in monitor mode causes a print for each captured packet flooding the dmesg. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
5f90472c |
|
04-Sep-2017 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: fix reorder buffer for 9000 devices The condition to check if reorder buffer ran out of space is faulty, as it takes into account only the NSSN. In case the head SN was too far behind the reorder buffer should move forward, regardless of the NSSN status. This caused the driver to release packets out of order in some scenarios. Fixes: b915c10174fb ("iwlwifi: mvm: add reorder buffer per queue") Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
790e6634 |
|
27-Jul-2017 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
iwlwifi: mvm: include more debug data when we get an unexpected baid When we get a valid baid in a received frame, we need to check that we are aware of this baid. If not, we check that the OLD_SN bit set. If that's not the case, we issue a WARNING. Print more data when that happens. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
a600852a |
|
27-Jul-2017 |
Emmanuel Grumbach <emmanuel.grumbach@intel.com> |
iwlwifi: mvm: don't WARN when a legit race happens in A-MPDU When we start an Rx A-MPDU session, we first get the AddBA request, then we send an ADD_STA command to the firmware that will reply with a BAID which is a hardware resource that tracks the BA session. This BAID will appear on each and every frame that we get from the firwmare until the A-MPDU session is torn down. In the Rx path, we look at this BAID to manage the reordering buffer. This flow is inherently racy since the hardware will start to put the BAID in the frames it receives even if the firmware hasn't sent the response to the ADD_STA command. This basically means that the driver can get frames with a valid BAID that it doesn't know yet. When that happens, the driver used to WARN. Fix this by simply not WARN in this case. When the driver will know abou the BAID, it will initialise the relevant states and the next frame with a valid BAID will refresh them. Fixes: b915c10174fb ("iwlwifi: mvm: add reorder buffer per queue") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
c67a3d05 |
|
07-Jun-2017 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: byte-swap constant instead of variable Convention has it to byte-swap the constant instead of the variable when doing bit checks. This also generates better code when the swap is actually needed, since the constant can be swapped at compile-time. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
7174beb6 |
|
01-Jun-2017 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: refactor firmware debug code Split out the firmware debug code to be more general, so that it can be used by different subdrivers. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
aeb8012c |
|
19-Apr-2017 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: remove pointless num_stored condition Since we exit if buf->num_stored is 0, there's no need to check it again later. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
59ae1d12 |
|
16-Jun-2017 |
Johannes Berg <johannes.berg@intel.com> |
networking: introduce and use skb_put_data() A common pattern with skb_put() is to just want to memcpy() some data into the new space, introduce skb_put_data() for this. An spatch similar to the one for skb_put_zero() converts many of the places using it: @@ identifier p, p2; expression len, skb, data; type t, t2; @@ ( -p = skb_put(skb, len); +p = skb_put_data(skb, data, len); | -p = (t)skb_put(skb, len); +p = skb_put_data(skb, data, len); ) ( p2 = (t2)p; -memcpy(p2, data, len); | -memcpy(p, data, len); ) @@ type t, t2; identifier p, p2; expression skb, data; @@ t *p; ... ( -p = skb_put(skb, sizeof(t)); +p = skb_put_data(skb, data, sizeof(t)); | -p = (t *)skb_put(skb, sizeof(t)); +p = skb_put_data(skb, data, sizeof(t)); ) ( p2 = (t2)p; -memcpy(p2, data, sizeof(*p)); | -memcpy(p, data, sizeof(*p)); ) @@ expression skb, len, data; @@ -memcpy(skb_put(skb, len), data, len); +skb_put_data(skb, data, len); (again, manually post-processed to retain some comments) Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
8613c948 |
|
26-Apr-2017 |
Johannes Berg <johannes.berg@intel.com> |
mac80211: rename ieee80211_rx_status::vht_nss to just nss This field will need to be used again for HE, so rename it now. Again, mostly done with this spatch: @@ expression status; @@ -status->vht_nss +status->nss @@ expression status; @@ -status.vht_nss +status.nss Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
da6a4352 |
|
25-Apr-2017 |
Johannes Berg <johannes.berg@intel.com> |
mac80211: separate encoding/bandwidth from flags We currently use a lot of flags that are mutually incompatible, separate this out into actual encoding and bandwidth enum values. Much of this again done with spatch, with manual post-editing, mostly to add the switch statements and get rid of the conversions. @@ expression status; @@ -status->enc_flags |= RX_ENC_FLAG_80MHZ +status->bw = RATE_INFO_BW_80 @@ expression status; @@ -status->enc_flags |= RX_ENC_FLAG_40MHZ +status->bw = RATE_INFO_BW_40 @@ expression status; @@ -status->enc_flags |= RX_ENC_FLAG_20MHZ +status->bw = RATE_INFO_BW_20 @@ expression status; @@ -status->enc_flags |= RX_ENC_FLAG_160MHZ +status->bw = RATE_INFO_BW_160 @@ expression status; @@ -status->enc_flags |= RX_ENC_FLAG_5MHZ +status->bw = RATE_INFO_BW_5 @@ expression status; @@ -status->enc_flags |= RX_ENC_FLAG_10MHZ +status->bw = RATE_INFO_BW_10 @@ expression status; @@ -status->enc_flags |= RX_ENC_FLAG_VHT +status->encoding = RX_ENC_VHT @@ expression status; @@ -status->enc_flags |= RX_ENC_FLAG_HT +status->encoding = RX_ENC_HT @@ expression status; @@ -status.enc_flags |= RX_ENC_FLAG_VHT +status.encoding = RX_ENC_VHT @@ expression status; @@ -status.enc_flags |= RX_ENC_FLAG_HT +status.encoding = RX_ENC_HT @@ expression status; @@ -(status->enc_flags & RX_ENC_FLAG_HT) +(status->encoding == RX_ENC_HT) @@ expression status; @@ -(status->enc_flags & RX_ENC_FLAG_VHT) +(status->encoding == RX_ENC_VHT) @@ expression status; @@ -(status->enc_flags & RX_ENC_FLAG_5MHZ) +(status->bw == RATE_INFO_BW_5) @@ expression status; @@ -(status->enc_flags & RX_ENC_FLAG_10MHZ) +(status->bw == RATE_INFO_BW_10) @@ expression status; @@ -(status->enc_flags & RX_ENC_FLAG_40MHZ) +(status->bw == RATE_INFO_BW_40) @@ expression status; @@ -(status->enc_flags & RX_ENC_FLAG_80MHZ) +(status->bw == RATE_INFO_BW_80) @@ expression status; @@ -(status->enc_flags & RX_ENC_FLAG_160MHZ) +(status->bw == RATE_INFO_BW_160) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
7fdd69c5 |
|
26-Apr-2017 |
Johannes Berg <johannes.berg@intel.com> |
mac80211: clean up rate encoding bits in RX status In preparation for adding support for HE rates, clean up the driver report encoding for rate/bandwidth reporting on RX frames. Much of this patch was done with the following spatch: @@ expression status; @@ -status->flag & (RX_FLAG_HT | RX_FLAG_VHT) +status->enc_flags & (RX_ENC_FLAG_HT | RX_ENC_FLAG_VHT) @@ assignment operator op; expression status; @@ -status->flag op RX_FLAG_SHORTPRE +status->enc_flags op RX_ENC_FLAG_SHORTPRE @@ expression status; @@ -status->flag & RX_FLAG_SHORTPRE +status->enc_flags & RX_ENC_FLAG_SHORTPRE @@ assignment operator op; expression status; @@ -status->flag op RX_FLAG_HT +status->enc_flags op RX_ENC_FLAG_HT @@ expression status; @@ -status->flag & RX_FLAG_HT +status->enc_flags & RX_ENC_FLAG_HT @@ assignment operator op; expression status; @@ -status->flag op RX_FLAG_40MHZ +status->enc_flags op RX_ENC_FLAG_40MHZ @@ expression status; @@ -status->flag & RX_FLAG_40MHZ +status->enc_flags & RX_ENC_FLAG_40MHZ @@ assignment operator op; expression status; @@ -status->flag op RX_FLAG_SHORT_GI +status->enc_flags op RX_ENC_FLAG_SHORT_GI @@ expression status; @@ -status->flag & RX_FLAG_SHORT_GI +status->enc_flags & RX_ENC_FLAG_SHORT_GI @@ assignment operator op; expression status; @@ -status->flag op RX_FLAG_HT_GF +status->enc_flags op RX_ENC_FLAG_HT_GF @@ expression status; @@ -status->flag & RX_FLAG_HT_GF +status->enc_flags & RX_ENC_FLAG_HT_GF @@ assignment operator op; expression status; @@ -status->flag op RX_FLAG_VHT +status->enc_flags op RX_ENC_FLAG_VHT @@ expression status; @@ -status->flag & RX_FLAG_VHT +status->enc_flags & RX_ENC_FLAG_VHT @@ assignment operator op; expression status; @@ -status->flag op RX_FLAG_STBC_MASK +status->enc_flags op RX_ENC_FLAG_STBC_MASK @@ expression status; @@ -status->flag & RX_FLAG_STBC_MASK +status->enc_flags & RX_ENC_FLAG_STBC_MASK @@ assignment operator op; expression status; @@ -status->flag op RX_FLAG_LDPC +status->enc_flags op RX_ENC_FLAG_LDPC @@ expression status; @@ -status->flag & RX_FLAG_LDPC +status->enc_flags & RX_ENC_FLAG_LDPC @@ assignment operator op; expression status; @@ -status->flag op RX_FLAG_10MHZ +status->enc_flags op RX_ENC_FLAG_10MHZ @@ expression status; @@ -status->flag & RX_FLAG_10MHZ +status->enc_flags & RX_ENC_FLAG_10MHZ @@ assignment operator op; expression status; @@ -status->flag op RX_FLAG_5MHZ +status->enc_flags op RX_ENC_FLAG_5MHZ @@ expression status; @@ -status->flag & RX_FLAG_5MHZ +status->enc_flags & RX_ENC_FLAG_5MHZ @@ assignment operator op; expression status; @@ -status->vht_flag op RX_VHT_FLAG_80MHZ +status->enc_flags op RX_ENC_FLAG_80MHZ @@ expression status; @@ -status->vht_flag & RX_VHT_FLAG_80MHZ +status->enc_flags & RX_ENC_FLAG_80MHZ @@ assignment operator op; expression status; @@ -status->vht_flag op RX_VHT_FLAG_160MHZ +status->enc_flags op RX_ENC_FLAG_160MHZ @@ expression status; @@ -status->vht_flag & RX_VHT_FLAG_160MHZ +status->enc_flags & RX_ENC_FLAG_160MHZ @@ assignment operator op; expression status; @@ -status->vht_flag op RX_VHT_FLAG_BF +status->enc_flags op RX_ENC_FLAG_BF @@ expression status; @@ -status->vht_flag & RX_VHT_FLAG_BF +status->enc_flags & RX_ENC_FLAG_BF @@ assignment operator op; expression status, STBC; @@ -status->flag op STBC << RX_FLAG_STBC_SHIFT +status->enc_flags op STBC << RX_ENC_FLAG_STBC_SHIFT @@ assignment operator op; expression status; @@ -status.flag op RX_FLAG_SHORTPRE +status.enc_flags op RX_ENC_FLAG_SHORTPRE @@ expression status; @@ -status.flag & RX_FLAG_SHORTPRE +status.enc_flags & RX_ENC_FLAG_SHORTPRE @@ assignment operator op; expression status; @@ -status.flag op RX_FLAG_HT +status.enc_flags op RX_ENC_FLAG_HT @@ expression status; @@ -status.flag & RX_FLAG_HT +status.enc_flags & RX_ENC_FLAG_HT @@ assignment operator op; expression status; @@ -status.flag op RX_FLAG_40MHZ +status.enc_flags op RX_ENC_FLAG_40MHZ @@ expression status; @@ -status.flag & RX_FLAG_40MHZ +status.enc_flags & RX_ENC_FLAG_40MHZ @@ assignment operator op; expression status; @@ -status.flag op RX_FLAG_SHORT_GI +status.enc_flags op RX_ENC_FLAG_SHORT_GI @@ expression status; @@ -status.flag & RX_FLAG_SHORT_GI +status.enc_flags & RX_ENC_FLAG_SHORT_GI @@ assignment operator op; expression status; @@ -status.flag op RX_FLAG_HT_GF +status.enc_flags op RX_ENC_FLAG_HT_GF @@ expression status; @@ -status.flag & RX_FLAG_HT_GF +status.enc_flags & RX_ENC_FLAG_HT_GF @@ assignment operator op; expression status; @@ -status.flag op RX_FLAG_VHT +status.enc_flags op RX_ENC_FLAG_VHT @@ expression status; @@ -status.flag & RX_FLAG_VHT +status.enc_flags & RX_ENC_FLAG_VHT @@ assignment operator op; expression status; @@ -status.flag op RX_FLAG_STBC_MASK +status.enc_flags op RX_ENC_FLAG_STBC_MASK @@ expression status; @@ -status.flag & RX_FLAG_STBC_MASK +status.enc_flags & RX_ENC_FLAG_STBC_MASK @@ assignment operator op; expression status; @@ -status.flag op RX_FLAG_LDPC +status.enc_flags op RX_ENC_FLAG_LDPC @@ expression status; @@ -status.flag & RX_FLAG_LDPC +status.enc_flags & RX_ENC_FLAG_LDPC @@ assignment operator op; expression status; @@ -status.flag op RX_FLAG_10MHZ +status.enc_flags op RX_ENC_FLAG_10MHZ @@ expression status; @@ -status.flag & RX_FLAG_10MHZ +status.enc_flags & RX_ENC_FLAG_10MHZ @@ assignment operator op; expression status; @@ -status.flag op RX_FLAG_5MHZ +status.enc_flags op RX_ENC_FLAG_5MHZ @@ expression status; @@ -status.flag & RX_FLAG_5MHZ +status.enc_flags & RX_ENC_FLAG_5MHZ @@ assignment operator op; expression status; @@ -status.vht_flag op RX_VHT_FLAG_80MHZ +status.enc_flags op RX_ENC_FLAG_80MHZ @@ expression status; @@ -status.vht_flag & RX_VHT_FLAG_80MHZ +status.enc_flags & RX_ENC_FLAG_80MHZ @@ assignment operator op; expression status; @@ -status.vht_flag op RX_VHT_FLAG_160MHZ +status.enc_flags op RX_ENC_FLAG_160MHZ @@ expression status; @@ -status.vht_flag & RX_VHT_FLAG_160MHZ +status.enc_flags & RX_ENC_FLAG_160MHZ @@ assignment operator op; expression status; @@ -status.vht_flag op RX_VHT_FLAG_BF +status.enc_flags op RX_ENC_FLAG_BF @@ expression status; @@ -status.vht_flag & RX_VHT_FLAG_BF +status.enc_flags & RX_ENC_FLAG_BF @@ assignment operator op; expression status, STBC; @@ -status.flag op STBC << RX_FLAG_STBC_SHIFT +status.enc_flags op STBC << RX_ENC_FLAG_STBC_SHIFT @@ @@ -RX_FLAG_STBC_SHIFT +RX_ENC_FLAG_STBC_SHIFT Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
77e40945 |
|
11-Jan-2017 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: support new rate flags Rates were changed to adapt to HE. Change is backward compatible. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
9dfa2151 |
|
14-Feb-2017 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: flip address 4 of AMSDU frames Address 4 is reversed as well. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
cb2de6bb |
|
13-Feb-2017 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: dump frames early on invalid rate Currently when rate isn't found (invalid rate or CCK rate in high band) driver is assigning rate -1, which causes mac80211 to dump it later with the cryptic rate value of 0xFF. Instead, warn early and dump the frame in mvm. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
5d43eab6 |
|
01-Feb-2017 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: ignore BAID for SN smaller than SSN When we get SN that is smaller than SSN of the aggregation, we shouldn't apply any reordering on them. Further more, HW NSSN will be zeroed, which can cause us to make some invalid decisions. Detect the situation and invalidate the BAID. Fixes: b915c10174fb ("iwlwifi: mvm: add reorder buffer per queue") Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
a56cb4f0 |
|
31-Jan-2017 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: work around HW issue with AMSDU de-aggregation Seems like HW is reversing addr3 in the MAC header of de-aggregated AMSDU. Reverse it back. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
bbf049d9 |
|
19-May-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: do not turn on RX_FLAG_AMSDU_MORE This flag is used for mac80211 reordering. As we do reordering ourselves, turning it on is misleading and pointless. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
0ae98812 |
|
04-Jan-2017 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: prepare for station count change In a000 devices we will support up to 32 stations. The max station define is used also for invalid station marking which makes finding usages of actual maximum station pretty hard to sort through - change it to be a different define in order to make future changes easier. Use also ARRAY_SIZE intead of define when possible. Do not move yet to 32 stations until firmware do it though. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
9c36fd71 |
|
04-Jan-2017 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: optimize reorder timeout frame releasing Currently we release up to the last expired frame. However, if there are consecutive frames after it - we can optimize it further and release them as well - until the next hole. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
5351f9ab |
|
03-Jan-2017 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: fix reorder timer re-arming When NSSN is behind the reorder buffer due to timeout the reorder timer isn't getting re-armed until NSSN catches up. Fix it. Fixes: 0690405fef29 ("iwlwifi: mvm: add reorder timeout per frame") Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
4b40571e |
|
08-Dec-2016 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: align copy-break SKB payload for MQ RX When a small frame is copied completely into the skb->head, the code doesn't take alignment into account, making mac80211 copy it again later on architectures that need the alignment. Avoid this by taking the PAD flag from the device into account when copying. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
3a732c65 |
|
09-Oct-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: wake the wait queue when the RX sync counter is zero When we sync the RX queues the driver waits to receive echo notification on all the RX queues. The wait queue is set with timeout until all queues have received the notification. However, iwl_mvm_rx_queue_notif() never woke up the wait queue, with the result of the counter value being checked only when the timeout expired. This may cause a latency of up to 1 second. Fixes: 0636b938214c ("iwlwifi: mvm: implement driver RX queues sync command") Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
8ec8ed43 |
|
18-Aug-2016 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: document passing unexpected Block Ack Request frames When we get an unexpected Block Ack Request frame, the BAID from the hardware will be invalid, and we'll pass it to mac80211 for further handling (sending a delBA action frame.) Add a comment explaining that, in case anyone looks in the future. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
9a73a7d2 |
|
08-Aug-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: support BAR in reorder buffer On default queue we will not receive frame release notification, but the BAR itself. Upon receiving the BAR driver should look at the NSSN and adjust window accordingly. Fixes: b915c10174fb ("iwlwifi: mvm: add reorder buffer per queue") Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
5a710b86 |
|
03-Aug-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: cleanup skb queue functions use Use skb_queue_empty() and not skb_peek_tail() to check for empty list. Avoid a redundant check as well - loop will take care of it. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
fd659f8e |
|
03-Aug-2016 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: tighten BAID range check As pointed out by smatch, checking the BAID for just >= INVALID is a bad idea since only 32 (IWL_MAX_BAID) actually exist. Check the range for that and print invalid ones in the warning. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
9b856836 |
|
03-Aug-2016 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: remove pointless _bh from spinlock in timer Inside the reorder timer expire function, there's no point in disabling BHs since it is in BH context. Remove that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
f1ae02b1 |
|
06-Mar-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: allow same PN for de-aggregated AMSDU The 9000 hardware will de-aggregate AMSDUs. In the process it will copy the mac header "as is" to the new MPDUs. This means driver should allow the same PN for MPDUs originated from the same AMSDU. Do that by incrementing the PN only for the last MPDU in the sequence. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
35263a03 |
|
20-Jun-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: add RX aggregation prints Add some prints to track BAID assignment. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
d3a108a4 |
|
28-Feb-2016 |
Andrei Otcheretianski <andrei.otcheretianski@intel.com> |
iwlwifi: mvm: Support CSA countdown offloading Add support CSA countdown offloading. When CSA starts, the driver specifies the offsets to the eCSA and CSA IEs in the beacon template command and the fw performs the countdown. The fw notifies the driver when the channel switch flow should be performed. Beacon sent notifications are not used anymore. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
fbe41127 |
|
04-Apr-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: update mpdu metadata API rx_phy notification is no longer sent in devices with multiple rx queues. All the needed data is now set in the metadata - update code accordingly to reflect all the features as in the previous RX path. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
6d99c88f |
|
03-Apr-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: remove RX_PHY support for 9000 device In multiple RX queues architecture, the RX_PHY notification is no longer useful as it is received in the default queue even for packets that are received on RSS queue, and cannot be accessed without locking. All the needed data is in the new RX packet metadata and firmware will no longer send this notification for 9000 devices. Remove support of it. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
e7e14089 |
|
17-Apr-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: do not trust NSSN for amsdu sub-frames We cannot trust NSSN for AMSDU sub-frames that are not the last. The reason is that NSSN advances on the first sub-frame, and may cause the reorder buffer to advance before all the sub-frames arrive. Example: Reorder buffer contains SN 0 & 2. We receive AMSDU with SN 1 and NSSN for first sub frame 3. The result us that driver releases SN 0,1, 2. When sub-frame 1 arrives - reorder buffer is already ahead and it will be dropped. If the last sub-frame is not on this queue - we will get frame release notification with up to date NSSN. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
1f9788f3 |
|
16-May-2016 |
Luca Coelho <luciano.coelho@intel.com> |
iwlwifi: mvm: fix potential NULL-dereference in iwl_mvm_reorder() We try to access sta before we check for IS_ERR_OR_NULL(), so we may end up accessing a NULL pointer. To prevent that, move the conversion from sta to mvm_sta below the check. Fixes: b915c10174fb ("iwlwifi: mvm: add reorder buffer per queue") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
74dd1764 |
|
30-Mar-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: loosen nssn comparison to reorder buffer head Up till now, the reorder buffer uses standard spec based comparison when comparing the buffer status to NSSN. This indeed works for the regular case, since we shouldn't cross the 2048 boundary without getting a frame release notification. However, this is problematic due to packet filtering that may be performed by the FW while we are in d0i3. Theoretically we may filter over 2048 packets, and then the check of the NSSN will get incorrect. Change the comparison to always trust nssn unless it is 64 or less frames behind the head - which might happen due to a timeout. This new comparison is to be used only when comparing reorder buffer head with nssn, and not when comparing the packet SN to nssn or reorder buffer head. Put this in a separate commit as the logic is a bit tricky and stands for its own commit message. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
43ec72b7 |
|
10-Mar-2016 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: pass station to mac80211 RX where known When we've already looked up the transmitter station, we can just pass it to mac80211 using the new ieee80211_rx_napi(). This saves the overhead of looking it up in mac80211 again. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
a338384b |
|
28-Feb-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: utilize the frame release infrastructure The firmware will send frame release notification in order to release "stuck" frames on a queue where no more frames arrive on. Upon receiving the message the driver shall indicate the frames up to the NSSN. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
0690405f |
|
28-Feb-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: add reorder timeout per frame Add a timer in order to release expired frames from the reorder buffer. This is needed since some APs do not retransmit frames to fill in the reorder holes and in TCP it results with a complete stall of traffic. This has a few side effects on the general design: The nssn may not reflect the the head of the reorder buffer. This situation is valid, and packets with SN lower than the reorder buffer head will be dropped. Another side effect is that since the reorder timer might expire we need to lock the reorder buffer. This however is fine since the locking is only inside a single reorder buffer between RX path and reorder timeout and there is no outside contention. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
b915c101 |
|
23-Mar-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: add reorder buffer per queue Next hardware will direct packets to core based on the TCP/UDP streams. This logic can create holes in reorder buffer since packets that belong to other stream were directed to a different core. However, those are valid holes and the packets can be indicated in L3 order. The hardware will utilize a mechanism of informing the driver of the normalized ssn and the driver shall release all packets that SN is lower than the nssn. This enables managing the reorder across the queues without sharing any data between them. The reorder buffer is allocated and released directly in the RX path in order to avoid various races between control path and rx path. The code utilizes the internal messaging to notify rx queues of when to delete the reorder buffer. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
10b2b201 |
|
20-Mar-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: add infrastructure for tracking BA session in driver According to the spec when a BA session is started there is a timeout set for the session in the ADDBA request. If there is not activity on the TA/TID then the session expires and a DELBA is sent. In order to check for the timeout, data must be shared among the rx queues. Add a timer that runs as long as BA session is active for the station and stops aggregation session if needed. This patch also lays the infrastructure for the reordering buffer which will be enabled in the next patches. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
d0ff5d22 |
|
23-Mar-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: change RX sync notification to be an attribute and not a type Currently the sync notification is a type of notification. However, it is better fitted as an attribute of a notification, since there might be another message in the payload (delba for instance) that should be sent while control path is waiting for all queues to process. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
0636b938 |
|
18-Feb-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: implement driver RX queues sync command mac80211 will call the driver whenever there is a race between RSS queues and control path that requires a processing of all pending frames in RSS queues. Implement that by utilizing the internal notification mechanism: queue a message to all queues. When the message is received on a queue it decrements the atomic counter. This guarantees that all pending frames in the RX queue were processed since the message is in order inside the queue. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
#
57fbcce3 |
|
12-Apr-2016 |
Johannes Berg <johannes.berg@intel.com> |
cfg80211: remove enum ieee80211_band This enum is already perfectly aliased to enum nl80211_band, and the only reason for it is that we get IEEE80211_NUM_BANDS out of it. There's no really good reason to not declare the number of bands in nl80211 though, so do that and remove the cfg80211 one. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
d63b548f |
|
31-Mar-2016 |
Johannes Berg <johannes.berg@intel.com> |
mac80211: allow passing transmitter station on RX Sometimes drivers already looked up, or know out-of-band from their device, which station transmitted a given RX frame. Allow them to pass the station pointer to mac80211 to save the extra lookup. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
b238be07 |
|
16-Mar-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: report checksum is done also for IPv6 packets Currently the code checks if hardware reported both L4 and L3 checksums as valid, and only then reports it as validated to the stack. However, IPv6 does not have checksum at all and the L3 checksum valid bit is always off for IPv6 packets, with the result of the stack re-validating L4 checksum. Fix code to set CHECKSUM_UNNECESSARY also for IPv6 packets whose TCP/UDP checksum was verified. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
#
62d23403 |
|
06-Mar-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: turn off AMSDU bit in QoS control for de-aggregated AMSDUs Our hardware de-aggregates AMSDUs but copies the mac header as it to the de-aggregated MPDUs. We need to turn off the AMSDU bit in the QoS control ourselves. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
#
e29cc6b9 |
|
28-Jan-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: take care of padded packets To ensure that the SNAP/TCP/IP headers are DW aligned, the firmware may add 2-byte pad at the end of the mac header - after the IV, before the SNAP. In that case the mpdu descriptor pad bit will be turned on. Driver should take it into consideration, and remove the padding before passing the packet to mac80211. Do that. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
#
94bb4481 |
|
16-Dec-2015 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: add RSS queues notification infrastructure In multi rx queue HW, without execessive locking, there is no sync between the ctrl path (default queue) and the rest of the rx queues. This might cause issues on certain situations. For example, in case a delBA was processed on a default queue but out of order packets still wait for processing on the other queue. The solution is to introduce internal messaging between the CTRL path and the other rx queues. The driver will send a message to the firmware, which will echo it to all the requested queues. The message will be in order inside the queue. This way we can avoid CTRL path and RSS queues races. Add support for this messaging mechanism. As the firmware is agnostic to the data sent, add internal representation of the data as well. Although currently only delBA flow will use it, the internal representation will enable generic use of this infrastructure for future uses. Next patch will utilize this messaging mechanism for the reorder buffer delBA flow. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
#
a571f5f6 |
|
06-Dec-2015 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: add duplicate packet detection per rx queue Next hardware will direct TCP/UDP streams to different cores. Packets belonging to the same stream will be directed to the same core. The result is that duplicates will be always directed to the same rx queue were the first packet was received. This enabled parallelizing the duplicate packet detection across the different cores, without sharing data between the rx queues. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
#
77fe7395 |
|
10-Jan-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: update rx_status with mactime flag When forming IBSS, mac80211 scans in order to find an already existing cell to join. In case the scan does not find any existing cell a new IBSS cell is formed. When receiving the beacons of another IBSS cell we should merge if the other IBSS cell's TSF is higher than ours. However, currently iwlmvm does not set any timestamp flag in rx_status so there is no valid rx timestamp to compare the beacon's TSF to. The reason for that is that TSF as indicated by the firmware is at INA time, but up till now mac80211 expected the TSF at the beginning or end of the MPDU. Set the flag to the newly added RX_FLAG_MACTIME_PLCP_START flag. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
#
d56a7801 |
|
25-Jan-2016 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: pcie: update iwl_mpdu_desc fields Final API of iwl_mpdu_desc has a change in the order of the fields and does not include energy from the third antenna (which is perfectly fine, since we don't have one). Update the structure accordingly. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
#
0c1c6e37 |
|
16-Dec-2015 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: change access to ieee80211_hdr Make the code clearer. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
#
f5e28eac |
|
06-Dec-2015 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: check PN for CCMP/GCMP in the driver As we're working on multi-queue RX, we want to parallelise checking the PN in order to avoid having to serialise the RX processing. It may seem that doing parallel PN checking is insecure, but it turns out to be OK because queue assignment is done based on the data in the frame (IP/TCP) and thus cannot be manipulated by an attacker, since the data is encrypted and must first have been decrypted successfully. There are some corner cases, in particular when the peer starts using fragmentation which redirects the packet to the default queue. However this redirection is remembered (for the STA, per TID) and thus cannot be exploited by an attacker either. Leave checking on the default queue (queue 0) to mac80211, since we get fragmented packets there and those are subject to stricter checks during reassembly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
#
585a6fcc |
|
01-Dec-2015 |
Sara Sharon <sara.sharon@intel.com> |
iwlwifi: mvm: infrastructure for frame-release message Incoming hardware will send frame release notifications to the reorder buffer in order to update with the BA session status and up to date NSSN. This patch enables the API. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
#
780e87c2 |
|
03-Sep-2015 |
Johannes Berg <johannes.berg@intel.com> |
iwlwifi: mvm: add 9000 series RX processing Convert the convert the new infrastructure added by previous patches to actually use the new RX descriptor layout. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|