[PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Ivo van Doorn]

rt2500pci and rt2500usb contain a special field in the EEPROM
which indicates which regulatory domain the card belongs to.
This code can easily be translated into a country code which
we can send as alpha2 hint for CRDA.

Please note that most cards will have 0xffff as EEPROM value,
and thus do not provide a regulatory hint through the EEPROM.

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
index 76f016d..98d3c6c 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -1512,6 +1512,17 @@ static int rt2500pci_validate_eeprom(struct rt2x00_dev *rt2x00dev)
 	return 0;
 }
 
+static const char* reg_domain_map[] = {
+	"US",	/* REGION_FCC: 1-11 */
+	"CA",	/* REGION_IC: 1-11 */
+	"DE",	/* REGION_ETSI: 1-13 */
+	"ES",	/* REGION_SPAIN: 10-11 */
+	"FR",	/* REGION_FRANCE: 10-13 */
+	"JP",	/* REGION_MKK: 14 */
+	"JP",	/* REGION_MKK1: 1-14 */
+	"IL",	/* REGION_ISRAEL: 3-9 */
+};
+
 static int rt2500pci_init_eeprom(struct rt2x00_dev *rt2x00dev)
 {
 	u32 reg;
@@ -1577,6 +1588,16 @@ static int rt2500pci_init_eeprom(struct rt2x00_dev *rt2x00dev)
 		__set_bit(CONFIG_DISABLE_LINK_TUNING, &rt2x00dev->flags);
 
 	/*
+	 * Read Geography information, if it contains valid data we should
+	 * send the regulatory hint as alpha2 value to cfg80211.
+	 */
+	rt2x00_eeprom_read(rt2x00dev, EEPROM_GEOGRAPHY, &eeprom);
+	if (eeprom != 0xffff) {
+		value = rt2x00_get_field16(eeprom, EEPROM_GEOGRAPHY_GEO);
+		regulatory_hint(rt2x00dev->hw->wiphy, reg_domain_map[value]);
+	}
+
+	/*
 	 * Read the RSSI <-> dBm offset information.
 	 */
 	rt2x00_eeprom_read(rt2x00dev, EEPROM_CALIBRATE_OFFSET, &eeprom);
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index 2bc4e46..7f364dd 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -1546,6 +1546,17 @@ static int rt2500usb_validate_eeprom(struct rt2x00_dev *rt2x00dev)
 	return 0;
 }
 
+static const char* reg_domain_map[] = {
+	"US",	/* REGION_FCC: 1-11 */
+	"CA",	/* REGION_IC: 1-11 */
+	"DE",	/* REGION_ETSI: 1-13 */
+	"ES",	/* REGION_SPAIN: 10-11 */
+	"FR",	/* REGION_FRANCE: 10-13 */
+	"JP",	/* REGION_MKK: 14 */
+	"JP",	/* REGION_MKK1: 1-14 */
+	"IL",	/* REGION_ISRAEL: 3-9 */
+};
+
 static int rt2500usb_init_eeprom(struct rt2x00_dev *rt2x00dev)
 {
 	u16 reg;
@@ -1626,6 +1637,16 @@ static int rt2500usb_init_eeprom(struct rt2x00_dev *rt2x00dev)
 		__set_bit(CONFIG_DISABLE_LINK_TUNING, &rt2x00dev->flags);
 
 	/*
+	 * Read Geography information, if it contains valid data we should
+	 * send the regulatory hint as alpha2 value to cfg80211.
+	 */
+	rt2x00_eeprom_read(rt2x00dev, EEPROM_GEOGRAPHY, &eeprom);
+	if (eeprom != 0xffff) {
+		value = rt2x00_get_field16(eeprom, EEPROM_GEOGRAPHY_GEO);
+		regulatory_hint(rt2x00dev->hw->wiphy, reg_domain_map[value]);
+	}
+
+	/*
 	 * Read the RSSI <-> dBm offset information.
 	 */
 	rt2x00_eeprom_read(rt2x00dev, EEPROM_CALIBRATE_OFFSET, &eeprom);

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Luis R. Rodriguez]

On Sun, Jan 04, 2009 at 11:21:10AM -0800, Ivo van Doorn wrote:
> rt2500pci and rt2500usb contain a special field in the EEPROM
> which indicates which regulatory domain the card belongs to.
> This code can easily be translated into a country code which
> we can send as alpha2 hint for CRDA.
> 
> Please note that most cards will have 0xffff as EEPROM value,
> and thus do not provide a regulatory hint through the EEPROM.
> 
> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>

I believe regulatory_hint() is being called before the ieee80211_register_hw()
call. This is not a requirement right now but I believe this should be the case
in the future as we want cfg80211 to keep track a few things for the driver, like
the regulatory domain it wants in case of conflicts with other drivers. I'm working
on this right now so just wanted to throw that out there.

Is it possible to move the regulatory_hint() to be used after ieee80211_register_hw()
is called?

  Luis

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Gertjan van Wingerde]

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

On 01/05/09 21:08, Luis R. Rodriguez wrote:
> On Sun, Jan 04, 2009 at 11:21:10AM -0800, Ivo van Doorn wrote:
>    
>> rt2500pci and rt2500usb contain a special field in the EEPROM
>> which indicates which regulatory domain the card belongs to.
>> This code can easily be translated into a country code which
>> we can send as alpha2 hint for CRDA.
>>
>> Please note that most cards will have 0xffff as EEPROM value,
>> and thus do not provide a regulatory hint through the EEPROM.
>>
>> Signed-off-by: Ivo van Doorn<IvDoorn@gmail.com>
>>      
>
> I believe regulatory_hint() is being called before the ieee80211_register_hw()
> call. This is not a requirement right now but I believe this should be the case
> in the future as we want cfg80211 to keep track a few things for the driver, like
> the regulatory domain it wants in case of conflicts with other drivers. I'm working
> on this right now so just wanted to throw that out there.
>
> Is it possible to move the regulatory_hint() to be used after ieee80211_register_hw()
> is called?
Luis, Ivo,

I do have an RFC patch that handles things in the way that Luis describes, and applies to all the rt2x00 drivers. Find it attached (sorry for attaching; I still haven't found a way to properly inline a patch with Thunderbird).

The things that kept me from submitting it so far are:
1. The conversion to a country code for the a-band EEPROM values is not complete / correct. So far I've been unable to map the possible code described in the EEPROM spec to real country codes.
2. I'm still puzzled how to handle the two different values that the EEPROM has, namely one for the bg band and one for the a band. I've handled it by registering the one associated with the configured band, but that seems to be unlikely to be correct. I still haven't found a better way to handle this.

Especially for 2 I haven't been able to determine how to handle that. The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.

---
Gertjan






[-- Attachment #2: 0001-rt2x00-Provide-regulatory-hint.patch --]
[-- Type: text/plain, Size: 11051 bytes --]

>From 23b99c8769ad8451368a2e95eabe1beb7fbd2200 Mon Sep 17 00:00:00 2001
From: Gertjan van Wingerde <gwingerde@kpnplanet.nl>
Date: Mon, 5 Jan 2009 22:12:25 +0100
Subject: [PATCH] rt2x00: Provide regulatory hint.

Properly register the EEPROM region information with the mac80211 regulatory framework.

Signed-off-by: Gertjan van Wingerde <gwingerde@kpnplanet.nl>
---
 drivers/net/wireless/rt2x00/rt2400pci.c |    6 +++
 drivers/net/wireless/rt2x00/rt2400pci.h |    7 ++++
 drivers/net/wireless/rt2x00/rt2500pci.c |    6 +++
 drivers/net/wireless/rt2x00/rt2500pci.h |    2 +-
 drivers/net/wireless/rt2x00/rt2500usb.c |    6 +++
 drivers/net/wireless/rt2x00/rt2500usb.h |    2 +-
 drivers/net/wireless/rt2x00/rt2800pci.c |    8 ++++
 drivers/net/wireless/rt2x00/rt2800pci.h |    9 +++++
 drivers/net/wireless/rt2x00/rt2800usb.c |    8 ++++
 drivers/net/wireless/rt2x00/rt2800usb.h |    9 +++++
 drivers/net/wireless/rt2x00/rt2x00.h    |    6 +++
 drivers/net/wireless/rt2x00/rt2x00dev.c |   60 +++++++++++++++++++++++++++++++
 drivers/net/wireless/rt2x00/rt61pci.c   |    8 ++++
 drivers/net/wireless/rt2x00/rt73usb.c   |    8 ++++
 14 files changed, 143 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c b/drivers/net/wireless/rt2x00/rt2400pci.c
index 9c02231..fa98932 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/rt2x00/rt2400pci.c
@@ -1416,6 +1416,12 @@ static int rt2400pci_init_eeprom(struct rt2x00_dev *rt2x00dev)
 	if (!rt2x00_get_field16(eeprom, EEPROM_ANTENNA_RX_AGCVGC_TUNING))
 		__set_bit(CONFIG_DISABLE_LINK_TUNING, &rt2x00dev->flags);
 
+	/*
+	 * Read the region information.
+	 */
+	rt2x00_eeprom_read(rt2x00dev, EEPROM_GEOGRAPHY, &eeprom);
+	rt2x00dev->region_bg = rt2x00_get_field16(eeprom, EEPROM_GEOGRAPHY_GEO);
+
 	return 0;
 }
 
diff --git a/drivers/net/wireless/rt2x00/rt2400pci.h b/drivers/net/wireless/rt2x00/rt2400pci.h
index 9aefda4..986e428 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.h
+++ b/drivers/net/wireless/rt2x00/rt2400pci.h
@@ -806,6 +806,13 @@
 #define EEPROM_TXPOWER_2		FIELD16(0xff00)
 
 /*
+ * EEPROM geography.
+ * GEO: Default geography setting for device.
+ */
+#define EEPROM_GEOGRAPHY		0x17
+#define EEPROM_GEOGRAPHY_GEO		FIELD16(0xff00)
+
+/*
  * DMA descriptor defines.
  */
 #define TXD_DESC_SIZE			( 8 * sizeof(__le32) )
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
index 76f016d..bf6624b 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -1577,6 +1577,12 @@ static int rt2500pci_init_eeprom(struct rt2x00_dev *rt2x00dev)
 		__set_bit(CONFIG_DISABLE_LINK_TUNING, &rt2x00dev->flags);
 
 	/*
+	 * Read the region information.
+	 */
+	rt2x00_eeprom_read(rt2x00dev, EEPROM_GEOGRAPHY, &eeprom);
+	rt2x00dev->region_bg = rt2x00_get_field16(eeprom, EEPROM_GEOGRAPHY_GEO);
+
+	/*
 	 * Read the RSSI <-> dBm offset information.
 	 */
 	rt2x00_eeprom_read(rt2x00dev, EEPROM_CALIBRATE_OFFSET, &eeprom);
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.h b/drivers/net/wireless/rt2x00/rt2500pci.h
index e135247..8a69af3 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.h
+++ b/drivers/net/wireless/rt2x00/rt2500pci.h
@@ -1060,7 +1060,7 @@
  * GEO: Default geography setting for device.
  */
 #define EEPROM_GEOGRAPHY		0x12
-#define EEPROM_GEOGRAPHY_GEO		FIELD16(0x0f00)
+#define EEPROM_GEOGRAPHY_GEO		FIELD16(0xff00)
 
 /*
  * EEPROM BBP.
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index 81400ea..99ba43e 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -1633,6 +1633,12 @@ static int rt2500usb_init_eeprom(struct rt2x00_dev *rt2x00dev)
 		__set_bit(CONFIG_DISABLE_LINK_TUNING, &rt2x00dev->flags);
 
 	/*
+	 * Read the region information.
+	 */
+	rt2x00_eeprom_read(rt2x00dev, EEPROM_GEOGRAPHY, &eeprom);
+	rt2x00dev->region_bg = rt2x00_get_field16(eeprom, EEPROM_GEOGRAPHY_GEO);
+
+	/*
 	 * Read the RSSI <-> dBm offset information.
 	 */
 	rt2x00_eeprom_read(rt2x00dev, EEPROM_CALIBRATE_OFFSET, &eeprom);
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.h b/drivers/net/wireless/rt2x00/rt2500usb.h
index e1f714e..634fb32 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.h
+++ b/drivers/net/wireless/rt2x00/rt2500usb.h
@@ -680,7 +680,7 @@
  * GEO: Default geography setting for device.
  */
 #define EEPROM_GEOGRAPHY		0x000d
-#define EEPROM_GEOGRAPHY_GEO		FIELD16(0x0f00)
+#define EEPROM_GEOGRAPHY_GEO		FIELD16(0xff00)
 
 /*
  * EEPROM BBP.
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index 1e21d5d..dab08a3 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -2227,6 +2227,14 @@ static int rt2800pci_init_eeprom(struct rt2x00_dev *rt2x00dev)
 		__set_bit(CONFIG_EXTERNAL_LNA_BG, &rt2x00dev->flags);
 
 	/*
+	 * Read region information.
+	 */
+	rt2x00_eeprom_read(rt2x00dev, EEPROM_GEOGRAPHY, &eeprom);
+
+	rt2x00dev->region_bg = rt2x00_get_field16(eeprom, EEPROM_GEOGRAPHY_GEO);
+	rt2x00dev->region_a = rt2x00_get_field16(eeprom, EEPROM_GEOGRAPHY_GEO_A);
+
+	/*
 	 * Detect if this device has an hardware controlled radio.
 	 */
 #ifdef CONFIG_RT2X00_LIB_RFKILL
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.h b/drivers/net/wireless/rt2x00/rt2800pci.h
index b19d019..31b0459 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.h
+++ b/drivers/net/wireless/rt2x00/rt2800pci.h
@@ -1551,6 +1551,15 @@ struct hw_key_entry {
 #define EEPROM_NIC_BW40M_A		FIELD16(0x0200)
 
 /*
+ * EEPROM geography.
+ * GEO_A: Default geographical setting for 5GHz band
+ * GEO: Default geographical setting.
+ */
+#define EEPROM_GEOGRAPHY		0x001c
+#define EEPROM_GEOGRAPHY_GEO_A		FIELD16(0x00ff)
+#define EEPROM_GEOGRAPHY_GEO		FIELD16(0xff00)
+
+/*
  * EEPROM frequency
  */
 #define	EEPROM_FREQ			0x001d
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 6bd252f..e365af2 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -2014,6 +2014,14 @@ static int rt2800usb_init_eeprom(struct rt2x00_dev *rt2x00dev)
 		__set_bit(CONFIG_EXTERNAL_LNA_BG, &rt2x00dev->flags);
 
 	/*
+	 * Read region information.
+	 */
+	rt2x00_eeprom_read(rt2x00dev, EEPROM_GEOGRAPHY, &eeprom);
+
+	rt2x00dev->region_bg = rt2x00_get_field16(eeprom, EEPROM_GEOGRAPHY_GEO);
+	rt2x00dev->region_a = rt2x00_get_field16(eeprom, EEPROM_GEOGRAPHY_GEO_A);
+
+	/*
 	 * Detect if this device has an hardware controlled radio.
 	 */
 #ifdef CONFIG_RT2X00_LIB_RFKILL
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.h b/drivers/net/wireless/rt2x00/rt2800usb.h
index c4c195a..d10d15a 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.h
+++ b/drivers/net/wireless/rt2x00/rt2800usb.h
@@ -1554,6 +1554,15 @@ struct hw_key_entry {
 #define EEPROM_NIC_BW40M_A		FIELD16(0x0200)
 
 /*
+ * EEPROM geography.
+ * GEO_A: Default geographical setting for 5GHz band
+ * GEO: Default geographical setting.
+ */
+#define EEPROM_GEOGRAPHY		0x001c
+#define EEPROM_GEOGRAPHY_GEO_A		FIELD16(0x00ff)
+#define EEPROM_GEOGRAPHY_GEO		FIELD16(0xff00)
+
+/*
  * EEPROM frequency
  */
 #define	EEPROM_FREQ			0x001d
diff --git a/drivers/net/wireless/rt2x00/rt2x00.h b/drivers/net/wireless/rt2x00/rt2x00.h
index 60a0e9e..36e4923 100644
--- a/drivers/net/wireless/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/rt2x00/rt2x00.h
@@ -695,6 +695,12 @@ struct rt2x00_dev {
 	struct antenna_setup default_ant;
 
 	/*
+	 * EEPROM region information;
+	 */
+	u16 region_bg;
+	u16 region_a;
+
+	/*
 	 * Register pointers
 	 * csr.base: CSR base register address. (PCI)
 	 * csr.cache: CSR cache for usb_control_msg. (USB)
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index cc25c83..a3f46a6 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -29,6 +29,54 @@
 #include "rt2x00.h"
 #include "rt2x00lib.h"
 
+enum {
+	RT2X00_REGION_FCC = 0,
+	RT2X00_REGION_IC = 1,
+	RT2X00_REGION_ETSI = 2,
+	RT2X00_REGION_SPAIN = 3,
+	RT2X00_REGION_FRANCE = 4,
+	RT2X00_REGION_MKK = 5,
+	RT2X00_REGION_MKK1 = 6,
+	RT2X00_REGION_ISRAEL = 7,
+};
+
+static inline char *rt2x00_region2alpha(u16 region)
+{
+	char *alpha2;
+
+	switch (region) {
+	case RT2X00_REGION_FCC:
+		alpha2 = "US";
+		break;
+	case RT2X00_REGION_IC:
+		alpha2 = "CA";
+		break;
+	case RT2X00_REGION_ETSI:
+		alpha2 = "DE";
+		break;
+	case RT2X00_REGION_SPAIN:
+		alpha2 = "ES";
+		break;
+	case RT2X00_REGION_FRANCE:
+		alpha2 = "FR";
+		break;
+	case RT2X00_REGION_MKK:
+		alpha2 = "JP";
+		break;
+	case RT2X00_REGION_MKK1:
+		alpha2 = "JP";
+		break;
+	case RT2X00_REGION_ISRAEL:
+		alpha2 = "IL";
+		break;
+	default:
+		alpha2 = NULL;
+		break;
+	}
+
+	return alpha2;
+}
+
 /*
  * Radio control handlers.
  */
@@ -735,6 +783,7 @@ static int rt2x00lib_initialize(struct rt2x00_dev *rt2x00dev)
 int rt2x00lib_start(struct rt2x00_dev *rt2x00dev)
 {
 	int retval;
+	char *alpha2;
 
 	if (test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags))
 		return 0;
@@ -758,6 +807,17 @@ int rt2x00lib_start(struct rt2x00_dev *rt2x00dev)
 	rt2x00dev->intf_sta_count = 0;
 	rt2x00dev->intf_associated = 0;
 
+	/*
+	 * Register the EEPROM region codes with mac80211.
+	 */
+	if (rt2x00dev->curr_band == IEEE80211_BAND_5GHZ)
+		alpha2 = rt2x00_region2alpha(rt2x00dev->region_a);
+	else
+		alpha2 = rt2x00_region2alpha(rt2x00dev->region_bg);
+
+	if (alpha2)
+		regulatory_hint(rt2x00dev->hw->wiphy, alpha2);
+
 	set_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags);
 
 	return 0;
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index f1150a7..b770ee2 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -2371,6 +2371,14 @@ static int rt61pci_init_eeprom(struct rt2x00_dev *rt2x00dev)
 		__set_bit(CONFIG_EXTERNAL_LNA_BG, &rt2x00dev->flags);
 
 	/*
+	 * Read region information.
+	 */
+	rt2x00_eeprom_read(rt2x00dev, EEPROM_GEOGRAPHY, &eeprom);
+
+	rt2x00dev->region_bg = rt2x00_get_field16(eeprom, EEPROM_GEOGRAPHY_GEO);
+	rt2x00dev->region_a = rt2x00_get_field16(eeprom, EEPROM_GEOGRAPHY_GEO_A);
+
+	/*
 	 * When working with a RF2529 chip without double antenna
 	 * the antenna settings should be gathered from the NIC
 	 * eeprom word.
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index 891554e..10c8613 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -1891,6 +1891,14 @@ static int rt73usb_init_eeprom(struct rt2x00_dev *rt2x00dev)
 	}
 
 	/*
+	 * Read region information.
+	 */
+	rt2x00_eeprom_read(rt2x00dev, EEPROM_GEOGRAPHY, &eeprom);
+
+	rt2x00dev->region_bg = rt2x00_get_field16(eeprom, EEPROM_GEOGRAPHY_GEO);
+	rt2x00dev->region_a = rt2x00_get_field16(eeprom, EEPROM_GEOGRAPHY_GEO_A);
+
+	/*
 	 * Store led settings, for correct led behaviour.
 	 */
 #ifdef CONFIG_RT2X00_LIB_LEDS
-- 
1.6.1

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Ivo van Doorn]

On Monday 05 January 2009, Gertjan van Wingerde wrote:
> On 01/05/09 21:08, Luis R. Rodriguez wrote:
> > On Sun, Jan 04, 2009 at 11:21:10AM -0800, Ivo van Doorn wrote:
> >    
> >> rt2500pci and rt2500usb contain a special field in the EEPROM
> >> which indicates which regulatory domain the card belongs to.
> >> This code can easily be translated into a country code which
> >> we can send as alpha2 hint for CRDA.
> >>
> >> Please note that most cards will have 0xffff as EEPROM value,
> >> and thus do not provide a regulatory hint through the EEPROM.
> >>
> >> Signed-off-by: Ivo van Doorn<IvDoorn@gmail.com>

John: Please drop this patch, a more correct patch should be merged later
which is based on the code from Gertjan.

> > I believe regulatory_hint() is being called before the ieee80211_register_hw()
> > call. This is not a requirement right now but I believe this should be the case
> > in the future as we want cfg80211 to keep track a few things for the driver, like
> > the regulatory domain it wants in case of conflicts with other drivers. I'm working
> > on this right now so just wanted to throw that out there.
> >
> > Is it possible to move the regulatory_hint() to be used after ieee80211_register_hw()
> > is called?

Sure, I was a bit doubting about the timing of the call, I noticed that zd1211rw called it during the start()
callback function. Would that be the best location? Or right after ieee80211_register_hw()?

> The things that kept me from submitting it so far are:
> 1. The conversion to a country code for the a-band EEPROM values is not complete / correct. So far I've been unable to map the possible code described in the EEPROM spec to real country codes.

I recall there would be a possibility to provide a custom definition for the domain, not sure if that ever went in.

> 2. I'm still puzzled how to handle the two different values that the EEPROM has, namely one for the bg band and one for the a band. I've handled it by registering the one associated with the configured band, but that seems to be unlikely to be correct. I still haven't found a better way to handle this.

Because of this I hadn't looked very deep into rt61 and rt73 yet.

> The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.

For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.

GertJan, some comments about your patch:

> diff --git a/drivers/net/wireless/rt2x00/rt2400pci.h b/drivers/net/wireless/rt2x00/rt2400pci.h
> index 9aefda4..986e428 100644
> --- a/drivers/net/wireless/rt2x00/rt2400pci.h
> +++ b/drivers/net/wireless/rt2x00/rt2400pci.h
> @@ -806,6 +806,13 @@
>  #define EEPROM_TXPOWER_2		FIELD16(0xff00)
>  
>  /*
> + * EEPROM geography.
> + * GEO: Default geography setting for device.
> + */
> +#define EEPROM_GEOGRAPHY		0x17
> +#define EEPROM_GEOGRAPHY_GEO		FIELD16(0xff00)

Where did you find this definition? I couldn't find it in the legacy driver or the specsheets.

> diff --git a/drivers/net/wireless/rt2x00/rt2500pci.h b/drivers/net/wireless/rt2x00/rt2500pci.h
> index e135247..8a69af3 100644
> --- a/drivers/net/wireless/rt2x00/rt2500pci.h
> +++ b/drivers/net/wireless/rt2x00/rt2500pci.h
> @@ -1060,7 +1060,7 @@
>   * GEO: Default geography setting for device.
>   */
>  #define EEPROM_GEOGRAPHY		0x12
> -#define EEPROM_GEOGRAPHY_GEO		FIELD16(0x0f00)
> +#define EEPROM_GEOGRAPHY_GEO		FIELD16(0xff00)

Legacy driver uses 0x0f00, and the definition indicates the max value is 7,
so extending the definition doesn't seem correct.

> +enum {
> +	RT2X00_REGION_FCC = 0,
> +	RT2X00_REGION_IC = 1,
> +	RT2X00_REGION_ETSI = 2,
> +	RT2X00_REGION_SPAIN = 3,
> +	RT2X00_REGION_FRANCE = 4,
> +	RT2X00_REGION_MKK = 5,
> +	RT2X00_REGION_MKK1 = 6,
> +	RT2X00_REGION_ISRAEL = 7,
> +};

This belongs in rt2x00reg.h with comments (also please give the enum a name,
so it can be used as type).

> +static inline char *rt2x00_region2alpha(u16 region)
> +{
> +	char *alpha2;
> +
> +	switch (region) {
> +	case RT2X00_REGION_FCC:
> +		alpha2 = "US";
> +		break;
> +	case RT2X00_REGION_IC:
> +		alpha2 = "CA";
> +		break;
> +	case RT2X00_REGION_ETSI:
> +		alpha2 = "DE";
> +		break;
> +	case RT2X00_REGION_SPAIN:
> +		alpha2 = "ES";
> +		break;
> +	case RT2X00_REGION_FRANCE:
> +		alpha2 = "FR";
> +		break;
> +	case RT2X00_REGION_MKK:
> +		alpha2 = "JP";
> +		break;
> +	case RT2X00_REGION_MKK1:
> +		alpha2 = "JP";
> +		break;
> +	case RT2X00_REGION_ISRAEL:
> +		alpha2 = "IL";
> +		break;
> +	default:
> +		alpha2 = NULL;
> +		break;
> +	}
> +
> +	return alpha2;
> +}

This would look nicer if all the alpha2 codes where either in an array:

static const char* alpha2_map[] = {
	"US",
	"CA",
	...
};

So we can simply translate the enum value to alpha2 by doing:
	alpha2_map[RT2X00_REGION_ETSI]

Or do somthing similar as zd1211rw, with the structure:

struct alpha2_entry {
	enum reg_domain;
	char alpha2[2];
}

static const char* alpha2_map[] = {
	{RT2X00_REGION_FCC, "US"},
	{RT2X00_REGION_IC, "CA"},
	...
};

and a for loop to find the correct alpha2 code.

Thanks

Ivo

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Luis R. Rodriguez]

On Mon, Jan 05, 2009 at 02:21:46PM -0800, Ivo van Doorn wrote:
> On Monday 05 January 2009, Gertjan van Wingerde wrote:
> > On 01/05/09 21:08, Luis R. Rodriguez wrote:
> > > On Sun, Jan 04, 2009 at 11:21:10AM -0800, Ivo van Doorn wrote:
> > >
> > >> rt2500pci and rt2500usb contain a special field in the EEPROM
> > >> which indicates which regulatory domain the card belongs to.
> > >> This code can easily be translated into a country code which
> > >> we can send as alpha2 hint for CRDA.
> > >>
> > >> Please note that most cards will have 0xffff as EEPROM value,
> > >> and thus do not provide a regulatory hint through the EEPROM.
> > >>
> > >> Signed-off-by: Ivo van Doorn<IvDoorn@gmail.com>
> 
> John: Please drop this patch, a more correct patch should be merged later
> which is based on the code from Gertjan.
> 
> > > I believe regulatory_hint() is being called before the ieee80211_register_hw()
> > > call. This is not a requirement right now but I believe this should be the case
> > > in the future as we want cfg80211 to keep track a few things for the driver, like
> > > the regulatory domain it wants in case of conflicts with other drivers. I'm working
> > > on this right now so just wanted to throw that out there.
> > >
> > > Is it possible to move the regulatory_hint() to be used after ieee80211_register_hw()
> > > is called?
> 
> Sure, I was a bit doubting about the timing of the call, I noticed that zd1211rw called it during the start()
> callback function. Would that be the best location? Or right after ieee80211_register_hw()?

Doesn't really matter, so long as its after ieee80211_register_hw() has been called
would be nice.

> > The things that kept me from submitting it so far are:
> > 1. The conversion to a country code for the a-band EEPROM values is not complete / correct. So far I've been unable to map the possible code described in the EEPROM spec to real country codes.
> 
> I recall there would be a possibility to provide a custom definition for the domain, not sure if that ever went in.

Nope, we determined its not necessary because it was only required for Intel driver and
we found a better solution for them.

> > 2. I'm still puzzled how to handle the two different values that the EEPROM has, namely one for the bg band and one for the a band. I've handled it by registering the one associated with the configured band, but that seems to be unlikely to be correct. I still haven't found a better way to handle this.
> 
> Because of this I hadn't looked very deep into rt61 and rt73 yet.
> 
> > The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.
> 
> For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
> comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.

Based on the documentation from the EEPROM for all devices I read that its recommended
that the EEPROM *not be relied on for the regulatory domain*, instead it recommends the
windows registry be used.

Based on tests for the devices with only one band, do are you seeing an actual regulatory
domain in the EEPROM?

To deal with the issue of having two separate EEPROM values for a regulatory domain
and since the documentation indicates to not rely on it I would advise to allow users
to be compliant by selecting the country they are in. wpa_supplicant has support for
selecting country now, and so does iw. Eventually I see Network Manager letting users
select the country. But you guys are the maintainers and developers so you will know
better.

  Luis

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Ivo van Doorn]

