[PATCH] cfg80211: 80MHz (11ac) regulatory change

[PATCH] cfg80211: 80MHz (11ac) regulatory change

[Mahesh Palivela]

80MHz Regulatory changes for 11ac.

Signed-off-by: Mahesh Palivela <maheshp@posedge.com>
---
 include/net/cfg80211.h |    8 +++++
 net/wireless/reg.c     |   76 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 84 insertions(+), 0 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 493fa0c..bde0fee 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -104,10 +104,18 @@ enum ieee80211_channel_flags {
 	IEEE80211_CHAN_RADAR		= 1<<3,
 	IEEE80211_CHAN_NO_HT40PLUS	= 1<<4,
 	IEEE80211_CHAN_NO_HT40MINUS	= 1<<5,
+	IEEE80211_CHAN_NO_VHT80PLUS	= 1<<6,
+	IEEE80211_CHAN_NO_VHT80MINUS	= 1<<7,
+	IEEE80211_CHAN_NO_VHT160PLUS	= 1<<8,
+	IEEE80211_CHAN_NO_VHT160MINUS	= 1<<9,
 };
 
 #define IEEE80211_CHAN_NO_HT40 \
 	(IEEE80211_CHAN_NO_HT40PLUS | IEEE80211_CHAN_NO_HT40MINUS)
+#define IEEE80211_CHAN_NO_VHT80 \
+	(IEEE80211_CHAN_NO_VHT80PLUS | IEEE80211_CHAN_NO_VHT80MINUS)
+#define IEEE80211_CHAN_NO_VHT160 \
+	(IEEE80211_CHAN_NO_VHT160PLUS | IEEE80211_CHAN_NO_VHT160MINUS)
 
 /**
  * struct ieee80211_channel - channel definition
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 2303ee7..0ad6c15 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1124,6 +1124,81 @@ static void reg_process_beacons(struct wiphy *wiphy)
 	wiphy_update_beacon_reg(wiphy);
 }
 
+static bool is_vht80_not_allowed(struct ieee80211_channel *chan)
+{
+	if (!chan)
+		return true;
+	if (chan->flags & IEEE80211_CHAN_DISABLED)
+		return true;
+	/* This would happen when regulatory rules disallow VHT80 completely */
+	if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & (IEEE80211_CHAN_NO_VHT80)))
+		return true;
+	return false;
+}
+
+static void reg_process_vht_flags_channel(struct wiphy *wiphy,
+					 unsigned int chan_idx)
+{
+	struct ieee80211_supported_band *sband;
+	struct ieee80211_channel *channel;
+	struct ieee80211_channel *channel_before = NULL, *channel_after = NULL;
+	unsigned int i;
+
+	assert_cfg80211_lock();
+
+	sband = wiphy->bands[IEEE80211_BAND_5GHZ];
+	BUG_ON(chan_idx >= sband->n_channels);
+	channel = &sband->channels[chan_idx];
+
+	if (is_vht80_not_allowed(channel)) {
+		channel->flags |= IEEE80211_CHAN_NO_VHT80;
+		return;
+	}
+
+	/*
+	 * We need to ensure the extension channels exist to
+	 * be able to use VHT80- or VHT80+, this finds them (or not)
+	 */
+	for (i = 0; i < sband->n_channels; i++) {
+		struct ieee80211_channel *c = &sband->channels[i];
+		if (c->center_freq == (channel->center_freq - 40))
+			channel_before = c;
+		if (c->center_freq == (channel->center_freq + 40))
+			channel_after = c;
+	}
+
+	/*
+	 * Please note that this assumes target bandwidth is 40 MHz,
+	 * if that ever changes we also need to change the below logic
+	 * to include that as well.
+	 */
+	if (is_vht80_not_allowed(channel_before))
+		channel->flags |= IEEE80211_CHAN_NO_VHT80MINUS;
+	else
+		channel->flags &= ~IEEE80211_CHAN_NO_VHT80MINUS;
+
+	if (is_vht80_not_allowed(channel_after))
+		channel->flags |= IEEE80211_CHAN_NO_VHT80PLUS;
+	else
+		channel->flags &= ~IEEE80211_CHAN_NO_VHT80PLUS;
+}
+
+static void reg_process_vht_flags(struct wiphy *wiphy)
+{
+	unsigned int i;
+	struct ieee80211_supported_band *sband;
+
+	if(!wiphy->bands[IEEE80211_BAND_5GHZ]) {
+		/* 5GHz band is not supported, which is 
+		 * mandatory for VHT. so simply return */
+		return;
+	}
+	sband = wiphy->bands[IEEE80211_BAND_5GHZ];
+
+	for (i = 0; i < sband->n_channels; i++)
+		reg_process_vht_flags_channel(wiphy, i);
+}
+
 static bool is_ht40_not_allowed(struct ieee80211_channel *chan)
 {
 	if (!chan)
@@ -1230,6 +1305,7 @@ static void wiphy_update_regulatory(struct wiphy *wiphy,
 
 	reg_process_beacons(wiphy);
 	reg_process_ht_flags(wiphy);
+	reg_process_vht_flags(wiphy);
 	if (wiphy->reg_notifier)
 		wiphy->reg_notifier(wiphy, last_request);
 }

Re: [PATCH] cfg80211: 80MHz (11ac) regulatory change

[Johannes Berg]

> +	IEEE80211_CHAN_NO_VHT80PLUS	= 1<<6,
> +	IEEE80211_CHAN_NO_VHT80MINUS	= 1<<7,
> +	IEEE80211_CHAN_NO_VHT160PLUS	= 1<<8,
> +	IEEE80211_CHAN_NO_VHT160MINUS	= 1<<9,

How are we going to handle 80+80?

Also, I believe there are many more possibilities, since we count from
the control channel -- ie. for HT HT40+ means secondary channel is above
the control channel. For VHT 80, you're going to have 4 possibilities:

|-1-|-2-|-3-|-4-|

the control channel can be any one of these four I believe? So you'd
have configurations like

VHT_CHAN_LAYOUT_0_3
VHT_CHAN_LAYOUT_1_2
VHT_CHAN_LAYOUT_2_1
VHT_CHAN_LAYOUT_3_0

indicating the number of channels below/above control (for control
channel 1,2,3,4 respectively). Similarly, for VHT160 you'd have 8
possibilities:

|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|

(which one could again capture as VHT_CHAN_LAYOUT_0_7 etc.)


> +static bool is_vht80_not_allowed(struct ieee80211_channel *chan)
> +{
> +	if (!chan)
> +		return true;
> +	if (chan->flags & IEEE80211_CHAN_DISABLED)
> +		return true;
> +	/* This would happen when regulatory rules disallow VHT80 completely */
> +	if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & (IEEE80211_CHAN_NO_VHT80)))
> +		return true;

