Re: [PATCH] ath9k: Allow over-riding reg-domain.

Re: [PATCH] ath9k: Allow over-riding reg-domain.

[Xose Vazquez Perez]

Ben Greear wrote:

> Otherwise, can't get the Sparklan AR9380 NICs to be
> 5Ghz APs, since they are in world-roaming domain by
> default.  Add this to /etc/modprobe.d/ath9k.conf:

You can use atheros branch [0] of iwleeprom [1] to
manipulate the EEPROM.

And you should read: http://wireless.kernel.org/en/users/Drivers/ath#Regulatory


[0] svn co http://iwleeprom.googlecode.com/svn/
[1] http://code.google.com/p/iwleeprom/

Re: [PATCH] ath9k: Allow over-riding reg-domain.

[Adrian Chadd]

Oh I hate you. ;-)

Besides, that will not work on AR9300 NICs with only OTP.



Adrian


On 11 March 2013 15:45, Xose Vazquez Perez <xose.vazquez@gmail.com> wrote:
> Ben Greear wrote:
>
>> Otherwise, can't get the Sparklan AR9380 NICs to be
>> 5Ghz APs, since they are in world-roaming domain by
>> default.  Add this to /etc/modprobe.d/ath9k.conf:
>
> You can use atheros branch [0] of iwleeprom [1] to
> manipulate the EEPROM.
>
> And you should read: http://wireless.kernel.org/en/users/Drivers/ath#Regulatory
>
>
> [0] svn co http://iwleeprom.googlecode.com/svn/
> [1] http://code.google.com/p/iwleeprom/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ath9k: Allow over-riding reg-domain.

[greearb]

From: Ben Greear <greearb@candelatech.com>

Otherwise, can't get the Sparklan AR9380 NICs to be
5Ghz APs, since they are in world-roaming domain by
default.  Add this to /etc/modprobe.d/ath9k.conf:

options ath9k override_eeprom_regdomain=0

Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 af932c9... dee91a2... M	drivers/net/wireless/ath/ath9k/init.c
 drivers/net/wireless/ath/ath9k/init.c |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index af932c9..dee91a2 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -56,6 +56,12 @@ static int ath9k_enable_diversity;
 module_param_named(enable_diversity, ath9k_enable_diversity, int, 0444);
 MODULE_PARM_DESC(enable_diversity, "Enable Antenna diversity for AR9565");
 
+static int modparam_override_eeprom_regdomain = -1;
+module_param_named(override_eeprom_regdomain,
+		   modparam_override_eeprom_regdomain, int, 0444);
+MODULE_PARM_DESC(override_eeprom_regdomain, "Override regdomain hardcoded in EEPROM with this value (DANGEROUS).");
+
+
 bool is_ath9k_unloaded;
 /* We use the hw_value as an index into our private channel structure */
 
@@ -740,6 +746,21 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
 	struct ath_hw *ah = sc->sc_ah;
 	struct ath_common *common = ath9k_hw_common(ah);
 
+	if (modparam_override_eeprom_regdomain != -1) {
+#ifdef CONFIG_CFG80211_CERTIFICATION_ONUS
+		struct ath_regulatory *regulatory = ath9k_hw_regulatory(sc->sc_ah);
+		printk(KERN_ERR "ath9k: DANGER! You're overriding EEPROM-defined regulatory domain,"
+		       "\nfrom: 0x%x to 0x%x\n",
+		       regulatory->current_rd, modparam_override_eeprom_regdomain);
+		printk(KERN_ERR "ath9k: Your card was not certified to operate in the domain you chose.\n");
+		printk(KERN_ERR "ath9k: This might result in a violation of your local regulatory rules.\n");
+		printk(KERN_ERR "ath9k: Do not ever do this unless you really know what you are doing!\n");
+		regulatory->current_rd = modparam_override_eeprom_regdomain;
+#else
+		printk(KERN_ERR "ath9k: ERROR:  override_eeprom_regdomain request will be ignored because CF80211_CERTIFICATION_ONUS was not selected when compiling the kernel.\n");
+#endif
+	}
+
 	hw->flags = IEEE80211_HW_RX_INCLUDES_FCS |
 		IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
 		IEEE80211_HW_SIGNAL_DBM |
