d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
fef99da69f
freebsd-skq/sys/net80211/ieee80211_vht.c

868 lines
24 KiB
C
Raw Normal View History

[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
/*-
* Copyright (c) 2017 Adrian Chadd <adrian@FreeBSD.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#include <sys/cdefs.h>
#ifdef __FreeBSD__
__FBSDID("$FreeBSD$");
#endif
/*
* IEEE 802.11ac-2013 protocol support.
*/
#include "opt_inet.h"
#include "opt_wlan.h"
#include <sys/param.h>
#include <sys/kernel.h>
#include <sys/malloc.h>
#include <sys/systm.h>
#include <sys/endian.h>
net: clean up empty lines in .c and .h files
2020-09-01 21:19:14 +00:00
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
#include <sys/socket.h>
#include <net/if.h>
#include <net/if_var.h>
#include <net/if_media.h>
#include <net/ethernet.h>
#include <net80211/ieee80211_var.h>
#include <net80211/ieee80211_action.h>
#include <net80211/ieee80211_input.h>
#include <net80211/ieee80211_vht.h>
#define ADDSHORT(frm, v) do { \
frm[0] = (v) & 0xff; \
frm[1] = (v) >> 8; \
frm += 2; \
} while (0)
#define ADDWORD(frm, v) do { \
frm[0] = (v) & 0xff; \
frm[1] = ((v) >> 8) & 0xff; \
frm[2] = ((v) >> 16) & 0xff; \
frm[3] = ((v) >> 24) & 0xff; \
frm += 4; \
} while (0)
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/*
* Immediate TODO:
*
* + handle WLAN_ACTION_VHT_OPMODE_NOTIF and other VHT action frames
* + ensure vhtinfo/vhtcap parameters correctly use the negotiated
* capabilities and ratesets
* + group ID management operation
*/
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
/*
* XXX TODO: handle WLAN_ACTION_VHT_OPMODE_NOTIF
*
* Look at mac80211/vht.c:ieee80211_vht_handle_opmode() for further details.
*/
[net80211] add VHT action frame placeholders for when it's time to implement.
2017-01-10 07:21:07 +00:00
static int
vht_recv_action_placeholder(struct ieee80211_node *ni,
const struct ieee80211_frame *wh,
const uint8_t *frm, const uint8_t *efrm)
{
Fix build without IEEE80211_DEBUG. Reported by: many
2017-01-10 19:28:40 +00:00
#ifdef IEEE80211_DEBUG
[net80211] add VHT action frame placeholders for when it's time to implement.
2017-01-10 07:21:07 +00:00
ieee80211_note(ni->ni_vap, "%s: called; fc=0x%.2x/0x%.2x",
net80211: remove vertical whitespace No functional changes. MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
2020-08-17 16:28:59 +00:00
__func__, wh->i_fc[0], wh->i_fc[1]);
Fix build without IEEE80211_DEBUG. Reported by: many
2017-01-10 19:28:40 +00:00
#endif
[net80211] add VHT action frame placeholders for when it's time to implement.
2017-01-10 07:21:07 +00:00
return (0);
}
static int
vht_send_action_placeholder(struct ieee80211_node *ni,
int category, int action, void *arg0)
{
Fix build without IEEE80211_DEBUG. Reported by: many
2017-01-10 19:28:40 +00:00
#ifdef IEEE80211_DEBUG
[net80211] add VHT action frame placeholders for when it's time to implement.
2017-01-10 07:21:07 +00:00
ieee80211_note(ni->ni_vap, "%s: called; category=%d, action=%d",
net80211: remove vertical whitespace No functional changes. MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
2020-08-17 16:28:59 +00:00
__func__, category, action);
Fix build without IEEE80211_DEBUG. Reported by: many
2017-01-10 19:28:40 +00:00
#endif
[net80211] add VHT action frame placeholders for when it's time to implement.
2017-01-10 07:21:07 +00:00
return (EINVAL);
}
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
static void
ieee80211_vht_init(void)
{
[net80211] add VHT action frame placeholders for when it's time to implement.
2017-01-10 07:21:07 +00:00
ieee80211_recv_action_register(IEEE80211_ACTION_CAT_VHT,
WLAN_ACTION_VHT_COMPRESSED_BF, vht_recv_action_placeholder);
ieee80211_recv_action_register(IEEE80211_ACTION_CAT_VHT,
WLAN_ACTION_VHT_GROUPID_MGMT, vht_recv_action_placeholder);
ieee80211_recv_action_register(IEEE80211_ACTION_CAT_VHT,
WLAN_ACTION_VHT_OPMODE_NOTIF, vht_recv_action_placeholder);
ieee80211_send_action_register(IEEE80211_ACTION_CAT_VHT,
WLAN_ACTION_VHT_COMPRESSED_BF, vht_send_action_placeholder);
ieee80211_send_action_register(IEEE80211_ACTION_CAT_VHT,
WLAN_ACTION_VHT_GROUPID_MGMT, vht_send_action_placeholder);
ieee80211_send_action_register(IEEE80211_ACTION_CAT_VHT,
WLAN_ACTION_VHT_OPMODE_NOTIF, vht_send_action_placeholder);
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
}
SYSINIT(wlan_vht, SI_SUB_DRIVERS, SI_ORDER_FIRST, ieee80211_vht_init, NULL);
void
ieee80211_vht_attach(struct ieee80211com *ic)
{
}
void
ieee80211_vht_detach(struct ieee80211com *ic)
{
}
void
ieee80211_vht_vattach(struct ieee80211vap *vap)
{
struct ieee80211com *ic = vap->iv_ic;
if (! IEEE80211_CONF_VHT(ic))
return;
vap->iv_vhtcaps = ic->ic_vhtcaps;
vap->iv_vhtextcaps = ic->ic_vhtextcaps;
/* XXX assume VHT80 support; should really check vhtcaps */
vap->iv_flags_vht =
IEEE80211_FVHT_VHT
| IEEE80211_FVHT_USEVHT40
| IEEE80211_FVHT_USEVHT80;
net80211: update for (more) VHT160 support Implement two macros IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_IS_160MHZ() and its 80+80 counter part to check in vhtcaps for appropriate levels of support and use the macros throughout the code. Add vht160_chan_ranges/is_vht160_valid_freq and handle analogue to vht80 in various parts of the code. Add ieee80211_add_channel_cbw() which also takes the CBW flag fields and make the former ieee80211_add_channel() a wrapper to it. With the CBW flags we can add HT/VHT channels passing them to getflags() for the 2/5ghz functions. In ifconfig(8) add the regdomain_addchans() support for VHT160 and VHT80P80. With this (+ regdoain.xml updates) VHT160 channels can be configured, listed, and pass regdomain where appropriate. Tested with: iwlwifi Reviewed by: adrian MFC after: 10 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D26712
2020-10-18 00:27:20 +00:00
if (IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_IS_160MHZ(vap->iv_vhtcaps))
net80211 / ifconfig: cleanup the use of IEEE80211_FVHT_USEVHT* Rather then using magic numbers duplicate IEEE80211_FVHT_VHT* in ifconfig (cleanup of these and other flags used and not exposed by net80211 should happen later) and use those. In the kernel this simplifies one ioctl path (the other one currently relies on individual bit flags being passed in). We also re-order the 80P80 and 160 flag for 160 to come before 80+80 and more clearly leave the flags as TODO in one of the 160/80+80 cases. Reviewed by: adrian MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26000
2020-08-17 12:43:07 +00:00
vap->iv_flags_vht |= IEEE80211_FVHT_USEVHT160;
net80211: update for (more) VHT160 support Implement two macros IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_IS_160MHZ() and its 80+80 counter part to check in vhtcaps for appropriate levels of support and use the macros throughout the code. Add vht160_chan_ranges/is_vht160_valid_freq and handle analogue to vht80 in various parts of the code. Add ieee80211_add_channel_cbw() which also takes the CBW flag fields and make the former ieee80211_add_channel() a wrapper to it. With the CBW flags we can add HT/VHT channels passing them to getflags() for the 2/5ghz functions. In ifconfig(8) add the regdomain_addchans() support for VHT160 and VHT80P80. With this (+ regdoain.xml updates) VHT160 channels can be configured, listed, and pass regdomain where appropriate. Tested with: iwlwifi Reviewed by: adrian MFC after: 10 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D26712
2020-10-18 00:27:20 +00:00
if (IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_IS_160_80P80MHZ(vap->iv_vhtcaps))
net80211 / ifconfig: cleanup the use of IEEE80211_FVHT_USEVHT* Rather then using magic numbers duplicate IEEE80211_FVHT_VHT* in ifconfig (cleanup of these and other flags used and not exposed by net80211 should happen later) and use those. In the kernel this simplifies one ioctl path (the other one currently relies on individual bit flags being passed in). We also re-order the 80P80 and 160 flag for 160 to come before 80+80 and more clearly leave the flags as TODO in one of the 160/80+80 cases. Reviewed by: adrian MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26000
2020-08-17 12:43:07 +00:00
vap->iv_flags_vht |= IEEE80211_FVHT_USEVHT80P80;
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
memcpy(&vap->iv_vht_mcsinfo, &ic->ic_vht_mcsinfo,
sizeof(struct ieee80211_vht_mcs_info));
}
void
ieee80211_vht_vdetach(struct ieee80211vap *vap)
{
}
#if 0
static void
vht_announce(struct ieee80211com *ic, enum ieee80211_phymode mode)
{
}
#endif
static int
vht_mcs_to_num(int m)
{
switch (m) {
case IEEE80211_VHT_MCS_SUPPORT_0_7:
return (7);
case IEEE80211_VHT_MCS_SUPPORT_0_8:
return (8);
case IEEE80211_VHT_MCS_SUPPORT_0_9:
return (9);
default:
return (0);
}
}
void
ieee80211_vht_announce(struct ieee80211com *ic)
{
int i, tx, rx;
if (! IEEE80211_CONF_VHT(ic))
return;
/* Channel width */
net80211: update for (more) VHT160 support Implement two macros IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_IS_160MHZ() and its 80+80 counter part to check in vhtcaps for appropriate levels of support and use the macros throughout the code. Add vht160_chan_ranges/is_vht160_valid_freq and handle analogue to vht80 in various parts of the code. Add ieee80211_add_channel_cbw() which also takes the CBW flag fields and make the former ieee80211_add_channel() a wrapper to it. With the CBW flags we can add HT/VHT channels passing them to getflags() for the 2/5ghz functions. In ifconfig(8) add the regdomain_addchans() support for VHT160 and VHT80P80. With this (+ regdoain.xml updates) VHT160 channels can be configured, listed, and pass regdomain where appropriate. Tested with: iwlwifi Reviewed by: adrian MFC after: 10 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D26712
2020-10-18 00:27:20 +00:00
ic_printf(ic, "[VHT] Channel Widths: 20MHz, 40MHz, 80MHz%s%s\n",
(IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_IS_160MHZ(ic->ic_vhtcaps)) ?
", 160MHz" : "",
(IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_IS_160_80P80MHZ(ic->ic_vhtcaps)) ?
", 80+80MHz" : "");
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
/* Features */
ic_printf(ic, "[VHT] Features: %b\n", ic->ic_vhtcaps,
IEEE80211_VHTCAP_BITS);
/* For now, just 5GHz VHT. Worry about 2GHz VHT later */
net80211: VHT correct NSS Set loop boundary For the <VHT-MCS, NSS> tuple, NSS is 1..8 (or in our loop case 0..7 but not 0..6). Correct the boundry to check for < 8 and not < 7. MFC after: 2 weeks Reviewed by: adrian Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26087
2020-08-17 20:16:33 +00:00
for (i = 0; i < 8; i++) {
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
/* Each stream is 2 bits */
tx = (ic->ic_vht_mcsinfo.tx_mcs_map >> (2*i)) & 0x3;
rx = (ic->ic_vht_mcsinfo.rx_mcs_map >> (2*i)) & 0x3;
if (tx == 3 && rx == 3)
continue;
ic_printf(ic, "[VHT] NSS %d: TX MCS 0..%d, RX MCS 0..%d\n",
net80211: remove vertical whitespace No functional changes. MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
2020-08-17 16:28:59 +00:00
i + 1, vht_mcs_to_num(tx), vht_mcs_to_num(rx));
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
}
}
void
ieee80211_vht_node_init(struct ieee80211_node *ni)
{
IEEE80211_NOTE(ni->ni_vap, IEEE80211_MSG_11N, ni,
"%s: called", __func__);
ni->ni_flags |= IEEE80211_NODE_VHT;
}
void
ieee80211_vht_node_cleanup(struct ieee80211_node *ni)
{
IEEE80211_NOTE(ni->ni_vap, IEEE80211_MSG_11N, ni,
"%s: called", __func__);
ni->ni_flags &= ~IEEE80211_NODE_VHT;
ni->ni_vhtcap = 0;
bzero(&ni->ni_vht_mcsinfo, sizeof(struct ieee80211_vht_mcs_info));
}
/*
* Parse an 802.11ac VHT operation IE.
*/
void
ieee80211_parse_vhtopmode(struct ieee80211_node *ni, const uint8_t *ie)
{
/* vht operation */
ni->ni_vht_chanwidth = ie[2];
ni->ni_vht_chan1 = ie[3];
ni->ni_vht_chan2 = ie[4];
ni->ni_vht_basicmcs = le16dec(ie + 5);
#if 0
printf("%s: chan1=%d, chan2=%d, chanwidth=%d, basicmcs=0x%04x\n",
net80211: remove vertical whitespace No functional changes. MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
2020-08-17 16:28:59 +00:00
__func__, ni->ni_vht_chan1, ni->ni_vht_chan2, ni->ni_vht_chanwidth,
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
ni->ni_vht_basicmcs);
#endif
}
/*
* Parse an 802.11ac VHT capability IE.
*/
void
ieee80211_parse_vhtcap(struct ieee80211_node *ni, const uint8_t *ie)
{
/* vht capability */
ni->ni_vhtcap = le32dec(ie + 2);
/* suppmcs */
ni->ni_vht_mcsinfo.rx_mcs_map = le16dec(ie + 6);
ni->ni_vht_mcsinfo.rx_highest = le16dec(ie + 8);
ni->ni_vht_mcsinfo.tx_mcs_map = le16dec(ie + 10);
ni->ni_vht_mcsinfo.tx_highest = le16dec(ie + 12);
}
int
ieee80211_vht_updateparams(struct ieee80211_node *ni,
const uint8_t *vhtcap_ie,
const uint8_t *vhtop_ie)
{
//printf("%s: called\n", __func__);
ieee80211_parse_vhtcap(ni, vhtcap_ie);
ieee80211_parse_vhtopmode(ni, vhtop_ie);
return (0);
}
void
ieee80211_setup_vht_rates(struct ieee80211_node *ni,
const uint8_t *vhtcap_ie,
const uint8_t *vhtop_ie)
{
//printf("%s: called\n", __func__);
/* XXX TODO */
}
void
[net80211] Commit files missing in the previous commit These belong to my previous commit, but apparently I typed ieee80211_vhf.[ch] and forgot ht.h. Le oops.
2020-07-01 00:24:55 +00:00
ieee80211_vht_timeout(struct ieee80211vap *vap)
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
{
}
void
ieee80211_vht_node_join(struct ieee80211_node *ni)
{
IEEE80211_NOTE(ni->ni_vap, IEEE80211_MSG_11N, ni,
"%s: called", __func__);
}
void
ieee80211_vht_node_leave(struct ieee80211_node *ni)
{
IEEE80211_NOTE(ni->ni_vap, IEEE80211_MSG_11N, ni,
"%s: called", __func__);
}
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/*
* Calculate the VHTCAP IE for a given node.
*
* This includes calculating the capability intersection based on the
* current operating mode and intersection of the TX/RX MCS maps.
*
* The standard only makes it clear about MCS rate negotiation
* and MCS basic rates (which must be a subset of the general
* negotiated rates). It doesn't make it clear that the AP should
* figure out the minimum functional overlap with the STA and
* support that.
*
* Note: this is in host order, not in 802.11 endian order.
*
* TODO: ensure I re-read 9.7.11 Rate Selection for VHT STAs.
*
* TODO: investigate what we should negotiate for MU-MIMO beamforming
* options.
*
* opmode is '1' for "vhtcap as if I'm a STA", 0 otherwise.
*/
void
ieee80211_vht_get_vhtcap_ie(struct ieee80211_node *ni,
struct ieee80211_ie_vhtcap *vhtcap, int opmode)
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
{
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
struct ieee80211vap *vap = ni->ni_vap;
// struct ieee80211com *ic = vap->iv_ic;
uint32_t val, val1, val2;
uint32_t new_vhtcap;
int i;
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
vhtcap->ie = IEEE80211_ELEMID_VHT_CAP;
vhtcap->len = sizeof(struct ieee80211_ie_vhtcap) - 2;
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/*
* Capabilities - it depends on whether we are a station
* or not.
*/
new_vhtcap = 0;
/*
* Station - use our desired configuration based on
* local config, local device bits and the already-learnt
* vhtcap/vhtinfo IE in the node.
*/
/* Limit MPDU size to the smaller of the two */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
IEEE80211_VHTCAP_MAX_MPDU_MASK);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
if (opmode == 1) {
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
IEEE80211_VHTCAP_MAX_MPDU_MASK);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
}
val = MIN(val1, val2);
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val, IEEE80211_VHTCAP_MAX_MPDU_MASK);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/* Limit supp channel config */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_MASK);
if (opmode == 1) {
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_MASK);
}
if ((val2 == 2) &&
((vap->iv_flags_vht & IEEE80211_FVHT_USEVHT80P80) == 0))
val2 = 1;
if ((val2 == 1) &&
((vap->iv_flags_vht & IEEE80211_FVHT_USEVHT160) == 0))
val2 = 0;
val = MIN(val1, val2);
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val,
IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_MASK);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/* RX LDPC */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
IEEE80211_VHTCAP_RXLDPC);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
if (opmode == 1) {
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
IEEE80211_VHTCAP_RXLDPC);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
}
val = MIN(val1, val2);
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val, IEEE80211_VHTCAP_RXLDPC);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/* Short-GI 80 */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
IEEE80211_VHTCAP_SHORT_GI_80);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
if (opmode == 1) {
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
IEEE80211_VHTCAP_SHORT_GI_80);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
}
val = MIN(val1, val2);
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val, IEEE80211_VHTCAP_SHORT_GI_80);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/* Short-GI 160 */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
IEEE80211_VHTCAP_SHORT_GI_160);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
if (opmode == 1) {
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
IEEE80211_VHTCAP_SHORT_GI_160);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
}
val = MIN(val1, val2);
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val, IEEE80211_VHTCAP_SHORT_GI_160);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/*
* STBC is slightly more complicated.
*
* In non-STA mode, we just announce our capabilities and that
* is that.
*
* In STA mode, we should calculate our capabilities based on
* local capabilities /and/ what the remote says. So:
*
* + Only TX STBC if we support it and the remote supports RX STBC;
* + Only announce RX STBC if we support it and the remote supports
* TX STBC;
* + RX STBC should be the minimum of local and remote RX STBC;
*/
/* TX STBC */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
IEEE80211_VHTCAP_TXSTBC);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
if (opmode == 1) {
/* STA mode - enable it only if node RXSTBC is non-zero */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = !! _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
IEEE80211_VHTCAP_RXSTBC_MASK);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
}
val = MIN(val1, val2);
/* XXX For now, use the 11n config flag */
if ((vap->iv_flags_ht & IEEE80211_FHT_STBC_TX) == 0)
val = 0;
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val, IEEE80211_VHTCAP_TXSTBC);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/* RX STBC1..4 */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
IEEE80211_VHTCAP_RXSTBC_MASK);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
if (opmode == 1) {
/* STA mode - enable it only if node TXSTBC is non-zero */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
IEEE80211_VHTCAP_TXSTBC);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
}
val = MIN(val1, val2);
/* XXX For now, use the 11n config flag */
if ((vap->iv_flags_ht & IEEE80211_FHT_STBC_RX) == 0)
val = 0;
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val, IEEE80211_VHTCAP_RXSTBC_MASK);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/*
* Finally - if RXSTBC is 0, then don't enable TXSTBC.
* Strictly speaking a device can TXSTBC and not RXSTBC, but
* it would be silly.
*/
if (val == 0)
new_vhtcap &= ~IEEE80211_VHTCAP_TXSTBC;
/*
* Some of these fields require other fields to exist.
* So before using it, the parent field needs to be checked
* otherwise the overridden value may be wrong.
*
* For example, if SU beamformee is set to 0, then BF STS
* needs to be 0.
*/
/* SU Beamformer capable */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
IEEE80211_VHTCAP_SU_BEAMFORMER_CAPABLE);
if (opmode == 1) {
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
IEEE80211_VHTCAP_SU_BEAMFORMER_CAPABLE);
}
val = MIN(val1, val2);
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val,
IEEE80211_VHTCAP_SU_BEAMFORMER_CAPABLE);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/* SU Beamformee capable */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
IEEE80211_VHTCAP_SU_BEAMFORMEE_CAPABLE);
if (opmode == 1) {
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
IEEE80211_VHTCAP_SU_BEAMFORMEE_CAPABLE);
}
val = MIN(val1, val2);
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val,
IEEE80211_VHTCAP_SU_BEAMFORMEE_CAPABLE);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/* Beamformee STS capability - only if SU beamformee capable */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
IEEE80211_VHTCAP_BEAMFORMEE_STS_MASK);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
if (opmode == 1) {
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
IEEE80211_VHTCAP_BEAMFORMEE_STS_MASK);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
}
val = MIN(val1, val2);
if ((new_vhtcap & IEEE80211_VHTCAP_SU_BEAMFORMEE_CAPABLE) == 0)
val = 0;
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val,
IEEE80211_VHTCAP_BEAMFORMEE_STS_MASK);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/* Sounding dimensions - only if SU beamformer capable */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
IEEE80211_VHTCAP_SOUNDING_DIMENSIONS_MASK);
if (opmode == 1)
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
IEEE80211_VHTCAP_SOUNDING_DIMENSIONS_MASK);
val = MIN(val1, val2);
if ((new_vhtcap & IEEE80211_VHTCAP_SU_BEAMFORMER_CAPABLE) == 0)
val = 0;
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val,
IEEE80211_VHTCAP_SOUNDING_DIMENSIONS_MASK);
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
/*
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
* MU Beamformer capable - only if SU BFF capable, MU BFF capable
* and STA (not AP)
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
*/
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
IEEE80211_VHTCAP_MU_BEAMFORMER_CAPABLE);
if (opmode == 1)
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
IEEE80211_VHTCAP_MU_BEAMFORMER_CAPABLE);
val = MIN(val1, val2);
if ((new_vhtcap & IEEE80211_VHTCAP_SU_BEAMFORMER_CAPABLE) == 0)
val = 0;
if (opmode != 1) /* Only enable for STA mode */
val = 0;
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val,
IEEE80211_VHTCAP_SU_BEAMFORMER_CAPABLE);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/*
* MU Beamformee capable - only if SU BFE capable, MU BFE capable
* and AP (not STA)
*/
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
IEEE80211_VHTCAP_MU_BEAMFORMEE_CAPABLE);
if (opmode == 1)
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
IEEE80211_VHTCAP_MU_BEAMFORMEE_CAPABLE);
val = MIN(val1, val2);
if ((new_vhtcap & IEEE80211_VHTCAP_SU_BEAMFORMEE_CAPABLE) == 0)
val = 0;
if (opmode != 0) /* Only enable for AP mode */
val = 0;
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val,
IEEE80211_VHTCAP_SU_BEAMFORMEE_CAPABLE);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/* VHT TXOP PS */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
IEEE80211_VHTCAP_VHT_TXOP_PS);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
if (opmode == 1)
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
IEEE80211_VHTCAP_VHT_TXOP_PS);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
val = MIN(val1, val2);
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val, IEEE80211_VHTCAP_VHT_TXOP_PS);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/* HTC_VHT */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
IEEE80211_VHTCAP_HTC_VHT);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
if (opmode == 1)
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
IEEE80211_VHTCAP_HTC_VHT);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
val = MIN(val1, val2);
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val, IEEE80211_VHTCAP_HTC_VHT);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/* A-MPDU length max */
/* XXX TODO: we need a userland config knob for this */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
IEEE80211_VHTCAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK);
if (opmode == 1)
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
IEEE80211_VHTCAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK);
val = MIN(val1, val2);
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val,
IEEE80211_VHTCAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/*
* Link adaptation is only valid if HTC-VHT capable is 1.
* Otherwise, always set it to 0.
*/
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
IEEE80211_VHTCAP_VHT_LINK_ADAPTATION_VHT_MASK);
if (opmode == 1)
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
IEEE80211_VHTCAP_VHT_LINK_ADAPTATION_VHT_MASK);
val = MIN(val1, val2);
if ((new_vhtcap & IEEE80211_VHTCAP_HTC_VHT) == 0)
val = 0;
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val,
IEEE80211_VHTCAP_VHT_LINK_ADAPTATION_VHT_MASK);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/*
* The following two options are 0 if the pattern may change, 1 if it
* does not change. So, downgrade to the higher value.
*/
/* RX antenna pattern */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
IEEE80211_VHTCAP_RX_ANTENNA_PATTERN);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
if (opmode == 1)
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
IEEE80211_VHTCAP_RX_ANTENNA_PATTERN);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
val = MAX(val1, val2);
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val,
IEEE80211_VHTCAP_RX_ANTENNA_PATTERN);
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/* TX antenna pattern */
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = val1 = _IEEE80211_MASKSHIFT(vap->iv_vhtcaps,
IEEE80211_VHTCAP_TX_ANTENNA_PATTERN);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
if (opmode == 1)
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
val2 = _IEEE80211_MASKSHIFT(ni->ni_vhtcap,
IEEE80211_VHTCAP_TX_ANTENNA_PATTERN);
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
val = MAX(val1, val2);
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
2020-09-24 10:57:39 +00:00
new_vhtcap |= _IEEE80211_SHIFTMASK(val,
IEEE80211_VHTCAP_TX_ANTENNA_PATTERN);
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
/*
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
* MCS set - again, we announce what we want to use
* based on configuration, device capabilities and
* already-learnt vhtcap/vhtinfo IE information.
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
*/
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/* MCS set - start with whatever the device supports */
vhtcap->supp_mcs.rx_mcs_map = vap->iv_vht_mcsinfo.rx_mcs_map;
vhtcap->supp_mcs.rx_highest = 0;
vhtcap->supp_mcs.tx_mcs_map = vap->iv_vht_mcsinfo.tx_mcs_map;
vhtcap->supp_mcs.tx_highest = 0;
vhtcap->vht_cap_info = new_vhtcap;
/*
* Now, if we're a STA, mask off whatever the AP doesn't support.
* Ie, we continue to state we can receive whatever we can do,
* but we only announce that we will transmit rates that meet
* the AP requirement.
*
* Note: 0 - MCS0..7; 1 - MCS0..8; 2 - MCS0..9; 3 = not supported.
* We can't just use MIN() because '3' means "no", so special case it.
*/
if (opmode) {
for (i = 0; i < 8; i++) {
val1 = (vhtcap->supp_mcs.tx_mcs_map >> (i*2)) & 0x3;
val2 = (ni->ni_vht_mcsinfo.tx_mcs_map >> (i*2)) & 0x3;
val = MIN(val1, val2);
if (val1 == 3 || val2 == 3)
val = 3;
vhtcap->supp_mcs.tx_mcs_map &= ~(0x3 << (i*2));
vhtcap->supp_mcs.tx_mcs_map |= (val << (i*2));
}
}
}
/*
* Add a VHTCAP field.
*
* If in station mode, we announce what we would like our
* desired configuration to be.
*
* Else, we announce our capabilities based on our current
* configuration.
*/
uint8_t *
ieee80211_add_vhtcap(uint8_t *frm, struct ieee80211_node *ni)
{
struct ieee80211_ie_vhtcap vhtcap;
int opmode;
opmode = 0;
if (ni->ni_vap->iv_opmode == IEEE80211_M_STA)
opmode = 1;
ieee80211_vht_get_vhtcap_ie(ni, &vhtcap, opmode);
memset(frm, '\0', sizeof(struct ieee80211_ie_vhtcap));
frm[0] = IEEE80211_ELEMID_VHT_CAP;
frm[1] = sizeof(struct ieee80211_ie_vhtcap) - 2;
frm += 2;
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
/* 32-bit VHT capability */
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
ADDWORD(frm, vhtcap.vht_cap_info);
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
/* suppmcs */
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
ADDSHORT(frm, vhtcap.supp_mcs.rx_mcs_map);
ADDSHORT(frm, vhtcap.supp_mcs.rx_highest);
ADDSHORT(frm, vhtcap.supp_mcs.tx_mcs_map);
ADDSHORT(frm, vhtcap.supp_mcs.tx_highest);
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
return (frm);
}
static uint8_t
ieee80211_vht_get_chwidth_ie(struct ieee80211_channel *c)
{
/*
* XXX TODO: look at the node configuration as
* well?
*/
net80211: remove vertical whitespace No functional changes. MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
2020-08-17 16:28:59 +00:00
if (IEEE80211_IS_CHAN_VHT80P80(c))
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
return IEEE80211_VHT_CHANWIDTH_80P80MHZ;
net80211: return 80P80 before 160 In ieee80211_vht_get_chwidth_ie() we need to return 80P80 (3) before VHT160 (2) as otherwise we'll never use 80P80. Fix the order. MFC after: 2 weeks X-MFC with: r364303 (which missed this) Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
2020-08-17 16:51:21 +00:00
if (IEEE80211_IS_CHAN_VHT160(c))
return IEEE80211_VHT_CHANWIDTH_160MHZ;
net80211: remove vertical whitespace No functional changes. MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
2020-08-17 16:28:59 +00:00
if (IEEE80211_IS_CHAN_VHT80(c))
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
return IEEE80211_VHT_CHANWIDTH_80MHZ;
net80211: remove vertical whitespace No functional changes. MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
2020-08-17 16:28:59 +00:00
if (IEEE80211_IS_CHAN_VHT40(c))
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
return IEEE80211_VHT_CHANWIDTH_USE_HT;
net80211: remove vertical whitespace No functional changes. MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
2020-08-17 16:28:59 +00:00
if (IEEE80211_IS_CHAN_VHT20(c))
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
return IEEE80211_VHT_CHANWIDTH_USE_HT;
/* We shouldn't get here */
printf("%s: called on a non-VHT channel (freq=%d, flags=0x%08x\n",
net80211: remove vertical whitespace No functional changes. MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
2020-08-17 16:28:59 +00:00
__func__, (int) c->ic_freq, c->ic_flags);
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
return IEEE80211_VHT_CHANWIDTH_USE_HT;
}
/*
* Note: this just uses the current channel information;
* it doesn't use the node info after parsing.
[net80211] use the correct freq2 field when populating VHT operation element. Whilst here, leave a TODO comment so I revisit this routine in the context of hostap operation probe requests for IBSS/mesh.
2017-01-08 10:07:54 +00:00
*
* XXX TODO: need to make the basic MCS set configurable.
* XXX TODO: read 802.11-2013 to determine what to set
* chwidth to when scanning. I have a feeling
* it isn't involved in scanning and we shouldn't
* be sending it; and I don't yet know what to set
* it to for IBSS or hostap where the peer may be
* a completely different channel width to us.
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
*/
uint8_t *
ieee80211_add_vhtinfo(uint8_t *frm, struct ieee80211_node *ni)
{
memset(frm, '\0', sizeof(struct ieee80211_ie_vht_operation));
frm[0] = IEEE80211_ELEMID_VHT_OPMODE;
frm[1] = sizeof(struct ieee80211_ie_vht_operation) - 2;
frm += 2;
/* 8-bit chanwidth */
*frm++ = ieee80211_vht_get_chwidth_ie(ni->ni_chan);
/* 8-bit freq1 */
*frm++ = ni->ni_chan->ic_vht_ch_freq1;
/* 8-bit freq2 */
[net80211] use the correct freq2 field when populating VHT operation element. Whilst here, leave a TODO comment so I revisit this routine in the context of hostap operation probe requests for IBSS/mesh.
2017-01-08 10:07:54 +00:00
*frm++ = ni->ni_chan->ic_vht_ch_freq2;
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
/* 16-bit basic MCS set - just MCS0..7 for NSS=1 for now */
ADDSHORT(frm, 0xfffc);
return (frm);
}
void
ieee80211_vht_update_cap(struct ieee80211_node *ni, const uint8_t *vhtcap_ie,
const uint8_t *vhtop_ie)
{
ieee80211_parse_vhtcap(ni, vhtcap_ie);
ieee80211_parse_vhtopmode(ni, vhtop_ie);
}
static struct ieee80211_channel *
findvhtchan(struct ieee80211com *ic, struct ieee80211_channel *c, int vhtflags)
{
return (ieee80211_find_channel(ic, c->ic_freq,
(c->ic_flags & ~IEEE80211_CHAN_VHT) | vhtflags));
}
/*
* Handle channel promotion to VHT, similar to ieee80211_ht_adjust_channel().
*/
struct ieee80211_channel *
ieee80211_vht_adjust_channel(struct ieee80211com *ic,
struct ieee80211_channel *chan, int flags)
{
struct ieee80211_channel *c;
/* First case - handle channel demotion - if VHT isn't set */
if ((flags & IEEE80211_FVHT_VHT) == 0) {
#if 0
printf("%s: demoting channel %d/0x%08x\n", __func__,
chan->ic_ieee, chan->ic_flags);
#endif
c = ieee80211_find_channel(ic, chan->ic_freq,
chan->ic_flags & ~IEEE80211_CHAN_VHT);
if (c == NULL)
c = chan;
#if 0
printf("%s: .. to %d/0x%08x\n", __func__,
c->ic_ieee, c->ic_flags);
#endif
return (c);
}
/*
* We can upgrade to VHT - attempt to do so
*
* Note: we don't clear the HT flags, these are the hints
* for HT40U/HT40D when selecting VHT40 or larger channels.
*/
/* Start with VHT80 */
c = NULL;
if ((c == NULL) && (flags & IEEE80211_FVHT_USEVHT160))
c = findvhtchan(ic, chan, IEEE80211_CHAN_VHT80);
if ((c == NULL) && (flags & IEEE80211_FVHT_USEVHT80P80))
80211: consistently spell 80P80 The standard uses 80+80 and 80p80 but nowhere 80_80. Switch the latter to 80P80 for all the macros and comments refering to #defined flags which I could find. The only place we leave as 80p80 is the ifconfig command line arguments as we spell them all in lower case. Ideally we would use 80+80 for any interactions with the user and 80P80 for anything internal but let us not confuse parsers and hence avoid the '+' in either case. Reviewed by: adrian, gnn MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26001
2020-08-17 12:52:57 +00:00
c = findvhtchan(ic, chan, IEEE80211_CHAN_VHT80P80);
[net80211] Add initial VHT support routines. This is a skeleton set based on ieee80211_ht.c. It implements some IE parsing, some basic unfinished negotiation, and channel promotion/demotion. However, by itself it's not enough to do VHT - notably, the actual channel promotion for STA mode at least is done in ieee80211_ht.c as part of htinfo_update_chw(). I was .. quite amused when I found that out. I'm checking this in so others can see progress rather than one huge commit when VHT is "done" (which will likely be quite a while.)
2017-01-08 04:25:41 +00:00
if ((c == NULL) && (flags & IEEE80211_FVHT_USEVHT80))
c = findvhtchan(ic, chan, IEEE80211_CHAN_VHT80);
if ((c == NULL) && (flags & IEEE80211_FVHT_USEVHT40))
c = findvhtchan(ic, chan, IEEE80211_CHAN_VHT40U);
if ((c == NULL) && (flags & IEEE80211_FVHT_USEVHT40))
c = findvhtchan(ic, chan, IEEE80211_CHAN_VHT40D);
/*
* If we get here, VHT20 is always possible because we checked
* for IEEE80211_FVHT_VHT above.
*/
if (c == NULL)
c = findvhtchan(ic, chan, IEEE80211_CHAN_VHT20);
if (c != NULL)
chan = c;
#if 0
printf("%s: selected %d/0x%08x\n", __func__, c->ic_ieee, c->ic_flags);
#endif
return (chan);
}
[net80211] create a helper function to calculate the station facing VHT capabilities. This is needed for two reasons: * Drivers will need to know what the negotiated set of VHT capabilities and rates are in order to configure (and reconfigure for opmode/chanwidth changes) how to speak to a given peer; and * Because some vendors are "special", we should be careful in what we announce to them during peer association. This isn't the complete solution, as I still need to make sure that when sending out probe requests before we know what we want, we don't limit the capabilities being announced. This is important for IBSS/mesh work later on as probe request/response exchanges are the first hint at what a peer supports. I'll look at adding that to the API soon.
2017-01-10 05:30:15 +00:00
/*
* Calculate the VHT operation IE for a given node.
*
* This includes calculating the suitable channel width/parameters
* and basic MCS set.
*
* TODO: ensure I read 9.7.11 Rate Selection for VHT STAs.
* TODO: ensure I read 10.39.7 - BSS Basic VHT-MCS and NSS set operation.
*/
void
ieee80211_vht_get_vhtinfo_ie(struct ieee80211_node *ni,
struct ieee80211_ie_vht_operation *vhtop, int opmode)
{
printf("%s: called; TODO!\n", __func__);
}
Reference in New Issue Copy Permalink