Is that really right? Need to document what the return value of this
function should be, I guess?


> +static void reg_process_vht_flags_channel(struct wiphy *wiphy,
> +					 unsigned int chan_idx)
> +{
> +	struct ieee80211_supported_band *sband;
> +	struct ieee80211_channel *channel;
> +	struct ieee80211_channel *channel_before = NULL, *channel_after = NULL;
> +	unsigned int i;
> +
> +	assert_cfg80211_lock();
> +
> +	sband = wiphy->bands[IEEE80211_BAND_5GHZ];
> +	BUG_ON(chan_idx >= sband->n_channels);
> +	channel = &sband->channels[chan_idx];
> +
> +	if (is_vht80_not_allowed(channel)) {
> +		channel->flags |= IEEE80211_CHAN_NO_VHT80;
> +		return;
> +	}
> +
> +	/*
> +	 * We need to ensure the extension channels exist to
> +	 * be able to use VHT80- or VHT80+, this finds them (or not)
> +	 */
> +	for (i = 0; i < sband->n_channels; i++) {
> +		struct ieee80211_channel *c = &sband->channels[i];
> +		if (c->center_freq == (channel->center_freq - 40))
> +			channel_before = c;
> +		if (c->center_freq == (channel->center_freq + 40))
> +			channel_after = c;
> +	}
> +
> +	/*
> +	 * Please note that this assumes target bandwidth is 40 MHz,
> +	 * if that ever changes we also need to change the below logic
> +	 * to include that as well.
> +	 */

???

johannes

RE: [PATCH] cfg80211: 80MHz (11ac) regulatory change

[Mahesh Palivela]

________________________________________
From: Johannes Berg [johannes@sipsolutions.net]
Sent: Monday, July 23, 2012 6:36 PM
To: Mahesh Palivela
Cc: linville@tuxdriver.com; linux-wireless@vger.kernel.org
Subject: Re: [PATCH] cfg80211: 80MHz (11ac) regulatory change

> +     IEEE80211_CHAN_NO_VHT80PLUS     = 1<<6,
> +     IEEE80211_CHAN_NO_VHT80MINUS    = 1<<7,
> +     IEEE80211_CHAN_NO_VHT160PLUS    = 1<<8,
> +     IEEE80211_CHAN_NO_VHT160MINUS   = 1<<9,

How are we going to handle 80+80?

[MP] This is a future item. Get to this at a later time.

Also, I believe there are many more possibilities, since we count from
the control channel -- ie. for HT HT40+ means secondary channel is above
the control channel. For VHT 80, you're going to have 4 possibilities:

|-1-|-2-|-3-|-4-|

the control channel can be any one of these four I believe? So you'd
have configurations like

VHT_CHAN_LAYOUT_0_3
VHT_CHAN_LAYOUT_1_2
VHT_CHAN_LAYOUT_2_1
VHT_CHAN_LAYOUT_3_0

indicating the number of channels below/above control (for control
channel 1,2,3,4 respectively). Similarly, for VHT160 you'd have 8
possibilities:

|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|

(which one could again capture as VHT_CHAN_LAYOUT_0_7 etc.)

[MP] I see your point. But according to 11ac spec, AP will use primary chan as specified in HT operation IE chan num. Secondary channel is center freq specified in VHT Operation IE. So I am thinking secondary channel is not relative offset to primary channel. Hope I am not mistaken here.

> +static bool is_vht80_not_allowed(struct ieee80211_channel *chan)
> +{
> +     if (!chan)
> +             return true;
> +     if (chan->flags & IEEE80211_CHAN_DISABLED)
> +             return true;
> +     /* This would happen when regulatory rules disallow VHT80 completely */
> +     if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & (IEEE80211_CHAN_NO_VHT80)))
> +             return true;