-- 
1.7.3.4

Re: [PATCH] ath9k: Allow over-riding reg-domain.

[John W. Linville]

On Mon, Mar 11, 2013 at 09:45:06AM -0700, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
> 
> Otherwise, can't get the Sparklan AR9380 NICs to be
> 5Ghz APs, since they are in world-roaming domain by
> default.  Add this to /etc/modprobe.d/ath9k.conf:
> 
> options ath9k override_eeprom_regdomain=0
> 
> Signed-off-by: Ben Greear <greearb@candelatech.com>

Why "=0" to enable it?  Just to make it more confusing?

Do the Atheros folks have an opinion on this?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: [PATCH] ath9k: Allow over-riding reg-domain.

[Ben Greear]

On 03/11/2013 12:05 PM, John W. Linville wrote:
> On Mon, Mar 11, 2013 at 09:45:06AM -0700, greearb@candelatech.com wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> Otherwise, can't get the Sparklan AR9380 NICs to be
>> 5Ghz APs, since they are in world-roaming domain by
>> default.  Add this to /etc/modprobe.d/ath9k.conf:
>>
>> options ath9k override_eeprom_regdomain=0
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>
> Why "=0" to enable it?  Just to make it more confusing?

You are just setting the country code...and country-code 0 seems
to at least open up the US regulatory domain so we use it
by default.

You can use any country code you wish here.

Thanks,
Ben

>
> Do the Atheros folks have an opinion on this?
>
> John
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] ath9k: Allow over-riding reg-domain.

[John W. Linville]

On Mon, Mar 11, 2013 at 12:51:41PM -0700, Ben Greear wrote:
> On 03/11/2013 12:05 PM, John W. Linville wrote:
> >On Mon, Mar 11, 2013 at 09:45:06AM -0700, greearb@candelatech.com wrote:
> >>From: Ben Greear <greearb@candelatech.com>
> >>
> >>Otherwise, can't get the Sparklan AR9380 NICs to be
> >>5Ghz APs, since they are in world-roaming domain by
> >>default.  Add this to /etc/modprobe.d/ath9k.conf:
> >>
> >>options ath9k override_eeprom_regdomain=0
> >>
> >>Signed-off-by: Ben Greear <greearb@candelatech.com>
> >
> >Why "=0" to enable it?  Just to make it more confusing?
> 
> You are just setting the country code...and country-code 0 seems
> to at least open up the US regulatory domain so we use it
> by default.
> 
> You can use any country code you wish here.

Ah, sorry -- I brain-locked on it being a logic value...

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: [PATCH] ath9k: Allow over-riding reg-domain.

[Felix Fietkau]

On 2013-03-11 8:51 PM, Ben Greear wrote:
> On 03/11/2013 12:05 PM, John W. Linville wrote:
>> On Mon, Mar 11, 2013 at 09:45:06AM -0700, greearb@candelatech.com wrote:
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> Otherwise, can't get the Sparklan AR9380 NICs to be
>>> 5Ghz APs, since they are in world-roaming domain by
>>> default.  Add this to /etc/modprobe.d/ath9k.conf:
>>>
>>> options ath9k override_eeprom_regdomain=0
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>
>> Why "=0" to enable it?  Just to make it more confusing?
> 
> You are just setting the country code...and country-code 0 seems
> to at least open up the US regulatory domain so we use it
> by default.
> 
> You can use any country code you wish here.
I'd like to have less fugly module parameter hackery please. How about
either using CONFIG_CFG80211_CERTIFICATION_ONUS the way it was intended,
or adding another config option that makes it bail out of
ath_regd_init_wiphy() early, thus still processing the EEPROM regdomain
hint and not making it binding.

- Felix

Re: [PATCH] ath9k: Allow over-riding reg-domain.

[Ben Greear]

