Re: Problems with regulatory domain support and BCM43224

From: Arend van Spriel
Date: Wed Apr 11 2012 - 12:52:08 EST


On 04/11/2012 03:39 PM, Seth Forshee wrote:
On Wed, Apr 11, 2012 at 12:16:40PM +0200, Arend van Spriel wrote:
On 04/10/2012 06:28 PM, Seth Forshee wrote:
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:)
This was due to always passing true for the value of mute_tx to
brcms_b_set_chanspec() on passive channels. For now I'm just always
passing false, which looks like it ought to be okay as we shouldn't have
any tx on passive channels unless beacons are seen on the channel.

Yes. I discovered this as well. Actually, I sent out a patch for
some people to test it. I submitted a slightly different patch to
John in which tx in unmuted upon receiving a beacon.

I assume you're talking about this patch?

http://www.spinics.net/lists/linux-wireless/msg88107.html

My original changes would mute tx whenever IEEE80211_CHAN_PASSIVE_SCAN
is set for the current channel. I'll try that again with your patch.


That is the one.

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?
This is still one of the largest unsolved issues. I'm probably going to
need some advice on how to fill out the txpwr information when
regualtory rules external to the driver can be applied.


The power constraints for HT (covered by struct locale_mimo_info)
are handled differently from non-HT. I have to confirm internally
whether this is specific for our devices or actually needed to be
compliant.

Great, thanks.


No answer on this one yet, but keep you posted.

Gr. AvS

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