Is that really right? Need to document what the return value of this
function should be, I guess?

[MP] I guess, it's possible for a channel not allowed for 80Mhz operation.

> +static void reg_process_vht_flags_channel(struct wiphy *wiphy,
> +                                      unsigned int chan_idx)
> +{
> +     struct ieee80211_supported_band *sband;
> +     struct ieee80211_channel *channel;
> +     struct ieee80211_channel *channel_before = NULL, *channel_after = NULL;
> +     unsigned int i;
> +
> +     assert_cfg80211_lock();
> +
> +     sband = wiphy->bands[IEEE80211_BAND_5GHZ];
> +     BUG_ON(chan_idx >= sband->n_channels);
> +     channel = &sband->channels[chan_idx];
> +
> +     if (is_vht80_not_allowed(channel)) {
> +             channel->flags |= IEEE80211_CHAN_NO_VHT80;
> +             return;
> +     }
> +
> +     /*
> +      * We need to ensure the extension channels exist to
> +      * be able to use VHT80- or VHT80+, this finds them (or not)
> +      */
> +     for (i = 0; i < sband->n_channels; i++) {
> +             struct ieee80211_channel *c = &sband->channels[i];
> +             if (c->center_freq == (channel->center_freq - 40))
> +                     channel_before = c;
> +             if (c->center_freq == (channel->center_freq + 40))
> +                     channel_after = c;
> +     }
> +
> +     /*
> +      * Please note that this assumes target bandwidth is 40 MHz,
> +      * if that ever changes we also need to change the below logic
> +      * to include that as well.
> +      */

???

[MP] Can you explain? This function doesn't make any sense?

johannes

Re: [PATCH] cfg80211: 80MHz (11ac) regulatory change

[Kalle Valo]

Mahesh Palivela <maheshp@posedge.com> writes:

> 80MHz Regulatory changes for 11ac.
>
> Signed-off-by: Mahesh Palivela <maheshp@posedge.com>

[...]

> +static bool is_vht80_not_allowed(struct ieee80211_channel *chan)
> +{
> +	if (!chan)
> +		return true;
> +	if (chan->flags & IEEE80211_CHAN_DISABLED)
> +		return true;
> +	/* This would happen when regulatory rules disallow VHT80 completely */
> +	if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & (IEEE80211_CHAN_NO_VHT80)))
> +		return true;
> +	return false;
> +}

