From: Johannes Berg <johannes@sipsolutions.net>
To: "Luis R. Rodriguez" <lrodriguez@atheros.com>
Cc: Luis Rodriguez <Luis.Rodriguez@Atheros.com>,
"linville@tuxdriver.com" <linville@tuxdriver.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH 00/12] cfg80211/mac80211: fixes/enhancements for reg_notifier()
Date: Wed, 14 Jan 2009 00:23:34 +0100 [thread overview]
Message-ID: <1231889014.3728.19.camel@johannes> (raw)
In-Reply-To: <20090113231741.GU4416@tesla>
[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]
On Tue, 2009-01-13 at 15:17 -0800, Luis R. Rodriguez wrote:
> > (2) you
> > should not do via the regulatory code and the notifier but rather by not
> > registering those channels to start with
>
> I did a lot of this work because you had opposed to allow drivers dynamically register
> their channels.
I think we may have had some miscommunication here? I didn't like
registering the channels dynamically with new calls, but I certainly
don't care how you arrive at your channel array, you can kmalloc it if
you want.
> The size of the code also increases considerably by using static set of
> channels for each custom regulatory domain, its possible though.
You don't have to.
> >, or setting the disabled flag
> > before registration if that's easier.
>
> You'll still need some sort of table. Either way -- all these are options of how to
> accomplish the same task. I did this as part of cfg80211 as I figured it could be
> used by other drivers.
In what form do you have this data? Is it "valid 2412-2472 and 4950-5250
MHz"? If so, can we just have a function that marks all channel that
would fall outside these ranges as invalid, and you call that function
with a specific band and channel before registering your wiphy?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2009-01-13 23:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-13 19:57 [PATCH 00/12] cfg80211/mac80211: fixes/enhancements for reg_notifier() Luis R. Rodriguez
2009-01-13 19:57 ` [PATCH 01/12] cfg80211: print correct intersected regulatory domain Luis R. Rodriguez
2009-01-13 19:57 ` [PATCH 02/12] cfg80211: add helper to indicate when to follow the driver regd Luis R. Rodriguez
2009-01-13 19:57 ` [PATCH 03/12] cfg80211: add option for wiphys to disregard country IEs Luis R. Rodriguez
2009-01-13 19:57 ` [PATCH 04/12] cfg80211: split wiphy_update_regulatory() in two Luis R. Rodriguez
2009-01-13 19:57 ` [PATCH 05/12] cfg80211: add regulatory_set_custom_rd() Luis R. Rodriguez
2009-01-13 19:57 ` [PATCH 06/12] cfg80211: add regdom_intersect_wiphy_regd() Luis R. Rodriguez
2009-01-13 19:57 ` [PATCH 07/12] cfg80211: allow driver read access to cfg80211_regdomain Luis R. Rodriguez
2009-01-13 19:57 ` [PATCH 08/12] cfg80211: export freq_reg_info() Luis R. Rodriguez
2009-01-13 19:57 ` [PATCH 09/12] cfg80211: Fix sanity check on 5 GHz when processing country IE Luis R. Rodriguez
2009-01-13 19:57 ` [PATCH 10/12] cfg80211: process user requests only after previous user/driver/core requests Luis R. Rodriguez
2009-01-13 19:57 ` [PATCH 11/12] mac80211: allow mac80211 drivers to get to driver priv from wiphy Luis R. Rodriguez
2009-01-13 19:57 ` [PATCH 12/12] cfg80211: Remove CONFIG_WIRELESS_OLD_REGULATORY Luis R. Rodriguez
2009-01-13 22:50 ` Johannes Berg
2009-01-13 23:00 ` Luis R. Rodriguez
2009-01-13 23:02 ` Johannes Berg
2009-01-13 22:50 ` [PATCH 11/12] mac80211: allow mac80211 drivers to get to driver priv from wiphy Johannes Berg
2009-01-13 22:46 ` [PATCH 07/12] cfg80211: allow driver read access to cfg80211_regdomain Johannes Berg
2009-01-13 22:51 ` Luis R. Rodriguez
2009-01-13 22:53 ` Johannes Berg
2009-01-13 23:02 ` Luis R. Rodriguez
2009-01-13 23:00 ` [PATCH 00/12] cfg80211/mac80211: fixes/enhancements for reg_notifier() Johannes Berg
2009-01-13 23:17 ` Luis R. Rodriguez
2009-01-13 23:23 ` Johannes Berg [this message]
2009-01-13 23:59 ` Luis R. Rodriguez
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=1231889014.3728.19.camel@johannes \
--to=johannes@sipsolutions.net \
--cc=Luis.Rodriguez@Atheros.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=lrodriguez@atheros.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.