All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Albert <jal2@gmx.de>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [PATCH] ath: add support for special 0x8000 regulatory domain
Date: Sun, 19 Jul 2009 14:35:45 +0200	[thread overview]
Message-ID: <4A631321.8070500@gmx.de> (raw)
In-Reply-To: <1247779124-29204-1-git-send-email-lrodriguez@atheros.com>

On 07/16/2009 11:18 PM, Luis R. Rodriguez wrote:
> Two users of ar9170 devices have now reported their cards
> have been programmed with a regulatory domain of 0x8000.
> This is not a valid regulatory domain as such these users were
> unable to use these devices. Since this doesn't seem to be
> a device EEPROM corruption we must treat it specially.
> 
> We default these devices to the default Atheros 0x64 world
> regulatory domain.
> ...
> David, or Joerg, can you please test this patch.

Hi Luis,

this patch doesn't work, I still get:

ath: EEPROM regdomain: 0x8000
ath: EEPROM indicates we should expect a country code
ath: No regulatory domain pair found, cannot continue
ar9170usb: probe of 1-1:1.0 failed with error -22

I guess that's due to reg->current_rd == 0x8000, while CTRY_DEFAULT 
== 0 in ath_regd_sanitize().

Applying

diff --git a/drivers/net/wireless/ath/regd.c 
b/drivers/net/wireless/ath/regd.c
index 62aa270..eae9a58 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -483,7 +483,7 @@ ath_regd_init_wiphy(struct ath_regulatory *reg,
   */
  static void ath_regd_sanitize(struct ath_regulatory *reg)
  {
-       if (reg->current_rd != CTRY_DEFAULT)
+       if (reg->current_rd != (CTRY_DEFAULT|COUNTRY_ERD_FLAG))
                 return;
         printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n");
         reg->current_rd = 0x64;

on top of your patch worked:

ath: EEPROM regdomain sanitized
ath: EEPROM regdomain: 0x64
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: 00
ath: Regpair used: 0x64

Why do we handle a regdomain of 0x8000 differently from a regdomain 
of 0?
0x8000 leads to regdomain 0x64 in ath_regd_sanitize() while 0 is
mapped into country code CTRY_UNITED_STATES.

With the above patch I don't see channels 12,13,100-140 in "iwlist 
wlan0 channel", which are allowed in DE, but I guess that's due to 
using regdomain WOR4_WORLD (0x64).

Do calibration data in the EEPROM really depend on the regdomain, 
i.e. do manufacturers calibrate only for a subset of channels due to 
the regdomain the device will be programmed with?

BTW, I bought this device refurbished in an U.K. webshop.

WARNING: multiple messages have this Message-ID (diff)
From: Joerg Albert <jal2@gmx.de>
To: "Luis R. Rodriguez" <lrodriguez@atheros.com>
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
	ath9k-devel@lists.ath9k.org,
	Stephen Chen <Stephen.Chen@atheros.com>,
	David Quan <David.Quan@atheros.com>,
	Tony Yang <Tony.Yang@atheros.com>
Subject: Re: [PATCH] ath: add support for special 0x8000 regulatory domain
Date: Sun, 19 Jul 2009 14:35:45 +0200	[thread overview]
Message-ID: <4A631321.8070500@gmx.de> (raw)
In-Reply-To: <1247779124-29204-1-git-send-email-lrodriguez@atheros.com>

On 07/16/2009 11:18 PM, Luis R. Rodriguez wrote:
> Two users of ar9170 devices have now reported their cards
> have been programmed with a regulatory domain of 0x8000.
> This is not a valid regulatory domain as such these users were
> unable to use these devices. Since this doesn't seem to be
> a device EEPROM corruption we must treat it specially.
> 
> We default these devices to the default Atheros 0x64 world
> regulatory domain.
> ...
> David, or Joerg, can you please test this patch.

Hi Luis,

this patch doesn't work, I still get:

ath: EEPROM regdomain: 0x8000
ath: EEPROM indicates we should expect a country code
ath: No regulatory domain pair found, cannot continue
ar9170usb: probe of 1-1:1.0 failed with error -22

I guess that's due to reg->current_rd == 0x8000, while CTRY_DEFAULT 
== 0 in ath_regd_sanitize().

Applying

diff --git a/drivers/net/wireless/ath/regd.c 
b/drivers/net/wireless/ath/regd.c
index 62aa270..eae9a58 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -483,7 +483,7 @@ ath_regd_init_wiphy(struct ath_regulatory *reg,
   */
  static void ath_regd_sanitize(struct ath_regulatory *reg)
  {
-       if (reg->current_rd != CTRY_DEFAULT)
+       if (reg->current_rd != (CTRY_DEFAULT|COUNTRY_ERD_FLAG))
                 return;
         printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n");
         reg->current_rd = 0x64;

on top of your patch worked:

ath: EEPROM regdomain sanitized
ath: EEPROM regdomain: 0x64
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: 00
ath: Regpair used: 0x64

Why do we handle a regdomain of 0x8000 differently from a regdomain 
of 0?
0x8000 leads to regdomain 0x64 in ath_regd_sanitize() while 0 is
mapped into country code CTRY_UNITED_STATES.

With the above patch I don't see channels 12,13,100-140 in "iwlist 
wlan0 channel", which are allowed in DE, but I guess that's due to 
using regdomain WOR4_WORLD (0x64).

Do calibration data in the EEPROM really depend on the regdomain, 
i.e. do manufacturers calibrate only for a subset of channels due to 
the regdomain the device will be programmed with?

BTW, I bought this device refurbished in an U.K. webshop.


  reply	other threads:[~2009-07-19 12:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-16 21:18 [ath9k-devel] [PATCH] ath: add support for special 0x8000 regulatory domain Luis R. Rodriguez
2009-07-16 21:18 ` Luis R. Rodriguez
2009-07-19 12:35 ` Joerg Albert [this message]
2009-07-19 12:35   ` Joerg Albert
2009-07-20 15:27   ` [ath9k-devel] " Luis R. Rodriguez
2009-07-20 15:27     ` Luis R. Rodriguez
  -- strict thread matches above, loose matches on Subject: below --
2009-07-20 15:32 [ath9k-devel] " 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=4A631321.8070500@gmx.de \
    --to=jal2@gmx.de \
    --cc=ath9k-devel@lists.ath9k.org \
    /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.