Search Linux Wireless

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux