Re: Problems with regulatory domain support and BCM43224

On Wed, Mar 21, 2012 at 05:27:15PM -0700, Luis R. Rodriguez wrote:

quoted

Arend, in order to proceed it looks like what we need to know is what
the custom domains represent, i.e. whether they map to a specific
country or set of countries, etc.

This is why it is crucial for vendors themselves to get involved in this
process. Only they will truly know and completely understand what this
all means. Since it is hard to keep track of this information it is also
why we have documented what our EEPROM regulatory domains look like and
what they mean / map to.

http://wireless.kernel.org/en/users/Drivers/ath

Something similar may be worthy for this driver. But just my own 0.02
costarican colones.

quoted

From what you've said so far it looks
like X0 may map to US 

BTW if this is the case, you may be able to send the regulatory hint
for "US" and then apply any thing you need on top of that after
through the reg_notifier() callback.

quoted

while X2 is more of a world roaming domain, but again I'm just guessing.

I've been studying the existing brcmsmac regulatory code in more detail,
and I think there's a lot of potential to make the integration with the
core regulatory support much better. I'm still making my way through
some of the code, but here's what I see so far.

Once full and accurate regdomain information is provided to the core
regulatory code, all the code in channel.c that's checking against
regulatory constraints can be eliminated, as that will get done at a
higher level. I think the code to set the Tx power should also be
reworked to use the constraints from the core regdom code. At that point
the need for the custom regdom structures is mostly eliminated.

I'm going to start toying with implementing some of this this week, time
permitting. I think X2 is the only domain I have enough information on
to realistically implement. But even with that one it would be helpful
to understand what it's meant to represent, as Luis pointed out.

I have one other question as well. Does the data in channel.c generally
represent the most permissive regulatory parameters that ought to be
used? That's the assumption I'm working under right now.

Thanks,
Seth