1. 09 4月, 2013 1 次提交
  2. 04 4月, 2013 1 次提交
  3. 27 3月, 2013 1 次提交
  4. 19 3月, 2013 2 次提交
  5. 28 2月, 2013 3 次提交
    • F
      ath9k_hw: improve reset reliability after errors · 3412f2f0
      Felix Fietkau 提交于
      On many different chips, important aspects of the MAC state are not
      fully cleared by a warm reset. This can show up as tx/rx hangs, those
      annoying "DMA failed to stop in 10 ms..." messages or other quirks.
      
      On AR933x, the chip can occasionally get stuck in a way that only a
      driver unload/reload or a reboot would bring it back to life.
      
      With this patch, a full reset is issued when bringing the chip out of
      FULL-SLEEP state (after idle), or if either Rx or Tx was not shut down
      properly. This makes the DMA related error messages disappear completely
      in my tests on AR933x, and the chip does not get stuck anymore.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3412f2f0
    • F
      ath9k_htc: fix signal strength handling issues · 838f4279
      Felix Fietkau 提交于
      The ath9k commit 2ef16755
      (ath9k: fix signal strength reporting issues) fixed an issue where the
      reported per-frame signal strength reported to mac80211 was being
      overwritten with an internal average. The same issue is also present
      in ath9k_htc.
      In addition to preventing the driver from overwriting the value, this
      commit also ensures that the internal average (which is used for ANI)
      only tracks beacons of the AP that we're connected to.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      838f4279
    • F
      ath9k: fix RSSI dummy marker value · a3d63cad
      Felix Fietkau 提交于
      RSSI is being stored internally as s8 in several places. The indication
      of an unset RSSI value, ATH_RSSI_DUMMY_MARKER, was supposed to have been
      set to 127, but ended up being set to 0x127 because of a code cleanup
      mistake. This could lead to invalid signal strength values in a few
      places.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a3d63cad
  6. 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
  7. 12 2月, 2013 2 次提交
  8. 09 2月, 2013 1 次提交
  9. 05 2月, 2013 1 次提交
  10. 02 2月, 2013 7 次提交
  11. 31 1月, 2013 4 次提交
  12. 23 1月, 2013 11 次提交
  13. 15 1月, 2013 3 次提交
  14. 14 1月, 2013 1 次提交
  15. 12 1月, 2013 1 次提交
新手
引导
客服 返回
顶部