> > Sure, I was a bit doubting about the timing of the call, I noticed that zd1211rw called it during the start()
> > callback function. Would that be the best location? Or right after ieee80211_register_hw()?
> 
> Doesn't really matter, so long as its after ieee80211_register_hw() has been called
> would be nice.

Ok.

> > > 2. I'm still puzzled how to handle the two different values that the EEPROM has, namely one for the bg band and one for the a band. I've handled it by registering the one associated with the configured band, but that seems to be unlikely to be correct. I still haven't found a better way to handle this.
> > 
> > Because of this I hadn't looked very deep into rt61 and rt73 yet.
> > 
> > > The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.
> > 
> > For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
> > comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.
> 
> Based on the documentation from the EEPROM for all devices I read that its recommended
> that the EEPROM *not be relied on for the regulatory domain*, instead it recommends the
> windows registry be used.
>
> Based on tests for the devices with only one band, do are you seeing an actual regulatory
> domain in the EEPROM?

I have to check, but I don't think I have any hardware with valid domain values.
 
> To deal with the issue of having two separate EEPROM values for a regulatory domain
> and since the documentation indicates to not rely on it I would advise to allow users
> to be compliant by selecting the country they are in. wpa_supplicant has support for
> selecting country now, and so does iw. Eventually I see Network Manager letting users
> select the country. But you guys are the maintainers and developers so you will know
> better.

Well it is fine with me,  understood from earlier discussion that it was advised that drivers
attempted to set the domain if they could. Hence the reason I had added reading the EEPROM
for domain values to the TODO list. But it is true that it is quite rare that there are valid values
for it. So it would be fine with me by letting the user handle it completely.

Ivo

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Luis R. Rodriguez]