On 03/11/2013 01:17 PM, Felix Fietkau wrote:
> On 2013-03-11 8:51 PM, Ben Greear wrote:
>> On 03/11/2013 12:05 PM, John W. Linville wrote:
>>> On Mon, Mar 11, 2013 at 09:45:06AM -0700, greearb@candelatech.com wrote:
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> Otherwise, can't get the Sparklan AR9380 NICs to be
>>>> 5Ghz APs, since they are in world-roaming domain by
>>>> default.  Add this to /etc/modprobe.d/ath9k.conf:
>>>>
>>>> options ath9k override_eeprom_regdomain=0
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>
>>> Why "=0" to enable it?  Just to make it more confusing?
>>
>> You are just setting the country code...and country-code 0 seems
>> to at least open up the US regulatory domain so we use it
>> by default.
>>
>> You can use any country code you wish here.
> I'd like to have less fugly module parameter hackery please. How about
> either using CONFIG_CFG80211_CERTIFICATION_ONUS the way it was intended,
> or adding another config option that makes it bail out of
> ath_regd_init_wiphy() early, thus still processing the EEPROM regdomain
> hint and not making it binding.

I am not sure what you are suggesting.  I enabled this override
only when ONUS is selected because I wanted it clear that users
were taking their regulatory compliance into their own hands.

I always want the module option at least visible so that
you don't have to muck with modprobe.conf just to get ath9k.ko
to load when it's compiled differently.

For the second part, you want the ability to set the regdomain
be a compile-time option like CONFIG_ATH9K_OVERRIDE_REGDOMAIN
or something like that?

Thanks,
Ben

>
> - Felix
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] ath9k: Allow over-riding reg-domain.

[Felix Fietkau]

On 2013-03-11 10:01 PM, Ben Greear wrote:
> On 03/11/2013 01:17 PM, Felix Fietkau wrote:
>> On 2013-03-11 8:51 PM, Ben Greear wrote:
>>> On 03/11/2013 12:05 PM, John W. Linville wrote:
>>>> On Mon, Mar 11, 2013 at 09:45:06AM -0700, greearb@candelatech.com wrote:
>>>>> From: Ben Greear <greearb@candelatech.com>
>>>>>
>>>>> Otherwise, can't get the Sparklan AR9380 NICs to be
>>>>> 5Ghz APs, since they are in world-roaming domain by
>>>>> default.  Add this to /etc/modprobe.d/ath9k.conf:
>>>>>
>>>>> options ath9k override_eeprom_regdomain=0
>>>>>
>>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>>
>>>> Why "=0" to enable it?  Just to make it more confusing?
>>>
>>> You are just setting the country code...and country-code 0 seems
>>> to at least open up the US regulatory domain so we use it
>>> by default.
>>>
>>> You can use any country code you wish here.
>> I'd like to have less fugly module parameter hackery please. How about
>> either using CONFIG_CFG80211_CERTIFICATION_ONUS the way it was intended,
>> or adding another config option that makes it bail out of
>> ath_regd_init_wiphy() early, thus still processing the EEPROM regdomain
>> hint and not making it binding.
> 
> I am not sure what you are suggesting.  I enabled this override
> only when ONUS is selected because I wanted it clear that users
> were taking their regulatory compliance into their own hands.
And as far as I understand, CONFIG_CFG80211_CERTIFICATION_ONUS already
enables some code in cfg80211 that allows a special type of regulatory
change request from user space that bypasses intersection.

> I always want the module option at least visible so that
> you don't have to muck with modprobe.conf just to get ath9k.ko
> to load when it's compiled differently.
> 
> For the second part, you want the ability to set the regdomain
> be a compile-time option like CONFIG_ATH9K_OVERRIDE_REGDOMAIN
> or something like that?
Something like that, yes. It should depend on
CONFIG_CFG80211_CERTIFICATION_ONUS and should contain a help text that
strongly discourages any distribution from enabling it in their kernel
builds.

- Felix

Re: [PATCH] ath9k: Allow over-riding reg-domain.

[Ben Greear]

On 03/11/2013 02:36 PM, Felix Fietkau wrote:
> On 2013-03-11 10:01 PM, Ben Greear wrote:
>> On 03/11/2013 01:17 PM, Felix Fietkau wrote:

