Handling of 80 MHz, 160 MHz channel bandwidths for VHT (11ac) Regulatory
and setting channel flags for allowed bandwidths.
Signed-off-by: Mahesh Palivela <[email protected]>
---
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(-)
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);
Thanks,
Mahesh
On Tue, Aug 21, 2012 at 10:50:13AM +0300, Kalle Valo wrote:
> Johannes Berg <[email protected]> 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
Johannes Berg <[email protected]> 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.
--
Kalle Valo
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
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 <[email protected]> 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
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
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
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 <[email protected]>
> >>---
> >>
> >>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
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
>
> 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;
};
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
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 <[email protected]>
>>>> ---
>>>>
>>>> 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.
--
Thanks,
Mahesh
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 <[email protected]>
>> ---
>>
>> 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
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
>
--
Thanks,
Mahesh
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
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 <[email protected]>
> ---
>
> 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
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
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