On Tue, Jan 06, 2009 at 09:32:20AM -0800, Ivo van Doorn wrote:
> > > Sure, I was a bit doubting about the timing of the call, I noticed that zd1211rw called it during the start()
> > > callback function. Would that be the best location? Or right after ieee80211_register_hw()?
> >
> > Doesn't really matter, so long as its after ieee80211_register_hw() has been called
> > would be nice.
> 
> Ok.
> 
> > > > 2. I'm still puzzled how to handle the two different values that the EEPROM has, namely one for the bg band and one for the a band. I've handled it by registering the one associated with the configured band, but that seems to be unlikely to be correct. I still haven't found a better way to handle this.
> > >
> > > Because of this I hadn't looked very deep into rt61 and rt73 yet.
> > >
> > > > The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.
> > >
> > > For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
> > > comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.
> >
> > Based on the documentation from the EEPROM for all devices I read that its recommended
> > that the EEPROM *not be relied on for the regulatory domain*, instead it recommends the
> > windows registry be used.
> >
> > Based on tests for the devices with only one band, do are you seeing an actual regulatory
> > domain in the EEPROM?
> 
> I have to check, but I don't think I have any hardware with valid domain values.
> 
> > To deal with the issue of having two separate EEPROM values for a regulatory domain
> > and since the documentation indicates to not rely on it I would advise to allow users
> > to be compliant by selecting the country they are in. wpa_supplicant has support for
> > selecting country now, and so does iw. Eventually I see Network Manager letting users
> > select the country. But you guys are the maintainers and developers so you will know
> > better.
> 
> Well it is fine with me,  understood from earlier discussion that it was advised that drivers
> attempted to set the domain if they could. Hence the reason I had added reading the EEPROM
> for domain values to the TODO list. But it is true that it is quite rare that there are valid values
> for it. So it would be fine with me by letting the user handle it completely.

I see -- well if there are *some* cards that do have valid EEPROM values then it seems worth it
to do the actual regulatory_hint(), for dual band cards you can probably just not support it. But
its up to you guys. Just my advice based on the documentation I have read so far.

  Luis

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Ivo van Doorn]

On Tuesday 06 January 2009, Luis R. Rodriguez wrote:
> On Tue, Jan 06, 2009 at 09:32:20AM -0800, Ivo van Doorn wrote:
> > > > Sure, I was a bit doubting about the timing of the call, I noticed that zd1211rw called it during the start()
> > > > callback function. Would that be the best location? Or right after ieee80211_register_hw()?
> > >
> > > Doesn't really matter, so long as its after ieee80211_register_hw() has been called
> > > would be nice.
> > 
> > Ok.
> > 
> > > > > 2. I'm still puzzled how to handle the two different values that the EEPROM has, namely one for the bg band and one for the a band. I've handled it by registering the one associated with the configured band, but that seems to be unlikely to be correct. I still haven't found a better way to handle this.
> > > >
> > > > Because of this I hadn't looked very deep into rt61 and rt73 yet.
> > > >
> > > > > The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.
> > > >
> > > > For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
> > > > comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.
> > >
> > > Based on the documentation from the EEPROM for all devices I read that its recommended
> > > that the EEPROM *not be relied on for the regulatory domain*, instead it recommends the
> > > windows registry be used.
> > >
> > > Based on tests for the devices with only one band, do are you seeing an actual regulatory
> > > domain in the EEPROM?
> > 
> > I have to check, but I don't think I have any hardware with valid domain values.
> > 
> > > To deal with the issue of having two separate EEPROM values for a regulatory domain
> > > and since the documentation indicates to not rely on it I would advise to allow users
> > > to be compliant by selecting the country they are in. wpa_supplicant has support for
> > > selecting country now, and so does iw. Eventually I see Network Manager letting users
> > > select the country. But you guys are the maintainers and developers so you will know
> > > better.
> > 
> > Well it is fine with me,  understood from earlier discussion that it was advised that drivers
> > attempted to set the domain if they could. Hence the reason I had added reading the EEPROM
> > for domain values to the TODO list. But it is true that it is quite rare that there are valid values
> > for it. So it would be fine with me by letting the user handle it completely.
> 
> I see -- well if there are *some* cards that do have valid EEPROM values then it seems worth it
> to do the actual regulatory_hint(), for dual band cards you can probably just not support it. But
> its up to you guys. Just my advice based on the documentation I have read so far.

Ok.

Gertjan, do you know if there is any hardware with valid GEO data in the EEPROM?

Ivo

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Gertjan van Wingerde]

On 01/06/09 18:47, Ivo van Doorn wrote:
> On Tuesday 06 January 2009, Luis R. Rodriguez wrote:
>    
>> On Tue, Jan 06, 2009 at 09:32:20AM -0800, Ivo van Doorn wrote:
>>      
>>>>>> 2. I'm still puzzled how to handle the two different values that the EEPROM has, namely one for the bg band and one for the a band. I've handled it by registering the one associated with the configured band, but that seems to be unlikely to be correct. I still haven't found a better way to handle this.
>>>>>>              
>>>>> Because of this I hadn't looked very deep into rt61 and rt73 yet.
>>>>>
>>>>>            
>>>>>> The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.
>>>>>>              
>>>>> For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
>>>>> comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.
>>>>>            
>>>> Based on the documentation from the EEPROM for all devices I read that its recommended
>>>> that the EEPROM *not be relied on for the regulatory domain*, instead it recommends the
>>>> windows registry be used.
>>>>
>>>> Based on tests for the devices with only one band, do are you seeing an actual regulatory
>>>> domain in the EEPROM?
>>>>          
>>> I have to check, but I don't think I have any hardware with valid domain values.
>>>
>>>        
>>>> To deal with the issue of having two separate EEPROM values for a regulatory domain
>>>> and since the documentation indicates to not rely on it I would advise to allow users
>>>> to be compliant by selecting the country they are in. wpa_supplicant has support for
>>>> selecting country now, and so does iw. Eventually I see Network Manager letting users
>>>> select the country. But you guys are the maintainers and developers so you will know
>>>> better.
>>>>          
>>> Well it is fine with me,  understood from earlier discussion that it was advised that drivers
>>> attempted to set the domain if they could. Hence the reason I had added reading the EEPROM
>>> for domain values to the TODO list. But it is true that it is quite rare that there are valid values
>>> for it. So it would be fine with me by letting the user handle it completely.
>>>        
>> I see -- well if there are *some* cards that do have valid EEPROM values then it seems worth it
>> to do the actual regulatory_hint(), for dual band cards you can probably just not support it. But
>> its up to you guys. Just my advice based on the documentation I have read so far.
>>      
>
> Ok.
>
> Gertjan, do you know if there is any hardware with valid GEO data in the EEPROM?
>    

As mentioned in my previous email, I do have devices that have valid GEO 
data in the EEPROM. So, we should be able to use that.
Also, for the dual band cards, it does seem that at least the numerical 
values are similar for both bands (although I'm not sure that same 
numerical values means same regulatory domain). This is at least the 
case on all the cards that I own.

FYI: The legacy drivers do use the information in the EEPROM to 
initialize the internal administration of regulatory information, but 
allow the end-user to override that via config-file or via private wext 
call. It would be good to have a similar possibility for rt2x00.

---
Gertjan.

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Luis R. Rodriguez]

On Tue, Jan 06, 2009 at 12:39:34PM -0800, Gertjan van Wingerde wrote:
> On 01/06/09 18:47, Ivo van Doorn wrote:
> > On Tuesday 06 January 2009, Luis R. Rodriguez wrote:
> >
> >> On Tue, Jan 06, 2009 at 09:32:20AM -0800, Ivo van Doorn wrote:
> >>
> >>>>>> 2. I'm still puzzled how to handle the two different values that the EEPROM has, namely one for the bg band and one for the a band. I've handled it by registering the one associated with the configured band, but that seems to be unlikely to be correct. I still haven't found a better way to handle this.
> >>>>>>
> >>>>> Because of this I hadn't looked very deep into rt61 and rt73 yet.
> >>>>>
> >>>>>
> >>>>>> The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.
> >>>>>>
> >>>>> For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
> >>>>> comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.
> >>>>>
> >>>> Based on the documentation from the EEPROM for all devices I read that its recommended
> >>>> that the EEPROM *not be relied on for the regulatory domain*, instead it recommends the
> >>>> windows registry be used.
> >>>>
> >>>> Based on tests for the devices with only one band, do are you seeing an actual regulatory
> >>>> domain in the EEPROM?
> >>>>
> >>> I have to check, but I don't think I have any hardware with valid domain values.
> >>>
> >>>
> >>>> To deal with the issue of having two separate EEPROM values for a regulatory domain
> >>>> and since the documentation indicates to not rely on it I would advise to allow users
> >>>> to be compliant by selecting the country they are in. wpa_supplicant has support for
> >>>> selecting country now, and so does iw. Eventually I see Network Manager letting users
> >>>> select the country. But you guys are the maintainers and developers so you will know
> >>>> better.
> >>>>
> >>> Well it is fine with me,  understood from earlier discussion that it was advised that drivers
> >>> attempted to set the domain if they could. Hence the reason I had added reading the EEPROM
> >>> for domain values to the TODO list. But it is true that it is quite rare that there are valid values
> >>> for it. So it would be fine with me by letting the user handle it completely.
> >>>
> >> I see -- well if there are *some* cards that do have valid EEPROM values then it seems worth it
> >> to do the actual regulatory_hint(), for dual band cards you can probably just not support it. But
> >> its up to you guys. Just my advice based on the documentation I have read so far.
> >>
> >
> > Ok.
> >
> > Gertjan, do you know if there is any hardware with valid GEO data in the EEPROM?
> >
> 
> As mentioned in my previous email, I do have devices that have valid GEO
> data in the EEPROM. So, we should be able to use that.
> Also, for the dual band cards, it does seem that at least the numerical
> values are similar for both bands (although I'm not sure that same
> numerical values means same regulatory domain). This is at least the
> case on all the cards that I own.

If that's the case and since dual band cards will most likely have 2ghz support
why not just provide regulatory_hint() based on the 2ghz band all the time?

> FYI: The legacy drivers do use the information in the EEPROM to
> initialize the internal administration of regulatory information, but
> allow the end-user to override that via config-file or via private wext
> call. It would be good to have a similar possibility for rt2x00.

We allow users to change regulatory domain, please see:

http://wireless.kernel.org/en/developers/Regulatory/CRDA#Changingregulatorydomains

  Luis

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Ivo van Doorn]

