[ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.
From: Ben Greear gree...@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 gree...@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
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Questions in 802.11 n timestamps traces for aggregated frames ?
Is this being recorded on transmit, or transmit completion? I'm guessing this is transmit completion on the transmit side. Is this information coming from the driver, or from some completion status going up to mac80211? Partly from the driver (timestamp and tx aggr flag) and partly from the status going to mac80211 (the bitrate array, retx count) and partly from the mac header ( sequence number) All of them are stored in the radiotap or mac header for each frame delivered in userspace in monitor mode. The data is recorded from transmit status(You might be referring to it as transmit complete) i.e net/mac80211/status.c The *attempted rates *array is extracted from *struct ieee80211_tx_info * which is part of skb control buffer.I don't really get how is this populated/copied from. The* timestamp* is got from *ath_tx_status*, which is later stored in the ieee80211_tx_info struct to be given to mac80211. Population of timestamp is done in driver (ath_tx_complete_buf() ) The *aggr flag *is populated using struct ath_buf field bf-bf_state.bf_type. I can tell you what's going on with the hardware. I can't guarantee that the driver or mac80211 isn't messing things up along the line. Can you tell what happens if the whole aggregate frame is tried and does not get transmitted. Does the hardware return it back to driver, and the driver 1)splits the aggregate frame into subframe and retries later 2) hardware does not return the aggregate buffer until its done transmitted it ? There's one TX status for each aggregate being transmitted. If there's some per-buffer completion information being sent up to mac80211 about the state of that frame, it _should_ be stamped with the completion status from the single TX status that represents all the successfully transmitted frames for that buffer. Yes, I have understood this part from your previous mails, and I am glad that holds true. In this case, I was fine with the above trace if the normal frame had the same timestamp, as it might be in the same buffer while sending. But the tx aggregate flag and different attempted bitrate shows something is wrong. There's no way at all to get an A-MPDU transmission with different TX rates for each sub-frame. The hardware just doesn't do it; there's no possible way to get that information from a single TX completion / status descriptor. So I'd go looking at what the ath9k driver is doing to mark completion status in the face of completion and software retransmit. It may be that something is messed up along the way and it's storing the wrong timestamp, or the previous rate control attempt, or something similar. (I had an issue in FreeBSD where I was processing the rate control information from the last descriptor in the last buffer, but not taking a copy of it before I processed the aggregate - so if the final aggregate succeeded, I'd end up looking at a descriptor from a just-freed buffer. That caused all kinds of weird behaviour.) Sure, I was also confused if I am seeing the last descriptor value, but it was too complicated to know how to find out. I will try to dig more. Can someone confirm if there can be a discrepancy in the status sent to mac80211 and what driver does. I did not understand how the hooks to rate control (rc.c functions) so I could not confirm myself :( - Abhinav Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Questions in 802.11 n timestamps traces for aggregated frames ?
On 2013-03-11 7:20 PM, abhinav narain wrote: Is this being recorded on transmit, or transmit completion? I'm guessing this is transmit completion on the transmit side. Is this information coming from the driver, or from some completion status going up to mac80211? Partly from the driver (timestamp and tx aggr flag) and partly from the status going to mac80211 (the bitrate array, retx count) and partly from the mac header ( sequence number) All of them are stored in the radiotap or mac header for each frame delivered in userspace in monitor mode. The data is recorded from transmit status(You might be referring to it as transmit complete) i.e net/mac80211/status.c The *attempted rates *array is extracted from *struct ieee80211_tx_info * which is part of skb control buffer.I don't really get how is this populated/copied from. The*timestamp* is got from *ath_tx_status*, which is later stored in the ieee80211_tx_info struct to be given to mac80211. Population of timestamp is done in driver (ath_tx_complete_buf() ) The *aggr flag *is populated using struct ath_buf field bf-bf_state.bf_type. One reason I told you to look into rate control is these lines in minstrel_ht_tx_status: /* This packet was aggregated but doesn't carry status info */ if ((info-flags IEEE80211_TX_CTL_AMPDU) !(info-flags IEEE80211_TX_STAT_AMPDU)) return; Any packet with IEEE80211_TX_CTL_AMPDU and not IEEE80211_TX_STAT_AMPDU does not carry valid rate/retry information. Did you filter your debug stuff accordingly? - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.
On Mon, Mar 11, 2013 at 09:45:06AM -0700, gree...@candelatech.com wrote: From: Ben Greear gree...@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 gree...@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. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.
On 03/11/2013 12:05 PM, John W. Linville wrote: On Mon, Mar 11, 2013 at 09:45:06AM -0700, gree...@candelatech.com wrote: From: Ben Greear gree...@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 gree...@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 gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.
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, gree...@candelatech.com wrote: From: Ben Greear gree...@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 gree...@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. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.
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, gree...@candelatech.com wrote: From: Ben Greear gree...@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 gree...@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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.
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, gree...@candelatech.com wrote: From: Ben Greear gree...@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 gree...@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 gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.
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, gree...@candelatech.com wrote: From: Ben Greear gree...@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 gree...@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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.
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 gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.
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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.
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 gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.
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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
