| Message ID | 952C5D5D0470AE4FB7D8A75C6ADC71CA0FCC5E3B@mbx022-e1-nj-10.exch022.domain.local (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
> + IEEE80211_CHAN_NO_VHT80PLUS = 1<<6, > + IEEE80211_CHAN_NO_VHT80MINUS = 1<<7, > + IEEE80211_CHAN_NO_VHT160PLUS = 1<<8, > + IEEE80211_CHAN_NO_VHT160MINUS = 1<<9, How are we going to handle 80+80? Also, I believe there are many more possibilities, since we count from the control channel -- ie. for HT HT40+ means secondary channel is above the control channel. For VHT 80, you're going to have 4 possibilities: |-1-|-2-|-3-|-4-| the control channel can be any one of these four I believe? So you'd have configurations like VHT_CHAN_LAYOUT_0_3 VHT_CHAN_LAYOUT_1_2 VHT_CHAN_LAYOUT_2_1 VHT_CHAN_LAYOUT_3_0 indicating the number of channels below/above control (for control channel 1,2,3,4 respectively). Similarly, for VHT160 you'd have 8 possibilities: |-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-| (which one could again capture as VHT_CHAN_LAYOUT_0_7 etc.) > +static bool is_vht80_not_allowed(struct ieee80211_channel *chan) > +{ > + if (!chan) > + return true; > + if (chan->flags & IEEE80211_CHAN_DISABLED) > + return true; > + /* This would happen when regulatory rules disallow VHT80 completely */ > + if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & (IEEE80211_CHAN_NO_VHT80))) > + return true; Is that really right? Need to document what the return value of this function should be, I guess? > +static void reg_process_vht_flags_channel(struct wiphy *wiphy, > + unsigned int chan_idx) > +{ > + struct ieee80211_supported_band *sband; > + struct ieee80211_channel *channel; > + struct ieee80211_channel *channel_before = NULL, *channel_after = NULL; > + unsigned int i; > + > + assert_cfg80211_lock(); > + > + sband = wiphy->bands[IEEE80211_BAND_5GHZ]; > + BUG_ON(chan_idx >= sband->n_channels); > + channel = &sband->channels[chan_idx]; > + > + if (is_vht80_not_allowed(channel)) { > + channel->flags |= IEEE80211_CHAN_NO_VHT80; > + return; > + } > + > + /* > + * We need to ensure the extension channels exist to > + * be able to use VHT80- or VHT80+, this finds them (or not) > + */ > + for (i = 0; i < sband->n_channels; i++) { > + struct ieee80211_channel *c = &sband->channels[i]; > + if (c->center_freq == (channel->center_freq - 40)) > + channel_before = c; > + if (c->center_freq == (channel->center_freq + 40)) > + channel_after = c; > + } > + > + /* > + * Please note that this assumes target bandwidth is 40 MHz, > + * if that ever changes we also need to change the below logic > + * to include that as well. > + */ ??? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Mahesh Palivela <maheshp@posedge.com> writes: > 80MHz Regulatory changes for 11ac. > > Signed-off-by: Mahesh Palivela <maheshp@posedge.com> [...] > +static bool is_vht80_not_allowed(struct ieee80211_channel *chan) > +{ > + if (!chan) > + return true; > + if (chan->flags & IEEE80211_CHAN_DISABLED) > + return true; > + /* This would happen when regulatory rules disallow VHT80 completely */ > + if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & (IEEE80211_CHAN_NO_VHT80))) > + return true; > + return false; > +} I think it's better to change this to is_vht80_allowed(). The not_allowed might trick someone.
It would be really good if you could convince your email client to put > in front of each quoted line ... this is really confusing as is. > Also, I believe there are many more possibilities, since we count from > the control channel -- ie. for HT HT40+ means secondary channel is above > the control channel. For VHT 80, you're going to have 4 possibilities: > > |-1-|-2-|-3-|-4-| > > the control channel can be any one of these four I believe? So you'd > have configurations like > > VHT_CHAN_LAYOUT_0_3 > VHT_CHAN_LAYOUT_1_2 > VHT_CHAN_LAYOUT_2_1 > VHT_CHAN_LAYOUT_3_0 > > indicating the number of channels below/above control (for control > channel 1,2,3,4 respectively). Similarly, for VHT160 you'd have 8 > possibilities: > > |-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-| > > (which one could again capture as VHT_CHAN_LAYOUT_0_7 etc.) > > [MP] I see your point. But according to 11ac spec, AP will use primary > chan as specified in HT operation IE chan num. Secondary channel is > center freq specified in VHT Operation IE. So I am thinking secondary > channel is not relative offset to primary channel. Hope I am not > mistaken here. Ok so HT has primary channel and secondary, and VHT has secondary VHT which can again be above/below? That would make sense, but you wouldn't be covering it. > > + /* This would happen when regulatory rules disallow VHT80 completely */ > > + if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & (IEEE80211_CHAN_NO_VHT80))) > > + return true; > > Is that really right? Need to document what the return value of this > function should be, I guess? > > [MP] I guess, it's possible for a channel not allowed for 80Mhz operation. Yeah but should it really check *all* the bits rather than any one of them? > > + /* > > + * Please note that this assumes target bandwidth is 40 MHz, > > + * if that ever changes we also need to change the below logic > > + * to include that as well. > > + */ > > ??? > > [MP] Can you explain? This function doesn't make any sense? The comment about 40 MHz doesn't make any sense. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/24/2012 02:26 PM, Johannes Berg wrote: > It would be really good if you could convince your email client to put > > in front of each quoted line ... this is really confusing as is. > Sorry. Switched to thunderbird now. >> Also, I believe there are many more possibilities, since we count from >> the control channel -- ie. for HT HT40+ means secondary channel is above >> the control channel. For VHT 80, you're going to have 4 possibilities: >> >> |-1-|-2-|-3-|-4-| >> >> the control channel can be any one of these four I believe? So you'd >> have configurations like >> >> VHT_CHAN_LAYOUT_0_3 >> VHT_CHAN_LAYOUT_1_2 >> VHT_CHAN_LAYOUT_2_1 >> VHT_CHAN_LAYOUT_3_0 >> >> indicating the number of channels below/above control (for control >> channel 1,2,3,4 respectively). Similarly, for VHT160 you'd have 8 >> possibilities: >> >> |-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-| >> >> (which one could again capture as VHT_CHAN_LAYOUT_0_7 etc.) >> >> [MP] I see your point. But according to 11ac spec, AP will use primary >> chan as specified in HT operation IE chan num. Secondary channel is >> center freq specified in VHT Operation IE. So I am thinking secondary >> channel is not relative offset to primary channel. Hope I am not >> mistaken here. > > Ok so HT has primary channel and secondary, and VHT has secondary VHT > which can again be above/below? That would make sense, but you wouldn't > be covering it. > I am thinking no need of above/below convention as the center frequency value itself we know. >>> + /* This would happen when regulatory rules disallow VHT80 completely */ >>> + if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & (IEEE80211_CHAN_NO_VHT80))) >>> + return true; >> >> Is that really right? Need to document what the return value of this >> function should be, I guess? >> >> [MP] I guess, it's possible for a channel not allowed for 80Mhz operation. > > Yeah but should it really check *all* the bits rather than any one of > them? > You mean to say other bits like HT40MINUS, HT40PLUS or even DFS? >>> + /* >>> + * Please note that this assumes target bandwidth is 40 MHz, >>> + * if that ever changes we also need to change the below logic >>> + * to include that as well. >>> + */ >> >> ??? >> >> [MP] Can you explain? This function doesn't make any sense? > > The comment about 40 MHz doesn't make any sense. > Agree. I will change this. > johannes > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2012-07-24 at 16:18 +0530, Mahesh Palivela wrote: > >> indicating the number of channels below/above control (for control > >> channel 1,2,3,4 respectively). Similarly, for VHT160 you'd have 8 > >> possibilities: > >> > >> |-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-| > >> > >> (which one could again capture as VHT_CHAN_LAYOUT_0_7 etc.) > >> > >> [MP] I see your point. But according to 11ac spec, AP will use primary > >> chan as specified in HT operation IE chan num. Secondary channel is > >> center freq specified in VHT Operation IE. So I am thinking secondary > >> channel is not relative offset to primary channel. Hope I am not > >> mistaken here. > > > > Ok so HT has primary channel and secondary, and VHT has secondary VHT > > which can again be above/below? That would make sense, but you wouldn't > > be covering it. > > > > I am thinking no need of above/below convention as the center frequency > value itself we know. But we don't use the center frequency of the overall Ht40/80/160 channel, we always use the center frequency of the control channel. > >>> + /* This would happen when regulatory rules disallow VHT80 completely */ > >>> + if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & (IEEE80211_CHAN_NO_VHT80))) > >>> + return true; > >> > >> Is that really right? Need to document what the return value of this > >> function should be, I guess? > >> > >> [MP] I guess, it's possible for a channel not allowed for 80Mhz operation. > > > > Yeah but should it really check *all* the bits rather than any one of > > them? > > > > You mean to say other bits like HT40MINUS, HT40PLUS or even DFS? No, I mean all the bits that are part of CHAN_NO_VHT80. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/24/2012 04:47 PM, Johannes Berg wrote: > On Tue, 2012-07-24 at 16:18 +0530, Mahesh Palivela wrote: > >>>> indicating the number of channels below/above control (for control >>>> channel 1,2,3,4 respectively). Similarly, for VHT160 you'd have 8 >>>> possibilities: >>>> >>>> |-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-| >>>> >>>> (which one could again capture as VHT_CHAN_LAYOUT_0_7 etc.) >>>> >>>> [MP] I see your point. But according to 11ac spec, AP will use primary >>>> chan as specified in HT operation IE chan num. Secondary channel is >>>> center freq specified in VHT Operation IE. So I am thinking secondary >>>> channel is not relative offset to primary channel. Hope I am not >>>> mistaken here. >>> >>> Ok so HT has primary channel and secondary, and VHT has secondary VHT >>> which can again be above/below? That would make sense, but you wouldn't >>> be covering it. >>> >> >> I am thinking no need of above/below convention as the center frequency >> value itself we know. > > But we don't use the center frequency of the overall Ht40/80/160 > channel, we always use the center frequency of the control channel. > 11ac Draft3.0 section 22.3.14 says VHT channel is specified by dot11CurrentChannelBandwidth, dot11CurrentChannelCenterFrequencyIndex0, dot11CurrentChannelCenterFrequencyIndex1 and dot11CurrentPrimaryChannel primary channel comes from HT Op IE. chanBW, chanCenterFreq0, chanCenterFreq1 comes from VHT Op IE. So multiple secondary channels doesn't seem to be a valid? >>>>> + /* This would happen when regulatory rules disallow VHT80 completely */ >>>>> + if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & (IEEE80211_CHAN_NO_VHT80))) >>>>> + return true; >>>> >>>> Is that really right? Need to document what the return value of this >>>> function should be, I guess? >>>> >>>> [MP] I guess, it's possible for a channel not allowed for 80Mhz operation. >>> >>> Yeah but should it really check *all* the bits rather than any one of >>> them? >>> >> >> You mean to say other bits like HT40MINUS, HT40PLUS or even DFS? > > No, I mean all the bits that are part of CHAN_NO_VHT80. > CHAN_NO_VHT80 is actually 2 bits. NO_VHT80MINUS & NO_VHT80PLUS. Is that ok? + IEEE80211_CHAN_NO_VHT80PLUS = 1<<6, + IEEE80211_CHAN_NO_VHT80MINUS = 1<<7, +#define IEEE80211_CHAN_NO_VHT80 \ + (IEEE80211_CHAN_NO_VHT80PLUS | IEEE80211_CHAN_NO_VHT80MINUS) > johannes > Thanks, Mahesh -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2012-07-25 at 09:31 +0530, Mahesh Palivela wrote: > >>> Ok so HT has primary channel and secondary, and VHT has secondary VHT > >>> which can again be above/below? That would make sense, but you wouldn't > >>> be covering it. > >>> > >> > >> I am thinking no need of above/below convention as the center frequency > >> value itself we know. > > > > But we don't use the center frequency of the overall Ht40/80/160 > > channel, we always use the center frequency of the control channel. > > > > 11ac Draft3.0 section 22.3.14 says VHT channel is specified by > dot11CurrentChannelBandwidth, dot11CurrentChannelCenterFrequencyIndex0, > dot11CurrentChannelCenterFrequencyIndex1 and dot11CurrentPrimaryChannel > > primary channel comes from HT Op IE. > chanBW, chanCenterFreq0, chanCenterFreq1 comes from VHT Op IE. > So multiple secondary channels doesn't seem to be a valid? Hmm. But that means we have to specify the channel completely differently? I think we should stick to our scheme of center freq of a 20 MHz channel + surrounding bandwidth, though it obviously won't work for 80+80. The question will be where we deviate from our previous scheme. I tend to think that HT80+80 should deviate, I have a feeling it won't be implemented soon (or ever?) anyway. > > No, I mean all the bits that are part of CHAN_NO_VHT80. > > > > > CHAN_NO_VHT80 is actually 2 bits. NO_VHT80MINUS & NO_VHT80PLUS. > Is that ok? > > + IEEE80211_CHAN_NO_VHT80PLUS = 1<<6, > + IEEE80211_CHAN_NO_VHT80MINUS = 1<<7, > > +#define IEEE80211_CHAN_NO_VHT80 \ > + (IEEE80211_CHAN_NO_VHT80PLUS | IEEE80211_CHAN_NO_VHT80MINUS) Right. But did you mean to check that all of them are set? What if one of them is set but the other isn't? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/25/2012 03:20 PM, Johannes Berg wrote: > On Wed, 2012-07-25 at 09:31 +0530, Mahesh Palivela wrote: > >>>>> Ok so HT has primary channel and secondary, and VHT has secondary VHT >>>>> which can again be above/below? That would make sense, but you wouldn't >>>>> be covering it. >>>>> >>>> >>>> I am thinking no need of above/below convention as the center frequency >>>> value itself we know. >>> >>> But we don't use the center frequency of the overall Ht40/80/160 >>> channel, we always use the center frequency of the control channel. >>> >> >> 11ac Draft3.0 section 22.3.14 says VHT channel is specified by >> dot11CurrentChannelBandwidth, dot11CurrentChannelCenterFrequencyIndex0, >> dot11CurrentChannelCenterFrequencyIndex1 and dot11CurrentPrimaryChannel >> >> primary channel comes from HT Op IE. >> chanBW, chanCenterFreq0, chanCenterFreq1 comes from VHT Op IE. >> So multiple secondary channels doesn't seem to be a valid? > > Hmm. But that means we have to specify the channel completely > differently? I think we should stick to our scheme of center freq of a > 20 MHz channel + surrounding bandwidth, ok. Let's stick to old way of channel config. Basically freq value and channel type which kind of specifies channel widths. so how about for VHT channel types as below. Its similar to what you proposed. For 80 MHz: VHT80_3PLUS VHT80_MINUS_2PLUS VHT80_2MINUS_PLUS VHT80_3MINUS For 160 MHz: VHT160_7PLUS VHT160_MINUS_6PLUS VHT160_2MINUS_5PLUS VHT160_3MINUS_4PLUS VHT160_4MINUS_3PLUS VHT160_5MINUS_2PLUS VHT160_6MINUS_PLUS VHT160_7MINUS > though it obviously won't work for 80+80. The question will be where > we deviate from our previous scheme. I tend to think that HT80+80 > should deviate, I have a feeling it won't be implemented soon > (or ever?) anyway. > Yea, even I feel the channel config representation what we are proposing is not really extendable to discrete bands. That's my only worry... >>> No, I mean all the bits that are part of CHAN_NO_VHT80. >>> >> >> >> CHAN_NO_VHT80 is actually 2 bits. NO_VHT80MINUS & NO_VHT80PLUS. >> Is that ok? >> >> + IEEE80211_CHAN_NO_VHT80PLUS = 1<<6, >> + IEEE80211_CHAN_NO_VHT80MINUS = 1<<7, >> >> +#define IEEE80211_CHAN_NO_VHT80 \ >> + (IEEE80211_CHAN_NO_VHT80PLUS | IEEE80211_CHAN_NO_VHT80MINUS) > > Right. But did you mean to check that all of them are set? What if one > of them is set but the other isn't? > If one of them is set, then we accept VHT80 for that channel. > johannes > - Mahesh -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2012-07-26 at 12:00 +0530, Mahesh Palivela wrote: > >> 11ac Draft3.0 section 22.3.14 says VHT channel is specified by > >> dot11CurrentChannelBandwidth, dot11CurrentChannelCenterFrequencyIndex0, > >> dot11CurrentChannelCenterFrequencyIndex1 and dot11CurrentPrimaryChannel > >> > >> primary channel comes from HT Op IE. > >> chanBW, chanCenterFreq0, chanCenterFreq1 comes from VHT Op IE. > >> So multiple secondary channels doesn't seem to be a valid? > > > > Hmm. But that means we have to specify the channel completely > > differently? I think we should stick to our scheme of center freq of a > > 20 MHz channel + surrounding bandwidth, > > ok. Let's stick to old way of channel config. Basically freq value and > channel type which kind of specifies channel widths. so how about for > VHT channel types as below. Its similar to what you proposed. > > For 80 MHz: > > VHT80_3PLUS > VHT80_MINUS_2PLUS > VHT80_2MINUS_PLUS > VHT80_3MINUS > > For 160 MHz: > > VHT160_7PLUS > VHT160_MINUS_6PLUS > VHT160_2MINUS_5PLUS > VHT160_3MINUS_4PLUS > VHT160_4MINUS_3PLUS > VHT160_5MINUS_2PLUS > VHT160_6MINUS_PLUS > VHT160_7MINUS Yeah, that would work. Lots of channel types ... > > though it obviously won't work for 80+80. The question will be where > > we deviate from our previous scheme. I tend to think that HT80+80 > > should deviate, I have a feeling it won't be implemented soon > > (or ever?) anyway. > > > > Yea, even I feel the channel config representation what we are proposing > is not really extendable to discrete bands. That's my only worry... ? What do you mean? > >> CHAN_NO_VHT80 is actually 2 bits. NO_VHT80MINUS & NO_VHT80PLUS. > >> Is that ok? > >> > >> + IEEE80211_CHAN_NO_VHT80PLUS = 1<<6, > >> + IEEE80211_CHAN_NO_VHT80MINUS = 1<<7, > >> > >> +#define IEEE80211_CHAN_NO_VHT80 \ > >> + (IEEE80211_CHAN_NO_VHT80PLUS | IEEE80211_CHAN_NO_VHT80MINUS) > > > > Right. But did you mean to check that all of them are set? What if one > > of them is set but the other isn't? > > > > If one of them is set, then we accept VHT80 for that channel. Yes, but is that really correct? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 7/26/2012 11:12 PM, Johannes Berg wrote: > On Thu, 2012-07-26 at 12:00 +0530, Mahesh Palivela wrote: > >>>> 11ac Draft3.0 section 22.3.14 says VHT channel is specified by >>>> dot11CurrentChannelBandwidth, dot11CurrentChannelCenterFrequencyIndex0, >>>> dot11CurrentChannelCenterFrequencyIndex1 and dot11CurrentPrimaryChannel >>>> >>>> primary channel comes from HT Op IE. >>>> chanBW, chanCenterFreq0, chanCenterFreq1 comes from VHT Op IE. >>>> So multiple secondary channels doesn't seem to be a valid? >>> >>> Hmm. But that means we have to specify the channel completely >>> differently? I think we should stick to our scheme of center freq of a >>> 20 MHz channel + surrounding bandwidth, >> >> ok. Let's stick to old way of channel config. Basically freq value and >> channel type which kind of specifies channel widths. so how about for >> VHT channel types as below. Its similar to what you proposed. >> >> For 80 MHz: >> >> VHT80_3PLUS >> VHT80_MINUS_2PLUS >> VHT80_2MINUS_PLUS >> VHT80_3MINUS >> >> For 160 MHz: >> >> VHT160_7PLUS >> VHT160_MINUS_6PLUS >> VHT160_2MINUS_5PLUS >> VHT160_3MINUS_4PLUS >> VHT160_4MINUS_3PLUS >> VHT160_5MINUS_2PLUS >> VHT160_6MINUS_PLUS >> VHT160_7MINUS > > Yeah, that would work. Lots of channel types ... > Yea, So I am thinking how about passing channel width and secondary channel center frequency from which we know chan_below or chan_above, instead of channel_type. >> > though it obviously won't work for 80+80. The question will be where >> > we deviate from our previous scheme. I tend to think that HT80+80 >> > should deviate, I have a feeling it won't be implemented soon >> > (or ever?) anyway. >> > >> >> Yea, even I feel the channel config representation what we are proposing >> is not really extendable to discrete bands. That's my only worry... > > ? What do you mean? > I mean 80+80 scenario is not possible to represent. >>>> CHAN_NO_VHT80 is actually 2 bits. NO_VHT80MINUS & NO_VHT80PLUS. >>>> Is that ok? >>>> >>>> + IEEE80211_CHAN_NO_VHT80PLUS = 1<<6, >>>> + IEEE80211_CHAN_NO_VHT80MINUS = 1<<7, >>>> >>>> +#define IEEE80211_CHAN_NO_VHT80 \ >>>> + (IEEE80211_CHAN_NO_VHT80PLUS | IEEE80211_CHAN_NO_VHT80MINUS) >>> >>> Right. But did you mean to check that all of them are set? What if one >>> of them is set but the other isn't? >>> >> >> If one of them is set, then we accept VHT80 for that channel. > > Yes, but is that really correct? > I think so. If one of the configuration is allowed we can perform VHT80 operation. > johannes > Thanks, Mahesh -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 493fa0c..bde0fee 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -104,10 +104,18 @@ enum ieee80211_channel_flags { IEEE80211_CHAN_RADAR = 1<<3, IEEE80211_CHAN_NO_HT40PLUS = 1<<4, IEEE80211_CHAN_NO_HT40MINUS = 1<<5, + IEEE80211_CHAN_NO_VHT80PLUS = 1<<6, + IEEE80211_CHAN_NO_VHT80MINUS = 1<<7, + IEEE80211_CHAN_NO_VHT160PLUS = 1<<8, + IEEE80211_CHAN_NO_VHT160MINUS = 1<<9, }; #define IEEE80211_CHAN_NO_HT40 \ (IEEE80211_CHAN_NO_HT40PLUS | IEEE80211_CHAN_NO_HT40MINUS) +#define IEEE80211_CHAN_NO_VHT80 \ + (IEEE80211_CHAN_NO_VHT80PLUS | IEEE80211_CHAN_NO_VHT80MINUS) +#define IEEE80211_CHAN_NO_VHT160 \ + (IEEE80211_CHAN_NO_VHT160PLUS | IEEE80211_CHAN_NO_VHT160MINUS) /** * struct ieee80211_channel - channel definition diff --git a/net/wireless/reg.c b/net/wireless/reg.c index 2303ee7..0ad6c15 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1124,6 +1124,81 @@ static void reg_process_beacons(struct wiphy *wiphy) wiphy_update_beacon_reg(wiphy); } +static bool is_vht80_not_allowed(struct ieee80211_channel *chan) +{ + if (!chan) + return true; + if (chan->flags & IEEE80211_CHAN_DISABLED) + return true; + /* This would happen when regulatory rules disallow VHT80 completely */ + if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & (IEEE80211_CHAN_NO_VHT80))) + return true; + return false; +} + +static void reg_process_vht_flags_channel(struct wiphy *wiphy, + unsigned int chan_idx) +{ + struct ieee80211_supported_band *sband; + struct ieee80211_channel *channel; + struct ieee80211_channel *channel_before = NULL, *channel_after = NULL; + unsigned int i; + + assert_cfg80211_lock(); + + sband = wiphy->bands[IEEE80211_BAND_5GHZ]; + BUG_ON(chan_idx >= sband->n_channels); + channel = &sband->channels[chan_idx]; + + if (is_vht80_not_allowed(channel)) { + channel->flags |= IEEE80211_CHAN_NO_VHT80; + return; + } + + /* + * We need to ensure the extension channels exist to + * be able to use VHT80- or VHT80+, this finds them (or not) + */ + for (i = 0; i < sband->n_channels; i++) { + struct ieee80211_channel *c = &sband->channels[i]; + if (c->center_freq == (channel->center_freq - 40)) + channel_before = c; + if (c->center_freq == (channel->center_freq + 40)) + channel_after = c; + } + + /* + * Please note that this assumes target bandwidth is 40 MHz, + * if that ever changes we also need to change the below logic + * to include that as well. + */ + if (is_vht80_not_allowed(channel_before)) + channel->flags |= IEEE80211_CHAN_NO_VHT80MINUS; + else + channel->flags &= ~IEEE80211_CHAN_NO_VHT80MINUS; + + if (is_vht80_not_allowed(channel_after)) + channel->flags |= IEEE80211_CHAN_NO_VHT80PLUS; + else + channel->flags &= ~IEEE80211_CHAN_NO_VHT80PLUS; +} + +static void reg_process_vht_flags(struct wiphy *wiphy) +{ + unsigned int i; + struct ieee80211_supported_band *sband; + + if(!wiphy->bands[IEEE80211_BAND_5GHZ]) { + /* 5GHz band is not supported, which is + * mandatory for VHT. so simply return */ + return; + } + sband = wiphy->bands[IEEE80211_BAND_5GHZ]; + + for (i = 0; i < sband->n_channels; i++) + reg_process_vht_flags_channel(wiphy, i); +} + static bool is_ht40_not_allowed(struct ieee80211_channel *chan) { if (!chan) @@ -1230,6 +1305,7 @@ static void wiphy_update_regulatory(struct wiphy *wiphy, reg_process_beacons(wiphy); reg_process_ht_flags(wiphy); + reg_process_vht_flags(wiphy); if (wiphy->reg_notifier) wiphy->reg_notifier(wiphy, last_request); }--
80MHz Regulatory changes for 11ac. Signed-off-by: Mahesh Palivela <maheshp@posedge.com> --- include/net/cfg80211.h | 8 +++++ net/wireless/reg.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 84 insertions(+), 0 deletions(-) To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html