aboutsummaryrefslogtreecommitdiffstats
path: root/net/mac80211/vht.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2016-04-12cfg80211: remove enum ieee80211_bandJohannes Berg1-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>
2016-04-05mac80211: TDLS: change BW calculation for WIDER_BW peersArik Nemtsov1-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>
2016-02-24mac80211: move MU_MIMO_OWNER flag to ieee80211_vifSara Sharon1-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>
2016-02-24mac80211: provide interface to driver to set VHT MU-MIMO dataSara Sharon1-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>
2016-02-24mac80211: fix VHT MU-MIMO frame processingSara Sharon1-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>
2016-02-24mac80211: limit the A-MSDU Tx based on peer's capabilitiesEmmanuel Grumbach1-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>
2016-01-14mac80211: process and save VHT MU-MIMO group frameSara Sharon1-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>
2015-12-15mac80211: handle width changes from opmode notification IE in beaconEyal Shapira1-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>
2015-09-04mac80211: avoid VHT usage with no 80MHz chans allowedArik Nemtsov1-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>
2015-08-14mac80211: add rate mask logic for vht ratesLorenzo Bianconi1-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>
2015-07-17mac80211: define TDLS wider BW support bitsArik Nemtsov1-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>
2015-03-03mac80211: TDLS: support VHT between peersArik Nemtsov1-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>
2014-12-17mac80211: update sta bw on ht chanwidth action frameEliad Peller1-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>
2014-11-19mac80211: don't allow 40MHz tx rates in case of 20MHz chandefEliad Peller1-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>
2014-07-21mac80211: disable VHT for TDLSArik Nemtsov1-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>
2014-05-09mac80211: allow VHT with peers not capable of 40MHzJohannes Berg1-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>
2014-02-05mac80211: update opmode when adding new stationMarek Kwaczynski1-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>
2013-11-25mac80211: enable easier manipulation of VHT beamforming capsEyal Shapira1-4/+3
Introduce shift and mask defines for beamformee STS cap and number of sounding dimensions cap as these can take any 3 bit value. While at it also cleanup an unrequired parenthesis. Signed-off-by: Eyal Shapira <eyal@wizery.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-10-01ieee80211: fix vht cap definitionsEliad Peller1-2/+2
VHT_CAP_BEAMFORMER_ANTENNAS cap is actually defined in the draft as VHT_CAP_BEAMFORMEE_STS_MAX, and its size is 3 bits long. VHT_CAP_SOUNDING_DIMENSIONS is also 3 bits long. Fix the definitions and change the cap masking accordingly. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-06-13mac80211: Fix VHT bandwidth change eventIlan Peer1-1/+1
Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-03-06mac80211: restrict peer's VHT capabilities to ownJohannes Berg1-1/+113
Implement restricting peer VHT capabilities to the device's own capabilities. This is useful when a single driver supports more than one device and the devices have different capabilities (often they will differ in the number of spatial streams), but in particular is also necessary for VHT capability overrides to work correctly -- otherwise it'd be possible to e.g. advertise, due to overrides, that TX-STBC is not supported, but then still use it to TX to the AP because it supports RX-STBC. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-03-06mac80211: support VHT capability overridesJohannes Berg1-0/+98
Support the cfg80211 API to override VHT capabilities on association. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: constify IE parsingJohannes Berg1-4/+5
Make all the parsed IE pointers const, and propagate the change to all the users etc. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: handle operating mode notif in beacon/assoc responseJohannes Berg1-1/+5
In beacons and association response frames an AP may include an operating mode notification element to advertise changes in the number of spatial streams it can receive. Handle this using the existing function that handles the action frame, but only handle NSS changes, not bandwidth changes which aren't allowed here. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: handle VHT operating mode notificationJohannes Berg1-10/+83
Handle the operating mode notification action frame. When the supported streams or the bandwidth change let the driver and rate control algorithm know. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: track number of spatial streamsJohannes Berg1-0/+41
With VHT, a station can change the number of spatial streams it can receive on the fly, not unlike spatial multiplexing in HT. Prepare for that by tracking the maximum number of spatial streams it can receive when the connection is established. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: stop toggling IEEE80211_HT_CAP_SUP_WIDTH_20_40Johannes Berg1-0/+39
For VHT, many more bandwidth changes are possible. As a first step, stop toggling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 flag in the HT capabilities and instead introduce a bandwidth field indicating the currently usable bandwidth to transmit to the station. Of course, make all drivers use it. To achieve this, make ieee80211_ht_cap_ie_to_sta_ht_cap() get the station as an argument, rather than the new capabilities, so it can set up the new bandwidth field. If the station is a VHT station and VHT bandwidth is in use, also set the bandwidth accordingly. Doing this allows us to get rid of the supports_40mhz flag as the HT capabilities now reflect the true capability instead of the current setting. While at it, also fix ieee80211_ht_cap_ie_to_sta_ht_cap() to not ignore HT cap overrides when MCS TX isn't supported (not that it really happens...) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: pass station to ieee80211_vht_cap_ie_to_sta_vht_capJohannes Berg1-3/+5
Like with HT, make things a bit simpler in future patches by passing the station to ieee80211_vht_cap_ie_to_sta_vht_cap() instead of the vht_cap pointer. Also disable VHT here if HT isn't supported. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-10-17mac80211: VHT peer STA capsMahesh Palivela1-0/+35
Save the AP's VHT capabilities (in managed mode) and make them available to the driver in the station information. Unlike HT capabilities, they aren't restricted to the common capabilities, so drivers must be aware of their own capabilities. Signed-off-by: Mahesh Palivela <maheshp@posedge.com> [fix endian conversion bug ...] Signed-off-by: Johannes Berg <johannes.berg@intel.com>