From: "Arend van Spriel" <arend@broadcom.com>
To: "Luis R. Rodriguez" <rodrigue@qca.qualcomm.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"Michael Green" <green@qca.qualcomm.com>,
"David Quan" <dquan@qca.qualcomm.com>,
"Henry Ptasinski" <henry@logout.com>,
linux-kernel@vger.kernel.org
Subject: Re: Problems with regulatory domain support and BCM43224
Date: Wed, 11 Apr 2012 18:52:25 +0200 [thread overview]
Message-ID: <4F85B6C9.7010003@broadcom.com> (raw)
In-Reply-To: <20120411133940.GA15854@thinkpad-t410>
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
next prev parent reply other threads:[~2012-04-11 16:52 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-07 19:40 Problems with regulatory domain support and BCM43224 Seth Forshee
2012-03-08 17:41 ` Seth Forshee
2012-03-08 18:53 ` Luis R. Rodriguez
2012-03-08 19:07 ` Quan, David
2012-03-08 19:36 ` Luis R. Rodriguez
2012-03-08 19:45 ` Quan, David
2012-03-08 19:51 ` Luis R. Rodriguez
2012-03-08 20:07 ` Seth Forshee
2012-03-08 20:17 ` Luis R. Rodriguez
2012-03-08 21:01 ` Arend van Spriel
2012-03-08 21:06 ` Luis R. Rodriguez
2012-03-08 21:31 ` Arend van Spriel
2012-03-08 21:42 ` Seth Forshee
2012-03-20 22:07 ` Seth Forshee
2012-03-21 11:05 ` Arend van Spriel
2012-03-21 14:19 ` Seth Forshee
2012-03-21 17:51 ` Arend van Spriel
2012-03-21 18:17 ` Luis R. Rodriguez
2012-03-21 19:37 ` Seth Forshee
2012-03-22 0:27 ` Luis R. Rodriguez
2012-03-26 19:36 ` Seth Forshee
2012-04-04 2:46 ` Seth Forshee
2012-04-04 7:03 ` Arend van Spriel
2012-04-10 16:28 ` Seth Forshee
2012-04-11 10:16 ` Arend van Spriel
2012-04-11 13:39 ` Seth Forshee
2012-04-11 16:52 ` Arend van Spriel [this message]
2012-03-08 21:59 ` Seth Forshee
2012-03-08 22:12 ` Luis R. Rodriguez
2012-03-08 22:30 ` Seth Forshee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F85B6C9.7010003@broadcom.com \
--to=arend@broadcom.com \
--cc=dquan@qca.qualcomm.com \
--cc=green@qca.qualcomm.com \
--cc=henry@logout.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=rodrigue@qca.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.