I think it's better to change this to is_vht80_allowed(). The
not_allowed might trick someone.

-- 
Kalle Valo

Re: [PATCH] cfg80211: 80MHz (11ac) regulatory change

[Johannes Berg]

It would be really good if you could convince your email client to put >
in front of each quoted line ... this is really confusing as is.

> Also, I believe there are many more possibilities, since we count from
> the control channel -- ie. for HT HT40+ means secondary channel is above
> the control channel. For VHT 80, you're going to have 4 possibilities:
> 
> |-1-|-2-|-3-|-4-|
> 
> the control channel can be any one of these four I believe? So you'd
> have configurations like
> 
> VHT_CHAN_LAYOUT_0_3
> VHT_CHAN_LAYOUT_1_2
> VHT_CHAN_LAYOUT_2_1
> VHT_CHAN_LAYOUT_3_0
> 
> indicating the number of channels below/above control (for control
> channel 1,2,3,4 respectively). Similarly, for VHT160 you'd have 8
> possibilities:
> 
> |-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|
> 
> (which one could again capture as VHT_CHAN_LAYOUT_0_7 etc.)
> 
> [MP] I see your point. But according to 11ac spec, AP will use primary
> chan as specified in HT operation IE chan num. Secondary channel is
> center freq specified in VHT Operation IE. So I am thinking secondary
> channel is not relative offset to primary channel. Hope I am not
> mistaken here.

Ok so HT has primary channel and secondary, and VHT has secondary VHT
which can again be above/below? That would make sense, but you wouldn't
be covering it.

> > +     /* This would happen when regulatory rules disallow VHT80 completely */
> > +     if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & (IEEE80211_CHAN_NO_VHT80)))
> > +             return true;
> 
> Is that really right? Need to document what the return value of this
> function should be, I guess?
> 
> [MP] I guess, it's possible for a channel not allowed for 80Mhz operation.

Yeah but should it really check *all* the bits rather than any one of
them?

> > +     /*
> > +      * Please note that this assumes target bandwidth is 40 MHz,
> > +      * if that ever changes we also need to change the below logic
> > +      * to include that as well.
> > +      */
> 
> ???
> 
> [MP] Can you explain? This function doesn't make any sense?

The comment about 40 MHz doesn't make any sense.

johannes

Re: [PATCH] cfg80211: 80MHz (11ac) regulatory change

[Mahesh Palivela]

On 07/24/2012 02:26 PM, Johannes Berg wrote:
> It would be really good if you could convince your email client to put >
> in front of each quoted line ... this is really confusing as is.
>

Sorry. Switched to thunderbird now.

>> Also, I believe there are many more possibilities, since we count from
>> the control channel -- ie. for HT HT40+ means secondary channel is above
>> the control channel. For VHT 80, you're going to have 4 possibilities:
>>
>> |-1-|-2-|-3-|-4-|
>>
>> the control channel can be any one of these four I believe? So you'd
>> have configurations like
>>
>> VHT_CHAN_LAYOUT_0_3
>> VHT_CHAN_LAYOUT_1_2
>> VHT_CHAN_LAYOUT_2_1
>> VHT_CHAN_LAYOUT_3_0
>>
>> indicating the number of channels below/above control (for control
>> channel 1,2,3,4 respectively). Similarly, for VHT160 you'd have 8
>> possibilities:
>>
>> |-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|
>>
>> (which one could again capture as VHT_CHAN_LAYOUT_0_7 etc.)
>>
>> [MP] I see your point. But according to 11ac spec, AP will use primary
>> chan as specified in HT operation IE chan num. Secondary channel is
>> center freq specified in VHT Operation IE. So I am thinking secondary
>> channel is not relative offset to primary channel. Hope I am not
>> mistaken here.
>
> Ok so HT has primary channel and secondary, and VHT has secondary VHT
> which can again be above/below? That would make sense, but you wouldn't
> be covering it.
>

I am thinking no need of above/below convention as the center frequency 
value itself we know.