On Tuesday 06 January 2009, Luis R. Rodriguez wrote:
> On Tue, Jan 06, 2009 at 12:39:34PM -0800, Gertjan van Wingerde wrote:
> > On 01/06/09 18:47, Ivo van Doorn wrote:
> > > On Tuesday 06 January 2009, Luis R. Rodriguez wrote:
> > >
> > >> On Tue, Jan 06, 2009 at 09:32:20AM -0800, Ivo van Doorn wrote:
> > >>
> > >>>>>> 2. I'm still puzzled how to handle the two different values that the EEPROM has, namely one for the bg band and one for the a band. I've handled it by registering the one associated with the configured band, but that seems to be unlikely to be correct. I still haven't found a better way to handle this.
> > >>>>>>
> > >>>>> Because of this I hadn't looked very deep into rt61 and rt73 yet.
> > >>>>>
> > >>>>>
> > >>>>>> The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.
> > >>>>>>
> > >>>>> For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
> > >>>>> comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.
> > >>>>>
> > >>>> Based on the documentation from the EEPROM for all devices I read that its recommended
> > >>>> that the EEPROM *not be relied on for the regulatory domain*, instead it recommends the
> > >>>> windows registry be used.
> > >>>>
> > >>>> Based on tests for the devices with only one band, do are you seeing an actual regulatory
> > >>>> domain in the EEPROM?
> > >>>>
> > >>> I have to check, but I don't think I have any hardware with valid domain values.
> > >>>
> > >>>
> > >>>> To deal with the issue of having two separate EEPROM values for a regulatory domain
> > >>>> and since the documentation indicates to not rely on it I would advise to allow users
> > >>>> to be compliant by selecting the country they are in. wpa_supplicant has support for
> > >>>> selecting country now, and so does iw. Eventually I see Network Manager letting users
> > >>>> select the country. But you guys are the maintainers and developers so you will know
> > >>>> better.
> > >>>>
> > >>> Well it is fine with me,  understood from earlier discussion that it was advised that drivers
> > >>> attempted to set the domain if they could. Hence the reason I had added reading the EEPROM
> > >>> for domain values to the TODO list. But it is true that it is quite rare that there are valid values
> > >>> for it. So it would be fine with me by letting the user handle it completely.
> > >>>
> > >> I see -- well if there are *some* cards that do have valid EEPROM values then it seems worth it
> > >> to do the actual regulatory_hint(), for dual band cards you can probably just not support it. But
> > >> its up to you guys. Just my advice based on the documentation I have read so far.
> > >>
> > >
> > > Ok.
> > >
> > > Gertjan, do you know if there is any hardware with valid GEO data in the EEPROM?
> > >
> > 
> > As mentioned in my previous email, I do have devices that have valid GEO
> > data in the EEPROM. So, we should be able to use that.
> > Also, for the dual band cards, it does seem that at least the numerical
> > values are similar for both bands (although I'm not sure that same
> > numerical values means same regulatory domain). This is at least the
> > case on all the cards that I own.
> 
> If that's the case and since dual band cards will most likely have 2ghz support
> why not just provide regulatory_hint() based on the 2ghz band all the time?

Sounds like the most reasonable solution to me as well.

Ivo

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Gertjan van Wingerde]

On 01/06/09 22:51, Ivo van Doorn wrote:
> On Tuesday 06 January 2009, Luis R. Rodriguez wrote:
>    
>> On Tue, Jan 06, 2009 at 12:39:34PM -0800, Gertjan van Wingerde wrote:
>>      
>>> On 01/06/09 18:47, Ivo van Doorn wrote:
>>>        
>>>> On Tuesday 06 January 2009, Luis R. Rodriguez wrote:
>>>>
>>>>          
>>>>> On Tue, Jan 06, 2009 at 09:32:20AM -0800, Ivo van Doorn wrote:
>>>>>
>>>>>            
>>>>>>>>> 2. I'm still puzzled how to handle the two different values that the EEPROM has, namely one for the bg band and one for the a band. I've handled it by registering the one associated with the configured band, but that seems to be unlikely to be correct. I still haven't found a better way to handle this.
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>> Because of this I hadn't looked very deep into rt61 and rt73 yet.
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>>>> The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>> For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
>>>>>>>> comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.
>>>>>>>>
>>>>>>>>                  
>>>>>>> Based on the documentation from the EEPROM for all devices I read that its recommended
>>>>>>> that the EEPROM *not be relied on for the regulatory domain*, instead it recommends the
>>>>>>> windows registry be used.
>>>>>>>
>>>>>>> Based on tests for the devices with only one band, do are you seeing an actual regulatory
>>>>>>> domain in the EEPROM?
>>>>>>>
>>>>>>>                
>>>>>> I have to check, but I don't think I have any hardware with valid domain values.
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> To deal with the issue of having two separate EEPROM values for a regulatory domain
>>>>>>> and since the documentation indicates to not rely on it I would advise to allow users
>>>>>>> to be compliant by selecting the country they are in. wpa_supplicant has support for
>>>>>>> selecting country now, and so does iw. Eventually I see Network Manager letting users
>>>>>>> select the country. But you guys are the maintainers and developers so you will know
>>>>>>> better.
>>>>>>>
>>>>>>>                
>>>>>> Well it is fine with me,  understood from earlier discussion that it was advised that drivers
>>>>>> attempted to set the domain if they could. Hence the reason I had added reading the EEPROM
>>>>>> for domain values to the TODO list. But it is true that it is quite rare that there are valid values
>>>>>> for it. So it would be fine with me by letting the user handle it completely.
>>>>>>
>>>>>>              
>>>>> I see -- well if there are *some* cards that do have valid EEPROM values then it seems worth it
>>>>> to do the actual regulatory_hint(), for dual band cards you can probably just not support it. But
>>>>> its up to you guys. Just my advice based on the documentation I have read so far.
>>>>>
>>>>>            
>>>> Ok.
>>>>
>>>> Gertjan, do you know if there is any hardware with valid GEO data in the EEPROM?
>>>>
>>>>          
>>> As mentioned in my previous email, I do have devices that have valid GEO
>>> data in the EEPROM. So, we should be able to use that.
>>> Also, for the dual band cards, it does seem that at least the numerical
>>> values are similar for both bands (although I'm not sure that same
>>> numerical values means same regulatory domain). This is at least the
>>> case on all the cards that I own.
>>>        
>> If that's the case and since dual band cards will most likely have 2ghz support
>> why not just provide regulatory_hint() based on the 2ghz band all the time?
>>      
>
> Sounds like the most reasonable solution to me as well.

I had a *slightly* more sophisticated model in mind: Check for dual-band 
devices whether the EEPROM values match. If they do, provide the 
regulatory_hint(), if they don't then just log an error, stating that 
the EEPROM cannot make up its mind in which geography it belongs. Just 
to prevent some unexpected behavior for devices that don't have sane 
EEPROM values.

However, that is all based on the assumption that we can match the 
numerical values of the two band geography domains. So far I haven't 
been able to establish that, and, moreover, the a-band field allows for 
values 0-10 where the bg-band field allows for values 0-7. So, we have 
to start matching these values against their defined allowed channels, 
and against the regulatory definitions, to see if we can actually match 
the values.

---
Gertjan

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Luis R. Rodriguez]

On Tue, Jan 06, 2009 at 02:11:16PM -0800, Gertjan van Wingerde wrote:
> On 01/06/09 22:51, Ivo van Doorn wrote:
> > On Tuesday 06 January 2009, Luis R. Rodriguez wrote:
> >>>>
> >>>> Gertjan, do you know if there is any hardware with valid GEO data in the EEPROM?
> >>>>
> >>>>
> >>> As mentioned in my previous email, I do have devices that have valid GEO
> >>> data in the EEPROM. So, we should be able to use that.
> >>> Also, for the dual band cards, it does seem that at least the numerical
> >>> values are similar for both bands (although I'm not sure that same
> >>> numerical values means same regulatory domain). This is at least the
> >>> case on all the cards that I own.
> >>>
> >> If that's the case and since dual band cards will most likely have 2ghz support
> >> why not just provide regulatory_hint() based on the 2ghz band all the time?
> >>
> >
> > Sounds like the most reasonable solution to me as well.
> 
> I had a *slightly* more sophisticated model in mind: Check for dual-band
> devices whether the EEPROM values match. If they do, provide the
> regulatory_hint(), if they don't then just log an error, stating that
> the EEPROM cannot make up its mind in which geography it belongs. Just
> to prevent some unexpected behavior for devices that don't have sane
> EEPROM values.

The documentation advises for the EEPROM to not be relied on though
so if you expect the EEPROM regulatory domain code to be valid you
are going against the documentation.

> However, that is all based on the assumption that we can match the
> numerical values of the two band geography domains. So far I haven't
> been able to establish that, and, moreover, the a-band field allows for
> values 0-10 where the bg-band field allows for values 0-7. So, we have
> to start matching these values against their defined allowed channels,
> and against the regulatory definitions, to see if we can actually match
> the values.

Yeah -- pretty messy...

BTW you may want to look at the patch:

[PATCH 05/12] cfg80211: add regulatory_set_custom_rd()

Which you can also use if you have very custom regulatory domains which
you must follow. We are using that for world regulatory domains which
are custom, for example. I would advise against using this for a country
regulatory hint but if you have no other option then that can be used.

I'm still inclined to believe the documentation though -- again you may
want to check with the vendor.

  Luis

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Gertjan van Wingerde]

On 01/06/09 00:45, Luis R. Rodriguez wrote:
> On Mon, Jan 05, 2009 at 02:21:46PM -0800, Ivo van Doorn wrote:
>    
>> On Monday 05 January 2009, Gertjan van Wingerde wrote:
>>      
>>> On 01/05/09 21:08, Luis R. Rodriguez wrote:
>>>        
>>> The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.
>>>        
>> For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
>> comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.
>>      
>
> Based on the documentation from the EEPROM for all devices I read that its recommended
> that the EEPROM *not be relied on for the regulatory domain*, instead it recommends the
> windows registry be used.
>
> Based on tests for the devices with only one band, do are you seeing an actual regulatory
> domain in the EEPROM?
>
> To deal with the issue of having two separate EEPROM values for a regulatory domain
> and since the documentation indicates to not rely on it I would advise to allow users
> to be compliant by selecting the country they are in. wpa_supplicant has support for
> selecting country now, and so does iw. Eventually I see Network Manager letting users
> select the country. But you guys are the maintainers and developers so you will know
> better.
>    

My tests indicate that there are devices out there that have this 
information set in the EEPROM. Based on tests with my own patch, and my 
own devices, I have been able to determine the following:

