[PATCH] d80211: Allow drivers to configure default regulatory domain

[PATCH] d80211: Allow drivers to configure default regulatory domain

[Michael Wu]

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

d80211: Allow drivers to configure default regulatory domain

This patch allows drivers to configure the default set of channels if the
device reports its default regulatory domain.

Signed-off-by: Michael Wu <flamingice@sourmilk.net>
---

 include/net/d80211.h   |    7 ++++++-
 net/d80211/ieee80211.c |    5 +++--
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/include/net/d80211.h b/include/net/d80211.h
index 25a4dca..e0180ec 100644
--- a/include/net/d80211.h
+++ b/include/net/d80211.h
@@ -54,7 +54,9 @@
  * freq, and val fields. Other fields will be filled in by 80211.o based on
  * hostapd information and low-level driver does not need to use them. The
  * limits for each channel will be provided in 'struct ieee80211_conf' when
- * configuring the low-level driver with hw->config callback. */
+ * configuring the low-level driver with hw->config callback. If a device has
+ * a default regulatory domain, IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED 
can
+ * be set to let the driver configure all fields. */
 struct ieee80211_channel {
 	short chan; /* channel number (IEEE 802.11) */
 	short freq; /* frequency in MHz */
@@ -532,6 +534,9 @@ struct ieee80211_hw {
 	/* Do TKIP phase1 and phase2 key mixing in stack and send the generated
 	 * per-packet RC4 key with each TX frame when doing hwcrypto */
 #define IEEE80211_HW_TKIP_REQ_PHASE2_KEY (1<<14)
+	/* Channels are already configured to the default regulatory domain
+	 * specified in the device's EEPROM */
+#define IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED (1<<15)
 
 	u32 flags;			/* hardware flags defined above */
 
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 0e5f23f..5af42aa 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -4652,6 +4652,9 @@ int ieee80211_register_hw(struct ieee802
 	memcpy(local->mdev->dev_addr, local->hw.perm_addr, ETH_ALEN);
 	SET_NETDEV_DEV(local->mdev, local->hw.dev);
 
+	if (!(hw->flags & IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED))
+		ieee80211_init_client(local->mdev);
+
 	result = register_netdevice(local->mdev);
 	if (result < 0) {
 		rtnl_unlock();
@@ -4746,8 +4749,6 @@ int ieee80211_register_hwmode(struct iee
 		ieee80211_prepare_rates(local);
 	}
 
-	ieee80211_init_client(local->mdev);
-
 	return 0;
 }
 EXPORT_SYMBOL(ieee80211_register_hwmode);

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] d80211: Allow drivers to configure default regulatory domain

[Jiri Benc]

On Sun, 18 Feb 2007 00:31:33 -0500, Michael Wu wrote:
> This patch allows drivers to configure the default set of channels if the
> device reports its default regulatory domain.

How is a driver supposed to handle this? By walking through the channel
list and based on some value obtained from its EEPROM (or firmware or
whatever) set appropriate flags? That sounds like a need for duplicate
code in drivers. Shouldn't the stack accept a regdomain code (defined
as an enum of integers or so) instead?

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs

Re: [PATCH] d80211: Allow drivers to configure default regulatory domain

[James Ketrenos]

Jiri Benc wrote:
> On Sun, 18 Feb 2007 00:31:33 -0500, Michael Wu wrote:
>> This patch allows drivers to configure the default set of channels if the
>> device reports its default regulatory domain.
> 
> How is a driver supposed to handle this? By walking through the channel
> list and based on some value obtained from its EEPROM (or firmware or
> whatever) set appropriate flags? 

Yes.

> That sounds like a need for duplicate code in drivers. 

Unfortunately it is vendor and device specific.  I think we can 
generalize things to provide helper functions and macros such that each 
driver does it roughly the same way, but the stack itself can't do it.

 > Shouldn't the stack accept a regdomain code (defined
> as an enum of integers or so) instead?

The hardware needs to tell the stack all the channels it supports and 
the restrictions on those channels.  The stack can then further restrict 
the set of channels based on the user input to a "standard" set of 
countries.

"regdomains" are not static maps; they evolve over time as governments 
change their regulations.  The channels and features supported by 
hardware is static based on what the device was certified for.

James

Re: [PATCH] d80211: Allow drivers to configure default regulatory domain

[Jiri Benc]

On Mon, 19 Feb 2007 12:37:16 -0800, James Ketrenos wrote:
> Unfortunately it is vendor and device specific.  I think we can 
> generalize things to provide helper functions and macros such that each 
> driver does it roughly the same way, but the stack itself can't do it.

If the stack really cannot do it, yes, such helpers make sense.

> The hardware needs to tell the stack all the channels it supports and 
> the restrictions on those channels.  The stack can then further restrict 
> the set of channels based on the user input to a "standard" set of 
> countries.

Yes.

> "regdomains" are not static maps; they evolve over time as governments 
> change their regulations.  The channels and features supported by 
> hardware is static based on what the device was certified for.

Ok.

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs

Re: [PATCH] d80211: Allow drivers to configure default regulatory domain

[Michael Wu]

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

On Monday 19 February 2007 14:49, Jiri Benc wrote:
> How is a driver supposed to handle this? By walking through the channel
> list and based on some value obtained from its EEPROM (or firmware or
> whatever) set appropriate flags? That sounds like a need for duplicate
> code in drivers. Shouldn't the stack accept a regdomain code (defined
> as an enum of integers or so) instead?
>
Region codes are not standardized though many devices these days tend towards 
using atheros' codes. Of course, you can make a d80211 specific region code 
enum and map hardware region codes to those region codes and this would work 
well for most hardware out there.. except for ipw3945. So, this patch would 
allow the ipw3945 to do its own funny thing while everyone else uses a 
library to setup the channels.

-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]