>>> +     /* This would happen when regulatory rules disallow VHT80 completely */
>>> +     if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & (IEEE80211_CHAN_NO_VHT80)))
>>> +             return true;
>>
>> Is that really right? Need to document what the return value of this
>> function should be, I guess?
>>
>> [MP] I guess, it's possible for a channel not allowed for 80Mhz operation.
>
> Yeah but should it really check *all* the bits rather than any one of
> them?
>

You mean to say other bits like HT40MINUS, HT40PLUS or even DFS?

>>> +     /*
>>> +      * Please note that this assumes target bandwidth is 40 MHz,
>>> +      * if that ever changes we also need to change the below logic
>>> +      * to include that as well.
>>> +      */
>>
>> ???
>>
>> [MP] Can you explain? This function doesn't make any sense?
>
> The comment about 40 MHz doesn't make any sense.
>

Agree. I will change this.

> johannes
>

Re: [PATCH] cfg80211: 80MHz (11ac) regulatory change

[Johannes Berg]

On Tue, 2012-07-24 at 16:18 +0530, Mahesh Palivela wrote:

> >> indicating the number of channels below/above control (for control
> >> channel 1,2,3,4 respectively). Similarly, for VHT160 you'd have 8
> >> possibilities:
> >>
> >> |-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|
> >>
> >> (which one could again capture as VHT_CHAN_LAYOUT_0_7 etc.)
> >>
> >> [MP] I see your point. But according to 11ac spec, AP will use primary
> >> chan as specified in HT operation IE chan num. Secondary channel is
> >> center freq specified in VHT Operation IE. So I am thinking secondary
> >> channel is not relative offset to primary channel. Hope I am not
> >> mistaken here.
> >
> > Ok so HT has primary channel and secondary, and VHT has secondary VHT
> > which can again be above/below? That would make sense, but you wouldn't
> > be covering it.
> >
> 
> I am thinking no need of above/below convention as the center frequency 
> value itself we know.

But we don't use the center frequency of the overall Ht40/80/160
channel, we always use the center frequency of the control channel.

> >>> +     /* This would happen when regulatory rules disallow VHT80 completely */
> >>> +     if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & (IEEE80211_CHAN_NO_VHT80)))
> >>> +             return true;
> >>
> >> Is that really right? Need to document what the return value of this
> >> function should be, I guess?
> >>
> >> [MP] I guess, it's possible for a channel not allowed for 80Mhz operation.
> >
> > Yeah but should it really check *all* the bits rather than any one of
> > them?
> >
> 
> You mean to say other bits like HT40MINUS, HT40PLUS or even DFS?

No, I mean all the bits that are part of CHAN_NO_VHT80.

johannes

Re: [PATCH] cfg80211: 80MHz (11ac) regulatory change

[Mahesh Palivela]

On 07/24/2012 04:47 PM, Johannes Berg wrote:
> On Tue, 2012-07-24 at 16:18 +0530, Mahesh Palivela wrote:
>
>>>> indicating the number of channels below/above control (for control
>>>> channel 1,2,3,4 respectively). Similarly, for VHT160 you'd have 8
>>>> possibilities:
>>>>
>>>> |-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|
>>>>
>>>> (which one could again capture as VHT_CHAN_LAYOUT_0_7 etc.)
>>>>
>>>> [MP] I see your point. But according to 11ac spec, AP will use primary
>>>> chan as specified in HT operation IE chan num. Secondary channel is
>>>> center freq specified in VHT Operation IE. So I am thinking secondary
>>>> channel is not relative offset to primary channel. Hope I am not
>>>> mistaken here.
>>>
>>> Ok so HT has primary channel and secondary, and VHT has secondary VHT
>>> which can again be above/below? That would make sense, but you wouldn't
>>> be covering it.
>>>
>>
>> I am thinking no need of above/below convention as the center frequency
>> value itself we know.
>
> But we don't use the center frequency of the overall Ht40/80/160
> channel, we always use the center frequency of the control channel.
>

11ac Draft3.0 section 22.3.14 says VHT channel is specified by
dot11CurrentChannelBandwidth, dot11CurrentChannelCenterFrequencyIndex0,
dot11CurrentChannelCenterFrequencyIndex1 and dot11CurrentPrimaryChannel

primary channel comes from HT Op IE.
chanBW, chanCenterFreq0, chanCenterFreq1 comes from VHT Op IE.
So multiple secondary channels doesn't seem to be a valid?

