linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-16 21:18 [PATCH] ath: add support for special 0x8000 regulatory domain Luis R. Rodriguez
2009-07-19 12:35 ` Joerg Albert [this message]
2009-07-20 15:27   ` Luis R. Rodriguez
  -- strict thread matches above, loose matches on Subject: below --
2009-07-20 15:32 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=David.Quan@atheros.com \
    --cc=Stephen.Chen@atheros.com \
    --cc=Tony.Yang@atheros.com \
    --cc=ath9k-devel@lists.ath9k.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).