Marvell regulatory domain info storage?

[Ronak Chokshi]

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: libertas-dev-bounces at lists.infradead.org
[mailto:libertas-dev-bounces at lists.infradead.org] On Behalf Of Dan
Williams

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

To: Mitch Bradley

Cc: devel at laptop.org; Michail Bletsas; jg at laptop.org;
libertas-dev at lists.infradead.org

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

libertas-dev at lists.infradead.org

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20061002/61649b7a/attachment.html>