1. 30 12月, 2016 2 次提交
  2. 17 11月, 2016 1 次提交
  3. 27 9月, 2016 2 次提交
  4. 08 7月, 2016 2 次提交
  5. 16 6月, 2016 1 次提交
    • A
      rtlwifi: fix error handling in *_read_adapter_info() · 5345ea6a
      Arnd Bergmann 提交于
      There are nine copies of the _rtl88ee_read_adapter_info() function,
      and most but not all of them cause a build warning in some configurations:
      
      rtl8192de/hw.c: In function '_rtl92de_read_adapter_info':
      rtl8192de/hw.c:1767:12: error: 'hwinfo' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      rtl8723ae/hw.c: In function '_rtl8723e_read_adapter_info.constprop':
      rtlwifi/rtl8723ae/hw.c:1654:12: error: 'hwinfo' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      The problem is that when rtlefuse->epromtype is something other than
      EEPROM_BOOT_EFUSE, the rest of the function uses undefined data, resulting
      in random behavior later.
      
      Apparently, in some drivers, the problem was already found and fixed
      but the fix did not make it into the others.
      
      This picks one approach to deal with the problem and applies identical
      code to all 9 files, to simplify the later consolidation of those.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      5345ea6a
  6. 14 10月, 2015 1 次提交
  7. 26 2月, 2015 1 次提交
  8. 25 12月, 2014 3 次提交
  9. 16 12月, 2014 1 次提交
  10. 02 12月, 2014 1 次提交
  11. 24 10月, 2014 1 次提交
  12. 01 10月, 2014 1 次提交
  13. 21 7月, 2014 1 次提交
  14. 26 6月, 2014 1 次提交
  15. 20 5月, 2014 1 次提交
  16. 28 3月, 2014 1 次提交
  17. 07 3月, 2014 1 次提交
  18. 05 3月, 2014 1 次提交
  19. 25 2月, 2014 1 次提交
    • 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
  20. 14 2月, 2014 1 次提交
    • 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
  21. 02 4月, 2013 2 次提交
  22. 15 2月, 2013 1 次提交
    • J
      mac80211: stop toggling IEEE80211_HT_CAP_SUP_WIDTH_20_40 · e1a0c6b3
      Johannes Berg 提交于
      For VHT, many more bandwidth changes are possible. As a first
      step, stop toggling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 flag
      in the HT capabilities and instead introduce a bandwidth field
      indicating the currently usable bandwidth to transmit to the
      station. Of course, make all drivers use it.
      
      To achieve this, make ieee80211_ht_cap_ie_to_sta_ht_cap() get
      the station as an argument, rather than the new capabilities,
      so it can set up the new bandwidth field.
      
      If the station is a VHT station and VHT bandwidth is in use,
      also set the bandwidth accordingly.
      
      Doing this allows us to get rid of the supports_40mhz flag as
      the HT capabilities now reflect the true capability instead of
      the current setting.
      
      While at it, also fix ieee80211_ht_cap_ie_to_sta_ht_cap() to not
      ignore HT cap overrides when MCS TX isn't supported (not that it
      really happens...)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e1a0c6b3
  23. 31 10月, 2012 2 次提交
  24. 20 10月, 2012 1 次提交
  25. 13 9月, 2012 1 次提交
  26. 08 9月, 2012 1 次提交
    • L
      rtlwifi: rtl8192c: rtl8192ce: rtl8192cu: rtl8192se: Remove sparse warnings · 8e2c406a
      Larry Finger 提交于
      The rtlwifi family of drivers has the following sparse errors:
      
        CHECK   drivers/net/wireless/rtlwifi/usb.c
      drivers/net/wireless/rtlwifi/usb.c:122:17: warning: cast to restricted __le32
        CHECK   drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
      drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:1157:13: warning: context imbalance in 'rtl92c_dm_refresh_rate_adaptive_mask' - different lock contexts for basic block
        CHECK   drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
      drivers/net/wireless/rtlwifi/rtl8192ce/hw.c:1909:30: warning: cast to restricted __le32
        CHECK   drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
      drivers/net/wireless/rtlwifi/rtl8192ce/sw.c:345:1: warning: symbol 'rtl92ce_pci_ids' was not declared. Should it be static?
        CHECK   drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
      drivers/net/wireless/rtlwifi/rtl8192cu/trx.c:494:9: warning: cast from restricted __le16
        CHECK   drivers/net/wireless/rtlwifi/rtl8192se/fw.c
      drivers/net/wireless/rtlwifi/rtl8192se/fw.c:490:17: warning: cast to restricted __le32
      drivers/net/wireless/rtlwifi/rtl8192se/fw.c:490:17: warning: cast to restricted __le32
      drivers/net/wireless/rtlwifi/rtl8192se/fw.c:494:17: warning: cast to restricted __le32
      drivers/net/wireless/rtlwifi/rtl8192se/fw.c:494:17: warning: cast to restricted __le32
      drivers/net/wireless/rtlwifi/rtl8192se/fw.c:499:17: warning: cast to restricted __le32
      drivers/net/wireless/rtlwifi/rtl8192se/fw.c:499:17: warning: cast to restricted __le32
      drivers/net/wireless/rtlwifi/rtl8192se/fw.c:510:25: warning: cast to restricted __le32
      drivers/net/wireless/rtlwifi/rtl8192se/fw.c:510:25: warning: cast to restricted __le32
      drivers/net/wireless/rtlwifi/rtl8192se/fw.c:607:9: warning: cast to restricted __le16
      drivers/net/wireless/rtlwifi/rtl8192se/fw.c:607:9: warning: cast to restricted __le16
      drivers/net/wireless/rtlwifi/rtl8192se/fw.c:650:9: warning: cast to restricted __le16
      drivers/net/wireless/rtlwifi/rtl8192se/fw.c:650:9: warning: cast to restricted __le16
      drivers/net/wireless/rtlwifi/rtl8192se/fw.c:652:9: warning: cast to restricted __le16
      drivers/net/wireless/rtlwifi/rtl8192se/fw.c:652:9: warning: cast to restricted __le16
        CHECK   drivers/net/wireless/rtlwifi/rtl8192se/trx.c
      drivers/net/wireless/rtlwifi/rtl8192se/trx.c:758:9: warning: cast from restricted __le32
      drivers/net/wireless/rtlwifi/rtl8192se/trx.c:788:17: warning: cast from restricted __le32
      drivers/net/wireless/rtlwifi/rtl8192se/trx.c:804:17: warning: cast to restricted __le32
      drivers/net/wireless/rtlwifi/rtl8192se/trx.c:804:17: warning: cast to restricted __le32
      drivers/net/wireless/rtlwifi/rtl8192se/trx.c:807:17: warning: cast from restricted __le32
      Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8e2c406a
  27. 07 6月, 2012 1 次提交
    • J
      wireless: Remove casts to same type · 2c208890
      Joe Perches 提交于
      Adding casts of objects to the same type is unnecessary
      and confusing for a human reader.
      
      For example, this cast:
      
              int y;
              int *p = (int *)&y;
      
      I used the coccinelle script below to find and remove these
      unnecessary casts.  I manually removed the conversions this
      script produces of casts with __force, __iomem and __user.
      
      @@
      type T;
      T *p;
      @@
      
      -       (T *)p
      +       p
      
      Neatened the mwifiex_deauthenticate_infra function which
      was doing odd things with array pointers and not using
      is_zero_ether_addr.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2c208890
  28. 13 2月, 2012 1 次提交
  29. 31 1月, 2012 1 次提交
  30. 25 1月, 2012 4 次提交