Hi,

A couple of points after reading the emails on this thread:

 

-        For AP being used in most of the countries outside the US, the 802.11d feature is generally enabled. Hence, the STAs, while associating would need enable this feature in the Marvell software. The Local Channel/Power information is available in the beacons of these AP is 802.11d is enabled on the AP.

-        These laptops are going to be sold mostly in the under-developed countries as we are told. Not sure if any of these countries have their own frequency specific constraints from FCC for the 802.11 devices.

-        Even if there are restrictions on any of these countries, you can maintain a list of region codes in an external flash as is being discussed in the email below.

-        Burning the region code in the manufacturing data of the EEPROM is an option but a slightly difficult one. A better suggestion would be maintain this information on an external flash memory and have the driver read this information from the flash. This is what we have suggested to most of our customers also. This also has an added advantage that it keeps the WLAN module the same for all the laptops going in several countries.

 

Thanks

Ronak

 

-----Original Message-----

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Williams

Sent: Monday, October 02, 2006 6:46 AM

To: Mitch Bradley

Cc: [email protected]; Michail Bletsas; [EMAIL PROTECTED]; [EMAIL PROTECTED]

Subject: Re: Marvell regulatory domain info storage?

 

On Sun, 2006-10-01 at 20:04 -1000, Mitch Bradley wrote:

> The region code, or something equivalent, is a good candidate for the

> "manufacturing data" that Quanta will put in their special section of

> FLASH.  I'm thinking of a two-prong approach:

>

> a) The manufacturing data will include a region code and the driver will

> have a lookup table that maps region code to a list of

> regulatory-approved channels.

 

Right; the current libertas driver already looks up the region code from

the card itself.  But if we get that from the manufacturing area, the

driver has a few tables (mostly for US, EU, and Japan) that show allowed

channels.  We'll likely need to add a lot more tables for different

countries.

 

> b) Optionally, the manufacturing data can also include an explicit

> channel list (probably a bitmask) that, if present, will override the

> region-derived channel list.

 

I'm not sure, but there may also be power restrictions on a per-country

basis too.  Need to look that up.  At least the FCC restricts power

output of unlicensed devices, but I'm not sure if that's band-specific.

 

Dan

 

>

> Jim Gettys wrote:

> > On Sun, 2006-10-01 at 10:55 -0400, Dan Williams wrote:

> >  

> >> Hi,

> >>

> >> Talking with Mitch this week brought up an interesting question.  Where

> >> regulatory domain information for the wireless stored?  We have to know

> >> what channels we can(not) operate on for a given country, and therefore

> >> must communicate that information to the laptop.

> >>

> >> Does the Marvell chip have internal EEPROM that we write the appropriate

> >> region code to?  Or must we pull that value from the SPI flash and write

> >> it to the card during init? 

> >>    

> >

> > This should be pretty easy.  On the manufacturing line, they know what

> > language/keyboard they are loading, and the machine's destination.

> >

> >  

> >> It appears that the driver pulls a preset

> >> region code from the card, see wlan_ret_get_hw_spec() in wlan_cmdresp.c.

> >> That indicates that the region code is either in (a) firmware, or (b) in

> >> EEPROM on the card.  The region code may apparently be set from

> >> userspace with a private ioctl.

> >>

> >> Thoughts?  At worst, we do country-specific flashes, which we were

> >> already going to do for fonts & translations.  At best, the server

> >> and/or firstboot process communicates region code somehow.

> >> 

> >>    

> >

> > Doesn't help: you could be off frequency for these operations.

> >                            - Jim

> >

> >  

>

 

 

_______________________________________________

libertas-dev mailing list

[EMAIL PROTECTED]

http://lists.infradead.org/mailman/listinfo/libertas-dev

_______________________________________________
Devel mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/devel

Reply via email to