1. rt2400pci --> don't know, don't own a rt2400pci device.
2. rt2500pci --> don't know, don't own a rt2500pci device anymore.
3. rt2500usb --> my e-tech device (not sure which type; the device 
doesn't say it) has an actual domain set for the bg band.
4. rt61pci --> my Sitecom WL151 device does not contain actual domain 
information.
5. rt73usb --> my Sitecom WL113-002 device does contain actual domain 
information, and the codes for the bg band and a band are the same.
6. rt2800pci --> my Sitecom WL182 device does contain actual domain 
information, and the codes for the bg band and a band are the same.
7. rt2800usb --> my Sitecom WL181 device does contain actual domain 
information, and the codes for the bg band and a band are the same.

So, there are devices out there that do contain "meaningful" regulatory 
information.

Luis, the definitions for the a-band EEPROM codes only give the channel 
numbers, it doesn't indicate a real "country". Is there any way we can 
check whether these sets of channels are actually consistent with the 
regulations of specific countries?

---
Gertjan.

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Luis R. Rodriguez]

On Tue, Jan 06, 2009 at 12:32:47PM -0800, Gertjan van Wingerde wrote:
> On 01/06/09 00:45, Luis R. Rodriguez wrote:
> > On Mon, Jan 05, 2009 at 02:21:46PM -0800, Ivo van Doorn wrote:
> >
> >> On Monday 05 January 2009, Gertjan van Wingerde wrote:
> >>
> >>> On 01/05/09 21:08, Luis R. Rodriguez wrote:
> >>>
> >>> The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.
> >>>
> >> For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
> >> comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.
> >>
> >
> > Based on the documentation from the EEPROM for all devices I read that its recommended
> > that the EEPROM *not be relied on for the regulatory domain*, instead it recommends the
> > windows registry be used.
> >
> > Based on tests for the devices with only one band, do are you seeing an actual regulatory
> > domain in the EEPROM?
> >
> > To deal with the issue of having two separate EEPROM values for a regulatory domain
> > and since the documentation indicates to not rely on it I would advise to allow users
> > to be compliant by selecting the country they are in. wpa_supplicant has support for
> > selecting country now, and so does iw. Eventually I see Network Manager letting users
> > select the country. But you guys are the maintainers and developers so you will know
> > better.
> >
> 
> My tests indicate that there are devices out there that have this
> information set in the EEPROM. Based on tests with my own patch, and my
> own devices, I have been able to determine the following:
> 
> 1. rt2400pci --> don't know, don't own a rt2400pci device.
> 2. rt2500pci --> don't know, don't own a rt2500pci device anymore.
> 3. rt2500usb --> my e-tech device (not sure which type; the device
> doesn't say it) has an actual domain set for the bg band.
> 4. rt61pci --> my Sitecom WL151 device does not contain actual domain
> information.
> 5. rt73usb --> my Sitecom WL113-002 device does contain actual domain
> information, and the codes for the bg band and a band are the same.
> 6. rt2800pci --> my Sitecom WL182 device does contain actual domain
> information, and the codes for the bg band and a band are the same.
> 7. rt2800usb --> my Sitecom WL181 device does contain actual domain
> information, and the codes for the bg band and a band are the same.
> 
> So, there are devices out there that do contain "meaningful" regulatory
> information.
> 
> Luis, the definitions for the a-band EEPROM codes only give the channel
> numbers, it doesn't indicate a real "country". Is there any way we can
> check whether these sets of channels are actually consistent with the
> regulations of specific countries?

You can help contribute to the wireless-regdb and check that the valid
channels apply there.

  Luis

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Gertjan van Wingerde]

On 01/06/09 21:47, Luis R. Rodriguez wrote:
> On Tue, Jan 06, 2009 at 12:32:47PM -0800, Gertjan van Wingerde wrote:
>    
>> On 01/06/09 00:45, Luis R. Rodriguez wrote:
>>      
>>> On Mon, Jan 05, 2009 at 02:21:46PM -0800, Ivo van Doorn wrote:
>>>
>>>        
>>>> On Monday 05 January 2009, Gertjan van Wingerde wrote:
>>>>
>>>>          
>>>>> On 01/05/09 21:08, Luis R. Rodriguez wrote:
>>>>>
>>>>> The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.
>>>>>
>>>>>            
>>>> For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
>>>> comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.
>>>>
>>>>          
>>> Based on the documentation from the EEPROM for all devices I read that its recommended
>>> that the EEPROM *not be relied on for the regulatory domain*, instead it recommends the
>>> windows registry be used.
>>>
>>> Based on tests for the devices with only one band, do are you seeing an actual regulatory
>>> domain in the EEPROM?
>>>
>>> To deal with the issue of having two separate EEPROM values for a regulatory domain
>>> and since the documentation indicates to not rely on it I would advise to allow users
>>> to be compliant by selecting the country they are in. wpa_supplicant has support for
>>> selecting country now, and so does iw. Eventually I see Network Manager letting users
>>> select the country. But you guys are the maintainers and developers so you will know
>>> better.
>>>
>>>        
>> My tests indicate that there are devices out there that have this
>> information set in the EEPROM. Based on tests with my own patch, and my
>> own devices, I have been able to determine the following:
>>
>> 1. rt2400pci -->  don't know, don't own a rt2400pci device.
>> 2. rt2500pci -->  don't know, don't own a rt2500pci device anymore.
>> 3. rt2500usb -->  my e-tech device (not sure which type; the device
>> doesn't say it) has an actual domain set for the bg band.
>> 4. rt61pci -->  my Sitecom WL151 device does not contain actual domain
>> information.
>> 5. rt73usb -->  my Sitecom WL113-002 device does contain actual domain
>> information, and the codes for the bg band and a band are the same.
>> 6. rt2800pci -->  my Sitecom WL182 device does contain actual domain
>> information, and the codes for the bg band and a band are the same.
>> 7. rt2800usb -->  my Sitecom WL181 device does contain actual domain
>> information, and the codes for the bg band and a band are the same.
>>
>> So, there are devices out there that do contain "meaningful" regulatory
>> information.
>>
>> Luis, the definitions for the a-band EEPROM codes only give the channel
>> numbers, it doesn't indicate a real "country". Is there any way we can
>> check whether these sets of channels are actually consistent with the
>> regulations of specific countries?
>>      
>
> You can help contribute to the wireless-regdb and check that the valid
> channels apply there.
>    

Well, the trouble I'm having is to match the allowed values and channels 
against the regdb, to see to which countries each of the values map, if any.
I'm a bit illiterate on channel assignments etc., so I don't know how to 
do the math from channel number to frequency, and all the other stuff 
that is in the regdb.

---
Gertjan.

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Luis R. Rodriguez]

On Tue, Jan 6, 2009 at 2:15 PM, Gertjan van Wingerde
<gwingerde@kpnplanet.nl> wrote:
> On 01/06/09 21:47, Luis R. Rodriguez wrote:
>>
>> On Tue, Jan 06, 2009 at 12:32:47PM -0800, Gertjan van Wingerde wrote:
>>
>>>
>>> On 01/06/09 00:45, Luis R. Rodriguez wrote:
>>>
>>>>
>>>> On Mon, Jan 05, 2009 at 02:21:46PM -0800, Ivo van Doorn wrote:
>>>>
>>>>
>>>>>
>>>>> On Monday 05 January 2009, Gertjan van Wingerde wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On 01/05/09 21:08, Luis R. Rodriguez wrote:
>>>>>>
>>>>>> The problem isn't there for the bits that Ivo sent, as the rt2500
>>>>>> devices don't support the a band.
>>>>>>
>>>>>>
>>>>>
>>>>> For rt2500pci and rt2500usb there are chipsets which support 5GHz (they
>>>>> are rare, but they do exist),
>>>>> comments for the Ralink drivers indicate they simply didn't add the
>>>>> regulatory domain definitions yet.
>>>>>
>>>>>
>>>>
>>>> Based on the documentation from the EEPROM for all devices I read that
>>>> its recommended
>>>> that the EEPROM *not be relied on for the regulatory domain*, instead it
>>>> recommends the
>>>> windows registry be used.
>>>>
>>>> Based on tests for the devices with only one band, do are you seeing an
>>>> actual regulatory
>>>> domain in the EEPROM?
>>>>
>>>> To deal with the issue of having two separate EEPROM values for a
>>>> regulatory domain
>>>> and since the documentation indicates to not rely on it I would advise
>>>> to allow users
>>>> to be compliant by selecting the country they are in. wpa_supplicant has
>>>> support for
>>>> selecting country now, and so does iw. Eventually I see Network Manager
>>>> letting users
>>>> select the country. But you guys are the maintainers and developers so
>>>> you will know
>>>> better.
>>>>
>>>>
>>>
>>> My tests indicate that there are devices out there that have this
>>> information set in the EEPROM. Based on tests with my own patch, and my
>>> own devices, I have been able to determine the following:
>>>
>>> 1. rt2400pci -->  don't know, don't own a rt2400pci device.
>>> 2. rt2500pci -->  don't know, don't own a rt2500pci device anymore.
>>> 3. rt2500usb -->  my e-tech device (not sure which type; the device
>>> doesn't say it) has an actual domain set for the bg band.
>>> 4. rt61pci -->  my Sitecom WL151 device does not contain actual domain
>>> information.
>>> 5. rt73usb -->  my Sitecom WL113-002 device does contain actual domain
>>> information, and the codes for the bg band and a band are the same.
>>> 6. rt2800pci -->  my Sitecom WL182 device does contain actual domain
>>> information, and the codes for the bg band and a band are the same.
>>> 7. rt2800usb -->  my Sitecom WL181 device does contain actual domain
>>> information, and the codes for the bg band and a band are the same.
>>>
>>> So, there are devices out there that do contain "meaningful" regulatory
>>> information.
>>>
>>> Luis, the definitions for the a-band EEPROM codes only give the channel
>>> numbers, it doesn't indicate a real "country". Is there any way we can
>>> check whether these sets of channels are actually consistent with the
>>> regulations of specific countries?
>>>
>>
>> You can help contribute to the wireless-regdb and check that the valid
>> channels apply there.
>>
>
> Well, the trouble I'm having is to match the allowed values and channels
> against the regdb, to see to which countries each of the values map, if any.
> I'm a bit illiterate on channel assignments etc., so I don't know how to do
> the math from channel number to frequency, and all the other stuff that is
> in the regdb.

Look at net/wireless/util.c ieee80211_channel_to_frequency() for how
to do this. If all you have is channel maps then just focus on that
then.

  Luis

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Gertjan van Wingerde]

