Commit Graph

14 Commits

Author SHA1 Message Date
Adrian Chadd
eff1a1bc13 More Japan regulatory domain fixes:
* Add HT40 entries for the two new Japan bands
* Fix a channel separation bug in one of the new bands I introduced
  in a previous commit.
2011-07-14 05:49:35 +00:00
Adrian Chadd
7a9a76167a Japan regulatory domain update #1 - sync with CRDA entries.
Specifics:

* add 4920MHz-4980MHz for 11a and 11n/HT20
* add 5040MHz-5080MHz for 11a and 11n/HT20
* add 5500MHz-5700MHz for 11a and 11n/HT20 (DFS needed)
* add 5500MHz-5680MHz for 11n/HT40 (DFS needed)

TODO:

* add correct HT40 bands for 4920-4980 and 5040-5080

For the curious:

There's been many revisions to the Japan regulatory rules.
Apparently, the requirements require old cards certified on a previous
version of the rules to obey the older rules, not the newer rules.

The regdomain.xml outlines the -current- restrictions.

The card driver (eg the ath_hal regulatory domain code) may include
previous revisions of the Japan rules.

The ath_hal regdomain code populates the initial channel list based on
what the EEPROM indicates is possible. The regdomain.xml database imposes
further restrictions on this.

So regdomain.xml only needs to have the -current- rules. If the card
was certified on an earlier set of JP rules, it may only support a subset
of those channels - these are calculated at device attach and this
restricted list is kicked to net80211. regdomain.xml operates on -this-
list of channels.

And thus, the correct regulatory behaviour for Japan is handled with only
one regdomain.xml Japan database entry.

(phew.)

Obtained from:	Linux wireless-regdb
2011-07-14 05:19:28 +00:00
Adrian Chadd
3cef2d90e3 I think 23dBm is the correct value to use here. CRDA uses 20dBm + 3dB max antenna
gain; I believe net80211 doesn't take antenna gain into account and leaves it
up to the driver to enforce. (ath_hal(4) certainly tries to do this.)
2011-06-26 10:34:01 +00:00
Adrian Chadd
1b8805b8aa Add a couple more frequency ranges to the FCC3 (FCC + DFS) regulatory domain.
The frequency range 5490MHz -> 5710MHz was opened up sometime in 2009, but
regdomain.xml wasn't updated.

FCC reference: (Section 15.407): http://louise.hallikainen.org/FCC/FccRules/2009/15/407/

The hole between 5600-5650MHz is due to a request from Airports using
a weather radar system which also utilises this range.
The GIT commit explaining this hole in more detail can be found here:

http://git.kernel.org/?p=linux/kernel/git/linville/wireless-regdb.git;a=commit;h=fcbf9225d56e82d9a4e506187d42285e76d81523
2011-06-26 10:32:09 +00:00
Adrian Chadd
e43496e5e6 Replace tab with 8 spaces, bringing it in line with the rest of the file. 2011-06-26 09:32:46 +00:00
Adrian Chadd
0b73ba9c97 Fix another broken HT40 channel band reference. 2011-06-24 14:31:30 +00:00
Adrian Chadd
9b9fc082ba More incorrect HT/40 setups in FCC.
Noticed-by:	bschmidt@
2011-06-24 12:50:18 +00:00
Adrian Chadd
74024442b7 Fix an incorrect frequency band for HT/40 in the FCC SKU.
Noticed by: bschmidt@
2011-06-24 12:31:36 +00:00
Adrian Chadd
796fd09a90 Import one of the two missing US FCC DFS bands to FCC3.
The FCC opened up this band sometime in 2009 (and ath was updated);
but regdomain.xml wasn't updated.
2011-06-24 12:30:43 +00:00
Doug Barton
2557f5bf0a Remove trailing white space. No functional changes. 2010-05-14 04:53:57 +00:00
Sam Leffler
c4506e0298 Remove gsm hacks now that we can do this "right":
o no need for special country codes; it's sufficient to use the sku
o no need to specify bands w/ 2.4G frequencies, use the real values
o remove duplicate band specs
2009-01-28 19:25:51 +00:00
Sam Leffler
bdb8f7ad51 add FCC4 SKU to expose Public Safety Band (PSB) frequencies; this is
modeled after the Atheros SKU of the same name
2009-01-16 20:40:50 +00:00
Sam Leffler
8311334503 o fix DEBUG sku definition
o add definitions for 900MHz radios: Ubiquiti SR9 and XR9, and ZComax GZ-901
2008-12-15 01:18:11 +00:00
Sam Leffler
67591c284e 802.11 regulatory definitions used by ifconfig
Support by:	Hobnob
2008-04-20 20:37:02 +00:00