>>>>> +     /* This would happen when regulatory rules disallow VHT80 completely */
>>>>> +     if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & (IEEE80211_CHAN_NO_VHT80)))
>>>>> +             return true;
>>>>
>>>> Is that really right? Need to document what the return value of this
>>>> function should be, I guess?
>>>>
>>>> [MP] I guess, it's possible for a channel not allowed for 80Mhz operation.
>>>
>>> Yeah but should it really check *all* the bits rather than any one of
>>> them?
>>>
>>
>> You mean to say other bits like HT40MINUS, HT40PLUS or even DFS?
>
> No, I mean all the bits that are part of CHAN_NO_VHT80.
>


CHAN_NO_VHT80 is actually 2 bits. NO_VHT80MINUS & NO_VHT80PLUS.
Is that ok?

+	IEEE80211_CHAN_NO_VHT80PLUS	= 1<<6,
+	IEEE80211_CHAN_NO_VHT80MINUS	= 1<<7,

+#define IEEE80211_CHAN_NO_VHT80 \
+	(IEEE80211_CHAN_NO_VHT80PLUS | IEEE80211_CHAN_NO_VHT80MINUS)

> johannes
>

Thanks,
Mahesh

Re: [PATCH] cfg80211: 80MHz (11ac) regulatory change

[Johannes Berg]

On Wed, 2012-07-25 at 09:31 +0530, Mahesh Palivela wrote:

> >>> Ok so HT has primary channel and secondary, and VHT has secondary VHT
> >>> which can again be above/below? That would make sense, but you wouldn't
> >>> be covering it.
> >>>
> >>
> >> I am thinking no need of above/below convention as the center frequency
> >> value itself we know.
> >
> > But we don't use the center frequency of the overall Ht40/80/160
> > channel, we always use the center frequency of the control channel.
> >
> 
> 11ac Draft3.0 section 22.3.14 says VHT channel is specified by
> dot11CurrentChannelBandwidth, dot11CurrentChannelCenterFrequencyIndex0,
> dot11CurrentChannelCenterFrequencyIndex1 and dot11CurrentPrimaryChannel
> 
> primary channel comes from HT Op IE.
> chanBW, chanCenterFreq0, chanCenterFreq1 comes from VHT Op IE.
> So multiple secondary channels doesn't seem to be a valid?

Hmm. But that means we have to specify the channel completely
differently? I think we should stick to our scheme of center freq of a
20 MHz channel + surrounding bandwidth, though it obviously won't work
for 80+80. The question will be where we deviate from our previous
scheme. I tend to think that HT80+80 should deviate, I have a feeling it
won't be implemented soon (or ever?) anyway.

> > No, I mean all the bits that are part of CHAN_NO_VHT80.
> >
> 
> 
> CHAN_NO_VHT80 is actually 2 bits. NO_VHT80MINUS & NO_VHT80PLUS.
> Is that ok?
> 
> +	IEEE80211_CHAN_NO_VHT80PLUS	= 1<<6,
> +	IEEE80211_CHAN_NO_VHT80MINUS	= 1<<7,
> 
> +#define IEEE80211_CHAN_NO_VHT80 \
> +	(IEEE80211_CHAN_NO_VHT80PLUS | IEEE80211_CHAN_NO_VHT80MINUS)

Right. But did you mean to check that all of them are set? What if one
of them is set but the other isn't?

johannes

Re: [PATCH] cfg80211: 80MHz (11ac) regulatory change

[Mahesh Palivela]

On 07/25/2012 03:20 PM, Johannes Berg wrote:
> On Wed, 2012-07-25 at 09:31 +0530, Mahesh Palivela wrote:
>
>>>>> Ok so HT has primary channel and secondary, and VHT has secondary VHT
>>>>> which can again be above/below? That would make sense, but you wouldn't
>>>>> be covering it.
>>>>>
>>>>
>>>> I am thinking no need of above/below convention as the center frequency
>>>> value itself we know.
>>>
>>> But we don't use the center frequency of the overall Ht40/80/160
>>> channel, we always use the center frequency of the control channel.
>>>
>>
>> 11ac Draft3.0 section 22.3.14 says VHT channel is specified by
>> dot11CurrentChannelBandwidth, dot11CurrentChannelCenterFrequencyIndex0,
>> dot11CurrentChannelCenterFrequencyIndex1 and dot11CurrentPrimaryChannel
>>
>> primary channel comes from HT Op IE.
>> chanBW, chanCenterFreq0, chanCenterFreq1 comes from VHT Op IE.
>> So multiple secondary channels doesn't seem to be a valid?
>
> Hmm. But that means we have to specify the channel completely
> differently? I think we should stick to our scheme of center freq of a
> 20 MHz channel + surrounding bandwidth,