>> I am not sure what you are suggesting.  I enabled this override
>> only when ONUS is selected because I wanted it clear that users
>> were taking their regulatory compliance into their own hands.
> And as far as I understand, CONFIG_CFG80211_CERTIFICATION_ONUS already
> enables some code in cfg80211 that allows a special type of regulatory
> change request from user space that bypasses intersection.
>
>> I always want the module option at least visible so that
>> you don't have to muck with modprobe.conf just to get ath9k.ko
>> to load when it's compiled differently.
>>
>> For the second part, you want the ability to set the regdomain
>> be a compile-time option like CONFIG_ATH9K_OVERRIDE_REGDOMAIN
>> or something like that?
> Something like that, yes. It should depend on
> CONFIG_CFG80211_CERTIFICATION_ONUS and should contain a help text that
> strongly discourages any distribution from enabling it in their kernel
> builds.

It seems to me that this doesn't gain much.  The ONUS configuration is already
strongly discouraged from vendor kernels.  If you are already compiling
with ONUS set, is there any reason you'd care to disable the override
module option?  When you don't set the module option, nothing happens
anyway...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] ath9k: Allow over-riding reg-domain.

[Felix Fietkau]

On 2013-03-11 10:44 PM, Ben Greear wrote:
> On 03/11/2013 02:36 PM, Felix Fietkau wrote:
>> On 2013-03-11 10:01 PM, Ben Greear wrote:
>>> On 03/11/2013 01:17 PM, Felix Fietkau wrote:
> 
>>> I am not sure what you are suggesting.  I enabled this override
>>> only when ONUS is selected because I wanted it clear that users
>>> were taking their regulatory compliance into their own hands.
>> And as far as I understand, CONFIG_CFG80211_CERTIFICATION_ONUS already
>> enables some code in cfg80211 that allows a special type of regulatory
>> change request from user space that bypasses intersection.
>>
>>> I always want the module option at least visible so that
>>> you don't have to muck with modprobe.conf just to get ath9k.ko
>>> to load when it's compiled differently.
>>>
>>> For the second part, you want the ability to set the regdomain
>>> be a compile-time option like CONFIG_ATH9K_OVERRIDE_REGDOMAIN
>>> or something like that?
>> Something like that, yes. It should depend on
>> CONFIG_CFG80211_CERTIFICATION_ONUS and should contain a help text that
>> strongly discourages any distribution from enabling it in their kernel
>> builds.
> 
> It seems to me that this doesn't gain much.  The ONUS configuration is already
> strongly discouraged from vendor kernels.  If you are already compiling
> with ONUS set, is there any reason you'd care to disable the override
> module option?  When you don't set the module option, nothing happens
> anyway...
I'd like to avoid accumulating more hackish driver specific module
options for working around a generic issue.

- Felix

Re: [PATCH] ath9k: Allow over-riding reg-domain.

[Ben Greear]

On 03/11/2013 02:51 PM, Felix Fietkau wrote:
> On 2013-03-11 10:44 PM, Ben Greear wrote:
>> On 03/11/2013 02:36 PM, Felix Fietkau wrote:
>>> On 2013-03-11 10:01 PM, Ben Greear wrote:
>>>> On 03/11/2013 01:17 PM, Felix Fietkau wrote:
>>
>>>> I am not sure what you are suggesting.  I enabled this override
>>>> only when ONUS is selected because I wanted it clear that users
>>>> were taking their regulatory compliance into their own hands.
>>> And as far as I understand, CONFIG_CFG80211_CERTIFICATION_ONUS already
>>> enables some code in cfg80211 that allows a special type of regulatory
>>> change request from user space that bypasses intersection.
>>>
>>>> I always want the module option at least visible so that
>>>> you don't have to muck with modprobe.conf just to get ath9k.ko
>>>> to load when it's compiled differently.
>>>>
>>>> For the second part, you want the ability to set the regdomain
>>>> be a compile-time option like CONFIG_ATH9K_OVERRIDE_REGDOMAIN
>>>> or something like that?
>>> Something like that, yes. It should depend on
>>> CONFIG_CFG80211_CERTIFICATION_ONUS and should contain a help text that
>>> strongly discourages any distribution from enabling it in their kernel
>>> builds.
>>
>> It seems to me that this doesn't gain much.  The ONUS configuration is already
>> strongly discouraged from vendor kernels.  If you are already compiling
>> with ONUS set, is there any reason you'd care to disable the override
>> module option?  When you don't set the module option, nothing happens
>> anyway...
> I'd like to avoid accumulating more hackish driver specific module
> options for working around a generic issue.

