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

[Mahesh Palivela <maheshp@posedge.com>]

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