| Message ID | 952C5D5D0470AE4FB7D8A75C6ADC71CA0FCDD559@mbx022-e1-nj-10.exch022.domain.local (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Tue, Aug 14, 2012 at 03:55:26PM +0000, Mahesh Palivela wrote: > Handling of 80 MHz, 160 MHz channel bandwidths for VHT (11ac) Regulatory > and setting channel flags for allowed bandwidths. > > Signed-off-by: Mahesh Palivela <maheshp@posedge.com> > --- > > Sending patch second time as Stanislaw Gruszka complained its malformed. And now complaining that patch is ugly. There is really on other, simpler way to handle that? Stanislaw -- 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 8/16/2012 3:52 PM, Stanislaw Gruszka wrote: > On Tue, Aug 14, 2012 at 03:55:26PM +0000, Mahesh Palivela wrote: >> Handling of 80 MHz, 160 MHz channel bandwidths for VHT (11ac) Regulatory >> and setting channel flags for allowed bandwidths. >> >> Signed-off-by: Mahesh Palivela <maheshp@posedge.com> >> --- >> >> Sending patch second time as Stanislaw Gruszka complained its malformed. > > And now complaining that patch is ugly. There is really on other, > simpler way to handle that? > > Stanislaw > oh, you mean my implementation is ugly? Not a problem. Give me some clue, I will work on it. Best Regards, 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, Aug 16, 2012 at 06:47:09PM +0530, Mahesh Palivela wrote: > On 8/16/2012 3:52 PM, Stanislaw Gruszka wrote: > >On Tue, Aug 14, 2012 at 03:55:26PM +0000, Mahesh Palivela wrote: > >>Handling of 80 MHz, 160 MHz channel bandwidths for VHT (11ac) Regulatory > >>and setting channel flags for allowed bandwidths. > >> > >>Signed-off-by: Mahesh Palivela <maheshp@posedge.com> > >>--- > >> > >>Sending patch second time as Stanislaw Gruszka complained its malformed. > > > >And now complaining that patch is ugly. There is really on other, > >simpler way to handle that? > > > >Stanislaw > > > oh, you mean my implementation is ugly? Not a problem. Give me some > clue, I will work on it. We can not extend channel, if regulatory disallow to use some nearby channels or disallow HT at all. So it's not possible that for particular channel that we can extend it to let say -160|0+ and -0|160+, but can not extend it to -40|120+. So we do not need zilion flags, but just specify left and right borders, inside which we can extend channel. For example: channel 36 (5180 MHz) is prohibited and all channels above are allowed. For channel 52 (5260 MHz) left border will be -60 and right border +160 (max). That will allow to support VHT160: -60|100+, -40|120+, -20|140+, -0|160+ ; VHT80: -60|20+, -40|40+, -20|60+, -0|80+ ; HT40 :-40|0+, -0|40+ Stanislaw -- 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 8/17/2012 7:36 PM, Stanislaw Gruszka wrote: > On Thu, Aug 16, 2012 at 06:47:09PM +0530, Mahesh Palivela wrote: >> On 8/16/2012 3:52 PM, Stanislaw Gruszka wrote: >>> On Tue, Aug 14, 2012 at 03:55:26PM +0000, Mahesh Palivela wrote: >>>> Handling of 80 MHz, 160 MHz channel bandwidths for VHT (11ac) Regulatory >>>> and setting channel flags for allowed bandwidths. >>>> >>>> Signed-off-by: Mahesh Palivela <maheshp@posedge.com> >>>> --- >>>> >>>> Sending patch second time as Stanislaw Gruszka complained its malformed. >>> >>> And now complaining that patch is ugly. There is really on other, >>> simpler way to handle that? >>> >>> Stanislaw >>> >> oh, you mean my implementation is ugly? Not a problem. Give me some >> clue, I will work on it. > > We can not extend channel, if regulatory disallow to use some > nearby channels or disallow HT at all. > > So it's not possible that for particular channel that we can extend it > to let say -160|0+ and -0|160+, but can not extend it to -40|120+. So > we do not need zilion flags, but just specify left and right borders, > inside which we can extend channel. > > For example: channel 36 (5180 MHz) is prohibited and all channels > above are allowed. For channel 52 (5260 MHz) left border will be > -60 and right border +160 (max). That will allow to support > VHT160: -60|100+, -40|120+, -20|140+, -0|160+ ; > VHT80: -60|20+, -40|40+, -20|60+, -0|80+ ; > HT40 :-40|0+, -0|40+ > > Stanislaw > Thanks for the description. I will get back to you soon.
On Fri, 2012-08-17 at 23:26 +0530, Mahesh Palivela wrote: > >> oh, you mean my implementation is ugly? Not a problem. Give me some > >> clue, I will work on it. > > > > We can not extend channel, if regulatory disallow to use some > > nearby channels or disallow HT at all. > > > > So it's not possible that for particular channel that we can extend it > > to let say -160|0+ and -0|160+, but can not extend it to -40|120+. So > > we do not need zilion flags, but just specify left and right borders, > > inside which we can extend channel. > > > > For example: channel 36 (5180 MHz) is prohibited and all channels > > above are allowed. For channel 52 (5260 MHz) left border will be > > -60 and right border +160 (max). That will allow to support > > VHT160: -60|100+, -40|120+, -20|140+, -0|160+ ; > > VHT80: -60|20+, -40|40+, -20|60+, -0|80+ ; > > HT40 :-40|0+, -0|40+ > Thanks for the description. I will get back to you soon. I guess the question is how we specify the channel. If we want to continue using the current scheme of encoding the bandwidth in the channel type, then we will need one channel type for each of the VHT possibilities: 80 MHz: * +3 * +2/-1 * +1/-2 * -3 160 MHz: * +7 * -1/+6 * -2/+5 * -3/+4 * -4/+3 * -5/+2 * -6/+1 * -7 That's 4 different 80 MHz channel types and 8 different 160 MHz channel types, all while disregarding 80+80 completely. Then we'd need all the different flags because structurally we want to be able to answer each channel type with a single bit. If we keep this then it would probably be worthwhile to rework this to use permitted (rather than prohibited) bits and use BIT(channel_type) instead of CHAN_NO_... flags. There are currently relatively few users of these flags, so such a change would be pretty easy. On the other hand, maybe for VHT we want to completely change channel specifications? Maybe it would be better to allow specifying the *global* center frequency of the entire channel, and the width, and the control channel offset instead of encoding everything into the single channel type value? I don't know. Discuss ;-) 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
Johannes Berg <johannes@sipsolutions.net> writes: > On the other hand, maybe for VHT we want to completely change channel > specifications? Maybe it would be better to allow specifying the > *global* center frequency of the entire channel, and the width, and the > control channel offset instead of encoding everything into the single > channel type value? I don't know. What about the future? Will we see 320 MHz wide channels in 2020? :) After following the discussion about this I'm starting to think that what you propose above makes our life easier in the long run. I just don't trust that using a single channel type value is scalable in the long run.
On Tue, Aug 21, 2012 at 10:50:13AM +0300, Kalle Valo wrote: > Johannes Berg <johannes@sipsolutions.net> writes: > > > On the other hand, maybe for VHT we want to completely change channel > > specifications? Maybe it would be better to allow specifying the > > *global* center frequency of the entire channel, and the width, and the > > control channel offset instead of encoding everything into the single > > channel type value? I don't know. > > What about the future? Will we see 320 MHz wide channels in 2020? :) Not in 2016 ? > After following the discussion about this I'm starting to think that > what you propose above makes our life easier in the long run. I just > don't trust that using a single channel type value is scalable in the > long run. Yeh, I think our channel description in code should reflect to what we have in new spec. That should fit well for legacy channels as well. Stanislaw -- 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 08/21/2012 01:48 PM, Stanislaw Gruszka wrote: > On Tue, Aug 21, 2012 at 10:50:13AM +0300, Kalle Valo wrote: >> Johannes Berg <johannes@sipsolutions.net> writes: >> >>> On the other hand, maybe for VHT we want to completely change channel >>> specifications? Maybe it would be better to allow specifying the >>> *global* center frequency of the entire channel, and the width, and the >>> control channel offset instead of encoding everything into the single >>> channel type value? I don't know. >> >> What about the future? Will we see 320 MHz wide channels in 2020? :) > > Not in 2016 ? > >> After following the discussion about this I'm starting to think that >> what you propose above makes our life easier in the long run. I just >> don't trust that using a single channel type value is scalable in the >> long run. > > Yeh, I think our channel description in code should reflect to what we > have in new spec. That should fit well for legacy channels as well. > > Stanislaw > so we are talking about how to specify channel info to cfg/mac80211 from upper layers. But regulatory tells if that channel config is allowed or not. so derive channel type from center freq, width and control chan offset. Then determine if that channel type is allowed from regulatory flags? In short we have scaled approach on specifying channel info but not regulatory. Please comment. Regards, 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 Tue, 2012-08-21 at 19:05 +0530, Mahesh Palivela wrote: > so we are talking about how to specify channel info to cfg/mac80211 from > upper layers. Correct > But regulatory tells if that channel config is allowed or not. Correct. > so derive channel type from center freq, width and control chan offset. > Then determine if that channel type is allowed from regulatory flags? > > In short we have scaled approach on specifying channel info but not > regulatory. Please comment. Well, we don't really have it yet :-) I think the question really is whether or not we actually need the flags. Sometimes, but very rarely really, we need to answer the question Is this set of parameters allowed with the current regulatory rules? There's nothing that says this needs to be a flag. It could just as well be a function bool regulatory_chan_use_permitted(...); where the ... gives all the necessary parameters or maybe some structure holding all these. If this was a function, it could go back to the regulatory definitions (that we hopefully keep track of in the kernel) and actually use the algorithm that today we use to determine the flags to determine the answer. Today, with the flags, we basically pre-determine the answers to all possible such questions, and encode the answers in the flags for each channel. If we don't pre-determine the answers, then we can get away without any flags at all. Does that make sense? Still doesn't solve the problems we saw with how to configure the channel with considerations such as - bandwidth - center frequency - primary subchannel - 80 + 80 (which is basically two such channels?) 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 8/21/2012 9:23 PM, Johannes Berg wrote: > On Tue, 2012-08-21 at 19:05 +0530, Mahesh Palivela wrote: > >> so we are talking about how to specify channel info to cfg/mac80211 from >> upper layers. > > Correct > >> But regulatory tells if that channel config is allowed or not. > > Correct. > >> so derive channel type from center freq, width and control chan offset. >> Then determine if that channel type is allowed from regulatory flags? >> >> In short we have scaled approach on specifying channel info but not >> regulatory. Please comment. > > Well, we don't really have it yet :-) > > I think the question really is whether or not we actually need the > flags. Sometimes, but very rarely really, we need to answer the question > > Is this set of parameters allowed with the current regulatory > rules? > > There's nothing that says this needs to be a flag. It could just as well > be a function > > bool regulatory_chan_use_permitted(...); > > where the ... gives all the necessary parameters or maybe some structure > holding all these. > > If this was a function, it could go back to the regulatory definitions > (that we hopefully keep track of in the kernel) and actually use the > algorithm that today we use to determine the flags to determine the > answer. > > Today, with the flags, we basically pre-determine the answers to all > possible such questions, and encode the answers in the flags for each > channel. If we don't pre-determine the answers, then we can get away > without any flags at all. > > Does that make sense? > Yes it does. Basically we want to retire look up table approach and compute everytime as its not scalable. Fine. In that case, even we need to cover HT20, HT40-, HT40+ as well right? > Still doesn't solve the problems we saw with how to configure the > channel with considerations such as > - bandwidth > - center frequency > - primary subchannel > - 80 + 80 (which is basically two such channels?) > Yes It does. From center freq, width, control chan offset we know the secondary chans. That's all we want. For 80+80 configuration, we will get two center freq values. > johannes >
On Tue, 2012-08-21 at 23:37 +0530, Mahesh Palivela wrote: > > I think the question really is whether or not we actually need the > > flags. Sometimes, but very rarely really, we need to answer the question > > > > Is this set of parameters allowed with the current regulatory > > rules? > > > > There's nothing that says this needs to be a flag. It could just as well > > be a function > > > > bool regulatory_chan_use_permitted(...); > > > > where the ... gives all the necessary parameters or maybe some structure > > holding all these. > > > > If this was a function, it could go back to the regulatory definitions > > (that we hopefully keep track of in the kernel) and actually use the > > algorithm that today we use to determine the flags to determine the > > answer. > > > > Today, with the flags, we basically pre-determine the answers to all > > possible such questions, and encode the answers in the flags for each > > channel. If we don't pre-determine the answers, then we can get away > > without any flags at all. > > > > Does that make sense? > > > Yes it does. Basically we want to retire look up table approach and > compute everytime as its not scalable. Fine. In that case, even we need > to cover HT20, HT40-, HT40+ as well right? I think we should, yeah. Might even just start with that to make the transition. > > Still doesn't solve the problems we saw with how to configure the > > channel with considerations such as > > - bandwidth > > - center frequency > > - primary subchannel > > - 80 + 80 (which is basically two such channels?) > > > Yes It does. From center freq, width, control chan offset we know the > secondary chans. That's all we want. For 80+80 configuration, we will > get two center freq values. Yeah but we don't have that yet. We could do it that way, sure, but it has wide-spread implications, since we'll need to - use this new form of specifying channels all over mac80211 and all drivers, - define new nl80211 attributes for it, - write new code in nl80211 to handle all this, - and parse the old attributes into the new data structure(s) so drivers use the new API but userspace can continue to use the old None of that is done yet. 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 Wed, Aug 22, 2012 at 09:03:28AM +0200, Johannes Berg wrote: > On Tue, 2012-08-21 at 23:37 +0530, Mahesh Palivela wrote: > > Yes it does. Basically we want to retire look up table approach and > > compute everytime as its not scalable. Fine. In that case, even we need > > to cover HT20, HT40-, HT40+ as well right? > > I think we should, yeah. Might even just start with that to make the > transition. [snip] > > > Still doesn't solve the problems we saw with how to configure the > > > channel with considerations such as > > > - bandwidth > > > - center frequency > > > - primary subchannel > > > - 80 + 80 (which is basically two such channels?) > > > > > Yes It does. From center freq, width, control chan offset we know the > > secondary chans. That's all we want. For 80+80 configuration, we will > > get two center freq values. > > Yeah but we don't have that yet. We could do it that way, sure, but it > has wide-spread implications, since we'll need to > - use this new form of specifying channels all over mac80211 and all > drivers, > - define new nl80211 attributes for it, > - write new code in nl80211 to handle all this, > - and parse the old attributes into the new data structure(s) so > drivers use the new API but userspace can continue to use the old > > None of that is done yet. For starters (for regulatory purpose only) would be sufficient to implement regulatory_chan_use_permitted(center freq, bandwidth, whatever else), and use it where currently IEEE80211_CHAN_NO_HT_X flags are used. Stanislaw -- 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-08-22 at 11:01 +0200, Stanislaw Gruszka wrote: > > Yeah but we don't have that yet. We could do it that way, sure, but it > > has wide-spread implications, since we'll need to > > - use this new form of specifying channels all over mac80211 and all > > drivers, > > - define new nl80211 attributes for it, > > - write new code in nl80211 to handle all this, > > - and parse the old attributes into the new data structure(s) so > > drivers use the new API but userspace can continue to use the old > > > > None of that is done yet. > > For starters (for regulatory purpose only) would be sufficient to > implement > > regulatory_chan_use_permitted(center freq, bandwidth, whatever else), > > and use it where currently IEEE80211_CHAN_NO_HT_X flags are used. Yes, in theory. However, if this was intended to use the actual "center freq, bandwidth, control channel offset" values, then it would be much better to first actually define a struct to hold those, use it here, and give it to drivers etc. Otherwise, drivers would have to take, e.g. - channel = 1 (2412 MHz) - HT40+ and calculate - center freq = 2422 MHz - bandwidth = 40 - control channel offset = 0 before being able to call this function. To me, that seems wrong. 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 Wed, Aug 22, 2012 at 11:04:42AM +0200, Johannes Berg wrote: > On Wed, 2012-08-22 at 11:01 +0200, Stanislaw Gruszka wrote: > > > > Yeah but we don't have that yet. We could do it that way, sure, but it > > > has wide-spread implications, since we'll need to > > > - use this new form of specifying channels all over mac80211 and all > > > drivers, > > > - define new nl80211 attributes for it, > > > - write new code in nl80211 to handle all this, > > > - and parse the old attributes into the new data structure(s) so > > > drivers use the new API but userspace can continue to use the old > > > > > > None of that is done yet. > > > > For starters (for regulatory purpose only) would be sufficient to > > implement > > > > regulatory_chan_use_permitted(center freq, bandwidth, whatever else), > > > > and use it where currently IEEE80211_CHAN_NO_HT_X flags are used. > > Yes, in theory. However, if this was intended to use the actual "center > freq, bandwidth, control channel offset" values, then it would be much > better to first actually define a struct to hold those, use it here, and > give it to drivers etc. Otherwise, drivers would have to take, e.g. > > - channel = 1 (2412 MHz) > - HT40+ > > and calculate > > - center freq = 2422 MHz > - bandwidth = 40 > - control channel offset = 0 > > before being able to call this function. To me, that seems wrong. I see, we could add helper function that will calculate center_freq/bandwidth, but starting from defining new channel structure and accompanying code in nl80211/mac80211 is more reasonable. Stanislaw -- 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
> > I see, we could add helper function that will calculate > center_freq/bandwidth, but starting from defining new channel > structure and accompanying code in nl80211/mac80211 is more > reasonable. > > Stanislaw > How about below new channel config structure? wanted to fit 80+80 config as well. /** * enum ieee80211_chan_width - channel bandwidths * * @IEEE80211_CHAN_WIDTH_20MHZ: 20 MHz chan bandwidth * @IEEE80211_CHAN_WIDTH_40MHZ: 40 MHz chan bandwidth * @IEEE80211_CHAN_WIDTH_80MHZ: 80 MHz chan bandwidth * @IEEE80211_CHAN_WIDTH_160MHZ: 160 MHz chan bandwidth */ enum ieee80211_chan_width { IEEE80211_CHAN_WIDTH_20MHZ = 20, IEEE80211_CHAN_WIDTH_40MHZ = 40, IEEE80211_CHAN_WIDTH_80MHZ = 80, IEEE80211_CHAN_WIDTH_160MHZ = 160 }; /** * struct ieee80211_channel_config - channel config definition * * This structure describes channel configuration * * @chan_width1: channel bandwidth 1 * @center_freq1: center frequency 1 for entire chan width * @control_offset1: control chan offset 1 * @chan_width2: channel bandwidth 2 * @center_freq2: center frequency 2 for entire chan width * @control_offset2: control chan offset 2 */ struct ieee80211_channel_config { enum ieee80211_chan_width chan_width1; u16 center_freq1; u16 control_offset1; enum ieee80211_chan_width chan_width2; u16 center_freq2; u16 control_offset2; }; -- 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 Fri, 2012-08-24 at 17:03 +0530, Mahesh Palivela wrote: > /** > * enum ieee80211_chan_width - channel bandwidths > * > * @IEEE80211_CHAN_WIDTH_20MHZ: 20 MHz chan bandwidth > * @IEEE80211_CHAN_WIDTH_40MHZ: 40 MHz chan bandwidth > * @IEEE80211_CHAN_WIDTH_80MHZ: 80 MHz chan bandwidth > * @IEEE80211_CHAN_WIDTH_160MHZ: 160 MHz chan bandwidth > */ We might need 20MHZ_NOHT or something? > enum ieee80211_chan_width chan_width2; > u16 control_offset2; Those shouldn't be necessary, I think? The secondary 80 MHz channel can't have a control channel, it seems, and the width should be the same as well? Plus this is only allowed in 80+80 anyway. 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 08/24/2012 05:35 PM, Johannes Berg wrote: > On Fri, 2012-08-24 at 17:03 +0530, Mahesh Palivela wrote: > >> /** >> * enum ieee80211_chan_width - channel bandwidths >> * >> * @IEEE80211_CHAN_WIDTH_20MHZ: 20 MHz chan bandwidth >> * @IEEE80211_CHAN_WIDTH_40MHZ: 40 MHz chan bandwidth >> * @IEEE80211_CHAN_WIDTH_80MHZ: 80 MHz chan bandwidth >> * @IEEE80211_CHAN_WIDTH_160MHZ: 160 MHz chan bandwidth >> */ > > We might need 20MHZ_NOHT or something? Yes, I missed that. 20MHZ_NOHT in 5G band and legacy operation 2.4G band may be 5MHZ. > >> enum ieee80211_chan_width chan_width2; >> u16 control_offset2; > > Those shouldn't be necessary, I think? The secondary 80 MHz channel > can't have a control channel, it seems, and the width should be the same > as well? Plus this is only allowed in 80+80 anyway. > > johannes > 11ac d3.0 spec section 8.4.2.10 says An operating class for an 80+80 MHz channel bandwidth is expressed by two consecutive Operating/Sub- band Sequences, where the first Operating/Subband Sequence field contains an Operating Triplet for an 80 MHz Channel Spacing with an 80+ Behavior Limit and the second Operating/Subband Sequence field contains an Operating Triplet for an 80 MHz Channel Spacing without an 80+ Behavior Limit. so country might allow primary chan to fall in other frequency segment? - 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 Fri, 2012-08-24 at 18:38 +0530, Mahesh Palivela wrote: > > We might need 20MHZ_NOHT or something? > > Yes, I missed that. > 20MHZ_NOHT in 5G band and legacy operation 2.4G band may be 5MHZ. We don't support 5/10 MHz (yet anyway), so we don't have to worry about that. > > Those shouldn't be necessary, I think? The secondary 80 MHz channel > > can't have a control channel, it seems, and the width should be the same > > as well? Plus this is only allowed in 80+80 anyway. > 11ac d3.0 spec section 8.4.2.10 says > > An operating class for an 80+80 MHz channel bandwidth is expressed by > two consecutive Operating/Sub- > band Sequences, where the first Operating/Subband Sequence field > contains an Operating Triplet for an > 80 MHz Channel Spacing with an 80+ Behavior Limit and the second > Operating/Subband Sequence field > contains an Operating Triplet for an 80 MHz Channel Spacing without an > 80+ Behavior Limit. > > so country might allow primary chan to fall in other frequency segment? Yes, but how's that related to how you specify the channel? joahnnes -- 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 08/26/2012 02:09 PM, Johannes Berg wrote: > On Fri, 2012-08-24 at 18:38 +0530, Mahesh Palivela wrote: > > We don't support 5/10 MHz (yet anyway), so we don't have to worry about > that. > Oh, for legacy we still depend on chan_type setting for sometime? >> so country might allow primary chan to fall in other frequency segment? > > Yes, but how's that related to how you specify the channel? > ok. I will change the channel config structure per 11ac spec. dot11CurrentChannelBandwidth Channel bandwidth. Possible values represent 20 MHz, 40 MHz, 80 MHz, 160 MHz and 80+80 MHz channels. dot11CurrentChannelCenterFrequencyIndex0 In 20 MHz, 40 MHz, 80 MHz and 160 MHz channels, denotes the channel center frequency.In 80+80 MHz channels, denotes the center frequency of the frequency segment 0, which is the frequency segment containing the primary channel. Valid range is 1 to 200. dot11CurrentChannelCenterFrequencyIndex1 In 80+80 MHz channels, denotes the center frequency of the fre- quency segment 1, which is the frequency segment that does not contain the primary channel.Valid range is 1 to 200. Undefined for 20 MHz, 40 MHz, 80 MHz and 160 MHz chan- nels. dot11CurrentPrimaryChannel Denotes the location of the primary 20 MHz channel. Valid range is 1 to 200. > joahnnes > -- 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 08/26/2012 02:09 PM, Johannes Berg wrote: > On Fri, 2012-08-24 at 18:38 +0530, Mahesh Palivela wrote: > >>> We might need 20MHZ_NOHT or something? >> >> Yes, I missed that. >> 20MHZ_NOHT in 5G band and legacy operation 2.4G band may be 5MHZ. > > We don't support 5/10 MHz (yet anyway), so we don't have to worry about > that. > > > > Yes, but how's that related to how you specify the channel? > > joahnnes > To keep the backward compatibility, how about we still keep channel type. New enum value "NL80211_CHAN_VHT" tells us to look at the new channel_config structure. That way not every driver out there have to change to use the new channel config structure. Let me know. 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-08-29 at 09:37 +0530, Mahesh Palivela wrote: > To keep the backward compatibility, how about we still keep channel > type. New enum value "NL80211_CHAN_VHT" tells us to look at the new > channel_config structure. That way not every driver out there have to > change to use the new channel config structure. Let me know. I think we should change drivers. Yes, this is possible, but overall it'll just result in a mess, don't you think? 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
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 493fa0c..552c9ed 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -96,19 +96,71 @@ enum ieee80211_band { * is not permitted. * @IEEE80211_CHAN_NO_HT40MINUS: extension channel below this channel * is not permitted. + * @IEEE80211_CHAN_NO_VHT80_80PLUS: 3 extension channels above this channel + * are not permitted. + * @IEEE80211_CHAN_NO_VHT80_40MINUS_60PLUS: 1 extension channel below this chan + * 2 ext chans above this chan are not permitted. + * @IEEE80211_CHAN_NO_VHT80_60MINUS_40PLUS: 2 extension channels below this chan + * 1 ext chan above this chan are not permitted. + * @IEEE80211_CHAN_NO_VHT80_80MINUS: 3 extension channels below this channel + * are not permitted. + * @IEEE80211_CHAN_NO_VHT160_160PLUS: 7 extension channels above this channel + * are not permitted. + * @IEEE80211_CHAN_NO_VHT160_40MINUS_140PLUS: 1 extension channel below this chan + * 6 ext chan above this chan are not permitted. + * @IEEE80211_CHAN_NO_VHT160_60MINUS_120PLUS: 2 extension channels below this chan + * 5 ext chan above this chan are not permitted. + * @IEEE80211_CHAN_NO_VHT160_80MINUS_100PLUS: 3 extension channels below this chan + * 4 ext chan above this chan are not permitted. + * @IEEE80211_CHAN_NO_VHT160_100MINUS_80PLUS: 4 extension channels below this chan + * 3 ext chan above this chan are not permitted. + * @IEEE80211_CHAN_NO_VHT160_120MINUS_60PLUS: 5 extension channels below this chan + * 2 ext chan above this chan are not permitted. + * @IEEE80211_CHAN_NO_VHT160_140MINUS_40PLUS: 6 extension channel below this chan + * 1 ext chan above this chan are not permitted. + * @IEEE80211_CHAN_NO_VHT160_160MINUS: 7 extension channels below this channel + * are not permitted. */ enum ieee80211_channel_flags { - IEEE80211_CHAN_DISABLED = 1<<0, - IEEE80211_CHAN_PASSIVE_SCAN = 1<<1, - IEEE80211_CHAN_NO_IBSS = 1<<2, - IEEE80211_CHAN_RADAR = 1<<3, - IEEE80211_CHAN_NO_HT40PLUS = 1<<4, - IEEE80211_CHAN_NO_HT40MINUS = 1<<5, + IEEE80211_CHAN_DISABLED = 1<<0, + IEEE80211_CHAN_PASSIVE_SCAN = 1<<1, + IEEE80211_CHAN_NO_IBSS = 1<<2, + IEEE80211_CHAN_RADAR = 1<<3, + IEEE80211_CHAN_NO_HT40PLUS = 1<<4, + IEEE80211_CHAN_NO_HT40MINUS = 1<<5, + IEEE80211_CHAN_NO_VHT80_80PLUS = 1<<6, + IEEE80211_CHAN_NO_VHT80_60PLUS_40MINUS = 1<<7, + IEEE80211_CHAN_NO_VHT80_40PLUS_60MINUS = 1<<8, + IEEE80211_CHAN_NO_VHT80_80MINUS = 1<<9, + IEEE80211_CHAN_NO_VHT160_160PLUS = 1<<10, + IEEE80211_CHAN_NO_VHT160_140PLUS_40MINUS = 1<<11, + IEEE80211_CHAN_NO_VHT160_120PLUS_60MINUS = 1<<12, + IEEE80211_CHAN_NO_VHT160_100PLUS_80MINUS = 1<<13, + IEEE80211_CHAN_NO_VHT160_80PLUS_100MINUS = 1<<14, + IEEE80211_CHAN_NO_VHT160_60PLUS_120MINUS = 1<<15, + IEEE80211_CHAN_NO_VHT160_40PLUS_140MINUS = 1<<16, + IEEE80211_CHAN_NO_VHT160_160MINUS = 1<<17, }; #define IEEE80211_CHAN_NO_HT40 \ (IEEE80211_CHAN_NO_HT40PLUS | IEEE80211_CHAN_NO_HT40MINUS) +#define IEEE80211_CHAN_NO_VHT80 \ + (IEEE80211_CHAN_NO_VHT80_80PLUS | \ + IEEE80211_CHAN_NO_VHT80_60PLUS_40MINUS | \ + IEEE80211_CHAN_NO_VHT80_40PLUS_60MINUS | \ + IEEE80211_CHAN_NO_VHT80_80MINUS) + +#define IEEE80211_CHAN_NO_VHT160 \ + (IEEE80211_CHAN_NO_VHT160_160PLUS | \ + IEEE80211_CHAN_NO_VHT160_140PLUS_40MINUS | \ + IEEE80211_CHAN_NO_VHT160_120PLUS_60MINUS | \ + IEEE80211_CHAN_NO_VHT160_100PLUS_80MINUS | \ + IEEE80211_CHAN_NO_VHT160_80PLUS_100MINUS | \ + IEEE80211_CHAN_NO_VHT160_60PLUS_120MINUS | \ + IEEE80211_CHAN_NO_VHT160_40PLUS_140MINUS | \ + IEEE80211_CHAN_NO_VHT160_160MINUS) + /** * struct ieee80211_channel - channel definition * diff --git a/net/wireless/reg.c b/net/wireless/reg.c index 2303ee7..4bb2641 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -877,7 +877,16 @@ static void handle_channel(struct wiphy *wiphy, freq_range = ®_rule->freq_range; if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40)) - bw_flags = IEEE80211_CHAN_NO_HT40; + bw_flags = IEEE80211_CHAN_NO_HT40 | + IEEE80211_CHAN_NO_VHT80 | + IEEE80211_CHAN_NO_VHT160; + + if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(80)) + bw_flags = IEEE80211_CHAN_NO_VHT80 | + IEEE80211_CHAN_NO_VHT160; + + if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(160)) + bw_flags = IEEE80211_CHAN_NO_VHT160; if (last_request->initiator == NL80211_REGDOM_SET_BY_DRIVER && request_wiphy && request_wiphy == wiphy && @@ -1124,6 +1133,166 @@ static void reg_process_beacons(struct wiphy *wiphy) wiphy_update_beacon_reg(wiphy); } +static bool is_vht_not_allowed(struct ieee80211_channel *chan, u32 vht_chbw) +{ + u32 flags; + if (!chan) + return true; + if (chan->flags & IEEE80211_CHAN_DISABLED) + return true; + /* This would happen when regulatory rules disallow 80/160 completely */ + + if (vht_chbw == VHT_CHBW_80) + flags = IEEE80211_CHAN_NO_VHT80; + else if (vht_chbw == VHT_CHBW_160) + flags = IEEE80211_CHAN_NO_VHT160; + else + return true; + + if (flags == (chan->flags & (flags))) + return true; + return false; +} + +static void reg_process_vht_flags_channel(struct wiphy *wiphy, + unsigned int chan_idx, + u32 vht_chbw) +{ + struct ieee80211_supported_band *sband; + struct ieee80211_channel *channel; + struct ieee80211_channel *ext_channels[EXT_CHANS_MAX] = + {NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, + NULL, NULL}; + unsigned int i,j; + int ext_chan_offset; + u32 vht80_flags[VHT_CHBW_80/CHWIDTH_5G] = { + IEEE80211_CHAN_NO_VHT80_80MINUS, + IEEE80211_CHAN_NO_VHT80_40PLUS_60MINUS, + IEEE80211_CHAN_NO_VHT80_60PLUS_40MINUS, + IEEE80211_CHAN_NO_VHT80_80PLUS + }; + u32 vht160_flags[VHT_CHBW_160/CHWIDTH_5G] = { + IEEE80211_CHAN_NO_VHT160_160MINUS, + IEEE80211_CHAN_NO_VHT160_40PLUS_140MINUS, + IEEE80211_CHAN_NO_VHT160_60PLUS_120MINUS, + IEEE80211_CHAN_NO_VHT160_80PLUS_100MINUS, + IEEE80211_CHAN_NO_VHT160_100PLUS_80MINUS, + IEEE80211_CHAN_NO_VHT160_120PLUS_60MINUS, + IEEE80211_CHAN_NO_VHT160_140PLUS_40MINUS, + IEEE80211_CHAN_NO_VHT160_160PLUS + }; + assert_cfg80211_lock(); + + sband = wiphy->bands[IEEE80211_BAND_5GHZ]; + BUG_ON(chan_idx >= sband->n_channels); + BUG_ON((vht_chbw != VHT_CHBW_80) && (vht_chbw != VHT_CHBW_160)); + channel = &sband->channels[chan_idx]; + + if (is_vht_not_allowed(channel, vht_chbw)) { + if (vht_chbw == VHT_CHBW_80) + channel->flags |= IEEE80211_CHAN_NO_VHT80; + else if (vht_chbw == VHT_CHBW_160) + channel->flags |= IEEE80211_CHAN_NO_VHT160; + return; + } + + /* + * We need to ensure the multiple extension channels exist + * to be able to use 80 or 160 MHz bw, this finds them (or not) + * + * Start with extreme below ext channel. + * extreme below for 80 MHz BW will be 80-, 160 MHz BW will be 160- + * extreme above for 80 MHz BW will be 80+, 160 MHz BW will be 160+ + */ + + for (i = 0; i < sband->n_channels; i++) { + struct ieee80211_channel *c = &sband->channels[i]; + + /* + * start with either 80- or 160- + * ext_channels[] array stores all possible ext channels + * for a given VHT channel and channel bandwidth + */ + ext_chan_offset = (CHWIDTH_5G - vht_chbw); + for (j=0; ext_chan_offset <= (vht_chbw - CHWIDTH_5G); + ext_chan_offset += CHWIDTH_5G, j++) { + if (ext_chan_offset == 0) + continue; + if(c->center_freq == + channel->center_freq + ext_chan_offset) + ext_channels[j] = c; + } + } + + /* + * Now that we have found all possible extension channels for + * a given channel and BW, set the channel flags if valid ext channels + * exists. + * + * For 80 Mhz BW, valid ext channels are + * 80- 60- 40- 40+ 60+ 80+ + * + * For 160 MHz BW, valid ext channels are + * 160- 140- 120- 100- 80- 60- 40- 40+ 60+ 80+ 100+ 120+ 140+ 160+. + */ + for (j=0; j < (vht_chbw/CHWIDTH_5G); j++) { + if (vht_chbw == VHT_CHBW_80) { + /* + * For 80 MHz channel bandwidth, ext_channels + * 80-, 60- 40- i.e ext_channels[0], ext_channels[1], + * ext_channels[2] should exist. Next 60-, 40-, 40+ + * should exist and so on. + */ + if (is_vht_not_allowed(ext_channels[j], vht_chbw) && + is_vht_not_allowed(ext_channels[j+1], vht_chbw) && + is_vht_not_allowed(ext_channels[j+2], vht_chbw)) + channel->flags |= vht80_flags[j]; + else + channel->flags &= vht80_flags[j]; + } + + if (vht_chbw == VHT_CHBW_160) { + /* + * For 160 MHz channel bandwidth, ext_channels + * 160-, 140-, 120-, 100-, 80-, 60- 40- means + * ext_channels[0], ext_channels[1], ext_channels[3] + * ext_channels[2], ext_channels[4], ext_channels[5] + * should exist. Next 140-, 120-, 100-, 80-, 60-, + * 40-, 40+ should exist and so on. + */ + if (is_vht_not_allowed(ext_channels[j], vht_chbw) && + is_vht_not_allowed(ext_channels[j+1], vht_chbw) && + is_vht_not_allowed(ext_channels[j+2], vht_chbw) && + is_vht_not_allowed(ext_channels[j+3], vht_chbw) && + is_vht_not_allowed(ext_channels[j+4], vht_chbw) && + is_vht_not_allowed(ext_channels[j+5], vht_chbw)) + channel->flags |= vht160_flags[j]; + else + channel->flags &= vht160_flags[j]; + } + } +} + +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, VHT_CHBW_80); + reg_process_vht_flags_channel(wiphy, i, VHT_CHBW_160); + } +} + static bool is_ht40_not_allowed(struct ieee80211_channel *chan) { if (!chan) @@ -1230,6 +1399,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); } @@ -1296,7 +1466,16 @@ static void handle_channel_custom(struct wiphy *wiphy, freq_range = ®_rule->freq_range; if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40)) - bw_flags = IEEE80211_CHAN_NO_HT40; + bw_flags = IEEE80211_CHAN_NO_HT40 | + IEEE80211_CHAN_NO_VHT80 | + IEEE80211_CHAN_NO_VHT160; + + if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(80)) + bw_flags = IEEE80211_CHAN_NO_VHT80 | + IEEE80211_CHAN_NO_VHT160; + + if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(160)) + bw_flags = IEEE80211_CHAN_NO_VHT160; chan->flags |= map_regdom_flags(reg_rule->flags) | bw_flags; chan->max_antenna_gain = (int) MBI_TO_DBI(power_rule->max_antenna_gain); diff --git a/net/wireless/reg.h b/net/wireless/reg.h index f023c8a..f2ba79a 100644 --- a/net/wireless/reg.h +++ b/net/wireless/reg.h @@ -16,6 +16,11 @@ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ +#define VHT_CHBW_80 80 +#define VHT_CHBW_160 160 +#define CHWIDTH_5G 20 +#define EXT_CHANS_MAX (2*VHT_CHBW_160/CHWIDTH_5G)-2 + extern const struct ieee80211_regdomain *cfg80211_regdomain; bool is_world_regdom(const char *alpha2);
Handling of 80 MHz, 160 MHz channel bandwidths for VHT (11ac) Regulatory and setting channel flags for allowed bandwidths. Signed-off-by: Mahesh Palivela <maheshp@posedge.com> --- Sending patch second time as Stanislaw Gruszka complained its malformed. include/net/cfg80211.h | 64 +++++++++++++++-- net/wireless/reg.c | 183 +++++++++++++++++++++++++++++++++++++++++++++++- net/wireless/reg.h | 5 ++ 3 files changed, 244 insertions(+), 8 deletions(-) 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