linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Mahesh Palivela <maheshp@posedge.com>
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 10:56:24 +0200	[thread overview]
Message-ID: <1343120184.4415.16.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <952C5D5D0470AE4FB7D8A75C6ADC71CA0FCC704B@mbx022-e1-nj-10.exch022.domain.local>

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


  reply	other threads:[~2012-07-24  8:56 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 [this message]
2012-07-24 10:48       ` Mahesh Palivela
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=1343120184.4415.16.camel@jlt3.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=maheshp@posedge.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).