[PATCH 1/1 V2] cfg80211: adding NONE regdomain

[PATCH 1/1 V2] cfg80211: adding NONE regdomain

[Tomas Winkler]

From: Ester Kummer <ester.kummer@intel.com>

This patch adds an option to enable all the channels by adding a
value of "NONE" to ieee80211_regdom module param. This is useful
for NICs that rely on EEPROM regulatory enforcement and for testing

Signed-off-by: Ester Kummer <ester.kummer@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 net/wireless/reg.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 855bff4..140b931 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -97,6 +97,14 @@ static const struct ieee80211_channel_range ieee80211_EU_channels[] = {
 				     IEEE80211_CHAN_RADAR),
 };
 
+static const struct ieee80211_channel_range ieee80211_NONE_channels[] = {
+	/* IEEE 802.11b/g, channels 1..14 */
+	RANGE_PWR(2412, 2484, 0xFF, 0xFF, 0),
+	/* IEEE 802.11a, channels 36..165 */
+	RANGE_PWR(5180, 6000, 0xFF, 0xFF, 0),
+};
+
+
 #define REGDOM(_code)							\
 	{								\
 		.code = __stringify(_code),				\
@@ -108,6 +116,7 @@ static const struct ieee80211_regdomain ieee80211_regdoms[] = {
 	REGDOM(US),
 	REGDOM(JP),
 	REGDOM(EU),
+	REGDOM(NONE),
 };
 
 
-- 
1.5.4.1

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH 1/1 V2] cfg80211: adding NONE regdomain

[Luis R. Rodriguez]

On Sun, Jun 29, 2008 at 2:43 AM, Tomas Winkler <tomas.winkler@intel.com> wrote:
> From: Ester Kummer <ester.kummer@intel.com>
>
> This patch adds an option to enable all the channels by adding a
> value of "NONE" to ieee80211_regdom module param. This is useful
> for NICs that rely on EEPROM regulatory enforcement and for testing

For the EEPROM we should not rely on "none" but on a callback notifier
chain to let the driver do 'the right thing'. I'll post patches
hopefully tonight.

  Luis

Re: [PATCH 1/1 V2] cfg80211: adding NONE regdomain

[Tomas Winkler]

On Mon, Jun 30, 2008 at 11:18 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Sun, Jun 29, 2008 at 2:43 AM, Tomas Winkler <tomas.winkler@intel.com> wrote:
>> From: Ester Kummer <ester.kummer@intel.com>
>>
>> This patch adds an option to enable all the channels by adding a
>> value of "NONE" to ieee80211_regdom module param. This is useful
>> for NICs that rely on EEPROM regulatory enforcement and for testing
>
> For the EEPROM we should not rely on "none" but on a callback notifier
> chain to let the driver do 'the right thing'. I'll post patches
> hopefully tonight.

Still can be useful for testing,
Tomas

Re: [PATCH 1/1 V2] cfg80211: adding NONE regdomain

[Luis R. Rodriguez]

On Mon, Jun 30, 2008 at 1:52 AM, Tomas Winkler <tomasw@gmail.com> wrote:
> On Mon, Jun 30, 2008 at 11:18 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Sun, Jun 29, 2008 at 2:43 AM, Tomas Winkler <tomas.winkler@intel.com> wrote:
>>> From: Ester Kummer <ester.kummer@intel.com>
>>>
>>> This patch adds an option to enable all the channels by adding a
>>> value of "NONE" to ieee80211_regdom module param. This is useful
>>> for NICs that rely on EEPROM regulatory enforcement and for testing
>>
>> For the EEPROM we should not rely on "none" but on a callback notifier
>> chain to let the driver do 'the right thing'. I'll post patches
>> hopefully tonight.
>
> Still can be useful for testing,

Testing can be done separately but not merged. The idea is to keep
mac80211 and mac80211 drivers as compliant as possible. This steers in
the other direction.

  Luis

Re: [PATCH 1/1 V2] cfg80211: adding NONE regdomain

[Tomas Winkler]

On Mon, Jun 30, 2008 at 11:59 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Mon, Jun 30, 2008 at 1:52 AM, Tomas Winkler <tomasw@gmail.com> wrote:
>> On Mon, Jun 30, 2008 at 11:18 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>>> On Sun, Jun 29, 2008 at 2:43 AM, Tomas Winkler <tomas.winkler@intel.com> wrote:
>>>> From: Ester Kummer <ester.kummer@intel.com>
>>>>
>>>> This patch adds an option to enable all the channels by adding a
>>>> value of "NONE" to ieee80211_regdom module param. This is useful
>>>> for NICs that rely on EEPROM regulatory enforcement and for testing
>>>
>>> For the EEPROM we should not rely on "none" but on a callback notifier
>>> chain to let the driver do 'the right thing'. I'll post patches
>>> hopefully tonight.
>>
>> Still can be useful for testing,
>
> Testing can be done separately but not merged. The idea is to keep
> mac80211 and mac80211 drivers as compliant as possible. This steers in
> the other direction.