ok. Let's stick to old way of channel config. Basically freq value and 
channel type which kind of specifies channel widths. so how about for 
VHT channel types as below. Its similar to what you proposed.

For 80 MHz:

VHT80_3PLUS
VHT80_MINUS_2PLUS
VHT80_2MINUS_PLUS
VHT80_3MINUS

For 160 MHz:

VHT160_7PLUS
VHT160_MINUS_6PLUS
VHT160_2MINUS_5PLUS
VHT160_3MINUS_4PLUS
VHT160_4MINUS_3PLUS
VHT160_5MINUS_2PLUS
VHT160_6MINUS_PLUS
VHT160_7MINUS

 > though it obviously won't work for 80+80. The question will be where 
 > we deviate from our previous scheme. I tend to think that HT80+80
 > should deviate, I have a feeling it won't be implemented soon
 > (or ever?) anyway.
 >

Yea, even I feel the channel config representation what we are proposing 
is not really extendable to discrete bands. That's my only worry...

>>> No, I mean all the bits that are part of CHAN_NO_VHT80.
>>>
>>
>>
>> CHAN_NO_VHT80 is actually 2 bits. NO_VHT80MINUS & NO_VHT80PLUS.
>> Is that ok?
>>
>> +	IEEE80211_CHAN_NO_VHT80PLUS	= 1<<6,
>> +	IEEE80211_CHAN_NO_VHT80MINUS	= 1<<7,
>>
>> +#define IEEE80211_CHAN_NO_VHT80 \
>> +	(IEEE80211_CHAN_NO_VHT80PLUS | IEEE80211_CHAN_NO_VHT80MINUS)
>
> Right. But did you mean to check that all of them are set? What if one
> of them is set but the other isn't?
>

If one of them is set, then we accept VHT80 for that channel.

> johannes
>

- Mahesh

Re: [PATCH] cfg80211: 80MHz (11ac) regulatory change

[Johannes Berg]

On Thu, 2012-07-26 at 12:00 +0530, Mahesh Palivela wrote:

> >> 11ac Draft3.0 section 22.3.14 says VHT channel is specified by
> >> dot11CurrentChannelBandwidth, dot11CurrentChannelCenterFrequencyIndex0,
> >> dot11CurrentChannelCenterFrequencyIndex1 and dot11CurrentPrimaryChannel
> >>
> >> primary channel comes from HT Op IE.
> >> chanBW, chanCenterFreq0, chanCenterFreq1 comes from VHT Op IE.
> >> So multiple secondary channels doesn't seem to be a valid?
> >
> > Hmm. But that means we have to specify the channel completely
> > differently? I think we should stick to our scheme of center freq of a
> > 20 MHz channel + surrounding bandwidth,
> 
> ok. Let's stick to old way of channel config. Basically freq value and 
> channel type which kind of specifies channel widths. so how about for 
> VHT channel types as below. Its similar to what you proposed.
> 
> For 80 MHz:
> 
> VHT80_3PLUS
> VHT80_MINUS_2PLUS
> VHT80_2MINUS_PLUS
> VHT80_3MINUS
> 
> For 160 MHz:
> 
> VHT160_7PLUS
> VHT160_MINUS_6PLUS
> VHT160_2MINUS_5PLUS
> VHT160_3MINUS_4PLUS
> VHT160_4MINUS_3PLUS
> VHT160_5MINUS_2PLUS
> VHT160_6MINUS_PLUS
> VHT160_7MINUS

Yeah, that would work. Lots of channel types ...

>  > though it obviously won't work for 80+80. The question will be where 
>  > we deviate from our previous scheme. I tend to think that HT80+80
>  > should deviate, I have a feeling it won't be implemented soon
>  > (or ever?) anyway.
>  >
> 
> Yea, even I feel the channel config representation what we are proposing 
> is not really extendable to discrete bands. That's my only worry...

