[PATCH] cfg80211: VHT (11ac) Regulatory change

[PATCH] cfg80211: VHT (11ac) Regulatory change

[Mahesh Palivela]

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(-)

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 = &reg_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 = &reg_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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Stanislaw Gruszka]

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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Mahesh Palivela]

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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Stanislaw Gruszka]

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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Mahesh Palivela]

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.
-- 
Thanks,
Mahesh

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Johannes Berg]

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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Kalle Valo]

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.

-- 
Kalle Valo

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Stanislaw Gruszka]

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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Mahesh Palivela]

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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Johannes Berg]

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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Mahesh Palivela]

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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Johannes Berg]

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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Stanislaw Gruszka]

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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Johannes Berg]

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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Stanislaw Gruszka]

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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Mahesh Palivela]

>
> 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;
};

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Johannes Berg]

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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Mahesh Palivela]

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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Johannes Berg]

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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Mahesh Palivela]

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
>

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Mahesh Palivela]

On 08/26/2012 02:09 PM, Johannes Berg wrote:
>
> 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
>
Please review below function if its inline with our email discussion.
---

  include/net/cfg80211.h |   36 +++++++++++++++++
  net/wireless/reg.c     |  103 
++++++++++++++++++++++++++++++++++++++++++++++++
  2 files changed, 139 insertions(+), 0 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 4c518f1..9a17e3d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -83,6 +83,25 @@ enum ieee80211_band {
  };

  /**
+ * enum ieee80211_chan_width - channel bandwidths
+ *
+ * @IEEE80211_CHAN_WIDTH_20MHZ_NOHT: 20 MHz chan bandwidth No HT
+ * @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
+ * @IEEE80211_CHAN_WIDTH_80P80MHZ: 80+80 MHz chan bandwidth
+ */
+enum ieee80211_chan_width {
+	IEEE80211_CHAN_WIDTH_20MHZ_NOHT,
+	IEEE80211_CHAN_WIDTH_20MHZ,
+	IEEE80211_CHAN_WIDTH_40MHZ,
+	IEEE80211_CHAN_WIDTH_80MHZ,
+	IEEE80211_CHAN_WIDTH_160MHZ,
+	IEEE80211_CHAN_WIDTH_80P80MHZ
+};
+
+/**
   * enum ieee80211_channel_flags - channel flags
   *
   * Channel flags set by the regulatory control code.
@@ -144,6 +163,23 @@ struct ieee80211_channel {
  };

  /**
+ * struct ieee80211_channel_config - channel config definition
+ *
+ * This structure describes channel configuration
+ *
+ * @chan_width1: channel bandwidth
+ * @center_freq1: center frequency of 1 st frequency segment
+ * @center_freq2: center frequency of 2 nd frequency segment
+ * @prim_chan_freq: primary channel frequency
+ */
+struct ieee80211_channel_config {
+	enum ieee80211_chan_width chan_width;
+	u16 center_freq1;
+	u16 center_freq2;
+	u16 prim_chan_freq;
+};
+
+/**
   * enum ieee80211_rate_flags - rate flags
   *
   * Hardware/specification flags for rates. These are structured
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 2303ee7..dd13f70 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1124,6 +1124,109 @@ static void reg_process_beacons(struct wiphy *wiphy)
  	wiphy_update_beacon_reg(wiphy);
  }

+static bool reg_sec_chans_permitted(struct wiphy *wiphy,
+				    u32 center_freq)
+				    u32 bw_khz)
+{
+	struct ieee80211_channel *chan;
+	u32 left_end_freq, right_end_freq;
+
+	if (center_freq == 0 || bw_khz == 0)
+		return false;
+
+	/* find left and right arms of center freq */
+	left_end_freq = center_freq - (bw_khz/2);
+	right_end_freq = center_freq + (bw_khz/2);
+
+	/* left_end_freq and right_end_freq are edge of left and right
+	 * channels. Get center freq of left and right channels
+	 * by subtracting 10 MHZ from each of them.
+	 */
+	left_end_freq -= MHZ_TO_KHZ(10);
+	right_end_freq -= MHZ_TO_KHZ(10);
+
+	/* find out all possible secondary channels */
+	while (left_end_freq < right_end_freq) {
+		chan = ieee80211_get_channel(wiphy, left_end_freq);
+		if (chan == NULL ||
+		    chan->flags & IEEE80211_CHAN_DISABLED) {
+			return false;
+		}
+		left_end_freq -= MHZ_TO_KHZ(20);
+	}
+
+	return true;
+}
+bool reg_chan_use_permitted(struct wiphy *wiphy,
+			    struct ieee80211_chan_config *chan_config,
+			    const struct ieee80211_regdomain *regd)
+{
+	int r;
+	u32 desired_bw_khz = MHZ_TO_KHZ(20);
+	const struct ieee80211_reg_rule *reg_rule = NULL;
+	const struct ieee80211_freq_range *freq_range = NULL;
+	bool ret;
+
+	assert_reg_lock();
+
+	// get chan BW from config
+	switch (chan_config->chan_width) {
+	case IEEE80211_CHAN_WIDTH_20MHZ_NOHT:
+	case IEEE80211_CHAN_WIDTH_20MHZ:
+		desired_bw_khz = MHZ_TO_KHZ(20);
+		break;
+
+	case IEEE80211_CHAN_WIDTH_40MHZ:
+		desired_bw_khz = MHZ_TO_KHZ(40);
+		break;
+
+	case IEEE80211_CHAN_WIDTH_80MHZ:
+		desired_bw_khz = MHZ_TO_KHZ(80);
+		break;
+
+	case IEEE80211_CHAN_WIDTH_160MHZ:
+	case IEEE80211_CHAN_WIDTH_80P80MHZ:
+		desired_bw_khz = MHZ_TO_KHZ(160);
+		break;
+	}
+
+	r = freq_reg_info_regd(wiphy,
+			       chan_config->prim_chan_freq,
+			       desired_bw_khz,
+			       &reg_rule,
+			       regd);
+
+	if (r) {
+		REG_DBG_PRINT("Disabling freq %d MHz as custom "
+			      "regd has no rule that fits a %d MHz "
+			      "wide channel\n",
+			      chan_config->prim_chan_freq,
+			      KHZ_TO_MHZ(desired_bw_khz));
+		return false;
+	}
+
+	freq_range = &reg_rule->freq_range;
+
+	if (freq_range->max_bandwidth_khz < desired_bw_khz)
+		return false;
+
+	if (chan_config->chan_width == IEEE80211_CHAN_WIDTH_80P80MHZ) {
+		ret = reg_sec_chans_permitted(wiphy,
+					      chan_config->center_freq1,
+					      desired_bw_khz/2);
+		if (ret == false)
+			return ret;
+		ret = reg_sec_chans_permitted(wiphy,
+					      chan_config->center_freq2,
+					      desired_bw_khz/2);
+	} else {
+		ret = reg_sec_chans_permitted(wiphy,
+					      chan_config->center_freq1,
+					      desired_bw_khz);
+	}
+	return ret;
+}
+
  static bool is_ht40_not_allowed(struct ieee80211_channel *chan)
  {
  	if (!chan)

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Mahesh Palivela]