I don't think I'm up for any significant re-write of the
regdomain logic, and I'm not sure it's worth the effort
of anyone doing this for code that will be compiled out
of all vendor kernels anyway...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] ath9k: Allow over-riding reg-domain.

[Felix Fietkau]

On 2013-03-11 11:00 PM, Ben Greear wrote:
> On 03/11/2013 02:51 PM, Felix Fietkau wrote:
>> On 2013-03-11 10:44 PM, Ben Greear wrote:
>>> On 03/11/2013 02:36 PM, Felix Fietkau wrote:
>>>> On 2013-03-11 10:01 PM, Ben Greear wrote:
>>>>> On 03/11/2013 01:17 PM, Felix Fietkau wrote:
>>>
>>>>> I am not sure what you are suggesting.  I enabled this override
>>>>> only when ONUS is selected because I wanted it clear that users
>>>>> were taking their regulatory compliance into their own hands.
>>>> And as far as I understand, CONFIG_CFG80211_CERTIFICATION_ONUS already
>>>> enables some code in cfg80211 that allows a special type of regulatory
>>>> change request from user space that bypasses intersection.
>>>>
>>>>> I always want the module option at least visible so that
>>>>> you don't have to muck with modprobe.conf just to get ath9k.ko
>>>>> to load when it's compiled differently.
>>>>>
>>>>> For the second part, you want the ability to set the regdomain
>>>>> be a compile-time option like CONFIG_ATH9K_OVERRIDE_REGDOMAIN
>>>>> or something like that?
>>>> Something like that, yes. It should depend on
>>>> CONFIG_CFG80211_CERTIFICATION_ONUS and should contain a help text that
>>>> strongly discourages any distribution from enabling it in their kernel
>>>> builds.
>>>
>>> It seems to me that this doesn't gain much.  The ONUS configuration is already
>>> strongly discouraged from vendor kernels.  If you are already compiling
>>> with ONUS set, is there any reason you'd care to disable the override
>>> module option?  When you don't set the module option, nothing happens
>>> anyway...
>> I'd like to avoid accumulating more hackish driver specific module
>> options for working around a generic issue.
> 
> I don't think I'm up for any significant re-write of the
> regdomain logic, and I'm not sure it's worth the effort
> of anyone doing this for code that will be compiled out
> of all vendor kernels anyway...
Who said anything about rewriting the regdomain logic? The code is
already there. If you make it a compile time option that gets rid of the
code in ath_regd_init_wiphy, it doesn't need a module parameter - iw reg
set will do the job, and the default still comes from EEPROM.

- Felix

Re: [PATCH] ath9k: Allow over-riding reg-domain.

[Ben Greear]

On 03/11/2013 01:17 PM, Felix Fietkau wrote:
> On 2013-03-11 8:51 PM, Ben Greear wrote:
>> On 03/11/2013 12:05 PM, John W. Linville wrote:
>>> On Mon, Mar 11, 2013 at 09:45:06AM -0700, greearb@candelatech.com wrote:
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> Otherwise, can't get the Sparklan AR9380 NICs to be
>>>> 5Ghz APs, since they are in world-roaming domain by
>>>> default.  Add this to /etc/modprobe.d/ath9k.conf:
>>>>
>>>> options ath9k override_eeprom_regdomain=0
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>
>>> Why "=0" to enable it?  Just to make it more confusing?
>>
>> You are just setting the country code...and country-code 0 seems
>> to at least open up the US regulatory domain so we use it
>> by default.
>>
>> You can use any country code you wish here.
> I'd like to have less fugly module parameter hackery please. How about
> either using CONFIG_CFG80211_CERTIFICATION_ONUS the way it was intended,
> or adding another config option that makes it bail out of
> ath_regd_init_wiphy() early, thus still processing the EEPROM regdomain
> hint and not making it binding.


I get lost in the weeds when trying to understand that code, and I'm
not sure where it should bail out early to accomplish the suggestion
above.

If by chance you have time & interest to put together a patch
to handle the code changes, I'll be happy to test it.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com