? What do you mean?

> >> CHAN_NO_VHT80 is actually 2 bits. NO_VHT80MINUS & NO_VHT80PLUS.
> >> Is that ok?
> >>
> >> +	IEEE80211_CHAN_NO_VHT80PLUS	= 1<<6,
> >> +	IEEE80211_CHAN_NO_VHT80MINUS	= 1<<7,
> >>
> >> +#define IEEE80211_CHAN_NO_VHT80 \
> >> +	(IEEE80211_CHAN_NO_VHT80PLUS | IEEE80211_CHAN_NO_VHT80MINUS)
> >
> > Right. But did you mean to check that all of them are set? What if one
> > of them is set but the other isn't?
> >
> 
> If one of them is set, then we accept VHT80 for that channel.

Yes, but is that really correct?

johannes

Re: [PATCH] cfg80211: 80MHz (11ac) regulatory change

[Mahesh Palivela]

On 7/26/2012 11:12 PM, Johannes Berg wrote:
> On Thu, 2012-07-26 at 12:00 +0530, Mahesh Palivela wrote:
>
>>>> 11ac Draft3.0 section 22.3.14 says VHT channel is specified by
>>>> dot11CurrentChannelBandwidth, dot11CurrentChannelCenterFrequencyIndex0,
>>>> dot11CurrentChannelCenterFrequencyIndex1 and dot11CurrentPrimaryChannel
>>>>
>>>> primary channel comes from HT Op IE.
>>>> chanBW, chanCenterFreq0, chanCenterFreq1 comes from VHT Op IE.
>>>> So multiple secondary channels doesn't seem to be a valid?
>>>
>>> Hmm. But that means we have to specify the channel completely
>>> differently? I think we should stick to our scheme of center freq of a
>>> 20 MHz channel + surrounding bandwidth,
>>
>> ok. Let's stick to old way of channel config. Basically freq value and
>> channel type which kind of specifies channel widths. so how about for
>> VHT channel types as below. Its similar to what you proposed.
>>
>> For 80 MHz:
>>
>> VHT80_3PLUS
>> VHT80_MINUS_2PLUS
>> VHT80_2MINUS_PLUS
>> VHT80_3MINUS
>>
>> For 160 MHz:
>>
>> VHT160_7PLUS
>> VHT160_MINUS_6PLUS
>> VHT160_2MINUS_5PLUS
>> VHT160_3MINUS_4PLUS
>> VHT160_4MINUS_3PLUS
>> VHT160_5MINUS_2PLUS
>> VHT160_6MINUS_PLUS
>> VHT160_7MINUS
>
> Yeah, that would work. Lots of channel types ...
>

Yea, So I am thinking how about passing channel width and secondary 
channel center frequency from which we know chan_below or chan_above, 
instead of channel_type.

>>   > though it obviously won't work for 80+80. The question will be where
>>   > we deviate from our previous scheme. I tend to think that HT80+80
>>   > should deviate, I have a feeling it won't be implemented soon
>>   > (or ever?) anyway.
>>   >
>>
>> Yea, even I feel the channel config representation what we are proposing
>> is not really extendable to discrete bands. That's my only worry...
>
> ? What do you mean?
>

I mean 80+80 scenario is not possible to represent.

>>>> CHAN_NO_VHT80 is actually 2 bits. NO_VHT80MINUS & NO_VHT80PLUS.
>>>> Is that ok?
>>>>
>>>> +	IEEE80211_CHAN_NO_VHT80PLUS	= 1<<6,
>>>> +	IEEE80211_CHAN_NO_VHT80MINUS	= 1<<7,
>>>>
>>>> +#define IEEE80211_CHAN_NO_VHT80 \
>>>> +	(IEEE80211_CHAN_NO_VHT80PLUS | IEEE80211_CHAN_NO_VHT80MINUS)
>>>
>>> Right. But did you mean to check that all of them are set? What if one
>>> of them is set but the other isn't?
>>>
>>
>> If one of them is set, then we accept VHT80 for that channel.
>
> Yes, but is that really correct?
>

I think so. If one of the configuration is allowed we can perform VHT80 
operation.

> johannes
>

Thanks,
Mahesh