Re: Problem with the rtl8192cu - kernelmodule after ifdown, ifup

[Joshua Roys <Joshua.Roys@gtri.gatech.edu>]

[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]

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.

Hope to help,

Josh


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5045 bytes --]