- 18 2月, 2022 13 次提交
-
-
由 Johannes Berg 提交于
Newer firmware versions will support a new queue allocation command, in order to deal with MLD where multiple stations are used for a single queue. Add support for the new command. This requires some refactoring of the queue allocation API, which now gets - the station mask instead of the station ID - the flags without the "enable" flag, since that's no longer used in the new API Additionally, this new API now requires that we remove queues before removing a station, the firmware will no longer do that internally. Also add support for that. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220210181930.acbf22ac2b66.I2bf38578c5ca1f7ffb2011a782f772db92fc4965@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Johannes Berg 提交于
It's always zero, just remove it. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220210181930.dc67b3c04d0f.I5fbc552812ab91f2c4b158eee39f63c44575db1b@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Johannes Berg 提交于
The command ID here is always hard-coded to the same, so we can remove it. In the future we actually need to make this configurable, but that doesn't need to be on each call, it can be done through the transport configuration. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220210181930.8b352828f767.Ice4c91d8ea3e207914104e72801b87cd7f409ba7@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Johannes Berg 提交于
There's no need to have this in a different place, it's only used in a single C file (sta.c). Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220205112029.699b4b9c2232.I0d7970d800a51fee5135946ee03a7d9e8a811893@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Luca Coelho 提交于
With the new ML API, we can't send the BAID removal command to firmware during hw_restart because it will cause an assertion failure 0x350D because the BAID doesn't exist at that point. So avoid sending the command if we are performing a hw_restart. Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220205112029.7b363457e1aa.Ie4634222e6a33451b88e1042c83e9ea28775bd9f@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Johannes Berg 提交于
Change a few places to not shadow variables. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220130115024.d53f2a7a9614.I7441559451d54b39dc0daeb4c31e5dce19d4d83e@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Emmanuel Grumbach 提交于
Those devices have more BAIDs, which is the hardware module that tracks the BA session. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220128153014.7120a90ed7d2.I9d6d907a2c1b965d1e42ff9f0886b1df627e4761@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Johannes Berg 提交于
Due to some rearchitecting inside the firmware, a new BAID allocation command is being introduced. Support it. Note that with it the firmware no longer returns "no space" but will crash instead, so check for that before sending the command to the firmware. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220128153014.a89fa3bd9d91.Ibe58c5d9e882dad43aa857aa1c8f54f3358c667b@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Johannes Berg 提交于
Refactor the firmware call in iwl_mvm_sta_rx_agg() out into its own function to be able to change it more easily in the next patch. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220128153014.8ec17e282b24.I37c008a9141a2868ee4560e6de303e8bfbb93502@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Mordechay Goodstein 提交于
In order to support 1K aggregations start ba queue with at least double the size, also allocate based on the connecting type to save memory usage. Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220128153014.16b43fe3e92f.I853c57648feee4b69ccb01ef4c75354377d60be2@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Johannes Berg 提交于
Instead of taking the group/command separately, make the function take a combined command ID. In many cases, this allows us to pass an existing command ID (e.g. cmd.id), or introduce a new variable for it, so that we don't use the command ID twice. This way, we can also use LONG_GROUP implicitly, so we don't need to spell that out for many commands. Apart from mvm.h, fw/img.{c,h} changes and some copyright and indentation updates, this was done with spatch: @@ identifier cmd; expression fw, G, C, def; @@ struct iwl_host_cmd cmd = { .id = WIDE_ID(G, C), ... }; ... -iwl_fw_lookup_cmd_ver(fw, G, C, def) +iwl_fw_lookup_cmd_ver(fw, cmd.id, def) @@ identifier cmd; expression fw, C, def; @@ struct iwl_host_cmd cmd = { .id = C, ... }; ... -iwl_fw_lookup_cmd_ver(fw, \(IWL_ALWAYS_LONG_GROUP\|LONG_GROUP\), C, def) +iwl_fw_lookup_cmd_ver(fw, cmd.id, def) @@ identifier func; expression fw, G, C, mvm, flags, cmd, size, def; type rettype; @@ rettype func(...) { +u32 cmd_id = WIDE_ID(G, C); ... -iwl_fw_lookup_cmd_ver(fw, G, C, def) +iwl_fw_lookup_cmd_ver(fw, cmd_id, def) ... -iwl_mvm_send_cmd_pdu(mvm, WIDE_ID(G, C), flags, cmd, size) +iwl_mvm_send_cmd_pdu(mvm, cmd_id, flags, cmd, size) ... } @@ identifier func; expression fw, G, C, mvm, flags, cmd, size, def; type rettype; @@ rettype func(...) { +u32 cmd_id = C; ... -iwl_fw_lookup_cmd_ver(fw, \(IWL_ALWAYS_LONG_GROUP\|LONG_GROUP\), C, def) +iwl_fw_lookup_cmd_ver(fw, cmd_id, def) ... -iwl_mvm_send_cmd_pdu(mvm, C, flags, cmd, size) +iwl_mvm_send_cmd_pdu(mvm, cmd_id, flags, cmd, size) ... } @@ expression fw, C, def; @@ -iwl_fw_lookup_cmd_ver(fw, \(IWL_ALWAYS_LONG_GROUP\|LONG_GROUP\), C, def) +iwl_fw_lookup_cmd_ver(fw, C, def) @@ expression fw, C, G, def; @@ -iwl_fw_lookup_cmd_ver(fw, G, C, def) +iwl_fw_lookup_cmd_ver(fw, WIDE_ID(G, C), def) Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220128153014.c4ac213cef5c.I6fd9a4fcbcf16ef3a3ae20a2b08ee54ebe06f96f@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Johannes Berg 提交于
The order of arguments for iwl_cmd_id() is confusing, and the version is always 0 and thus a useless argument. Prefer the WIDE_ID() macro (which needs to be a macro due to use in switch cases etc.) over the iwl_cmd_id() function. Obviously done with spatch: @@ expression G, C; @@ -iwl_cmd_id(C, G, 0) +WIDE_ID(G, C) Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220128153014.cc4f9d1a2e9b.Ieb023cd773ea22e819d1ef1c37ae857ecc1a839d@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Nathan Errera 提交于
Since FW is now in charge of timing the channel switch, there is no need to send the add/modify/remove time event command to fw with every (e)CSA element. However, the driver needs to cancel the channel switch if the CS start notification arrives and it does not know about an ongoing channel switch. Signed-off-by: NNathan Errera <nathan.errera@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220128153013.ac3af0ff22c7.Ie87c62047b71b93b12aa80b5dc5391b4798dbe97@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
- 16 2月, 2022 1 次提交
-
-
由 Ilan Peer 提交于
Add initial support for EHT and 320 MHz bandwidth in mac80211. As a new IEEE80211_STA_RX_BW_320 is added to enum ieee80211_sta_rx_bandwidth, update the drivers to avoid compilation warnings. Signed-off-by: NIlan Peer <ilan.peer@intel.com> Link: https://lore.kernel.org/r/20220214173004.0f144cc0bba6.Iad18111264da87eed5fd7b017f0cc6e58c604e07@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 08 12月, 2021 1 次提交
-
-
由 Johannes Berg 提交于
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: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083237.44abbbc50f40.I5492600dfe513356555abe2d7df0e2835846e3d8@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
- 27 8月, 2021 4 次提交
-
-
由 Johannes Berg 提交于
There's no need to differentiate identical default and cipher type cases, nor do we really need to have a 'ret' variable. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210802215208.e89178b22fbf.I4d62baad9a9fdfd5c645a3cc5dbffb22feab5033@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Johannes Berg 提交于
The new version 3 of the station key API has gotten rid of the strange hole in the sequence counter values, support that. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210802215208.39a00ca1a1a6.Ifb4adeb4edd2b72232046dd2d59c0b3732f497c2@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Johannes Berg 提交于
When TVQM is enabled (iwl_mvm_has_new_tx_api() is true), then queue numbers are just sequentially assigned 0, 1, 2, ... Prior to TVQM, in DQA, there were some statically allocated queue numbers: * IWL_MVM_DQA_AUX_QUEUE == 1, * both IWL_MVM_DQA_INJECT_MONITOR_QUEUE and IWL_MVM_DQA_P2P_DEVICE_QUEUE == 2, and * IWL_MVM_DQA_AP_PROBE_RESP_QUEUE == 9. Now, these values are assigned to the members mvm->aux_queue, mvm->snif_queue, mvm->probe_queue and mvm->p2p_dev_queue by default. Normally, this doesn't really matter, and if TVQM is in fact available we override them to the real values after allocating a queue for use there. However, this allocation doesn't always happen. For example, for mvm->p2p_dev_queue (== 2) it only happens when the P2P Device interface is started, if any. If it's not started, the value in mvm->p2p_dev_queue remains 2. This wouldn't really matter all that much if it weren't for iwl_mvm_is_static_queue() which checks a queue number against one of those four static numbers. Now, if no P2P Device or monitor interface is added then queue 2 may be dynamically allocated, yet alias mvm->p2p_dev_queue or mvm->snif_queue, and thus iwl_mvm_is_static_queue() erroneously returns true for it. If it then gets full, all interface queues are stopped, instead of just backpressuring against the one TXQ that's really the only affected one. This clearly can lead to issues, as everything is stopped even if just a single TXQ filled its corresponding HW queue, if it happens to have an appropriate number (2 or 9, AUX is always reassigned.) Due to a mac80211 bug, this also led to a situation in which the queues remained stopped across a deauthentication and then attempts to connect to a new AP started failing, but that's fixed separately. Fix all of this by simply initializing the queue numbers to the invalid value until they're used, if TVQM is enabled, and also setting them back to that value when the queues are later freed again. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210802172232.2e47e623f9e2.I9b0830dafbb68ef35b7b8f0f46160abec02ac7d0@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Johannes Berg 提交于
When installing a (new) key, set the replay counter so that after FW restart the firmware has the correct value of the replay counters. This doesn't have a large effect - for frames that reach the driver, it will do a replay check, and when installing a new key, the counter is normally zero to start with (not for GTK though, if joining the BSS for the first time). Since this only affects frames handled entirely by the FW, and that's restricted to a few unicast management frames, the only affect here is for those after a firmware restart. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210802172232.1cedf2ca7bb6.I2e609c28eaa301436e6740f4f1beca838f69a96a@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
- 22 6月, 2021 1 次提交
-
-
由 Naftali Goldstein 提交于
When operating in AP mode with NICs supporting the AP_LINK_PS hw flag, mac80211 doesn't need to start/stop queueing tx for connected stations because the FW already handles that. Signed-off-by: NNaftali Goldstein <naftali.goldstein@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618105614.64df994c8fbb.I0fa5cda3a5f893a396eef30a01522422be359e69@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
- 14 4月, 2021 1 次提交
-
-
由 Johannes Berg 提交于
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: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210331121101.f62833fd9893.I612d7ac1c655ec4880329360e15d207698c750bc@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
- 05 2月, 2021 3 次提交
-
-
由 Emmanuel Grumbach 提交于
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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210205110447.f5b813753bdb.Id58979b678974c3ccf44d8b381c68165ac55a3d3@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Johannes Berg 提交于
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: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210205110447.f5a3d53301b3.I23e84c9bb0b039d9106a07e9d6847776757f9029@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Mordechay Goodstein 提交于
In the new api all the flush in the FW is done before we get the response and in the response we only get the updated read pointer and all queued packets don't get anymore rx_tx per packet to free the queued packet, so driver needs to free all queued packets on flushed queue at once after flush response. Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210117130510.4bd0eca8c0ef.I1601aad2eb2cc83f6f73b8ca52be57bb9fd626ab@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
- 25 1月, 2021 1 次提交
-
-
由 Gregory Greenman 提交于
Having sta_id not set for aux_sta and snif_sta can potentially lead to a hard to debug issue in case remove station is called without an add. In this case sta_id 0, an unrelated regular station, will be removed. In fact, we do have a FW assert that occures rarely and from the debug data analysis it looks like sta_id 0 is removed by mistake, though it's hard to pinpoint the exact flow. The WARN_ON in this patch should help to find it. Signed-off-by: NGregory Greenman <gregory.greenman@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210122144849.5dc6dd9b22d5.I2add1b5ad24d0d0a221de79d439c09f88fcaf15d@changeid
-
- 12 12月, 2020 1 次提交
-
-
由 Gustavo A. R. Silva 提交于
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly using the fallthrough pseudo-keyword as a replacement for a number of "fall through" markings. Notice that Clang doesn't recognize "fall through" comments as implicit fall-through. Link: https://github.com/KSPP/linux/issues/115Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201117135053.GA13248@embeddedor
-
- 10 12月, 2020 2 次提交
-
-
由 Johannes Berg 提交于
Use SPDX tags instead of the long copyright notices. Also cleanup some duplicate copyright notices and combine the years where possible. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201210000603.481bcb512a6f.I8146abe5a637079e7336209f23cb26af98b12b31@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Luca Coelho 提交于
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: NHaim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: NHaim Dreyfuss <haim.dreyfuss@intel.com> Co-developed-by: NIlan Peer <ilan.peer@intel.com> Signed-off-by: NIlan Peer <ilan.peer@intel.com> Co-developed-by: NTova Mussai <tova.mussai@intel.com> Signed-off-by: NTova Mussai <tova.mussai@intel.com> Co-developed-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com> Co-developed-by: NTali Levi Rovinsky <Tali.Levi-rovinsky@intel.com> Signed-off-by: NTali Levi Rovinsky <Tali.Levi-rovinsky@intel.com> Co-developed-by: NAvraham Stern <avraham.stern@intel.com> Signed-off-by: NAvraham Stern <avraham.stern@intel.com> Co-developed-by: NAyala Beker <ayala.beker@intel.com> Signed-off-by: NAyala Beker <ayala.beker@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201210000657.0fdbfc3d7352.Idb648536faf21716e2ab2c6d6890d3e49f719cd3@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
- 11 11月, 2020 1 次提交
-
-
由 Mordechay Goodstein 提交于
Currently, our max tpt is limited to max HT A-MPDU for LB, and max VHT A-MPDU for HB. Configure HE exponent value correctly to achieve HE max A-MPDU, both on LB and HB. Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20201107104557.4486852ebb56.I9eb0d028e31f183597fb90120e7d4ca87e0dd6cb@changeid
-
- 09 10月, 2020 3 次提交
-
-
由 Nathan Errera 提交于
ADD_STA_CMD_API_S ver 12 was added in order to properly support auxiliary activities in CDB NICs. In the new version we don't need to allocate an aux station at initialization, instead we add an aux station only when an auxiliary activity that requires a dedicated Tx queue is needed. For now the only case we need this kind of activity is when using hot spot 2.0 Signed-off-by: NNathan Errera <nathan.errera@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20201008180656.700e6e2e3077.Icdd807b6a3ad3fed806449ea0a13f856aa20e632@changeid
-
由 Nathan Errera 提交于
As part of changes made to properly support auxiliary activities in CDB NICs, an aux sta will be added when using hot spot 2.0 and will need to be removed when roc flow is done. In order to do so, prepare the roc_done_wk to work synchronously as the rm_aux_sta is a SYNC command. Since now all of th iwl_mvm_flush_sta function are using it sync, removed the flag argument from the function. Signed-off-by: NNathan Errera <nathan.errera@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20201008180656.71b441c8b682.Ia1d216cb680308b91d6da9f73e23ae9f4baac79f@changeid
-
由 Nathan Errera 提交于
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: NNathan Errera <nathan.errera@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20201008180656.863ab470babc.I393223392f36436663c4e66add03fefe77b74e60@changeid
-
- 02 10月, 2020 3 次提交
-
-
由 Luca Coelho 提交于
We are printing the same thing twice, "Enabling TXQ #%d". Previously the second print was including more information, but now it only prints the queue number, which is already in the first print. Remove the redundant one. Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200930191738.1c22d1bc0a88.I24e57317bdddc6c72f69725e1d95683a935e893d@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Avraham Stern 提交于
A FTM responder may do PASN authentication with unassociated stations to allow secure ranging. In this case, the driver will add an internal station and install the TK so the FW will accept protected FTM request frames from this station and will send a protected FTM response frame. In addition, the driver needs to configure the HLTK to the FW so the FW can derive the secure LTF bits. This is left for a later patch since it is not yet supported by the FW. Signed-off-by: NAvraham Stern <avraham.stern@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200911204056.c915b44ad7dd.I72ef7f9753964555561c27ec503241105eddb14e@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Mordechay Goodstein 提交于
This avoids cases that we have a lot of packets in the queue and until we are able to transmit SSN packet the other side sends DELBA due to timeout. Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200911204056.8a8481c60663.I353ab6f1bc04c7fdf873dead59f483454e2425ba@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
- 23 6月, 2020 1 次提交
-
-
由 Johannes Berg 提交于
iwl_mvm_free_inactive_queue() will sleep in synchronize_net() under some circumstances, so don't call it under RCU. There doesn't appear to be a need for RCU protection around this particular call. Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20200403112332.0f49448c133d.I17fd308bc4a9491859c9b112f4eb5d2c3fc18d7d@changeid
-
- 10 6月, 2020 1 次提交
-
-
由 YueHaibing 提交于
commit cfbc6c4c ("iwlwifi: mvm: support mac80211 TXQs model") left behind this, remove it. Signed-off-by: NYueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20200506134217.49760-1-yuehaibing@huawei.comSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
- 29 5月, 2020 1 次提交
-
-
由 Sharon 提交于
When mvm is initialized we alloc aux station with aux queue. We later free the station memory when driver is stopped, but we never free the queue's memory, which casues a leak. Add a proper de-initialization of the station. Signed-off-by: NSharon <sara.sharon@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200529092401.0121c5be55e9.Id7516fbb3482131d0c9dfb51ff20b226617ddb49@changeid
-
- 08 5月, 2020 2 次提交
-
-
由 Johannes Berg 提交于
We can currently end up transmitting on an unallocated queue, if the allocation fails. Stop doing that, by simply not transmitting. We don't have any better strategy here, unfortunately, but the previous commits make that much less likely. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200425130140.dcf1801f25ef.I6d71e13ea042765800f2ee41401b8eb282527c34@changeid
-
由 Johannes Berg 提交于
We currently attempt to allocate queues that are 512 entries long, but that requires 32 KiB memory, which may not be available, at least not contiguously. If we fail to allocate, attempt to use a smaller queue all the way down to 16 entries (which fit into a single page). Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200425130140.c8548d7cc08a.I5059c410e628726cbce98d6311b690c632d00f97@changeid
-