summaryrefslogtreecommitdiffstats
path: root/net/mac80211/vht.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* wifi: mac80211: work around Cisco AP 9115 VHT MPDU lengthJohannes Berg2023-09-251-2/+14
| | | | | | | | | | | | | | | Cisco AP module 9115 with FW 17.3 has a bug and sends a too large maximum MPDU length in the association response (indicating 12k) that it cannot actually process. Work around that by taking the minimum between what's in the association response and the BSS elements (from beacon or probe response). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230918140607.d1966a9a532e.I090225babb7cd4d1081ee9acd40e7de7e41c15ae@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: Allow NSS change only up to capabilityRameshkumar Sundaram2023-02-141-5/+20
| | | | | | | | | | | | | | | | | | | | Stations can update bandwidth/NSS change in VHT action frame with action type Operating Mode Notification. (IEEE Std 802.11-2020 - 9.4.1.53 Operating Mode field) For Operating Mode Notification, an RX NSS change to a value greater than AP's maximum NSS should not be allowed. During fuzz testing, by forcefully sending VHT Op. mode notif. frames from STA with random rx_nss values, it is found that AP accepts rx_nss values greater that APs maximum NSS instead of discarding such NSS change. Hence allow NSS change only up to maximum NSS that is negotiated and capped to AP's capability during association. Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Link: https://lore.kernel.org/r/20230207114146.10567-1-quic_ramess@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: keep A-MSDU data in sta and per-linkBenjamin Berg2022-09-061-3/+5
| | | | | | | | | | | | | | The A-MSDU data needs to be stored per-link and aggregated into a single value for the station. Add a new struct ieee_80211_sta_aggregates in order to store this data and a new function ieee80211_sta_recalc_aggregates to update the current data for the STA. Note that in the non MLO case the pointer in ieee80211_sta will directly reference the data in deflink.agg, which means that recalculation may be skipped in that case. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: Support multi link in ieee80211_recalc_min_chandef()Andrei Otcheretianski2022-07-151-1/+1
| | | | | | | | | | Recalculate min channel context for the given or all interface links, depending on the caller. For a station state change, we need to recalculate all of them since we don't know which link (or multiple) it might be on. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: RCU-ify link/link_conf pointersJohannes Berg2022-07-151-19/+43
| | | | | | | | | | Since links can be added and removed dynamically, we need to somehow protect the sdata->link[] and vif->link_conf[] array pointers from disappearing when accessing them without locks. RCU-ify the pointers to achieve this, which requires quite a bit of rework. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: RCU-ify link STA pointersJohannes Berg2022-06-201-65/+74
| | | | | | | | | We need to be able to access these in a race-free way under traffic while adding/removing them, so RCU-ify the pointers. This requires passing a link_sta to a lot of functions so we don't have to do the RCU handling everywhere. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: add link_id to vht.c code for MLOJohannes Berg2022-06-201-58/+64
| | | | | | | Update the code in vht.c and add the link_id parameter where necessary. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: make channel context code MLO-awareJohannes Berg2022-06-201-17/+19
| | | | | | | | Make the channel context code MLO aware, along with some functions that it uses, so that the chan.c file is now MLD-clean and no longer uses deflink/bss_conf/etc. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: split bss_info_changed methodJohannes Berg2022-06-201-1/+1
| | | | | | | | | Split the bss_info_changed method to vif_cfg_changed and link_info_changed, with the latter getting a link ID. Also change the 'changed' parameter to u64 already, we know we need that. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: move some future per-link data to bss_confJohannes Berg2022-06-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | | To add MLD, reuse the bss_conf structure later for per-link information, so move some things into it that are per link. Most transformations were done with the following spatch: @@ expression sdata; identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color }; @@ -sdata->vif.var +sdata->vif.bss_conf.var @@ struct ieee80211_vif *vif; identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color }; @@ -vif->var +vif->bss_conf.var Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: prepare sta handling for MLO supportSriram R2022-04-111-39/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently in mac80211 each STA object is represented using sta_info datastructure with the associated STA specific information and drivers access ieee80211_sta part of it. With MLO (Multi Link Operation) support being added in 802.11be standard, though the association is logically with a single Multi Link capable STA, at the physical level communication can happen via different advertised links (uniquely identified by Channel, operating class, BSSID) and hence the need to handle multiple link STA parameters within a composite sta_info object called the MLD STA. The different link STA part of MLD STA are identified using the link address which can be same or different as the MLD STA address and unique link id based on the link vif. To support extension of such a model, the sta_info datastructure is modified to hold multiple link STA objects with link specific params currently within sta_info moved to this new structure. Similarly this is done for ieee80211_sta as well which will be accessed within mac80211 as well as by drivers, hence trivial driver changes are expected to support this. For current non MLO supported drivers, only one link STA is present and link information is accessed via 'deflink' member. For MLO drivers, we still need to define the APIs etc. to get the correct link ID and access the correct part of the station info. Currently in mac80211, all link STA info are accessed directly via deflink. These will be updated to access via link pointers indexed by link id with MLO support patches, with link id being 0 for non MLO supported cases. Except for couple of macro related changes, below spatch takes care of updating mac80211 and driver code to access to the link STA info via deflink. @ieee80211_sta@ struct ieee80211_sta *s; struct sta_info *si; identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr}; @@ ( s-> - var + deflink.var | si->sta. - var + deflink.var ) @sta_info@ struct sta_info *si; identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth}; @@ ( si-> - var + deflink.var ) Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com [remove MLO-drivers notes from commit message, not clear yet; run spatch] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: calculate max RX NSS for EHT modeMordechay Goodstein2022-02-161-1/+13
| | | | | | | | | If the station supports EHT mode, calculate the maximum RX NSS from EHT station capabilities. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Link: https://lore.kernel.org/r/20220214173004.cf61972c8919.I54f5a416f0789bf4eefad04703d941b6755f6dd6@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Handle station association response with EHTIlan Peer2022-02-161-2/+14
| | | | | | | | | | When the association is an EHT association, parse the EHT element from the association response and update the station's EHT capabilities accordingly. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Link: https://lore.kernel.org/r/20220214173004.f33574718755.I21182234c5303d9423eabd5eb997e7cf75f8e0c8@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Add initial support for EHT and 320 MHz channelsIlan Peer2022-02-161-1/+3
| | | | | | | | | | | | 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: Ilan Peer <ilan.peer@intel.com> Link: https://lore.kernel.org/r/20220214173004.0f144cc0bba6.Iad18111264da87eed5fd7b017f0cc6e58c604e07@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: vht: use HE macros for parsing HE capabilitiesMordechay Goodstein2022-02-041-2/+2
| | | | | | | | | | | IEEE80211_VHT_MCS_NOT_SUPPORTED and IEEE80211_HE_MCS_NOT_SUPPORTED have the same value so no real bug, but for code integrity use the HE macros for parsing HE capabilities. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20220202104617.e974b7b3b217.I732cc7f770c7fa06e4840adb5d45d7ee99ac8eb5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove NSS number of 160MHz if not support 160MHz for HEWen Gong2021-01-211-1/+8
| | | | | | | | | | When it does not support 160MHz in HE phy capabilities information, it should not treat the NSS number of 160MHz as a valid number, otherwise the final NSS will be set to 0. Signed-off-by: Wen Gong <wgong@codeaurora.org> Link: https://lore.kernel.org/r/1609816120-9411-2-git-send-email-wgong@codeaurora.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: don't set set TDLS STA bandwidth wider than possibleJohannes Berg2020-12-111-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we set up a TDLS station, we set sta->sta.bandwidth solely based on the capabilities, because the "what's the current bandwidth" check is bypassed and only applied for other types of stations. This leads to the unfortunate scenario that the sta->sta.bandwidth is 160 MHz if both stations support it, but we never actually configure this bandwidth unless the AP is already using 160 MHz; even for wider bandwidth support we only go up to 80 MHz (at least right now.) For iwlwifi, this can also lead to firmware asserts, telling us that we've configured the TX rates for a higher bandwidth than is actually available due to the PHY configuration. For non-TDLS, we check against the interface's requested bandwidth, but we explicitly skip this check for TDLS to cope with the wider BW case. Change this to (a) still limit to the TDLS peer's own chandef, which gets factored into the overall PHY configuration we request from the driver, and (b) limit it to when the TDLS peer is authorized, because it's only factored into the channel context in this case. Fixes: 504871e602d9 ("mac80211: fix bandwidth computation for TDLS peers") 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.20201206145305.fcc7d29c4590.I11f77e9e25ddf871a3c8d5604650c763e2c5887a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller2020-09-231-4/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two minor conflicts: 1) net/ipv4/route.c, adding a new local variable while moving another local variable and removing it's initial assignment. 2) drivers/net/dsa/microchip/ksz9477.c, overlapping changes. One pretty prints the port mode differently, whilst another changes the driver to try and obtain the port mode from the port node rather than the switch node. Signed-off-by: David S. Miller <davem@davemloft.net>
| * mac80211: do not allow bigger VHT MPDUs than the hardware supportsFelix Fietkau2020-09-181-4/+4
| | | | | | | | | | | | | | | | Limit maximum VHT MPDU size by local capability. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20200917125031.45009-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: allow bigger A-MSDU sizes in VHT, even if HT is limitedFelix Fietkau2020-09-181-4/+0
|/ | | | | | | | | | | Some APs (e.g. Asus RT-AC88U) have been observed to report an HT MSDU size limit of 3839 and a VHT limit of 7991. These APs can handle bigger frames than 3839 bytes just fine, so we should remove the VHT limit based on the HT capabilities. This improves tx throughput. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20200916164611.8022-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: implement Operating Mode Notification extended NSS supportJohannes Berg2020-04-241-2/+8
| | | | | | | | | | | | | | | | | | | | | Somehow we missed this for a long time, but similar to the extended NSS support in VHT capabilities, we need to have this in Operating Mode notification. Implement it by * parsing the 160/80+80 bit there and setting the bandwidth appropriately * having callers of ieee80211_get_vht_max_nss() pass in the current max NSS value as received in the operating mode notification in order to modify it appropriately depending on the extended NSS bits. This updates all drivers that use it, i.e. only iwlwifi/mvm. 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.20200326150855.098483728cfa.I4e8c25d3288441759c2793247197229f0696a37d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: HE: set RX NSSTova Mussai2020-02-071-3/+32
| | | | | | | | | | | | | | In case of HE, the RX NSS is taken from the HE capabilities. If the supported NSS capabilities that are reported by AP for HE mode in the HE Capabilities element are different from the NSS capabilities that are reported by AP for the VHT mode in the VHT Capabilities element, use the lowest supported NSS to not get all the values confused. Signed-off-by: Tova Mussai <tova.mussai@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20200131111300.891737-9-luca@coelho.fi Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: set station bandwidth from HE capabilityJohannes Berg2020-02-071-0/+23
| | | | | | | | | | | Set the station bandwidth in HE capability parsing and from HE capability as the HT/VHT information will not be present on the 6 GHz band. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20200131111300.891737-5-luca@coelho.fi Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: vht: add support VHT EXT NSS BW in parsing VHTMordechay Goodstein2019-09-111-1/+9
| | | | | | | | | | | This fixes was missed in parsing the vht capabilities max bw support. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Fixes: e80d642552a3 ("mac80211: copy VHT EXT NSS BW Support/Capable data to station") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20190830114057.22197-1-luca@coelho.fi Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner2019-06-191-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* mac80211: copy VHT EXT NSS BW Support/Capable data to stationJohannes Berg2018-09-051-0/+20
| | | | | | | | | | When taking VHT capabilities for a station, copy the new fields if we support them as a transmitter. Also adjust the maximum bandwidth the station supports appropriately. Also, since it was missing, copy tx_highest and rx_highest. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Use proper chan_width enum in sta opmode eventtamizhr@codeaurora.org2018-03-291-1/+31
| | | | | | | | | | | | | Bandwidth change value reported via nl80211 contains mac80211 specific enum value(ieee80211_sta_rx_bw) and which is not understand by userspace application. Map the mac80211 specific value to nl80211_chan_width enum value to avoid using wrong value in the userspace application. And used station's ht/vht capability to map IEEE80211_STA_RX_BW_20 and IEEE80211_STA_RX_BW_160 with proper nl80211 value. Signed-off-by: Tamizh chelvam <tamizhr@codeaurora.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Add support to notify ht/vht opmode modification.tamizhr@codeaurora.org2018-01-311-0/+9
| | | | | | | | | This will add support to send an event to a userspace application whenever station advertise its ht/vht opmode modification through an action frame. Signed-off-by: Tamizh chelvam <tamizhr@codeaurora.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix bandwidth computation for TDLS peersManikanta Pubbisetty2017-10-021-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | Section 11.23.1 of 80211-2016 specification allows TDLS peers to operate on wider bandwidths though they are connected to a BSS which do not support wider bandwidth operations, provided both the peers advertise wider bandwidth capabilities. The existing logic considers the minimum of station's and AP's capability for bandwidth computation. The same logic applies for TDLS peers as well, this restricts operating on wider bandwidths over a TDLS link when the peers are connected to legacy APs. As an example, if 80Mhz VHT capable peers are connected to a 20Mhz 5 GHz AP, then as per the existing logic TDLS operation will be restricted to 20Mhz. Address this problem by not considering BSS capability in bandwidth computation if the participating TDLS peers have wider bandwidth capability. Signed-off-by: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com> [lots of wording/typo fixes] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2017-01-171-1/+3
|\
| * mac80211: recalculate min channel width on VHT opmode changesJohannes Berg2017-01-111-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | When an associated station changes its VHT operating mode this can/will affect the bandwidth it's using, and consequently we must recalculate the minimum bandwidth we need to use. Failure to do so can lead to one of two scenarios: 1) we use a too high bandwidth, this is benign 2) we use a too narrow bandwidth, causing rate control and actual PHY configuration to be out of sync, which can in turn cause problems/crashes Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: Remove unused 'sband' and 'local' variablesKirtika Ruchandani2016-12-131-4/+0
|/ | | | | | | | | | | | | | | | | | | | | | | Commit b1bce14a7954 (mac80211: update opmode when adding new station) refactored ieee80211_vht_handle_opmode into __ieee80211_vht_handle_opmode and ieee80211_vht_handle_opmode leaving a set but unused variable (sband) in the former. Compiling with W=1 gives the following warning, fix it. net/mac80211/vht.c: In function ‘__ieee80211_vht_handle_opmode’: net/mac80211/vht.c:424:35: warning: variable ‘sband’ set but not used [-Wunused-but-set-variable] Remove 'struct ieee80211_local* local' as well, it was only used to set sband. This is a harmless warning, and is only being fixed to reduce the noise with W=1 in the kernel. Fixes: b1bce14a7954 ("mac80211: update opmode when adding new station") Cc: Marek Kwaczynski <marek.kwaczynski@tieto.com> Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kirtika Ruchandani <kirtika@chromium.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Ignore VHT IE from peer with wrong rx_mcs_mapFilip Matusiak2016-11-151-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a workaround for VHT-enabled STAs which break the spec and have the VHT-MCS Rx map filled in with value 3 for all eight spacial streams, an example is AR9462 in AP mode. As per spec, in section 22.1.1 Introduction to the VHT PHY A VHT STA shall support at least single spactial stream VHT-MCSs 0 to 7 (transmit and receive) in all supported channel widths. Some devices in STA mode will get firmware assert when trying to associate, examples are QCA9377 & QCA6174. Packet example of broken VHT Cap IE of AR9462: Tag: VHT Capabilities (IEEE Std 802.11ac/D3.1) Tag Number: VHT Capabilities (IEEE Std 802.11ac/D3.1) (191) Tag length: 12 VHT Capabilities Info: 0x00000000 VHT Supported MCS Set Rx MCS Map: 0xffff .... .... .... ..11 = Rx 1 SS: Not Supported (0x0003) .... .... .... 11.. = Rx 2 SS: Not Supported (0x0003) .... .... ..11 .... = Rx 3 SS: Not Supported (0x0003) .... .... 11.. .... = Rx 4 SS: Not Supported (0x0003) .... ..11 .... .... = Rx 5 SS: Not Supported (0x0003) .... 11.. .... .... = Rx 6 SS: Not Supported (0x0003) ..11 .... .... .... = Rx 7 SS: Not Supported (0x0003) 11.. .... .... .... = Rx 8 SS: Not Supported (0x0003) ...0 0000 0000 0000 = Rx Highest Long GI Data Rate (in Mb/s, 0 = subfield not in use): 0x0000 Tx MCS Map: 0xffff ...0 0000 0000 0000 = Tx Highest Long GI Data Rate (in Mb/s, 0 = subfield not in use): 0x0000 Signed-off-by: Filip Matusiak <filip.matusiak@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: remove enum ieee80211_bandJohannes Berg2016-04-121-2/+2
| | | | | | | | | 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>
* mac80211: TDLS: change BW calculation for WIDER_BW peersArik Nemtsov2016-04-051-5/+25
| | | | | | | | | | | | | | | | The previous approach simply ignored chandef restrictions when calculating the appropriate peer BW for a WIDER_BW peer. This could result in a regulatory violation if both peers indicated 80MHz support, but the regdomain forbade it. Change the approach to setting a WIDER_BW peer's BW. Don't exempt it from the chandef width at first. If during TDLS negotiation the chandef width is upgraded, update the peer's BW to match. Fixes: 0fabfaafec3a ("mac80211: upgrade BW of TDLS peers when possible") Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: move MU_MIMO_OWNER flag to ieee80211_vifSara Sharon2016-02-241-4/+3
| | | | | | | | | | Drivers may need to track which vif is using VHT MU-MIMO. Move the flag indicationg the ownership of MU_MIMO to ieee80211_vif. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: provide interface to driver to set VHT MU-MIMO dataSara Sharon2016-02-241-1/+15
| | | | | | | | | | | Provide an interface to the lower level driver to set the VHT MU-MIMO data. This is needed for example when there is an update of the group data during low power state, where the management frame will not be passed to the host at all. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix VHT MU-MIMO frame processingSara Sharon2016-02-241-4/+6
| | | | | | | | | | The source and destintation addresses in the memcpy arguments are flipped. Fix that. Fixes: 23a1f8d44c0b("mac80211: process and save VHT MU-MIMO group frame") Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: limit the A-MSDU Tx based on peer's capabilitiesEmmanuel Grumbach2016-02-241-0/+17
| | | | | | | | | | | | | | | | In VHT, the specification allows to limit the number of MSDUs in an A-MSDU in the Extended Capabilities IE. There is also a limitation on the byte size in the VHT IE. In HT, the only limitation is on the byte size. Parse the capabilities from the peer and make them available to the driver. In HT, there is another limitation when a BA agreement is active: the byte size can't be greater than 4095. This is not enforced here. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: process and save VHT MU-MIMO group frameSara Sharon2016-01-141-0/+25
| | | | | | | | | | | | | The Group ID Management frame is an Action frame of category VHT. It is transmitted by the AP to assign or change the user position of a STA for one or more group IDs. Process and save the group membership data. Notify underlying driver of changes. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: handle width changes from opmode notification IE in beaconEyal Shapira2015-12-151-7/+3
| | | | | | | | | | | An AP can send an operating channel width change in a beacon opmode notification IE as long as there's a change in the nss as well (See 802.11ac-2013 section 10.41). So don't limit updating to nss only from an opmode notification IE. Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: avoid VHT usage with no 80MHz chans allowedArik Nemtsov2015-09-041-0/+15
| | | | | | | | | | | | | Currently if 80MHz channels are not allowed for use, the VHT IE is not included in the probe request for an AP. This is not good enough if the AP is configured with the wrong regulatory and supports VHT even where prohibited or in TDLS scenarios. Mark the ifmgd with the DISABLE_VHT flag for the misbehaving-AP case, and unset VHT support from the peer-station entry for the TDLS case. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add rate mask logic for vht ratesLorenzo Bianconi2015-08-141-0/+26
| | | | | | | | Define rc_rateidx_vht_mcs_mask array and rate_idx_match_vht_mcs_mask() method in order to apply mcs mask for vht rates Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: define TDLS wider BW support bitsArik Nemtsov2015-07-171-2/+6
| | | | | | | | | | | | | | | | | Allow a device to specify support for the TDLS wider-bandwidth feature. Indicate this support during TDLS setup in the ext-capab IE and set an appropriate station flag when our TDLS peer supports it. This feature gives TDLS peers the ability to use a wider channel than the base width of the BSS. For instance VHT capable TDLS peers connected on a 20MHz channel can extend the channel to 80MHz, if regulatory considerations allow it. Do not cap the bandwidth of such stations by the current BSS channel width in mac80211. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: TDLS: support VHT between peersArik Nemtsov2015-03-031-4/+0
| | | | | | | | | Add the AID and VHT-cap/operation IEs during TDLS setup. Remove the block of TDLS peers when setting HT-caps of the peer station. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: update sta bw on ht chanwidth action frameEliad Peller2014-12-171-35/+38
| | | | | | | | | | | | | | | | Commit e1a0c6b ("mac80211: stop toggling IEEE80211_HT_CAP_SUP_WIDTH_20_40") mistakenly removed the actual update of sta->sta.bandwidth. Refactor ieee80211_sta_cur_vht_bw() into multiple functions (calculate caps-bw and chandef-bw separately, and min them with cur_max_bandwidth). On ht chanwidth action frame set only cur_max_bandwidth (according to the sta capabilities) and recalc the sta bw. Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: don't allow 40MHz tx rates in case of 20MHz chandefEliad Peller2014-11-191-0/+2
| | | | | | | | | | When 20MHz chandef is used, 40MHz rates shouldn't be used (by the rate-control algorithm), even if the sta ht capabilities indicate support for it. Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Singed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: disable VHT for TDLSArik Nemtsov2014-07-211-0/+4
| | | | | | | | | | TDLS VHT support requires some more information elements during setup. While these are not there, mask out the peer's VHT capabilities so that VHT rates are not mistakenly used. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: allow VHT with peers not capable of 40MHzJohannes Berg2014-05-091-3/+6
| | | | | | | | | | | | | | | | | | | | | There are two (related) issues with this. One case, reported by Michal, is related to hostap: it unsets the 20/40 capability bit for stations that associate when it's in 20 MHz mode. The other case, reported by Eyal, is that some APs like Netgear R6300v2 and probably others based on the BCM4360 chipset can be configured for doing VHT at 20Mhz. In this case the beacon has a VHT IE but the HT cap indicates transmitter only support 20Mhz. In both of these cases, we currently avoid VHT and use only HT this means we can't use the highest rates (MCS8), so fixing this leads to throughput improvements. Reported-by: Michal Kazior <michal.kazior@tieto.com> Reported-by: Eyal Shapira <eyal@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: update opmode when adding new stationMarek Kwaczynski2014-02-051-7/+19
| | | | | | | | | | Update the operating mode field is needed when an association request contains the operating mode notification element and it's not just changed later on the fly. Signed-off-by: Marek Kwaczynski <marek.kwaczynski@tieto.com> [clarify commit log, comments & fix whitespace] Signed-off-by: Johannes Berg <johannes.berg@intel.com>