From: Johannes Berg <johannes@sipsolutions.net>
To: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Mahesh Palivela <maheshp@posedge.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: Wed, 22 Aug 2012 11:04:42 +0200 [thread overview]
Message-ID: <1345626282.4635.8.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <20120822090104.GA4959@redhat.com>
On Wed, 2012-08-22 at 11:01 +0200, Stanislaw Gruszka wrote:
> > Yeah but we don't have that yet. We could do it that way, sure, but it
> > has wide-spread implications, since we'll need to
> > - use this new form of specifying channels all over mac80211 and all
> > drivers,
> > - define new nl80211 attributes for it,
> > - write new code in nl80211 to handle all this,
> > - and parse the old attributes into the new data structure(s) so
> > drivers use the new API but userspace can continue to use the old
> >
> > None of that is done yet.
>
> For starters (for regulatory purpose only) would be sufficient to
> implement
>
> regulatory_chan_use_permitted(center freq, bandwidth, whatever else),
>
> and use it where currently IEEE80211_CHAN_NO_HT_X flags are used.
Yes, in theory. However, if this was intended to use the actual "center
freq, bandwidth, control channel offset" values, then it would be much
better to first actually define a struct to hold those, use it here, and
give it to drivers etc. Otherwise, drivers would have to take, e.g.
- channel = 1 (2412 MHz)
- HT40+
and calculate
- center freq = 2422 MHz
- bandwidth = 40
- control channel offset = 0
before being able to call this function. To me, that seems wrong.
johannes
next prev parent reply other threads:[~2012-08-22 9:04 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
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 [this message]
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=1345626282.4635.8.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).