| Message ID | 20201019063921.4335-1-shay.bar@celeno.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] mac80211: 160MHz support per IEEE802.11ax standard | expand |
On Mon, 2020-10-19 at 16:26 +0300, Shay Bar wrote: > According to the new IEEE802.11ax standard center frequency of the 160MHz > should be published in segment2 field of HT operation IE when using EXT NSS > (when supporting smaller number of NSS in VHT in 160MHz BW). > This patch adds the required support to mac80211, cfg80211 to parse it properly > according to the new style as appears in the new standard. > > According to the new style, the AP should publish that its bw is 80MHz and not > 160MHz. > A STA should conclude that an AP is working in 160MHz if it publishes > the center frequency of the 160MHz bandwidth in seg1 field of VHT operation IE > or seg2 field of HT operation IE. Is this referring to D6.2 Table 26-9 "Setting of the VHT Channel Width and VHT NSS at an HE STA transmitting the OM Control subfield"? If so, then what does the part of "at an HE STA transmitting the OM Control subfield" do? Do we need to check it? That doesn't sound like we should apply any changed logic to normal VHT STAs? johannes
On 06/11/2020 12:35, Johannes Berg wrote: > External Email > > > On Mon, 2020-10-19 at 16:26 +0300, Shay Bar wrote: >> According to the new IEEE802.11ax standard center frequency of the 160MHz >> should be published in segment2 field of HT operation IE when using EXT NSS >> (when supporting smaller number of NSS in VHT in 160MHz BW). >> This patch adds the required support to mac80211, cfg80211 to parse it properly >> according to the new style as appears in the new standard. >> >> According to the new style, the AP should publish that its bw is 80MHz and not >> 160MHz. >> A STA should conclude that an AP is working in 160MHz if it publishes >> the center frequency of the 160MHz bandwidth in seg1 field of VHT operation IE >> or seg2 field of HT operation IE. > Is this referring to D6.2 Table 26-9 "Setting of the VHT Channel Width > and VHT NSS at an HE STA transmitting the OM Control subfield"? No, it is referring to IEEE P802.11-REVmd™/D5.0, September 2020 Table 9-81- "Setting of the Channel Width subfield and 160/80+80 BW subfield at a VHT STA transmitting the Operating Mode field" (where it doesn't refer to OM) The nl80211.c change is also described in the first 3 rows of Table 9-274 "VHT Operation Information subfields".
On Sun, 2020-11-08 at 10:11 +0200, Shay Bar wrote: > On 06/11/2020 12:35, Johannes Berg wrote: > > External Email > > > > > > On Mon, 2020-10-19 at 16:26 +0300, Shay Bar wrote: > > > According to the new IEEE802.11ax standard center frequency of the 160MHz > > > should be published in segment2 field of HT operation IE when using EXT NSS > > > (when supporting smaller number of NSS in VHT in 160MHz BW). > No, it is referring to IEEE P802.11-REVmd™/D5.0, September 2020 Table > 9-81- "Setting of the Channel Width subfield and 160/80+80 BW subfield > at a VHT STA transmitting the Operating Mode field" (where it doesn't > refer to OM) But you said above "according to the new IEEE802.11ax"? I guess that confuses me. Or did D5.0 incorporate 802.11ax? But that seems unlikely, 802.11ax D8.0 was still in circulation until yesterday, i.e. after you sent the patch? > The nl80211.c change is also described in the first 3 rows of Table > 9-274 "VHT Operation Information subfields". OK, thanks, I'll have to check that out. johannes
On 13/11/2020 11:04, Johannes Berg wrote: > On Sun, 2020-11-08 at 10:11 +0200, Shay Bar wrote: >> On 06/11/2020 12:35, Johannes Berg wrote: >>> On Mon, 2020-10-19 at 16:26 +0300, Shay Bar wrote: >>>> According to the new IEEE802.11ax standard center frequency of the 160MHz >>>> should be published in segment2 field of HT operation IE when using EXT NSS >>>> (when supporting smaller number of NSS in VHT in 160MHz BW). >> No, it is referring to IEEE P802.11-REVmd™/D5.0, September 2020 Table >> 9-81- "Setting of the Channel Width subfield and 160/80+80 BW subfield >> at a VHT STA transmitting the Operating Mode field" (where it doesn't >> refer to OM) > But you said above "according to the new IEEE802.11ax"? I guess that > confuses me. > > Or did D5.0 incorporate 802.11ax? But that seems unlikely, 802.11ax D8.0 > was still in circulation until yesterday, i.e. after you sent the patch? "Setting of the VHT Channel Width and VHT NSS at an HE STA transmitting the OM Control subfield" table in the 802.11ax D* files is identical to the "Setting of the Channel Width subfield and 160/80+80 BW subfield at a VHT STA transmitting the Operating Mode field" table in the Draft P802.11REVmd_D* files. This is the source of confusion, sorry :) >> The nl80211.c change is also described in the first 3 rows of Table >> 9-274 "VHT Operation Information subfields". > OK, thanks, I'll have to check that out. Thanks.
On Sun, 2020-11-15 at 10:57 +0200, Shay Bar wrote: > > This is the source of confusion, sorry :) Actually, the confusion is that you said "160 MHz support" ... and you really only meant "160 MHz in extended channel switch" :-) I'll respond to the patch also again. johannes
On Mon, 2020-10-19 at 09:39 +0300, Shay Bar wrote: > According to the new IEEE802.11ax standard center frequency of the 160MHz > should be published in segment2 field of HT operation IE when using EXT NSS > (when supporting smaller number of NSS in VHT in 160MHz BW). > This patch adds the required support to mac80211, cfg80211 to parse it properly > according to the new style as appears in the new standard. > > According to the new style, the AP should publish that its bw is 80MHz and not > 160MHz. > A STA should conclude that an AP is working in 160MHz if it publishes > the center frequency of the 160MHz bandwidth in seg1 field of VHT operation IE > or seg2 field of HT operation IE. > > A little about the old/new style of the channel/bandwidth publish in beacons: > > - In the old style bandwidth of 160MHz and center frequency segment 0 are > published in vht/he operation information element, while the center_freq_seg0 > indicates the center frequency of 160MHz. > - According to the new style, bandwidth of 80MHz is published and also the > following: > * If the supported number of VHT NSS in 160MHz is at least max VHT NSS > support, then center_freq_seg0 indicates the center frequency of 80MHz and > center_freq_seg1 indicates the center frequency of 160MHz. > * If the supported number of VHT NSS in 160MHz is less than max VHT NSS > support, then center_freq_seg0 indicates the center frequency of 80MHz and > center_freq_seg1 is 0. The center frequency of 160MHz is published in HT > operation information element instead. All of that is nice, but basically we already covered it ... Seems like perhaps you rebased this patch and dropped the bits that we already had upstream now/later, but we don't have the CSA pieces, and then you didn't update the commit message? :-) > +/** > + * enum ieee80211_center_freq_seg1_location - the location of center > + * frequency segment1 > + * @IEEE80211_CENTER_FREQ_SEG1_NONE: center freq seg1 is located no where > + * @IEEE80211_CENTER_FREQ_SEG1_VHT_OPER: center freq seg1 is located in VHT > + * operation IE > + * @IEEE80211_CENTER_FREQ_SEG1_HT_OPER: center freq seg1 is located in HT > + * operation IE please use tabs at the beginning of continued documentation lines > +static enum ieee80211_vht_chanwidth > +ieee80211_vht_get_actual_chwidth(u8 vht_oper_bw, > + u32 seg0, > + u32 seg1) the parameters all fit on one line > +{ > + enum ieee80211_vht_chanwidth ret = IEEE80211_VHT_CHANWIDTH_USE_HT; > + > + if (vht_oper_bw != IEEE80211_VHT_CHANWIDTH_80MHZ) > + return vht_oper_bw; > + > + if (!seg1) { > + return IEEE80211_VHT_CHANWIDTH_80MHZ; > + } else { > + int diff; > + > + diff = abs((int) seg0 - (int) seg1); > + > + if (diff == 8) > + return IEEE80211_VHT_CHANWIDTH_160MHZ; > + > + if (diff > 16) > + return IEEE80211_VHT_CHANWIDTH_80P80MHZ; > + } > + > + return ret; You can remove the 'ret' variable, and having "else" after "return" is also pointless. Easier to just do a chain of ifs, and return IEEE80211_VHT_CHANWIDTH_USE_HT at the end. > +} > + > +static enum ieee80211_center_freq_seg1 > +ieee80211_get_center_freq_seg1_location(struct ieee80211_sub_if_data *sdata, > + u32 vht_cap_info, > + u8 actual_chanwidth) > +{ > + u8 ext_nss_bw = (vht_cap_info & > + IEEE80211_VHT_CAP_EXT_NSS_BW_MASK) >> > + IEEE80211_VHT_CAP_EXT_NSS_BW_SHIFT; > + u8 supp_chwidth = (vht_cap_info & > + IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK) >> > + IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_SHIFT; please use the include/bitfield.h helpers, specifically u32_get_bits(). > + enum ieee80211_center_freq_seg1 res = > + IEEE80211_CENTER_FREQ_SEG1_NONE; > + > + /* The bandwidth is less than 80+80/160MHz */ > + if (actual_chanwidth < IEEE80211_VHT_CHANWIDTH_160MHZ) > + return IEEE80211_CENTER_FREQ_SEG1_NONE; > + > + switch (supp_chwidth) { > + case 0: > + if ((ext_nss_bw > 1) || > + ((ext_nss_bw == 1) && > + (actual_chanwidth == IEEE80211_VHT_CHANWIDTH_160MHZ))) > + /* CCFS2 */ > + res = IEEE80211_CENTER_FREQ_SEG1_HT_OPER; You can also just return here and get rid of the 'res' variable. > + break; > + case 1: > + if ((ext_nss_bw > 2) || > + (actual_chanwidth == IEEE80211_VHT_CHANWIDTH_160MHZ)) > + /* CCFS1 */ > + res = IEEE80211_CENTER_FREQ_SEG1_VHT_OPER; > + else if (ext_nss_bw > 0) > + /* CCFS2 */ > + res = IEEE80211_CENTER_FREQ_SEG1_HT_OPER; > + break; > + case 2: > + res = IEEE80211_CENTER_FREQ_SEG1_VHT_OPER; > + if ((ext_nss_bw > 0) && (ext_nss_bw < 3)) > + sdata_info(sdata, > + "Invalid ext_nss_bw %u\n", ext_nss_bw); > + break; > + default: > + break; > + } > + > + return res; > +} Maybe that could reuse some code from ieee80211_chandef_vht_oper()? Seems very similar? Or refactor some of it? > +++ b/net/wireless/nl80211.c > @@ -2976,6 +2976,21 @@ int nl80211_parse_chandef(struct cfg80211_registered_device *rdev, > chandef->edmg.channels = 0; > } > > + if (chandef->width == NL80211_CHAN_WIDTH_80) { > + if (chandef->center_freq2) { > + int diff = abs(chandef->center_freq1 - > + chandef->center_freq2); > + > + if (diff == 40) > + chandef->width = NL80211_CHAN_WIDTH_160; > + else if (diff > 80) > + chandef->width = NL80211_CHAN_WIDTH_80P80; > + > + chandef->center_freq1 = chandef->center_freq2; > + chandef->center_freq2 = 0; > + } > + } This doesn't seem appropriate at all, why would we possibly want to do such a backward compat workaround in the *nl80211* API?? _If_ there's a good reason for it, it needs to come in a separate patch, but I really don't see it. johannes
Hi Johannes, I published a new (short) patch for 160Mhz with extended NSS BW in CSA Message-Id: <20201221141441.17613-1-shay.bar@celeno.com> I will discard the previous patches. Thanks, Shay Bar. On 11/12/2020 14:22, Johannes Berg wrote: > On Sun, 2020-11-15 at 10:57 +0200, Shay Bar wrote: >> This is the source of confusion, sorry :) > Actually, the confusion is that you said "160 MHz support" ... and you > really only meant "160 MHz in extended channel switch" :-) > > I'll respond to the patch also again. >
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h index 770408b2fdaf..768285b143a3 100644 --- a/include/linux/ieee80211.h +++ b/include/linux/ieee80211.h @@ -1748,6 +1748,21 @@ enum ieee80211_vht_chanwidth { IEEE80211_VHT_CHANWIDTH_80P80MHZ = 3, }; +/** + * enum ieee80211_center_freq_seg1_location - the location of center + * frequency segment1 + * @IEEE80211_CENTER_FREQ_SEG1_NONE: center freq seg1 is located no where + * @IEEE80211_CENTER_FREQ_SEG1_VHT_OPER: center freq seg1 is located in VHT + * operation IE + * @IEEE80211_CENTER_FREQ_SEG1_HT_OPER: center freq seg1 is located in HT + * operation IE + */ +enum ieee80211_center_freq_seg1 { + IEEE80211_CENTER_FREQ_SEG1_NONE = 0, + IEEE80211_CENTER_FREQ_SEG1_VHT_OPER = 1, + IEEE80211_CENTER_FREQ_SEG1_HT_OPER = 2, +}; + /** * struct ieee80211_vht_operation - VHT operation IE * diff --git a/net/mac80211/spectmgmt.c b/net/mac80211/spectmgmt.c index ae1cb2c68722..d03763c8b648 100644 --- a/net/mac80211/spectmgmt.c +++ b/net/mac80211/spectmgmt.c @@ -19,6 +19,81 @@ #include "sta_info.h" #include "wme.h" +static enum ieee80211_vht_chanwidth +ieee80211_vht_get_actual_chwidth(u8 vht_oper_bw, + u32 seg0, + u32 seg1) +{ + enum ieee80211_vht_chanwidth ret = IEEE80211_VHT_CHANWIDTH_USE_HT; + + if (vht_oper_bw != IEEE80211_VHT_CHANWIDTH_80MHZ) + return vht_oper_bw; + + if (!seg1) { + return IEEE80211_VHT_CHANWIDTH_80MHZ; + } else { + int diff; + + diff = abs((int) seg0 - (int) seg1); + + if (diff == 8) + return IEEE80211_VHT_CHANWIDTH_160MHZ; + + if (diff > 16) + return IEEE80211_VHT_CHANWIDTH_80P80MHZ; + } + + return ret; +} + +static enum ieee80211_center_freq_seg1 +ieee80211_get_center_freq_seg1_location(struct ieee80211_sub_if_data *sdata, + u32 vht_cap_info, + u8 actual_chanwidth) +{ + u8 ext_nss_bw = (vht_cap_info & + IEEE80211_VHT_CAP_EXT_NSS_BW_MASK) >> + IEEE80211_VHT_CAP_EXT_NSS_BW_SHIFT; + u8 supp_chwidth = (vht_cap_info & + IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK) >> + IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_SHIFT; + enum ieee80211_center_freq_seg1 res = + IEEE80211_CENTER_FREQ_SEG1_NONE; + + /* The bandwidth is less than 80+80/160MHz */ + if (actual_chanwidth < IEEE80211_VHT_CHANWIDTH_160MHZ) + return IEEE80211_CENTER_FREQ_SEG1_NONE; + + switch (supp_chwidth) { + case 0: + if ((ext_nss_bw > 1) || + ((ext_nss_bw == 1) && + (actual_chanwidth == IEEE80211_VHT_CHANWIDTH_160MHZ))) + /* CCFS2 */ + res = IEEE80211_CENTER_FREQ_SEG1_HT_OPER; + break; + case 1: + if ((ext_nss_bw > 2) || + (actual_chanwidth == IEEE80211_VHT_CHANWIDTH_160MHZ)) + /* CCFS1 */ + res = IEEE80211_CENTER_FREQ_SEG1_VHT_OPER; + else if (ext_nss_bw > 0) + /* CCFS2 */ + res = IEEE80211_CENTER_FREQ_SEG1_HT_OPER; + break; + case 2: + res = IEEE80211_CENTER_FREQ_SEG1_VHT_OPER; + if ((ext_nss_bw > 0) && (ext_nss_bw < 3)) + sdata_info(sdata, + "Invalid ext_nss_bw %u\n", ext_nss_bw); + break; + default: + break; + } + + return res; +} + int ieee80211_parse_ch_switch_ie(struct ieee80211_sub_if_data *sdata, struct ieee802_11_elems *elems, enum nl80211_band current_band, @@ -133,17 +208,30 @@ int ieee80211_parse_ch_switch_ie(struct ieee80211_sub_if_data *sdata, } if (wide_bw_chansw_ie) { + u8 new_channel_width = wide_bw_chansw_ie->new_channel_width; + u8 new_seg0 = wide_bw_chansw_ie->new_center_freq_seg0; + u8 new_seg1 = wide_bw_chansw_ie->new_center_freq_seg1; + enum ieee80211_vht_chanwidth act_chanwidth = + ieee80211_vht_get_actual_chwidth( + new_channel_width, new_seg0, new_seg1); + enum ieee80211_center_freq_seg1 seg1_location = + ieee80211_get_center_freq_seg1_location(sdata, + vht_cap_info, + act_chanwidth); struct ieee80211_vht_operation vht_oper = { - .chan_width = - wide_bw_chansw_ie->new_channel_width, - .center_freq_seg0_idx = - wide_bw_chansw_ie->new_center_freq_seg0, - .center_freq_seg1_idx = - wide_bw_chansw_ie->new_center_freq_seg1, + .chan_width = new_channel_width, + .center_freq_seg0_idx = new_seg0, /* .basic_mcs_set doesn't matter */ }; struct ieee80211_ht_operation ht_oper = {}; + if (seg1_location == IEEE80211_CENTER_FREQ_SEG1_VHT_OPER) + vht_oper.center_freq_seg1_idx = new_seg1; + else if (seg1_location == IEEE80211_CENTER_FREQ_SEG1_HT_OPER) + ht_oper.operation_mode = + (le16_to_cpu(new_seg1) << + IEEE80211_HT_OP_MODE_CCFS2_SHIFT); + /* default, for the case of IEEE80211_VHT_CHANWIDTH_USE_HT, * to the previously parsed chandef */ diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index 554796a6c6fe..690a5a382d94 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -2976,6 +2976,21 @@ int nl80211_parse_chandef(struct cfg80211_registered_device *rdev, chandef->edmg.channels = 0; } + if (chandef->width == NL80211_CHAN_WIDTH_80) { + if (chandef->center_freq2) { + int diff = abs(chandef->center_freq1 - + chandef->center_freq2); + + if (diff == 40) + chandef->width = NL80211_CHAN_WIDTH_160; + else if (diff > 80) + chandef->width = NL80211_CHAN_WIDTH_80P80; + + chandef->center_freq1 = chandef->center_freq2; + chandef->center_freq2 = 0; + } + } + if (!cfg80211_chandef_valid(chandef)) { NL_SET_ERR_MSG(extack, "invalid channel definition"); return -EINVAL;
According to the new IEEE802.11ax standard center frequency of the 160MHz should be published in segment2 field of HT operation IE when using EXT NSS (when supporting smaller number of NSS in VHT in 160MHz BW). This patch adds the required support to mac80211, cfg80211 to parse it properly according to the new style as appears in the new standard. According to the new style, the AP should publish that its bw is 80MHz and not 160MHz. A STA should conclude that an AP is working in 160MHz if it publishes the center frequency of the 160MHz bandwidth in seg1 field of VHT operation IE or seg2 field of HT operation IE. A little about the old/new style of the channel/bandwidth publish in beacons: - In the old style bandwidth of 160MHz and center frequency segment 0 are published in vht/he operation information element, while the center_freq_seg0 indicates the center frequency of 160MHz. - According to the new style, bandwidth of 80MHz is published and also the following: * If the supported number of VHT NSS in 160MHz is at least max VHT NSS support, then center_freq_seg0 indicates the center frequency of 80MHz and center_freq_seg1 indicates the center frequency of 160MHz. * If the supported number of VHT NSS in 160MHz is less than max VHT NSS support, then center_freq_seg0 indicates the center frequency of 80MHz and center_freq_seg1 is 0. The center frequency of 160MHz is published in HT operation information element instead. Signed-off-by: Aviad Brikman <aviad.brikman@celeno.com> Signed-off-by: Shay Bar <shay.bar@celeno.com> --- include/linux/ieee80211.h | 15 ++++++ net/mac80211/spectmgmt.c | 100 +++++++++++++++++++++++++++++++++++--- net/wireless/nl80211.c | 15 ++++++ 3 files changed, 124 insertions(+), 6 deletions(-)