1. 14 5月, 2014 1 次提交
  2. 07 5月, 2014 1 次提交
  3. 01 5月, 2014 4 次提交
  4. 23 4月, 2014 1 次提交
  5. 10 4月, 2014 1 次提交
  6. 09 4月, 2014 1 次提交
  7. 01 4月, 2014 2 次提交
  8. 28 3月, 2014 2 次提交
  9. 14 3月, 2014 1 次提交
  10. 07 3月, 2014 10 次提交
  11. 05 3月, 2014 6 次提交
  12. 01 3月, 2014 1 次提交
  13. 25 2月, 2014 2 次提交
    • P
      rtlwifi: properly apply filter flags · 711f145a
      Peter Wu 提交于
      commit 0baa0fd7
      ("rtlwifi: Convert core routines for addition of rtl8192se and
      rtl8192de") removed setting HW_VAR_RCR, HW_VAR_MGT_FILTER and
      HW_VAR_CTRL_FILTER. The last two are probably done because some hardware
      does not support them. The first is probably a mistake. This patch adds
      the missing set_hw_reg call.
      
      For PCI support, rx_conf is not touched directly. Instead, get_hw_reg is
      used to abstract between receive_config (for PCI) and rx_conf (for USB).
      
      This was tested on a 10ec:8176 Realtek RTL8188CE (according to the
      label on the mini-PCIe card). Before this patch, `iw wlan0 set monitor
      otherbss` did not capture frames from other BSS's. After this patch, it
      does print packets.
      Tested-by: NPeter Wu <lekensteyn@gmail.com>
      Signed-off-by: NPeter Wu <lekensteyn@gmail.com>
      Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      711f145a
    • P
      rtlwifi: avoid accessing RCR directly · e51048cd
      Peter Wu 提交于
      The rtl*_set_check_bssid functions are mostly the same, but access the
      RCR register in different ways. Use the get_hw_reg abstraction layer
      (which reads rtlpci->receive_config for PCI devices and mac->rx_conf for
      USB).
      
      There is no functional change for cases where receive_config was
      accessed directly. For rtl8192ce, there is still no change because
      nothing modifies REG_RCR or receive_config. For rtl8192cu, it now also
      applies changes to rx_conf from configure_filter, but that can be
      considered a bug which is fixed later.
      Signed-off-by: NPeter Wu <lekensteyn@gmail.com>
      Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e51048cd
  14. 14 2月, 2014 2 次提交
    • O
      rtlwifi: Fix incorrect return from rtl_ps_enable_nic() · 2e8c5e56
      Olivier Langlois 提交于
      rtl_ps_enable_nic() is called from loops that will loop until this function returns true or a
      maximum number of retries is performed.
      
      hw_init() returns non-zero on error. In that situation return false to
      restore the original design intent to retry hw init when it fails.
      Signed-off-by: NOlivier Langlois <olivier@trillion01.com>
      Cc: Stable <stable@vger.kernel.org>
      Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2e8c5e56
    • O
      rtlwifi: rtl8192ce: Fix too long disable of IRQs · f78bccd7
      Olivier Langlois 提交于
      rtl8192ce is disabling for too long the local interrupts during hw initiatialisation when performing scans
      
      The observable symptoms in dmesg can be:
      
      - underruns from ALSA playback
      - clock freezes (tstamps do not change for several dmesg entries until irqs are finaly reenabled):
      
      [  250.817669] rtlwifi:rtl_op_config():<0-0-0> 0x100
      [  250.817685] rtl8192ce:_rtl92ce_phy_set_rf_power_state():<0-1-0> IPS Set eRf nic enable
      [  250.817732] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.817796] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.817910] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818024] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818139] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818253] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818367] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:98053f15:10
      [  250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
      [  250.818472] rtl8192c_common:rtl92c_download_fw():<0-1-0> Firmware Version(49), Signature(0x88c1),Size(32)
      [  250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> PairwiseEncAlgorithm = 0 GroupEncAlgorithm = 0
      [  250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> The SECR-value cc
      [  250.818472] rtl8192c_common:rtl92c_dm_check_txpower_tracking_thermal_meter():<0-1-0> Schedule TxPowerTracking direct call!!
      [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> rtl92c_dm_txpower_tracking_callback_thermalmeter
      [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf
      [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial pathA ele_d reg0xc80 = 0x40000000, ofdm_index=0xc
      [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial reg0xa24 = 0x90e1317, cck_index=0xc, ch14 0
      [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf delta 0x1 delta_lck 0x0 delta_iqk 0x0
      [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> <===
      [  250.818472] rtl8192c_common:rtl92c_dm_initialize_txpower_tracking_thermalmeter():<0-1-0> pMgntInfo->txpower_tracking = 1
      [  250.818472] rtl8192ce:rtl92ce_led_control():<0-1-0> ledaction 3
      [  250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
      [  250.818472] rtlwifi:rtl_ips_nic_on():<0-1-0> before spin_unlock_irqrestore
      [  251.154656] PCM: Lost interrupts? [Q]-0 (stream=0, delta=15903, new_hw_ptr=293408, old_hw_ptr=277505)
      
      The exact code flow that causes that is:
      
      1. wpa_supplicant send a start_scan request to the nl80211 driver
      2. mac80211 module call rtl_op_config with IEEE80211_CONF_CHANGE_IDLE
      3.   rtl_ips_nic_on is called which disable local irqs
      4.     rtl92c_phy_set_rf_power_state() is called
      5.       rtl_ps_enable_nic() is called and hw_init()is executed and then the interrupts on the device are enabled
      
      A good solution could be to refactor the code to avoid calling rtl92ce_hw_init() with the irqs disabled
      but a quick and dirty solution that has proven to work is
      to reenable the irqs during the function rtl92ce_hw_init().
      
      I think that it is safe doing so since the device interrupt will only be enabled after the init function succeed.
      Signed-off-by: NOlivier Langlois <olivier@trillion01.com>
      Cc: Stable <stable@vger.kernel.org>
      Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f78bccd7
  15. 05 2月, 2014 3 次提交
  16. 14 1月, 2014 1 次提交
  17. 08 1月, 2014 1 次提交