aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
AgeCommit message (Collapse)AuthorFilesLines
2019-04-27netlink: make validation more configurable for future strictnessJohannes Berg1-2/+2
We currently have two levels of strict validation: 1) liberal (default) - undefined (type >= max) & NLA_UNSPEC attributes accepted - attribute length >= expected accepted - garbage at end of message accepted 2) strict (opt-in) - NLA_UNSPEC attributes accepted - attribute length >= expected accepted Split out parsing strictness into four different options: * TRAILING - check that there's no trailing data after parsing attributes (in message or nested) * MAXTYPE - reject attrs > max known type * UNSPEC - reject attributes with NLA_UNSPEC policy entries * STRICT_ATTRS - strictly validate attribute size The default for future things should be *everything*. The current *_strict() is a combination of TRAILING and MAXTYPE, and is renamed to _deprecated_strict(). The current regular parsing has none of this, and is renamed to *_parse_deprecated(). Additionally it allows us to selectively set one of the new flags even on old policies. Notably, the UNSPEC flag could be useful in this case, since it can be arranged (by filling in the policy) to not be an incompatible userspace ABI change, but would then going forward prevent forgetting attribute entries. Similar can apply to the POLICY flag. We end up with the following renames: * nla_parse -> nla_parse_deprecated * nla_parse_strict -> nla_parse_deprecated_strict * nlmsg_parse -> nlmsg_parse_deprecated * nlmsg_parse_strict -> nlmsg_parse_deprecated_strict * nla_parse_nested -> nla_parse_nested_deprecated * nla_validate_nested -> nla_validate_nested_deprecated Using spatch, of course: @@ expression TB, MAX, HEAD, LEN, POL, EXT; @@ -nla_parse(TB, MAX, HEAD, LEN, POL, EXT) +nla_parse_deprecated(TB, MAX, HEAD, LEN, POL, EXT) @@ expression NLH, HDRLEN, TB, MAX, POL, EXT; @@ -nlmsg_parse(NLH, HDRLEN, TB, MAX, POL, EXT) +nlmsg_parse_deprecated(NLH, HDRLEN, TB, MAX, POL, EXT) @@ expression NLH, HDRLEN, TB, MAX, POL, EXT; @@ -nlmsg_parse_strict(NLH, HDRLEN, TB, MAX, POL, EXT) +nlmsg_parse_deprecated_strict(NLH, HDRLEN, TB, MAX, POL, EXT) @@ expression TB, MAX, NLA, POL, EXT; @@ -nla_parse_nested(TB, MAX, NLA, POL, EXT) +nla_parse_nested_deprecated(TB, MAX, NLA, POL, EXT) @@ expression START, MAX, POL, EXT; @@ -nla_validate_nested(START, MAX, POL, EXT) +nla_validate_nested_deprecated(START, MAX, POL, EXT) @@ expression NLH, HDRLEN, MAX, POL, EXT; @@ -nlmsg_validate(NLH, HDRLEN, MAX, POL, EXT) +nlmsg_validate_deprecated(NLH, HDRLEN, MAX, POL, EXT) For this patch, don't actually add the strict, non-renamed versions yet so that it breaks compile if I get it wrong. Also, while at it, make nla_validate and nla_parse go down to a common __nla_validate_parse() function to avoid code duplication. Ultimately, this allows us to have very strict validation for every new caller of nla_parse()/nlmsg_parse() etc as re-introduced in the next patch, while existing things will continue to work as is. In effect then, this adds fully strict validation for any new command. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-04-18Merge tag 'wireless-drivers-next-for-davem-2019-04-18' of ↵David S. Miller1-58/+170
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 5.2 Nothing really special standing out this time, iwlwifi being the most active driver. Major changes: iwlwifi * send NO_DATA events so they can be captured in radiotap * support for multiple BSSID * support for some new FW API versions * support new hardware * debugfs cleanups by Greg-KH qtnfmac * allow each MAC to specify its own regulatory rules ==================== Signed-off-by: David S. Miller <[email protected]>
2019-04-03iwlwifi: mvm: support HE context cmd API changeSara Sharon1-1/+11
Support API change to pass all mbssid parameters to the firmware. Signed-off-by: Sara Sharon <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-04-03iwlwifi: mvm: use correct GP2 register address for 22000 familyAvraham Stern1-2/+2
The device time register address has changed for 22000 devices. Add a util function for getting the GP2 time and use the correct register address depending on the device family. Signed-off-by: Avraham Stern <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-04-03iwlwifi: mvm: fix pointer reference when setting HE QAM thresLiad Kaufman1-4/+6
Pointer referencing when setting HE QAM thresholds (when nominal packet padding bit is on) caused kernel crash due to bad referencing. Fix that. Signed-off-by: Liad Kaufman <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-04-03iwlwifi: mvm: update offloaded rate control on changesJohannes Berg1-0/+7
With offloaded rate control, if the station parameters (rates, NSS, bandwidth) change (sta_rc_update method), call iwl_mvm_rs_rate_init() to propagate those change to the firmware. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-03-22iwlwifi: mvm: use dump worker during restart instead of sync dumpShahar S Matityahu1-9/+0
In restart flow, the driver requests HW restart from mac80211 and then mac80211 uses a worker to do the restart flow. In that flow a sync dump is performed. Instead, schedule the dump worker before requesting HW restart from mac80211. This approach simplifies the restart flow. Also, it is neeeded in order to differentiate between the handling of SW and HW errors in a future commit. Signed-off-by: Shahar S Matityahu <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-03-22iwlwifi: mvm: enable HT/VHT IBSSJohannes Berg1-0/+3
For some reason we never enabled it, but it appears to work fine. Enable it now. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-03-22iwlwifi: mvm: support multiple BSSIDSara Sharon1-1/+9
Set the capabilities flags and inform firmware Signed-off-by: Sara Sharon <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-03-22iwlwifi: mvm: track changes in beacon count during channel switchSara Sharon1-0/+15
There are some buggy APs that keeps changing the count while forcing us to block TX. This eventually results in queue hang, assert, and disconnection. Detect such APs and disconnect gracefully in advance. Signed-off-by: Sara Sharon <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-03-22iwlwifi: mvm: disconnect in case of bad channel switch parametersSara Sharon1-72/+99
In case we receive channel switch announcement with immediate quiet and unknown switching time, we will switch when FW identifies AP left channel. However, if AP remains on channel, we will eventually get TX queue hang. Init a work to disconnect if switch doesn't occur within 1500 milliseconds. Do it also for a too long channel switch. Signed-off-by: Sara Sharon <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-03-22iwlwifi: mvm: notify FW on quiet mode in CSASara Sharon1-0/+2
Let FW know if quiet mode is on or not. This is needed in order to disable it in FW when CSA is complete. Signed-off-by: Sara Sharon <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-03-22iwlwifi: mvm: track CSA beaconsSara Sharon1-2/+28
Send to FW modify command for every beacon we receive during channel switch. FW will track the count, and make sure the event is scheduled in time even if AP changed count. Signed-off-by: Sara Sharon <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-03-22iwlwifi: mvm: implement CSA abortSara Sharon1-0/+24
In case we receive abort operation for CSA, clean up our state. Signed-off-by: Sara Sharon <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-03-22iwlwifi: mvm: report delayed beacon count to FWSara Sharon1-0/+4
Support passing to FW delayed beacon count. This represents the delay the AP can have when moving to the new channel. Signed-off-by: Sara Sharon <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-03-22iwlwifi: mvm: fix TX crypto on 22560+ devicesJohannes Berg1-49/+15
In the old days, we could transmit with HW crypto with an arbitrary key by filling it into TX_CMD. This was broken first with the advent of CCMP/GCMP-256 keys which don't fit there. This was broken *again* with the newer TX_CMD format on 22560+, where we simply cannot pass key material anymore. However, we forgot to update all the cases when we get a key from mac80211 and don't program it into the hardware but still return 0 for HW crypto on TX. In AP mode with WEP, we tried to fix this by programming the keys separately for each station later, but this ultimately turns out to be buggy, for example now it leaks memory when we have more than one WEP key. Fix this by simply using only SW crypto for WEP in newer devices by returning -EOPNOTSUPP instead of trying to program WEP keys later. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-02-22Merge tag 'wireless-drivers-next-for-davem-2019-02-22' of ↵David S. Miller1-41/+251
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 5.1 Most likely the last set of patches for 5.1. WPA3 support to ath10k and qtnfmac. FTM support to iwlwifi and ath10k. And of course other new features and bugfixes. wireless-drivers was merged due to dependency in mt76. Major changes: iwlwifi * HE radiotap * FTM (Fine Timing Measurement) initiator and responder implementation * bump supported firmware API to 46 * VHT extended NSS support * new PCI IDs for 9260 and 22000 series ath10k * change QMI interface to support the new (and backwards incompatible) interface from HL3.1 and used in recent HL2.0 branch firmware releases * support WPA3 with WCN3990 * support for mac80211 airtime fairness based on transmit rate estimation, the firmware needs to support WMI_SERVICE_PEER_STATS to enable this * report transmit airtime to mac80211 with firmwares having WMI_SERVICE_REPORT_AIRTIME feature, this to have more accurate airtime fairness based on real transmit time (instead of just estimated from transmit rate) * support Fine Timing Measurement (FTM) responder role * add dynamic VLAN support with firmware having WMI_SERVICE_PER_PACKET_SW_ENCRYPT * switch to use SPDX license identifiers ath * add new country codes for US brcmfmac * support monitor frames with the hardware/ucode header qtnfmac * enable WPA3 SAE and OWE support mt76 * beacon support for USB devices (mesh+ad-hoc only) rtlwifi * convert to use SPDX license identifiers libertas_tf * get the MAC address before registering the device ==================== Signed-off-by: David S. Miller <[email protected]>
2019-02-22Merge remote-tracking branch 'net-next/master' into mac80211-nextJohannes Berg1-59/+190
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 <[email protected]>
2019-02-22mac80211: update HE IEs to D3.3Liad Kaufman1-0/+40
Update element names and new fields according to D3.3 of the HE spec. Signed-off-by: Liad Kaufman <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2019-02-20iwlwifi: mvm: add some debug data to TX pathSara Sharon1-1/+7
This helps debugging when things go wrong. Signed-off-by: Sara Sharon <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-02-20iwlwifi: mvm: remove IWL_MVM_INIT_STATUS_REG_HW_INIT_COMPLETEJohannes Berg1-4/+1
There's no point in this, we already do everything in a nested fashion, and if we didn't we'd already crash in iwl_mvm_leds_exit() etc. Just remove the bit. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-02-20iwlwifi: mvm: fix error path in iwl_mvm_mac_setup_register()Johannes Berg1-6/+9
The IWL_MVM_INIT_STATUS_REG_HW_INIT_COMPLETE bit shouldn't be set, and realistically we should complete all setup before we call the ieee80211_register_hw() function. Fix this. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-02-14iwlwifi: mvm: Do not return an error value on HW restartIlan Peer1-0/+4
When HW restart is requested but not started yet, commands would not be sent to the FW, and some function calls would return an error. In case of iwl_mvm_mac_sta_state() returning an error value when a station is removed can lead to an unneeded warning in __sta_info_destroy_part2(). Handle this by setting the return value to 0, in case HW restart is in progress. Signed-off-by: Ilan Peer <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-02-14iwlwifi: mvm: Don't warn on command failure during restartIlan Peer1-2/+8
When HW restart is requested but not started yet, commands would not be sent to the FW, and some function calls return an error. Such cases can trigger unneeded warning messages, e.g., in iwl_mvm_mac_sta_state() and iwl_mvm_bss_info_changed_station(). Handle a couple of these cases by also checking in the WARN_ON() condition that HW restart is not requested. Signed-off-by: Ilan Peer <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-02-14iwlwifi: add FW recovery flowMordechay Goodstein1-0/+2
Add new API and TLV for the ability to send commands in the beginning and end of reset flow. The full flow of recovery is: 1. While loading FW, get address (from the TLV) of target buffer to read in case of reset 2. If an error/assert happens read the address data from step 1. 3. Reset the HW and load the FW. 4. Send the data read in step 2. 5. Add station keys 6. Send notification to FW that reset flow is done. The main use of the recovery flow is for support in PN/SN recovery when offloaded Signed-off-by: Mordechay Goodstein <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-02-14iwlwifi: mvm: support FTM initiatorJohannes Berg1-1/+55
Add support for FTM initiator, i.e. peer measurements with FTM if the firmware supports FTM. Additionally, add two defines we depend on in include/linux/ieee80211.h. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Avraham Stern <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-02-14iwlwifi: mvm: support FTM responderJohannes Berg1-4/+88
Add support for FTM responder for hardware/firmware combinations that advertise support for it. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Avraham Stern <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-02-14iwlwifi: mvm: don't require WOWLAN images when unifiedIdo Yariv1-1/+5
WOWLAN images in unified firmwares should not be used, so don't require them to support wowlan. This will allow to reduce the firmware's file size. Signed-off-by: Ido Yariv <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-02-04iwlwifi: mvm: config mac ctxt to HE before TLCLiad Kaufman1-0/+4
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 <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-02-04iwlwifi: mvm: fix AP mode in WEPEmmanuel Grumbach1-9/+21
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 <[email protected]> Fixes: 337bfc9881a2 ("iwlwifi: mvm: set wep key for all stations in soft ap mode") Signed-off-by: Luca Coelho <[email protected]>
2019-02-04iwlwifi: mvm: add fall through comments where neededLuca Coelho1-0/+1
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 <[email protected]>
2019-02-04iwlwifi: mvm: support CHANNEL_SWITCH_TIME_EVENT_CMD commandSara Sharon1-19/+52
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 <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-01-29iwlwifi: mvm: update firmware when MU EDCA params changeShaul Triebitz1-0/+6
When MU EDCA params change, resend the STA_HE_CTXT command updating the MU EDCA params. Signed-off-by: Shaul Triebitz <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-01-29iwlwifi: mvm: include configured sniffer AID in radiotapJohannes Berg1-0/+2
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 <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-01-29iwlwifi: mvm: freeze management TXQ timer when station goes to sleepEmmanuel Grumbach1-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 <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-01-29iwlwifi: mvm: Change FW channel info APIDavid Spinadel1-12/+18
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 <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-01-29iwlwifi: mvm: get rid of tx_path_lockSara Sharon1-14/+34
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 <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-01-29iwlwifi: mvm: add an option to dereference vif by idSara Sharon1-0/+4
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 <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-01-29iwlwifi: mvm: remove sta key on wep apLiad Kaufman1-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 <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-01-29iwlwifi: move iwl_enable_{rx,tx}_ampdu to iwl-modparams.hJohannes Berg1-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 <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-01-25iwlwifi: mvm: bring back mvm GSO codeSara Sharon1-1/+0
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 <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-01-25iwlwifi: mvm: support mac80211 AMSDUSara Sharon1-0/+33
Support getting mac80211 building AMSDUs for us. Remove GSO support from mvm - we don't need it anymore. Signed-off-by: Sara Sharon <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-01-25iwlwifi: mvm: support mac80211 TXQs modelSara Sharon1-33/+80
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 <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2019-01-25iwlwifi: mvm: advertise support for TWT in the Extended Capability IEEmmanuel Grumbach1-0/+22
We want to advertise support for TWT in the Extended Capability IE. Since we don't want to set the bits for all the interface types, define an interface specific configuration. Signed-off-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2018-12-20iwlwifi: mvm: fix spelling mistake "Recieved" -> "Received"Colin Ian King1-1/+1
Trivial fix to spelling mistake in debug message. Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2018-12-20iwlwifi: mvm: fix setting HE ppe FW configNaftali Goldstein1-1/+7
The FW expects to get the ppe value for each NSS-BW pair in the same format as in the he phy capabilities IE, which means that a value of 0 implies ppe should be used for BPSK (mcs 0). If there are no PPE thresholds in the IE, or if for some NSS-RU pair there's no threshold set for it (this could happen because it's a variable-sized field), it means no PPE should not be used for that pair, so the value sent to FW should be 7 which corresponds to "none". Fixes: 514c30696fbc ("iwlwifi: add support for IEEE802.11ax") Signed-off-by: Naftali Goldstein <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2018-12-14iwlwifi: mvm: activate apply pointsSara Sharon1-0/+2
Call the previously introduced apply points entry point when reaching an apply point. Signed-off-by: Sara Sharon <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2018-12-03Merge tag 'wireless-drivers-next-for-davem-2018-11-30' of ↵David S. Miller1-0/+31
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 4.21 First set of patches for 4.21. Most notable here is support for Quantenna's QSR1000/QSR2000 chipsets and more flexible ways to provide nvram files for brcmfmac. Major changes: brcmfmac * add support for first trying to get a board specific nvram file * add support for getting nvram contents from EFI variables qtnfmac * use single PCIe driver for all platforms and rename Kconfig option CONFIG_QTNFMAC_PEARL_PCIE to CONFIG_QTNFMAC_PCIE * add support for QSR1000/QSR2000 (Topaz) family of chipsets ath10k * add support for WCN3990 firmware crash recovery * add firmware memory dump support for QCA4019 wil6210 * add firmware error recovery while in AP mode ath9k * remove experimental notice from dynack feature iwlwifi * PCI IDs for some new 9000-series cards * improve antenna usage on connection problems * new firmware debugging infrastructure * some more work on 802.11ax * improve support for multiple RF modules with 22000 devices cordic * move cordic macros and defines to a public header file * convert brcmsmac and b43 to fully use cordic library ==================== Signed-off-by: David S. Miller <[email protected]>
2018-11-23iwlwifi: mvm: set HW capability VHT_EXT_NSS_BWShaul Triebitz1-0/+1
Enable the VHT extended NSS BW feature in iwlwifi/mvm. Signed-off-by: Shaul Triebitz <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
2018-11-23iwlwifi: mvm: send the STA_HE_CTXT command in AP modeShaul Triebitz1-0/+3
In AP mode, if AP supports HE (and the STA), send the STA_HE_CTXT command. This is needed mainly for PPE (packet extension) params. Signed-off-by: Shaul Triebitz <[email protected]> Signed-off-by: Luca Coelho <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.