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: Stanislaw Gruszka <sgruszka@redhat.com>,
	Kalle Valo <kvalo@adurom.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"linville@tuxdriver.com" <linville@tuxdriver.com>
Subject: Re: [PATCH] cfg80211: VHT (11ac) Regulatory change
Date: Tue, 21 Aug 2012 17:53:41 +0200	[thread overview]
Message-ID: <1345564421.10280.9.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <50338E84.3050709@posedge.com>

On Tue, 2012-08-21 at 19:05 +0530, Mahesh Palivela wrote:

> so we are talking about how to specify channel info to cfg/mac80211 from 
> upper layers. 

Correct

> But regulatory tells if that channel config is allowed or not.

Correct.

> so derive channel type from center freq, width and control chan offset.
> Then determine if that channel type is allowed from regulatory flags?
> 
> In short we have scaled approach on specifying channel info but not 
> regulatory. Please comment.

Well, we don't really have it yet :-)

I think the question really is whether or not we actually need the
flags. Sometimes, but very rarely really, we need to answer the question

        Is this set of parameters allowed with the current regulatory
        rules?

There's nothing that says this needs to be a flag. It could just as well
be a function

bool regulatory_chan_use_permitted(...);

where the ... gives all the necessary parameters or maybe some structure
holding all these.

If this was a function, it could go back to the regulatory definitions
(that we hopefully keep track of in the kernel) and actually use the
algorithm that today we use to determine the flags to determine the
answer.

Today, with the flags, we basically pre-determine the answers to all
possible such questions, and encode the answers in the flags for each
channel. If we don't pre-determine the answers, then we can get away
without any flags at all.

Does that make sense?

Still doesn't solve the problems we saw with how to configure the
channel with considerations such as
  - bandwidth
  - center frequency
  - primary subchannel
  - 80 + 80 (which is basically two such channels?)

johannes


  reply	other threads:[~2012-08-21 15:53 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-14 15:55 [PATCH] cfg80211: VHT (11ac) Regulatory change Mahesh Palivela
2012-08-16 10:22 ` Stanislaw Gruszka
2012-08-16 13:17   ` Mahesh Palivela
2012-08-17 14:06     ` Stanislaw Gruszka
2012-08-17 17:56       ` Mahesh Palivela
2012-08-20 16:38         ` Johannes Berg
2012-08-21  7:50           ` Kalle Valo
2012-08-21  8:18             ` Stanislaw Gruszka
2012-08-21 13:35               ` Mahesh Palivela
2012-08-21 15:53                 ` Johannes Berg [this message]
2012-08-21 18:07                   ` Mahesh Palivela
2012-08-22  7:03                     ` Johannes Berg
2012-08-22  9:01                       ` Stanislaw Gruszka
2012-08-22  9:04                         ` Johannes Berg
2012-08-22 10:12                           ` Stanislaw Gruszka
2012-08-24 11:33                             ` Mahesh Palivela
2012-08-24 12:05                               ` Johannes Berg
2012-08-24 13:08                                 ` Mahesh Palivela
2012-08-26  8:39                                   ` Johannes Berg
2012-08-27  4:15                                     ` Mahesh Palivela
2012-08-27 12:05                                     ` Mahesh Palivela
2012-08-28 12:20                                       ` Mahesh Palivela
2012-08-29  4:07                                     ` Mahesh Palivela
2012-09-04  8:17                                       ` Johannes Berg
  -- strict thread matches above, loose matches on Subject: below --
2012-08-14  7:32 Mahesh Palivela
2012-08-14 12:05 ` Stanislaw Gruszka

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=1345564421.10280.9.camel@jlt3.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=kvalo@adurom.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=maheshp@posedge.com \
    --cc=sgruszka@redhat.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).