1. 14 Apr, 2010 2 commits
    • Bruno Randolf's avatar
      ath5k: treat RXORN as non-fatal · 87d77c4e
      Bruno Randolf authored
      We get RXORN interrupts when all receive buffers are full. This is not
      necessarily a fatal situation. It can also happen when the bus is busy or the
      CPU is not fast enough to process all frames.
      
      Older chipsets apparently need a reset to come out of this situration, but on
      newer chips we can treat RXORN like RX, as going thru a full reset does more
      harm than good, there.
      
      The exact chip revisions which need a reset are unknown - this guess
      AR5K_SREV_AR5212 ("venice") is copied from the HAL.
      
      Inspired by openwrt 413-rxorn.patch:
      "treat rxorn like rx, reset after rxorn seems to do more harm than good"
      Signed-off-by: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      87d77c4e
    • Bruno Randolf's avatar
      ath5k: Use high bitrates for ACK/CTS · 0edc9a67
      Bruno Randolf authored
      There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and
      AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for
      ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually
      resulted in high bitrates, which i think is what we want anyways. Cleared the
      confusion and added some documentation.
      Signed-off-by: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0edc9a67
  2. 12 Apr, 2010 11 commits
  3. 09 Apr, 2010 21 commits
  4. 08 Apr, 2010 6 commits