Re: Problems with regulatory domain support and BCM43224

["Arend van Spriel" <arend@broadcom.com>]

On 04/04/2012 04:46 AM, Seth Forshee wrote:
> On Mon, Mar 26, 2012 at 02:36:08PM -0500, Seth Forshee wrote:
>> 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.
>
> Below is a diff of the changes I've made locally to the brcmsmac
> regulatory support. I haven't started thinking about dividing it up into
> more digestible chunks, so for now it's just one massive diff. I've made
> a lot of progress towards moving brcmsmac away from its custom formats
> for regulatory information, but there are a few points I'm still having
> difficulty with.
>
> The patch builds, and kind of works. Scanning seems to be fine; I can
> see all the APs I expect in my area, including the one on a DFS channel
> that I couldn't see previously. I can associate with my 2.4 GHz APs, but
> not the 5 GHz AP. I see timme outs waiting for probe responses, and I'm
> hitting the WARN_ON_ONCE in brcms_c_wait_for_tx_completion(). I haven't
> really debugged this yet -- I thought I'd send out the patch to collect
> comments while I debug. Suggestions of what's causing this are also
> welcome :)
>
> One of the major unresolved issues in the patch is what to do with the
> data in struct locale_mimo_info. The regulatory rules only hold one
> power level. I'm unsure why the brcmsmac implementation differs in this
> regard. Suggestions?
>
> The txpwr calculations are modified, both to use the regdomain data so
> far as possible and to eliminate redundant code. I'd appreciate review
> of these changes in addition to the suggestions on how to handle the
> MIMO power limits as I've already mentioned.
>
> Initialization has also changed somewhat. The piece that looks most
> significant to me is that wlc_phy_txpower_limit_set() gets called later,
> not until after the ieee80211_hw device is registered.
>
> Beyond these I still have a number of comments with my initials (SAF)
> that contain questions, comments, and TODOs. Feedback regarding these
> items, or anything else, are greatly appreciated.
>
> Looking forward to your comments.
>
> Thanks,
> Seth
>

Thanks, Seth

I am sure you are moving in the right direction here. Unfortunately, I 
am currently unable to give the patch a spin. I am attending the linux 
collaboration summit in San Francisco and I can only do some basic 
testing on it. I will be back in my office next week to do some more 
elaborate testing on it.

Gr. AvS