On 01/06/09 23:23, Luis R. Rodriguez wrote:
> On Tue, Jan 6, 2009 at 2:15 PM, Gertjan van Wingerde
> <gwingerde@kpnplanet.nl>  wrote:
>    
>> On 01/06/09 21:47, Luis R. Rodriguez wrote:
>>      
>>> On Tue, Jan 06, 2009 at 12:32:47PM -0800, Gertjan van Wingerde wrote:
>>>
>>>        
>>>> On 01/06/09 00:45, Luis R. Rodriguez wrote:
>>>>
>>>>          
>>>>> On Mon, Jan 05, 2009 at 02:21:46PM -0800, Ivo van Doorn wrote:
>>>>>
>>>>>
>>>>>            
>>>>>> On Monday 05 January 2009, Gertjan van Wingerde wrote:
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> On 01/05/09 21:08, Luis R. Rodriguez wrote:
>>>>>>>
>>>>>>> The problem isn't there for the bits that Ivo sent, as the rt2500
>>>>>>> devices don't support the a band.
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>> For rt2500pci and rt2500usb there are chipsets which support 5GHz (they
>>>>>> are rare, but they do exist),
>>>>>> comments for the Ralink drivers indicate they simply didn't add the
>>>>>> regulatory domain definitions yet.
>>>>>>
>>>>>>
>>>>>>              
>>>>> Based on the documentation from the EEPROM for all devices I read that
>>>>> its recommended
>>>>> that the EEPROM *not be relied on for the regulatory domain*, instead it
>>>>> recommends the
>>>>> windows registry be used.
>>>>>
>>>>> Based on tests for the devices with only one band, do are you seeing an
>>>>> actual regulatory
>>>>> domain in the EEPROM?
>>>>>
>>>>> To deal with the issue of having two separate EEPROM values for a
>>>>> regulatory domain
>>>>> and since the documentation indicates to not rely on it I would advise
>>>>> to allow users
>>>>> to be compliant by selecting the country they are in. wpa_supplicant has
>>>>> support for
>>>>> selecting country now, and so does iw. Eventually I see Network Manager
>>>>> letting users
>>>>> select the country. But you guys are the maintainers and developers so
>>>>> you will know
>>>>> better.
>>>>>
>>>>>
>>>>>            
>>>> My tests indicate that there are devices out there that have this
>>>> information set in the EEPROM. Based on tests with my own patch, and my
>>>> own devices, I have been able to determine the following:
>>>>
>>>> 1. rt2400pci -->   don't know, don't own a rt2400pci device.
>>>> 2. rt2500pci -->   don't know, don't own a rt2500pci device anymore.
>>>> 3. rt2500usb -->   my e-tech device (not sure which type; the device
>>>> doesn't say it) has an actual domain set for the bg band.
>>>> 4. rt61pci -->   my Sitecom WL151 device does not contain actual domain
>>>> information.
>>>> 5. rt73usb -->   my Sitecom WL113-002 device does contain actual domain
>>>> information, and the codes for the bg band and a band are the same.
>>>> 6. rt2800pci -->   my Sitecom WL182 device does contain actual domain
>>>> information, and the codes for the bg band and a band are the same.
>>>> 7. rt2800usb -->   my Sitecom WL181 device does contain actual domain
>>>> information, and the codes for the bg band and a band are the same.
>>>>
>>>> So, there are devices out there that do contain "meaningful" regulatory
>>>> information.
>>>>
>>>> Luis, the definitions for the a-band EEPROM codes only give the channel
>>>> numbers, it doesn't indicate a real "country". Is there any way we can
>>>> check whether these sets of channels are actually consistent with the
>>>> regulations of specific countries?
>>>>
>>>>          
>>> You can help contribute to the wireless-regdb and check that the valid
>>> channels apply there.
>>>
>>>        
>> Well, the trouble I'm having is to match the allowed values and channels
>> against the regdb, to see to which countries each of the values map, if any.
>> I'm a bit illiterate on channel assignments etc., so I don't know how to do
>> the math from channel number to frequency, and all the other stuff that is
>> in the regdb.
>>      
>
> Look at net/wireless/util.c ieee80211_channel_to_frequency() for how
> to do this. If all you have is channel maps then just focus on that
> then.
>    

OK. Will have a look at that. This will have to wait until the weekend 
tho (need to travel for work for the rest of the week).

---
Gertjan.

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Gertjan van Wingerde]

On 01/05/09 23:21, Ivo van Doorn wrote:
> On Monday 05 January 2009, Gertjan van Wingerde wrote:
>    
>> On 01/05/09 21:08, Luis R. Rodriguez wrote:
>>      
>>> On Sun, Jan 04, 2009 at 11:21:10AM -0800, Ivo van Doorn wrote:
>>>
>>>        
>>>> rt2500pci and rt2500usb contain a special field in the EEPROM
>>>> which indicates which regulatory domain the card belongs to.
>>>> This code can easily be translated into a country code which
>>>> we can send as alpha2 hint for CRDA.
>>>>
>>>> Please note that most cards will have 0xffff as EEPROM value,
>>>> and thus do not provide a regulatory hint through the EEPROM.
>>>>
>>>> Signed-off-by: Ivo van Doorn<IvDoorn@gmail.com>
>>>>          
>
> John: Please drop this patch, a more correct patch should be merged later
> which is based on the code from Gertjan.
>
>    
>>> I believe regulatory_hint() is being called before the ieee80211_register_hw()
>>> call. This is not a requirement right now but I believe this should be the case
>>> in the future as we want cfg80211 to keep track a few things for the driver, like
>>> the regulatory domain it wants in case of conflicts with other drivers. I'm working
>>> on this right now so just wanted to throw that out there.
>>>
>>> Is it possible to move the regulatory_hint() to be used after ieee80211_register_hw()
>>> is called?
>>>        
>
> Sure, I was a bit doubting about the timing of the call, I noticed that zd1211rw called it during the start()
> callback function. Would that be the best location? Or right after ieee80211_register_hw()?
>
>    
>> The things that kept me from submitting it so far are:
>> 1. The conversion to a country code for the a-band EEPROM values is not complete / correct. So far I've been unable to map the possible code described in the EEPROM spec to real country codes.
>>      
>
> I recall there would be a possibility to provide a custom definition for the domain, not sure if that ever went in.
>    

That possibility has been removed AFAIK.

>> 2. I'm still puzzled how to handle the two different values that the EEPROM has, namely one for the bg band and one for the a band. I've handled it by registering the one associated with the configured band, but that seems to be unlikely to be correct. I still haven't found a better way to handle this.
>>      
>
> Because of this I hadn't looked very deep into rt61 and rt73 yet.
>    

;-)

>    
>> The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.
>>      
>
> For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
> comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.
>    

OK. But the EEPROM definitions I got from Ralink on the Country 
information indicate that there is only a single indication in the EEPROM.

> GertJan, some comments about your patch:
>
>    
>> diff --git a/drivers/net/wireless/rt2x00/rt2400pci.h b/drivers/net/wireless/rt2x00/rt2400pci.h
>> index 9aefda4..986e428 100644
>> --- a/drivers/net/wireless/rt2x00/rt2400pci.h
>> +++ b/drivers/net/wireless/rt2x00/rt2400pci.h
>> @@ -806,6 +806,13 @@
>>   #define EEPROM_TXPOWER_2		FIELD16(0xff00)
>>
>>   /*
>> + * EEPROM geography.
>> + * GEO: Default geography setting for device.
>> + */
>> +#define EEPROM_GEOGRAPHY		0x17
>> +#define EEPROM_GEOGRAPHY_GEO		FIELD16(0xff00)
>>      
>
> Where did you find this definition? I couldn't find it in the legacy driver or the specsheets.
>    

I got an excerpt from the EEPROM definition for the rt2460 chip (which I 
received with the help of Luis). It's defined in there.

>    
>> diff --git a/drivers/net/wireless/rt2x00/rt2500pci.h b/drivers/net/wireless/rt2x00/rt2500pci.h
>> index e135247..8a69af3 100644
>> --- a/drivers/net/wireless/rt2x00/rt2500pci.h
>> +++ b/drivers/net/wireless/rt2x00/rt2500pci.h
>> @@ -1060,7 +1060,7 @@
>>    * GEO: Default geography setting for device.
>>    */
>>   #define EEPROM_GEOGRAPHY		0x12
>> -#define EEPROM_GEOGRAPHY_GEO		FIELD16(0x0f00)
>> +#define EEPROM_GEOGRAPHY_GEO		FIELD16(0xff00)
>>      
>
> Legacy driver uses 0x0f00, and the definition indicates the max value is 7,
> so extending the definition doesn't seem correct.
>    

Well, the EEPROM definition indicates that this is an 8-bit field, so 
updating it looked appropriate, although the max value indeed is 7.

>    
>> +enum {
>> +	RT2X00_REGION_FCC = 0,
>> +	RT2X00_REGION_IC = 1,
>> +	RT2X00_REGION_ETSI = 2,
>> +	RT2X00_REGION_SPAIN = 3,
>> +	RT2X00_REGION_FRANCE = 4,
>> +	RT2X00_REGION_MKK = 5,
>> +	RT2X00_REGION_MKK1 = 6,
>> +	RT2X00_REGION_ISRAEL = 7,
>> +};
>>      
>
> This belongs in rt2x00reg.h with comments (also please give the enum a name,
> so it can be used as type).
>    

OK.

>    
>> +static inline char *rt2x00_region2alpha(u16 region)
>> +{
>> +	char *alpha2;
>> +
>> +	switch (region) {
>> +	case RT2X00_REGION_FCC:
>> +		alpha2 = "US";
>> +		break;
>> +	case RT2X00_REGION_IC:
>> +		alpha2 = "CA";
>> +		break;
>> +	case RT2X00_REGION_ETSI:
>> +		alpha2 = "DE";
>> +		break;
>> +	case RT2X00_REGION_SPAIN:
>> +		alpha2 = "ES";
>> +		break;
>> +	case RT2X00_REGION_FRANCE:
>> +		alpha2 = "FR";
>> +		break;
>> +	case RT2X00_REGION_MKK:
>> +		alpha2 = "JP";
>> +		break;
>> +	case RT2X00_REGION_MKK1:
>> +		alpha2 = "JP";
>> +		break;
>> +	case RT2X00_REGION_ISRAEL:
>> +		alpha2 = "IL";
>> +		break;
>> +	default:
>> +		alpha2 = NULL;
>> +		break;
>> +	}
>> +
>> +	return alpha2;
>> +}
>>      
>
> This would look nicer if all the alpha2 codes where either in an array:
>
> static const char* alpha2_map[] = {
> 	"US",
> 	"CA",
> 	...
> };
>
> So we can simply translate the enum value to alpha2 by doing:
> 	alpha2_map[RT2X00_REGION_ETSI]
>
> Or do somthing similar as zd1211rw, with the structure:
>
> struct alpha2_entry {
> 	enum reg_domain;
> 	char alpha2[2];
> }
>
> static const char* alpha2_map[] = {
> 	{RT2X00_REGION_FCC, "US"},
> 	{RT2X00_REGION_IC, "CA"},
> 	...
> };
>
> and a for loop to find the correct alpha2 code.
>    

