From: Mahesh Palivela <maheshp@posedge.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "linville@tuxdriver.com" <linville@tuxdriver.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] cfg80211: 80MHz (11ac) regulatory change
Date: Tue, 24 Jul 2012 16:18:22 +0530 [thread overview]
Message-ID: <500E7D76.9010205@posedge.com> (raw)
In-Reply-To: <1343120184.4415.16.camel@jlt3.sipsolutions.net>
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
>
next prev parent reply other threads:[~2012-07-24 10:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-23 9:17 [PATCH] cfg80211: 80MHz (11ac) regulatory change Mahesh Palivela
2012-07-23 13:06 ` Johannes Berg
2012-07-24 6:46 ` Mahesh Palivela
2012-07-24 8:56 ` Johannes Berg
2012-07-24 10:48 ` Mahesh Palivela [this message]
2012-07-24 11:17 ` Johannes Berg
2012-07-25 4:01 ` Mahesh Palivela
2012-07-25 9:50 ` Johannes Berg
2012-07-26 6:30 ` Mahesh Palivela
2012-07-26 17:42 ` Johannes Berg
2012-07-30 8:31 ` Mahesh Palivela
2012-07-24 7:12 ` Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=500E7D76.9010205@posedge.com \
--to=maheshp@posedge.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).