Marvell regulatory domain info storage?

[Dan Williams]

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
> >
> >   
>