From: Larry Finger <Larry.Finger@lwfinger.net>
To: linux-wireless@vger.kernel.org
Cc: Joshua Roys <Joshua.Roys@gtri.gatech.edu>,
Nicu Pavel <npavel@mini-box.com>
Subject: Re: Problem with the rtl8192cu - kernelmodule after ifdown, ifup
Date: Thu, 05 Apr 2012 21:04:26 -0500 [thread overview]
Message-ID: <4F7E4F2A.1030404@lwfinger.net> (raw)
In-Reply-To: <4F7D90AF.2040109@gtri.gatech.edu>
[-- Attachment #1: Type: text/plain, Size: 3707 bytes --]
On 04/05/2012 07:31 AM, Joshua Roys wrote:
> On 04/05/2012 03:27 AM, Nicu Pavel wrote:
>> After mode debugging with DBG_LOUD I found out that the difference when the
>> driver is loaded/modprobed and ifdown/ifup to be a receive configuration
>> register (RCR) value.
>>
>> On bootup/modprobe: ### Set RCR(0xf0002a0e) ###
>> On ifdown/ifup: ### Set RCR(0xf0002ace) ###
>>
>> If I force RCR value to 0x2a0e in rtl92cu_set_hw_reg()inside HW_VAR_RCR case
>> everything works ok.
>>
>> This seems to work with 3 different vendors USB sticks based on 8192cu chipset
>> (Edimax, EDUP and some unknown vendor).
>>
>> I tried looking up the bit values meanings from that register but couldn't find
>> a proper spec.
>
> Hello,
>
> I found a header file that seems to have better definitions and comments than
> what is currently in-tree (I think it's a copy of the Realtek sources). It says
> that the "8192C (RCR) Receive Configuration Register" BIT 6 and 7 are,
> respectively: RCR_CBSSID_DATA [Accept BSSID match packet (Data)] and
> RCR_CBSSID_BCN [Accept BSSID match packet (Rx beacon, probe rsp)].
> These bits are set/cleared in _rtl92cu_set_check_bssid (it calls set_hw_reg
> w/HW_VAR_RCR) which is called by rtl92cu_set_network_type. The set/clear choice
> is made based on the rtlphy->current_io_type which is set in
> rtl8192c/phy_common.c:rtl92c_phy_scan_operation_backup which in turn is called
> from core.c:rtl_op_sw_scan_start/_complete.
> It would be interesting to see the output from rtl8192c/phy_common.c functions
> rtl92c_phy_set_io_cmd and rtl92c_phy_set_io to see if the current_io_type
> perhaps isn't being updated properly.
Attached is a patch that I think will help. The main thing it changes is that
routine rtl92cu_set_check_bssid() has been coded to update RCR. The other thing
that was changed is to make the RCR setting always log even with the default
debug option of 0. That will be temporary and that change will be deleted once
we get this problem fixed.
Let me know if the patch helps.
I did some stack dumps to see what code is changing the RCR. I captured the
following instances:
Type 1, which I think is OK.
rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
Call Trace:
rtl92cu_set_hw_reg+0x60e/0x11d0 [rtl8192cu]
rtl92cu_set_check_bssid+0x9b/0xc0 [rtl8192cu]
rtl_op_configure_filter+0xd0/0x400 [rtlwifi]
ieee80211_configure_filter+0x15b/0x5c0 [mac80211]
Type 2: This one sets the filter, but it is at the end of scanning and should be OK.
rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002ace) ###
Call Trace:
rtl92cu_set_hw_reg+0x60e/0x11d0 [rtl8192cu]
rtl92cu_set_check_bssid+0x56/0xc0 [rtl8192cu]
rtl_op_configure_filter+0x2d3/0x400 [rtlwifi]
ieee80211_configure_filter+0x15b/0x5c0 [mac80211]
__ieee80211_scan_completed+0x168/0x660 [mac80211]
Type 3: This one clears the filter, and is also at the end of scanning. I don't
understand it yet. It seems that the filter should still be set.
rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
Call Trace:
rtl92cu_set_hw_reg+0x60e/0x11d0 [rtl8192cu]
_rtl92cu_set_check_bssid+0xce/0x190 [rtl8192cu]
rtl92cu_set_network_type+0x2f/0x40 [rtl8192cu]
rtl_op_sw_scan_complete+0x89/0xd0 [rtlwifi]
Type 4: This one occurred when the module was removed. It sets the filter, but
that seems to be wrong. It probably does not matter as reloading the driver will
clear those bits,
rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002ace) ###
Call Trace:
rtl92cu_set_hw_reg+0x60e/0x11d0 [rtl8192cu]
_rtl92cu_set_check_bssid+0x118/0x190 [rtl8192cu]
rtl92cu_set_network_type+0x2f/0x40 [rtl8192cu]
rtl_op_bss_info_changed+0x487/0xaa0 [rtlwifi]
Larry
[-- Attachment #2: rtl8192cu_set_check_bssid --]
[-- Type: text/plain, Size: 1653 bytes --]
Index: wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
+++ wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
@@ -1377,12 +1377,27 @@ void rtl92cu_card_disable(struct ieee802
void rtl92cu_set_check_bssid(struct ieee80211_hw *hw, bool check_bssid)
{
- /* dummy routine needed for callback from rtl_op_configure_filter() */
+ struct rtl_priv *rtlpriv = rtl_priv(hw);
+ u32 reg_rcr = rtl_read_dword(rtlpriv, REG_RCR);
+
+ if (!check_bssid) {
+ reg_rcr &= ~(RCR_CBSSID_DATA | RCR_CBSSID_BCN);
+ rtlpriv->cfg->ops->set_hw_reg(hw,
+ HW_VAR_RCR, (u8 *)(®_rcr));
+ /* disable update TSF */
+ _rtl92cu_set_bcn_ctrl_reg(hw, BIT(4), 0);
+ } else {
+ reg_rcr |= (RCR_CBSSID_DATA | RCR_CBSSID_BCN);
+ rtlpriv->cfg->ops->set_hw_reg(hw,
+ HW_VAR_RCR, (u8 *)(®_rcr));
+ /* enable update TSF */
+ _rtl92cu_set_bcn_ctrl_reg(hw, 0, BIT(4));
+ }
}
/*========================================================================== */
-static void _rtl92cu_set_check_bssid(struct ieee80211_hw *hw,
+void _rtl92cu_set_check_bssid(struct ieee80211_hw *hw,
enum nl80211_iftype type)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
@@ -1869,7 +1884,7 @@ void rtl92cu_set_hw_reg(struct ieee80211
case HW_VAR_RCR:{
rtl_write_dword(rtlpriv, REG_RCR, ((u32 *) (val))[0]);
mac->rx_conf = ((u32 *) (val))[0];
- RT_TRACE(rtlpriv, COMP_RECV, DBG_DMESG,
+ RT_TRACE(rtlpriv, COMP_RECV, DBG_EMERG,
"### Set RCR(0x%08x) ###\n", mac->rx_conf);
break;
}
next prev parent reply other threads:[~2012-04-06 2:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-12 14:11 Problem with the rtl8192cu - kernelmodule after ifdown, ifup Markus Königshaus
2012-01-13 3:28 ` Larry Finger
2012-04-02 11:32 ` Nicu Pavel
2012-04-05 7:27 ` Nicu Pavel
2012-04-05 12:31 ` Joshua Roys
2012-04-05 16:23 ` Larry Finger
2012-04-06 2:04 ` Larry Finger [this message]
2012-04-06 8:48 ` Nicu Pavel
2012-04-06 19:54 ` Larry Finger
2012-04-09 8:40 ` Nicu Pavel
2012-04-09 16:03 ` Larry Finger
2012-04-09 16:29 ` Nicu Pavel
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=4F7E4F2A.1030404@lwfinger.net \
--to=larry.finger@lwfinger.net \
--cc=Joshua.Roys@gtri.gatech.edu \
--cc=linux-wireless@vger.kernel.org \
--cc=npavel@mini-box.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).