linux-kernel - Re: Problems with regulatory domain support and BCM43224

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120326193608.GE17126@thinkpad-t410>
Date:	Mon, 26 Mar 2012 14:36:08 -0500
From:	Seth Forshee <seth.forshee@...onical.com>
To:	Arend van Spriel <arend@...adcom.com>,
	"Luis R. Rodriguez" <rodrigue@....qualcomm.com>
Cc:	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	Michael Green <green@....qualcomm.com>,
	David Quan <dquan@....qualcomm.com>,
	Henry Ptasinski <henry@...out.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Problems with regulatory domain support and BCM43224

On Wed, Mar 21, 2012 at 05:27:15PM -0700, Luis R. Rodriguez wrote:
> > 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.
> 
> > 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.
> 
> > 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/