1. 27 6月, 2012 1 次提交
  2. 21 6月, 2012 1 次提交
  3. 14 6月, 2012 3 次提交
  4. 12 6月, 2012 2 次提交
    • M
      ath9k: remove incompatible IBSS interface check in change_iface · a23415fd
      Mohammed Shafi Shajakhan 提交于
      'cfg80211: fix interface combinations' ensures that if an interface
      type is not advertised by the driver in any of the interface combinations
      (via ieee80211_iface_combination) then it shall be treated as a single
      incompatible interface. if there are more than one interfaces present
      and changing them to incompatible interface type is not possible.
      These checks will be properly handled by cfg80211_change_iface ->
      cfg80211_can_change_interface.
      
      this patch is dependent on 'cfg80211: fix interface combinations'
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a23415fd
    • M
      ath9k: Fix a WARNING on suspend/resume with IBSS · 2031b4c2
      Mohammed Shafi Shajakhan 提交于
      this patch is dependent on the patch "cfg80211: fix interface
      combinations"
      
      In ath9k currently we have ADHOC interface as a single incompatible
      interface. when drv_add_interface is called during resume we got to
      consider number of vifs already present in addition to checking the
      drivers 'opmode' information about ADHOC.  we incorrectly assume
      an ADHOC interface is already present. Then we may miss some driver
      specific data for the ADHOC interface after resume.
      
      The above mentioned checks can be removed from the driver,
      as the patch 'cfg80211: fix interface combinations' ensures that
      if an interface type is not advertised by the driver in any of the
      interface combinations(via ieee80211_iface_combination) then it shall
      be treated as a single incompatible interface. Fixes the following
      warning on suspend/resume with ibss interface.
      
              ath: phy0: Cannot create ADHOC interface when other
              interfaces already exist.
              WARNING: at net/mac80211/driver-ops.h:12
              ieee80211_reconfig+0x1882/0x1ca0 [mac80211]()
              Hardware name: 2842RK1
              wlan2:  Failed check-sdata-in-driver check, flags: 0x0
      
              Call Trace:
              [<c01361b2>] warn_slowpath_common+0x72/0xa0
              [<f8aaa7c2>] ? ieee80211_reconfig+0x1882/0x1ca0
              [mac80211]
              [<f8aaa7c2>] ? ieee80211_reconfig+0x1882/0x1ca0
              [mac80211]
              [<c0136283>] warn_slowpath_fmt+0x33/0x40
              [<f8aaa7c2>] ieee80211_reconfig+0x1882/0x1ca0 [mac80211]
              [<c06c1d1a>] ? mutex_lock_nested+0x23a/0x2f0
              [<f8a95097>] ieee80211_resume+0x27/0x70 [mac80211]
              [<fd177edf>] wiphy_resume+0x8f/0xa0 [cfg80211]
      
      Cc: stable@vger.kernel.org
      Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2031b4c2
  5. 07 6月, 2012 10 次提交
  6. 06 6月, 2012 1 次提交
  7. 30 5月, 2012 1 次提交
  8. 25 4月, 2012 1 次提交
  9. 24 4月, 2012 1 次提交
  10. 17 4月, 2012 1 次提交
  11. 14 4月, 2012 1 次提交
  12. 12 4月, 2012 1 次提交
  13. 11 4月, 2012 1 次提交
  14. 10 4月, 2012 1 次提交
    • R
      ath9k: recover ar9380 chips from rare stuck state · 01e18918
      Rajkumar Manoharan 提交于
      In the experiment with Azimuth ADEPT-n testbed where the APs transmit
      power was reduced to 25% and the signal strength was futher attenuated
      by 20dB and induced a path loss of ~7dB, the station was reporting
      beacon losses and the following issue were observed.
      
      * rx clear is stuck at low for more than 300ms
      * dcu chain and complete state is stuck at one of the hang signature
      
      This patch triggers the hang detection logic that recovers the chip
      from any of the above conditions. As the issue was originally reported
      in ChromeOs with AR9382 chips, this detection logic is enabled only for
      AR9380/2 chips.
      
      Cc: Paul Stewart <pstew@google.com>
      Reported-by: NGary Morain <gmorain@google.com>
      Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      01e18918
  15. 29 3月, 2012 1 次提交
  16. 16 3月, 2012 6 次提交
  17. 13 3月, 2012 2 次提交
  18. 06 3月, 2012 1 次提交
  19. 28 2月, 2012 2 次提交
  20. 23 2月, 2012 2 次提交