Currently EEPROM and reg domains creates strange intersections. We are
hitting this complains every other day.
What we are missing is the clear indication for end users (not on this
mailing list) what and why channels are restricted.
Thanks
Tomas

Re: [PATCH 1/1 V2] cfg80211: adding NONE regdomain

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

On Mon, 2008-06-30 at 01:59 -0700, Luis R. Rodriguez wrote:

> >>> This patch adds an option to enable all the channels by adding a
> >>> value of "NONE" to ieee80211_regdom module param. This is useful
> >>> for NICs that rely on EEPROM regulatory enforcement and for testing

> > Still can be useful for testing,
> 
> Testing can be done separately but not merged. The idea is to keep
> mac80211 and mac80211 drivers as compliant as possible. This steers in
> the other direction.

I agree, testing is no reason to merge a patch if it's intrusive and not
useful outside testing.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/1 V2] cfg80211: adding NONE regdomain

[Tomas Winkler]

On Mon, Jun 30, 2008 at 12:22 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2008-06-30 at 01:59 -0700, Luis R. Rodriguez wrote:
>
>> >>> This patch adds an option to enable all the channels by adding a
>> >>> value of "NONE" to ieee80211_regdom module param. This is useful
>> >>> for NICs that rely on EEPROM regulatory enforcement and for testing
>
>> > Still can be useful for testing,
>>
>> Testing can be done separately but not merged. The idea is to keep
>> mac80211 and mac80211 drivers as compliant as possible. This steers in
>> the other direction.
>
> I agree, testing is no reason to merge a patch if it's intrusive and not
> useful outside testing.

The idea was ask troubled user to make change in modprobe.conf and not
changing the code.
Thanks
Tomas

Re: [PATCH 1/1 V2] cfg80211: adding NONE regdomain

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

On Mon, 2008-06-30 at 14:25 +0300, Tomas Winkler wrote:

> The idea was ask troubled user to make change in modprobe.conf and not
> changing the code.

Yeah but IMHO you're solving the wrong problem. If we want any
credibility we shouldn't allow users to ignore any regdom that easily,
and this is system-wide. Also, iwlwifi partly caused this problem in the
first place by printing out eeprom channels rather than having users use
"iwlist wlan0 channel" to see which channels are usable. Or even iw,
which shows you which are disabled.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/1 V2] cfg80211: adding NONE regdomain

[Tomas Winkler]

On Mon, Jun 30, 2008 at 2:35 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2008-06-30 at 14:25 +0300, Tomas Winkler wrote:
>
>> The idea was ask troubled user to make change in modprobe.conf and not
>> changing the code.
>
> Yeah but IMHO you're solving the wrong problem. If we want any
> credibility we shouldn't allow users to ignore any regdom that easily,
> and this is system-wide. Also, iwlwifi partly caused this problem in the
> first place by printing out eeprom channels rather than having users use
> "iwlist wlan0 channel" to see which channels are usable. Or even iw,
> which shows you which are disabled.

Unfortunately iwlist channel gives very little information about
channels and iw is not distributed by any distro as far as I know.

Here is little patch to help iw be more useful.

--- a/iw.c
+++ b/iw.c
@@ -95,7 +95,7 @@ static void usage(char *argv0)
        fprintf(stderr, "Usage: %1$s dev <phydev> <OBJECT> <COMMAND> [OPTIONS]"
                        "\n     %1$s dev <phydev> info\n"
                        "\n"
-                       "where OBJECT := { interface | station | mpath }\n"
+                       "where OBJECT := { interface | station | mpath
| info }\n"
                        "and COMMAND := { add | del | set | get | dump }\n",
                        argv0);
 }


Tomas

Re: [PATCH 1/1 V2] cfg80211: adding NONE regdomain

[John W. Linville]

On Mon, Jun 30, 2008 at 01:35:47PM +0200, Johannes Berg wrote:
> On Mon, 2008-06-30 at 14:25 +0300, Tomas Winkler wrote:
> 
> > The idea was ask troubled user to make change in modprobe.conf and not
> > changing the code.
> 
> Yeah but IMHO you're solving the wrong problem. If we want any
> credibility we shouldn't allow users to ignore any regdom that easily,
> and this is system-wide.

I share this opinion.  I'm not inclined to merge this patch.

-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH 1/1 V2] cfg80211: adding NONE regdomain

[Tomas Winkler]

On Mon, Jun 30, 2008 at 4:55 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Mon, Jun 30, 2008 at 01:35:47PM +0200, Johannes Berg wrote:
>> On Mon, 2008-06-30 at 14:25 +0300, Tomas Winkler wrote:
>>
>> > The idea was ask troubled user to make change in modprobe.conf and not
>> > changing the code.
>>
>> Yeah but IMHO you're solving the wrong problem. If we want any
>> credibility we shouldn't allow users to ignore any regdom that easily,
>> and this is system-wide.
>
> I share this opinion.  I'm not inclined to merge this patch.

That's okay. I hope Luis will provide better solution for this. And
mostly I hope that everybody agrees  with me that we have a problem
here from the user perspective.
Tomas