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:
smime.p7s
Description: S/MIME Cryptographic Signature
