summaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/intel/iwlwifi/mvm
Commit message (Collapse)AuthorAgeFilesLines
...
| * iwlwifi: mvm: add HE TB PPDU SIG-A BW to radiotapJohannes Berg2019-02-041-6/+15
| | | | | | | | | | | | | | | | 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>
| * iwlwifi: mvm: config mac ctxt to HE before TLCLiad Kaufman2019-02-042-2/+5
| | | | | | | | | | | | | | | | | | If we have a station connecting HE, make sure that the MAC ctxt is updated with indication of this before setting the TLC rates via the TLC manager command. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: add tlc command name to outputLiad Kaufman2019-02-041-0/+1
| | | | | | | | | | | | | | | | Instead of having the command appear as "UNKNOWN" in the dmesg, add the name to it. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: remove redundant conditionJohannes Berg2019-02-041-5/+3
| | | | | | | | | | | | | | | | In iwl_mvm_sta_alloc_queue_tvqm(), we know that we have a station, so no need to check it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: limit AMSDU size to 8KSara Sharon2019-02-041-1/+6
| | | | | | | | | | | | | | | | Typically, when not in HE mode, we will not perform well with AMSDUs bigger than 8K. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: fix AP mode in WEPEmmanuel Grumbach2019-02-043-63/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recently we started to send the WEP keys to the firmware so that we could use hardware Tx encryption also on newer devices that require the keys to be installed in the firmware for encryption (as opposed to older devices that can get the key in the Tx command for each Tx). When we implemented that, we forgot to remove the key when we remove a station leading to a situation where a station that connects and disconnects a lot of times exhausts the key database inside the firmware. A fix was made for that, but we always removed the same key: mvmvif->ap_wep_key which means that we removed the same key entry in the firmware. This can make sense since in WEP, the key is the same for all the stations, but the internal implementation of iwl_mvm_set_sta_key and iwl_mvm_remove_sta_key assumes that each station uses a different key in the firmware's key database. So now we got to the situation where we have a single ieee80211_key_conf instance that means, a single ieee80211_key_conf.hw_key_idx index for several stations and hence for several keys. ieee80211_key_conf.hw_key_idx is set to 0 when the first station associates, and then it is overwritten to 1 when the second station associates which is a buggy of course. This led to the following message upon the removal of the second station: iwlwifi 0000:00:03.0: offset 1 not used in fw key table. WARNING: CPU: 2 PID: 27883 at net/mac80211/sta_info.c:1122 __sta_info_destroy_part2+0x16b/0x180 [mac80211] RIP: 0010:__sta_info_destroy_part2+0x16b/0x180 [mac80211] Call Trace: __sta_info_destroy+0x2a/0x40 [mac80211] sta_info_destroy_addr_bss+0x38/0x60 [mac80211] ieee80211_del_station+0x1d/0x30 [mac80211] nl80211_del_station+0xe0/0x1f0 [cfg80211] Fix this by copying the ieee80211_key_conf structure for each and every station. This is the easiest way to properly remove the keys with the right index. Another solution would have been to allow several stations to use the same key offset in the firmware. That would require to change the way we track keys in iwlmvm and not really worth it. Also, maintain correctly fw_key_table when we add a key for the multicast station. Remove the key when we remove the multicast station. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Fixes: 337bfc9881a2 ("iwlwifi: mvm: set wep key for all stations in soft ap mode") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: add fall through comments where neededLuca Coelho2019-02-046-5/+10
| | | | | | | | | | | | | | | | | | | | 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>
| * iwlwifi: Fix pre operational dumping flowsShahar S Matityahu2019-02-043-9/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are several dumping flows in the driver in case of a fail prior to operational. In some cases we get 2 dumps while in others we get none. Fix this by uniting the different flows. Add a different dump type to driver triggered dumps in case we want a dump but did not got assert, and make all dumping go through iwl_fw_dbg_collect_desc to avoid multiple dumps. Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: remove duplicated include from ops.cYueHaibing2019-02-041-1/+0
| | | | | | | | | | | | | | Remove duplicated include. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: support new format for the beacon notificationEmmanuel Grumbach2019-02-042-12/+29
| | | | | | | | | | | | | | | | | | The firmware is changing the format of the beacon notification to remove the dependency on the Tx response format. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: differentiate between alive timeout and alive flow failureShahar S Matityahu2019-02-042-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two cases that can cause the alive flow to fail, an assert or a timeout. Currently we mask any incoming asserts when we wait for alive. Solve this by differentiating between the two cases: 1. Let the regular error handling to handle a received assert 2. Do a dump collection in the case of a timeout Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Fixes: f38efdb29389 ("iwlwifi: add dump collection in case alive flow fails") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: support CHANNEL_SWITCH_TIME_EVENT_CMD commandSara Sharon2019-02-043-40/+90
| | | | | | | | | | | | | | | | | | When we do channel switch, we used to schedule time events ourselves. This was offloaded to FW. Support the new command and flow. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: simplify some return conditionsSara Sharon2019-02-043-14/+7
| | | | | | | | | | | | | | | | Simplify some return conditions found by running a semantic patch to detect unnecessary assignments to local variables. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
* | Merge remote-tracking branch 'net-next/master' into mac80211-nextJohannes Berg2019-02-2225-1922/+987
|\| | | | | | | | | | | | | Merge net-next to resolve a conflict and to get the mac80211 rhashtable fixes so further patches can be applied on top. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * wireless: prefix header search paths with $(srctree)/Masahiro Yamada2019-02-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the Kbuild core manipulates header search paths in a crazy way [1]. To fix this mess, I want all Makefiles to add explicit $(srctree)/ to the search paths in the srctree. Some Makefiles are already written in that way, but not all. The goal of this work is to make the notation consistent, and finally get rid of the gross hacks. Having whitespaces after -I does not matter since commit 48f6e3cf5bc6 ("kbuild: do not drop -I without parameter"). I also removed one header search path in: drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile I was able to compile without it. [1]: https://patchwork.kernel.org/patch/9632347/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * iwlwifi: mvm: fix merge damage in iwl_mvm_rx_mpdu_mq()Luca Coelho2019-01-311-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * iwlwifi: mvm: update firmware when MU EDCA params changeShaul Triebitz2019-01-291-0/+6
| | | | | | | | | | | | | | | | When MU EDCA params change, resend the STA_HE_CTXT command updating the MU EDCA params. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: trigger dump on assert prior to setting the device upShahar S Matityahu2019-01-291-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the regular flow, when we receive an assert, ieee80211_reconfig is called which reconfig the driver using iwl_mvm_mac_start. iwl_mvm_mac_start is clearing the restart bit and does dump collection. Prior to setting the device up, ieee80211_reconfig does not call iwl_mvm_mac_start since there is nothing to reconfig and we miss the dump collection of the assert. solve it by checking the restart bit before we stop the device and trigger a dump collection in case it is set. note that we don't need to do it in the fmac case since in fmac assert flow in iwl_fmac_nic_error we call iwl_fw_dbg_collect_desc so we can be sure that there will a dump collection in iwl_fmac_stop_device. Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: include configured sniffer AID in radiotapJohannes Berg2019-01-294-5/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * iwlwifi: mvm: document monitor mode reorder buffer bypassJohannes Berg2019-01-291-0/+2
| | | | | | | | | | | | | | | | 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>
| * iwlwifi: mvm: disable completely low latency mode with debugfsMordechay Goodstein2019-01-292-8/+103
| | | | | | | | | | | | | | | | | | | | | | We introduce a new state for latency, force mode, in force mode you can enable always to be in low latency or always to be in non low latency. This is required for test mode in max TpT test. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: freeze management TXQ timer when station goes to sleepEmmanuel Grumbach2019-01-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We maintain a timer for each Tx queue to detect stalls and be able to recover / debug. When we work in AP mode, we can freeze the Tx queue timer if a station goes to sleep, because we don't want to warn about stalls that are caused by faulty clients that don't wake up on time. This mechanism was applied to the queues of the clients, but the management queue was omitted. Fix that. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: Change FW channel info APIDavid Spinadel2019-01-295-45/+101
| | | | | | | | | | | | | | | | | | | | Change iwl_fw_channel_info structure so it can have channel number greater than 255. This is needed for 6 GHz channel numbers. Change all relevant structs and member accesses accordingly. The new API is indicated by a TLV capability bit. Signed-off-by: David Spinadel <david.spinadel@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: implement CSI reportingJohannes Berg2019-01-293-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * iwlwifi: mvm: add location APIsJohannes Berg2019-01-292-0/+18
| | | | | | | | | | | | | | | | Add the location/time-of-flight/FTM APIs that we'll use in follow-up patches to implement FTM responder and initiator. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: Disconnect on large beacon lossAndrei Otcheretianski2019-01-292-2/+5
| | | | | | | | | | | | | | | | | | | | Some buggy APs stop sending beacons, but continue to ack our null data packets or even run some traffic. It's better not to stick connected to such an AP forever, so disconnect after some larger beacon loss threshold is crossed. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: remove TOF implementationJohannes Berg2019-01-297-1177/+2
| | | | | | | | | | | | | | | | | | This is an ancient (~2015) implementation that no longer matches the firmware in any way, and most likely never worked. Remove all of it so it can be reintroduced properly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: get rid of tx_path_lockSara Sharon2019-01-293-19/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TX path lock was introduced in order to prevent out of order invocations of TX. This can happen in the following flow: TX path invoked from net dev Packet dequeued TX path invoked from RX path Packet dequeued Packet TXed Packet TXed However, we don't really need a lock. If TX path is already invoked from some location, other paths can simply abort their execution, instead of waiting to the first path to finish, and then discover queue is (likely) empty or stopped. Replace the lock with an atomic variable to track TX ownership. This simplifies the locking dependencies between RX and TX paths, and should improve performance. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: fix A-MPDU reference assignmentJohannes Berg2019-01-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * iwlwifi: mvm: add an option to dereference vif by idSara Sharon2019-01-294-67/+72
| | | | | | | | | | | | | | | | | | | | | | | | Currently whenever we get firmware notification with mac id, we iterate over all the interfaces to find the ID. This is a bit cumbersome. Instead, adding an array of RCU pointers, like we have for station IDs. This is not expensive space wise since we have only up to 4 active MACs, and not complicated code wise, since we have a clear point to init and de-init it. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: remove sta key on wep apLiad Kaufman2019-01-291-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If WEP is used, no one removes the STA key upon STA removal, leading to a situation where after 16 connect/disconnects - the AP could no longer decrypt incoming data frames since iwl_mvm_set_fw_key_idx() called from iwl_mvm_set_sta_key() during association returns STA_KEY_IDX_INVALID, thus not setting the key for that connecting STA. Fix this by removing the key in the driver when the STA is removed. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: pre-initialize alive_data in wait_alive()Luca Coelho2019-01-291-1/+1
| | | | | | | | | | | | | | | | | | The function we pass to the wait alive notification procedure may may not even get called if the timeout occurs before the function is called. To prevent accessing unitialized data in alive_data, pre-set it to zero in the declaration. Found by static analyzers. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: move iwl_enable_{rx,tx}_ampdu to iwl-modparams.hJohannes Berg2019-01-291-20/+2
| | | | | | | | | | | | | | | | These inlines just check the module parameters, so they don't need a configuration parameter and can move to a better place. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: save and export regdb blob from the NVMLuca Coelho2019-01-293-0/+9
| | | | | | | | | | | | | | | | Sometimes we want to debug issues related to the regulatory blob in the NVM. To make that easier, add a debugfs entry to export it together with the other nvm blobs we export. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: clean up LDBG config command usageJohannes Berg2019-01-292-43/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clean up the LDBG config command to not be called "continuous recording", and while at it actually remove the continuous recording implementation completely since it was only used for store & forward architectures. This also fixes a bug at least in iwl_fw_dbg_buffer_allocation() because what's now "__le32 type" (matching the firmware) used to be "__le16 enable_recording", so the buffer allocation config sub-struct would erroneously have started at the wrong offset. In the other cases this didn't actually lead to a bug as other bytes in pad[] were all zeroes, so accessing the 16-bit value as a 32-bit value wouldn't make a difference (in little endian.) Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: read IWL_RX_MPDU_PHY_SHORT_PREAMBLE only for CCKJohannes Berg2019-01-291-1/+2
| | | | | | | | | | | | | | | | | | 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>
| * iwlwifi: mvm: fix %16 to %016 print formatJohannes Berg2019-01-292-2/+2
| | | | | | | | | | | | | | | | | | With just %16, it means 16 characters padding, but we really don't want to print "0x 1F4547B", but instead want to have this filled with zeroes, so we need the 0. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: iwlmvm: in monitor NDP notif take the NSS from rx_vecShaul Triebitz2019-01-291-4/+13
| | | | | | | | | | | | | | | | | | | | | | 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>
| * iwlwifi: iwlmvm: ignore HE PPDU type regarding EOFShaul Triebitz2019-01-291-11/+7
| | | | | | | | | | | | | | | | | | 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>
| * iwlwifi: mvm: avoid possible access out of array.Mordechay Goodstein2019-01-251-6/+13
| | | | | | | | | | | | | | | | | | The value in txq_id can be out of array scope, validate it before accessing the array. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Fixes: cf961e16620f ("iwlwifi: mvm: support dqa-mode agg on non-shared queue") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: tighten boundary checksLiad Kaufman2019-01-251-5/+19
| | | | | | | | | | | | | | | | | | | | The driver assumes certain sizes and lengths aren't crossed in some places. Make sure this indeed happens. Found by Klocwork. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: make num_active_macs unsignedLiad Kaufman2019-01-251-1/+3
| | | | | | | | | | | | | | | | | | There is no point in having num_active_macs signed since it should never be negative. Set it to be an unsigned variable to ensure this. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: Do not set RTS/CTS protection for P2P Device MACIlan Peer2019-01-251-2/+0
| | | | | | | | | | | | | | | | As this is not needed and might cause interoperability issues during pairing with devices that would not reply to RTS frames. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: Set Tx rate and flags when there is not stationIlan Peer2019-01-251-3/+4
| | | | | | | | | | | | | | | | | | When a frame is transmitted without a station, need to set the rate and flags in the Tx command, as the FW does not have any information as to what rate and flags should be used for this frame. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: Flush transmit queues on P2P Device ROC doneIlan Peer2019-01-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | When a time event for a P2P Device interface is done, it is possible that there is still a frame pending for transmission that should be flushed. Set the IWL_MVM_STATUS_NEED_FLUSH_P2P to indicate to the ROC worker that P2P Device station queue need also to be flushed. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: bring back mvm GSO codeSara Sharon2019-01-252-2/+223
| | | | | | | | | | | | | | | | | | We have a slightly better TCP performance with GSO. Add it back, it can co-exist with the code that builds AMSDUs in mac80211. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: fix values in the table exampleLuca Coelho2019-01-251-6/+6
| | | | | | | | | | | | | | | | | | We erroneously had some values for NGI in the table we give as an example in rs_fill_rates_for_column(), when they should be SGI. Change them so that they match what we say. Reported-by: Rémy Grünblatt <remy@grunblatt.org> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: support mac80211 AMSDUSara Sharon2019-01-255-226/+67
| | | | | | | | | | | | | | | | Support getting mac80211 building AMSDUs for us. Remove GSO support from mvm - we don't need it anymore. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: support mac80211 TXQs modelSara Sharon2019-01-259-443/+331
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move to use the new mac80211 TXQs implementation. This has quite a few benefits for us. We can get rid of the awkward mapping of DQA to mac80211 queues. We can stop buffering traffic while waiting for the queue to be allocated. We can also use mac80211 AMSDUs instead of building it ourselves. The usage is pretty simple: Each ieee80211_txq contains iwl_mvm_txq. There is such a queue for each TID, and one for management frames. We keep having static AP queues for probes and non-bufferable MMPDUs, along with broadcast and multicast queues. Those are being used from the "old" TX invocation path - iwl_mvm_mac_tx. When there is a new frame in a TXQ, iwl_mvm_mac_wake_tx is being called, and either invokes the TX path, or allocates the queue if it does not exist. Most of the TX path is left untouched, although we can consider cleaning it up some more, for example get rid of the duplication of txq_id in both iwl_mvm_txq and iwl_mvm_dqa_txq_info. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| * iwlwifi: mvm: make NVM access actually fail on failuresJohannes Berg2019-01-251-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | On any failure, including if we crash the firmware or get garbage data, we currently ignore this and pretend the OTP was empty. Clearly, this isn't typically the case. In cases other than the firmware saying it can't read the requested section, or the section having ended, make the access actually fail and trickle the error up through the layers to fail init. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
OpenPOWER on IntegriCloud