On 08/27/2012 05:35 PM, Mahesh Palivela wrote:
> On 08/26/2012 02:09 PM, Johannes Berg wrote:
>>
>> 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
>>
> Please review below function if its inline with our email discussion.
> ---
Compiled the code. updated patch. Review the reg_chan_use_permitted().

  include/net/cfg80211.h |   36 ++++++++++++++++
  net/wireless/reg.c     |  104 
++++++++++++++++++++++++++++++++++++++++++++++++
  2 files changed, 140 insertions(+), 0 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 4c518f1..9a17e3d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -83,6 +83,25 @@ enum ieee80211_band {
  };

  /**
+ * enum ieee80211_chan_width - channel bandwidths
+ *
+ * @IEEE80211_CHAN_WIDTH_20MHZ_NOHT: 20 MHz chan bandwidth No HT
+ * @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
+ * @IEEE80211_CHAN_WIDTH_80P80MHZ: 80+80 MHz chan bandwidth
+ */
+enum ieee80211_chan_width {
+	IEEE80211_CHAN_WIDTH_20MHZ_NOHT,
+	IEEE80211_CHAN_WIDTH_20MHZ,
+	IEEE80211_CHAN_WIDTH_40MHZ,
+	IEEE80211_CHAN_WIDTH_80MHZ,
+	IEEE80211_CHAN_WIDTH_160MHZ,
+	IEEE80211_CHAN_WIDTH_80P80MHZ
+};
+
+/**
   * enum ieee80211_channel_flags - channel flags
   *
   * Channel flags set by the regulatory control code.
@@ -144,6 +163,23 @@ struct ieee80211_channel {
  };

  /**
+ * struct ieee80211_channel_config - channel config definition
+ *
+ * This structure describes channel configuration
+ *
+ * @chan_width1: channel bandwidth
+ * @center_freq1: center frequency of 1 st frequency segment
+ * @center_freq2: center frequency of 2 nd frequency segment
+ * @prim_chan_freq: primary channel frequency
+ */
+struct ieee80211_channel_config {
+	enum ieee80211_chan_width chan_width;
+	u16 center_freq1;
+	u16 center_freq2;
+	u16 prim_chan_freq;
+};
+
+/**
   * enum ieee80211_rate_flags - rate flags
   *
   * Hardware/specification flags for rates. These are structured
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 2303ee7..5a4bbe9 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1124,6 +1124,110 @@ static void reg_process_beacons(struct wiphy *wiphy)
  	wiphy_update_beacon_reg(wiphy);
  }

+static bool reg_sec_chans_permitted(struct wiphy *wiphy,
+				    u32 center_freq,
+				    u32 bw_khz)
+{
+	struct ieee80211_channel *chan;
+	u32 left_end_freq, right_end_freq;
+
+	if (center_freq == 0 || bw_khz == 0)
+		return false;
+
+	/* find left and right arms of center freq */
+	left_end_freq = center_freq - (bw_khz/2);
+	right_end_freq = center_freq + (bw_khz/2);
+
+	/* left_end_freq and right_end_freq are edge of left and right
+	 * channels. Get center freq of left and right channels
+	 * by subtracting 10 MHZ from each of them.
+	 */
+	left_end_freq -= MHZ_TO_KHZ(10);
+	right_end_freq -= MHZ_TO_KHZ(10);
+
+	/* find out all possible secondary channels */
+	while (left_end_freq < right_end_freq) {
+		chan = ieee80211_get_channel(wiphy, left_end_freq);
+		if (chan == NULL ||
+		    chan->flags & IEEE80211_CHAN_DISABLED) {
+			return false;
+		}
+		left_end_freq -= MHZ_TO_KHZ(20);
+	}
+
+	return true;
+}
+
+bool reg_chan_use_permitted(struct wiphy *wiphy,
+			    struct ieee80211_channel_config *chan_config,
+			    const struct ieee80211_regdomain *regd)
+{
+	int r;
+	u32 desired_bw_khz = MHZ_TO_KHZ(20);
+	const struct ieee80211_reg_rule *reg_rule = NULL;
+	const struct ieee80211_freq_range *freq_range = NULL;
+	bool ret;
+
+	assert_reg_lock();
+
+	// get chan BW from config
+	switch (chan_config->chan_width) {
+	case IEEE80211_CHAN_WIDTH_20MHZ_NOHT:
+	case IEEE80211_CHAN_WIDTH_20MHZ:
+		desired_bw_khz = MHZ_TO_KHZ(20);
+		break;
+
+	case IEEE80211_CHAN_WIDTH_40MHZ:
+		desired_bw_khz = MHZ_TO_KHZ(40);
+		break;
+
+	case IEEE80211_CHAN_WIDTH_80MHZ:
+		desired_bw_khz = MHZ_TO_KHZ(80);
+		break;
+
+	case IEEE80211_CHAN_WIDTH_160MHZ:
+	case IEEE80211_CHAN_WIDTH_80P80MHZ:
+		desired_bw_khz = MHZ_TO_KHZ(160);
+		break;
+	}
+
+	r = freq_reg_info_regd(wiphy,
+			       chan_config->prim_chan_freq,
+			       desired_bw_khz,
+			       &reg_rule,
+			       regd);
+
+	if (r) {
+		REG_DBG_PRINT("Disabling freq %d MHz as custom "
+			      "regd has no rule that fits a %d MHz "
+			      "wide channel\n",
+			      chan_config->prim_chan_freq,
+			      KHZ_TO_MHZ(desired_bw_khz));
+		return false;
+	}
+
+	freq_range = &reg_rule->freq_range;
+
+	if (freq_range->max_bandwidth_khz < desired_bw_khz)
+		return false;
+
+	if (chan_config->chan_width == IEEE80211_CHAN_WIDTH_80P80MHZ) {
+		ret = reg_sec_chans_permitted(wiphy,
+					      chan_config->center_freq1,
+					      desired_bw_khz/2);
+		if (ret == false)
+			return ret;
+		ret = reg_sec_chans_permitted(wiphy,
+					      chan_config->center_freq2,
+					      desired_bw_khz/2);
+	} else {
+		ret = reg_sec_chans_permitted(wiphy,
+					      chan_config->center_freq1,
+					      desired_bw_khz);
+	}
+	return ret;
+}
+
  static bool is_ht40_not_allowed(struct ieee80211_channel *chan)
  {
  	if (!chan)

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Mahesh Palivela]

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

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Johannes Berg]

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

[PATCH] cfg80211: VHT (11ac) Regulatory change

[Mahesh Palivela]

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>
---

  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 = &reg_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 = &reg_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);

Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Stanislaw Gruszka]

On Tue, Aug 14, 2012 at 01:02:03PM +0530, 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>
> ---
> 
>  include/net/cfg80211.h |   64 +++++++++++++++--
>  net/wireless/reg.c     |  183
> +++++++++++++++++++++++++++++++++++++++++++++++-
>  net/wireless/reg.h     |    5 ++
Patch was malformed by your email client or similar.

Stanislaw