From: Mahesh Palivela <maheshp@posedge.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"linville@tuxdriver.com" <linville@tuxdriver.com>,
Stanislaw Gruszka <sgruszka@redhat.com>
Subject: Re: [RFC v2] cfg80211: VHT regulatory
Date: Mon, 10 Sep 2012 15:29:47 +0530 [thread overview]
Message-ID: <504DBA13.3060505@posedge.com> (raw)
In-Reply-To: <1347019809.4256.21.camel@jlt4.sipsolutions.net>
On 9/7/2012 5:40 PM, Johannes Berg wrote:
> We don't have to do any calculation in kernel though as far as I can
> tell? Maybe we do need the channel, but I think in terms of
> *specifying*, in particular in the nl80211 and cfg80211 APIs, we should
> stick to the standard if we're going to change it now.
>
If we don't have to do any calculation, what for the formulas in spec?
converting chan number to frequency value. Just with channel number
entire cfg,mac and drivers are fine?
>
> I have no idea. I don't know the regulatory code very well, sorry.
>
Sorry I take it back. we can pass center freq to get reg rule. RFC v3 is
on way ...
>
> It seems to me that if we're going to specify things as an overall
> center frequency + bandwidth then we don't really care about
> primary/secondary channels? We'd rather just get the reg rule(s) from
> the center freq(s)/bandwidth, and then check all channels that happen to
> fall into this space, or something like that?
>
> Even if we do that, there's still another issue though. Some drivers,
> like ours, don't support HT40 everywhere. Right now I believe we pretty
> much support HT40 everywhere that is allowed, but that might not be the
> case for all drivers.
>
> So previously, the driver was able to set the IEEE80211_CHAN_NO_HT40PLUS
> etc. flags on a channel before registering. If we remove these flags
> we'll have to find a way to allow the driver to influence the decision
> about what is allowed in some way, I guess? Or maybe the driver would
> have to register a regulatory rule that encapsulates everything in the
> device's EEPROM?
Let me know if my RFC v3 is ok for this.
>
> johannes
>
--
Thanks,
Mahesh
next prev parent reply other threads:[~2012-09-10 9:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-05 7:11 [RFC v2] cfg80211: VHT regulatory Mahesh Palivela
2012-09-05 13:39 ` Johannes Berg
2012-09-06 3:44 ` Mahesh Palivela
2012-09-06 9:54 ` Johannes Berg
2012-09-06 12:04 ` Mahesh Palivela
2012-09-07 12:10 ` Johannes Berg
2012-09-10 9:59 ` Mahesh Palivela [this message]
2012-09-28 8:09 ` Mahesh Palivela
2012-09-28 10:39 ` Johannes Berg
2012-09-28 10:42 ` Johannes Berg
2012-09-28 17:34 ` Mahesh Palivela
2012-10-10 9:11 ` Johannes Berg
2012-10-15 3:47 ` Mahesh Palivela
2012-10-19 13:11 ` Johannes Berg
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=504DBA13.3060505@posedge.com \
--to=maheshp@posedge.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.