OK. I'll work on that when we decide to move ahead with this code.

---
Gertjan.

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Ivo van Doorn]

> >    
> >> The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.
> >>      
> >
> > For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
> > comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.
> >    
> 
> OK. But the EEPROM definitions I got from Ralink on the Country 
> information indicate that there is only a single indication in the EEPROM.

That is right, like I said the comments already indicates there the legacy code didn't contain the
definitions (yet). ;)

> > GertJan, some comments about your patch:
> >
> >    
> >> diff --git a/drivers/net/wireless/rt2x00/rt2400pci.h b/drivers/net/wireless/rt2x00/rt2400pci.h
> >> index 9aefda4..986e428 100644
> >> --- a/drivers/net/wireless/rt2x00/rt2400pci.h
> >> +++ b/drivers/net/wireless/rt2x00/rt2400pci.h
> >> @@ -806,6 +806,13 @@
> >>   #define EEPROM_TXPOWER_2		FIELD16(0xff00)
> >>
> >>   /*
> >> + * EEPROM geography.
> >> + * GEO: Default geography setting for device.
> >> + */
> >> +#define EEPROM_GEOGRAPHY		0x17
> >> +#define EEPROM_GEOGRAPHY_GEO		FIELD16(0xff00)
> >>      
> >
> > Where did you find this definition? I couldn't find it in the legacy driver or the specsheets.
> >    
> 
> I got an excerpt from the EEPROM definition for the rt2460 chip (which I 
> received with the help of Luis). It's defined in there.

I assume you mean the file RT2460_DS_P1.3.pdf, could you point me to the right pagenumber?

> >> diff --git a/drivers/net/wireless/rt2x00/rt2500pci.h b/drivers/net/wireless/rt2x00/rt2500pci.h
> >> index e135247..8a69af3 100644
> >> --- a/drivers/net/wireless/rt2x00/rt2500pci.h
> >> +++ b/drivers/net/wireless/rt2x00/rt2500pci.h
> >> @@ -1060,7 +1060,7 @@
> >>    * GEO: Default geography setting for device.
> >>    */
> >>   #define EEPROM_GEOGRAPHY		0x12
> >> -#define EEPROM_GEOGRAPHY_GEO		FIELD16(0x0f00)
> >> +#define EEPROM_GEOGRAPHY_GEO		FIELD16(0xff00)
> >>      
> >
> > Legacy driver uses 0x0f00, and the definition indicates the max value is 7,
> > so extending the definition doesn't seem correct.
> >    
> 
> Well, the EEPROM definition indicates that this is an 8-bit field, so 
> updating it looked appropriate, although the max value indeed is 7.

Ok, apparently I messed up the code interpretation. :S, the change from 0xf to 0xff is fine.

Ivo

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Gertjan van Wingerde]

On 01/06/09 22:52, Ivo van Doorn wrote:
>>>
>>>        
>>>> The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.
>>>>
>>>>          
>>> For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
>>> comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.
>>>
>>>        
>> OK. But the EEPROM definitions I got from Ralink on the Country
>> information indicate that there is only a single indication in the EEPROM.
>>      
>
> That is right, like I said the comments already indicates there the legacy code didn't contain the
> definitions (yet). ;)
>
>    
>>> GertJan, some comments about your patch:
>>>
>>>
>>>        
>>>> diff --git a/drivers/net/wireless/rt2x00/rt2400pci.h b/drivers/net/wireless/rt2x00/rt2400pci.h
>>>> index 9aefda4..986e428 100644
>>>> --- a/drivers/net/wireless/rt2x00/rt2400pci.h
>>>> +++ b/drivers/net/wireless/rt2x00/rt2400pci.h
>>>> @@ -806,6 +806,13 @@
>>>>    #define EEPROM_TXPOWER_2		FIELD16(0xff00)
>>>>
>>>>    /*
>>>> + * EEPROM geography.
>>>> + * GEO: Default geography setting for device.
>>>> + */
>>>> +#define EEPROM_GEOGRAPHY		0x17
>>>> +#define EEPROM_GEOGRAPHY_GEO		FIELD16(0xff00)
>>>>
>>>>          
>>> Where did you find this definition? I couldn't find it in the legacy driver or the specsheets.
>>>
>>>        
>> I got an excerpt from the EEPROM definition for the rt2460 chip (which I
>> received with the help of Luis). It's defined in there.
>>      
>
> I assume you mean the file RT2460_DS_P1.3.pdf, could you point me to the right pagenumber?
>
>    
No, I meant RT2460_EEPROM_Channels.pdf, which was sent by Ralink a 
couple of months ago. You were copied on the email; let me know if you 
can't find them. Note that these were only small excerpts from the 
entire EEPROM definitions, only the parts on geography information.

---
Gertjan.

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Ivo van Doorn]

On Tuesday 06 January 2009, Gertjan van Wingerde wrote:
> On 01/06/09 22:52, Ivo van Doorn wrote:
> >>>
> >>>        
> >>>> The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.
> >>>>
> >>>>          
> >>> For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
> >>> comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.
> >>>
> >>>        
> >> OK. But the EEPROM definitions I got from Ralink on the Country
> >> information indicate that there is only a single indication in the EEPROM.
> >>      
> >
> > That is right, like I said the comments already indicates there the legacy code didn't contain the
> > definitions (yet). ;)
> >
> >    
> >>> GertJan, some comments about your patch:
> >>>
> >>>
> >>>        
> >>>> diff --git a/drivers/net/wireless/rt2x00/rt2400pci.h b/drivers/net/wireless/rt2x00/rt2400pci.h
> >>>> index 9aefda4..986e428 100644
> >>>> --- a/drivers/net/wireless/rt2x00/rt2400pci.h
> >>>> +++ b/drivers/net/wireless/rt2x00/rt2400pci.h
> >>>> @@ -806,6 +806,13 @@
> >>>>    #define EEPROM_TXPOWER_2		FIELD16(0xff00)
> >>>>
> >>>>    /*
> >>>> + * EEPROM geography.
> >>>> + * GEO: Default geography setting for device.
> >>>> + */
> >>>> +#define EEPROM_GEOGRAPHY		0x17
> >>>> +#define EEPROM_GEOGRAPHY_GEO		FIELD16(0xff00)
> >>>>
> >>>>          
> >>> Where did you find this definition? I couldn't find it in the legacy driver or the specsheets.
> >>>
> >>>        
> >> I got an excerpt from the EEPROM definition for the rt2460 chip (which I
> >> received with the help of Luis). It's defined in there.
> >>      
> >
> > I assume you mean the file RT2460_DS_P1.3.pdf, could you point me to the right pagenumber?
> >
> >    
> No, I meant RT2460_EEPROM_Channels.pdf, which was sent by Ralink a 
> couple of months ago. You were copied on the email; let me know if you 
> can't find them. Note that these were only small excerpts from the 
> entire EEPROM definitions, only the parts on geography information.

ah those, I thought they only contained the valid values. :S
well ok, that means that this part of the patch is correct as well. :)

Ivo

Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Luis R. Rodriguez]

On Tue, Jan 6, 2009 at 2:06 PM, Gertjan van Wingerde
<gwingerde@kpnplanet.nl> wrote:
> On 01/06/09 22:52, Ivo van Doorn wrote:
>>>>
>>>>
>>>>>
>>>>> The problem isn't there for the bits that Ivo sent, as the rt2500
>>>>> devices don't support the a band.
>>>>>
>>>>>
>>>>
>>>> For rt2500pci and rt2500usb there are chipsets which support 5GHz (they
>>>> are rare, but they do exist),
>>>> comments for the Ralink drivers indicate they simply didn't add the
>>>> regulatory domain definitions yet.
>>>>
>>>>
>>>
>>> OK. But the EEPROM definitions I got from Ralink on the Country
>>> information indicate that there is only a single indication in the
>>> EEPROM.
>>>
>>
>> That is right, like I said the comments already indicates there the legacy
>> code didn't contain the
>> definitions (yet). ;)
>>
>>
>>>>
>>>> GertJan, some comments about your patch:
>>>>
>>>>
>>>>
>>>>>
>>>>> diff --git a/drivers/net/wireless/rt2x00/rt2400pci.h
>>>>> b/drivers/net/wireless/rt2x00/rt2400pci.h
>>>>> index 9aefda4..986e428 100644
>>>>> --- a/drivers/net/wireless/rt2x00/rt2400pci.h
>>>>> +++ b/drivers/net/wireless/rt2x00/rt2400pci.h
>>>>> @@ -806,6 +806,13 @@
>>>>>   #define EEPROM_TXPOWER_2             FIELD16(0xff00)
>>>>>
>>>>>   /*
>>>>> + * EEPROM geography.
>>>>> + * GEO: Default geography setting for device.
>>>>> + */
>>>>> +#define EEPROM_GEOGRAPHY               0x17
>>>>> +#define EEPROM_GEOGRAPHY_GEO           FIELD16(0xff00)
>>>>>
>>>>>
>>>>
>>>> Where did you find this definition? I couldn't find it in the legacy
>>>> driver or the specsheets.
>>>>
>>>>
>>>
>>> I got an excerpt from the EEPROM definition for the rt2460 chip (which I
>>> received with the help of Luis). It's defined in there.
>>>
>>
>> I assume you mean the file RT2460_DS_P1.3.pdf, could you point me to the
>> right pagenumber?
>>
>>
>
> No, I meant RT2460_EEPROM_Channels.pdf, which was sent by Ralink a couple of
> months ago. You were copied on the email; let me know if you can't find
> them. Note that these were only small excerpts from the entire EEPROM
> definitions, only the parts on geography information.

BTW we received permission from Ralink to put these up so they are also here:

http://wireless.kernel.org/en/developers/Documentation/specs#Ralinkdocumentation

  Luis