1. 17 9月, 2010 2 次提交
  2. 28 8月, 2010 1 次提交
  3. 25 8月, 2010 6 次提交
  4. 17 8月, 2010 1 次提交
  5. 14 8月, 2010 1 次提交
    • M
      ath5k: disable ASPM L0s for all cards · 6ccf15a1
      Maxim Levitsky 提交于
      Atheros PCIe wireless cards handled by ath5k do require L0s disabled.
      For distributions shipping with CONFIG_PCIEASPM (this will be enabled
      by default in the future in 2.6.36) this will also mean both L1 and L0s
      will be disabled when a pre 1.1 PCIe device is detected. We do know L1
      works correctly even for all ath5k pre 1.1 PCIe devices though but cannot
      currently undue the effect of a blacklist, for details you can read
      pcie_aspm_sanity_check() and see how it adjusts the device link
      capability.
      
      It may be possible in the future to implement some PCI API to allow
      drivers to override blacklists for pre 1.1 PCIe but for now it is
      best to accept that both L0s and L1 will be disabled completely for
      distributions shipping with CONFIG_PCIEASPM rather than having this
      issue present. Motivation for adding this new API will be to help
      with power consumption for some of these devices.
      
      Example of issues you'd see:
      
        - On the Acer Aspire One (AOA150, Atheros Communications Inc. AR5001
          Wireless Network Adapter [168c:001c] (rev 01)) doesn't work well
          with ASPM enabled, the card will eventually stall on heavy traffic
          with often 'unsupported jumbo' warnings appearing. Disabling
          ASPM L0s in ath5k fixes these problems.
      
        - On the same card you would see a storm of RXORN interrupts
          even though medium is idle.
      
      Credit for root causing and fixing the bug goes to Jussi Kivilinna.
      
      Cc: David Quan <David.Quan@atheros.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Tim Gardner <tim.gardner@canonical.com>
      Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Cc: stable@kernel.org
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6ccf15a1
  6. 15 7月, 2010 3 次提交
    • B
      ath5k: clean up rxlink handling · b3f194e5
      Bruno Randolf 提交于
      There were a few places where the sc->rxlink pointer was set to NULL "just in
      case". This helps nothing - quite to the contrary it is problematic since it
      can create self-linked rx descriptors in the middle of the list of receive
      buffers.
      
      Here is an example how this could happen (thanks Bob!):
      
      cpu 0:                                      cpu 1:
      
      ath5k_rx_stop
                                                  ath5k_tasklet_rx
      sc->rxlink = NULL;   /* just in case */
                                                    // following doesn't link used
                                                    // buffer to prev.
                                                    ath5k_rxbuf_setup()
      
      In the case of ath5k_rx_stop() and ath5k_stop_locked() buffers/descriptors are
      not changed so rxlink should not be changed as well.
      
      In ath5k_intr() we seem to  try to work around a hardware bug, as the comment
      (which is copied 1:1 from the HAL) suggests. I don't see how this could help.
      Also the HAL does not set rxlink in this case (So where does this code come
      from? It has been there since the first import of ath5k). Changed to just
      increment a statistics counter.
      
      After this patch rxlink is only set to NULL before we initialize rx descriptors
      and updated when the descriptors are linked together.
      Signed-off-by: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b3f194e5
    • B
      ath5k: disable tasklets during reset · 450464de
      Bob Copeland 提交于
      Based on a patch from Bruno Randolf, attempting useful
      work while we are resetting the chip just leads to interface
      lockups and bad descriptor data, and possibly DMAing to
      freed buffers.  Let's suspend all tasklets while
      reprogramming the registers in the card to avoid such
      problems.
      
      In the future we can convert the tasklets to threaded
      interrupt handlers to simplify things.
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Acked-by: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      450464de
    • B
      ath5k: move reset to mac80211 workqueue · 5faaff74
      Bob Copeland 提交于
      We currently trigger a reset via a tasklet when certain error
      conditions are detected so that the card will (eventually)
      restart.  Unfortunately this makes locking complicated since
      reset can also be called in process context (e.g. for channel
      change).  Currently nothing protects against concurrent resets,
      which can be the source of corruption bugs.
      
      Reset takes too long to spinlock the whole thing, so this
      patch moves deferred resets into the mac80211 workqueue to
      enable use of sc->lock mutex.
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Acked-by: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5faaff74
  7. 17 6月, 2010 9 次提交
  8. 05 6月, 2010 2 次提交
  9. 03 6月, 2010 6 次提交
  10. 02 6月, 2010 1 次提交
  11. 25 5月, 2010 1 次提交
    • B
      ath5k: consistently use rx_bufsize for RX DMA · b5eae9ff
      Bruno Randolf 提交于
      We should use the same buffer size we set up for DMA also in the hardware
      descriptor. Previously we used common->rx_bufsize for setting up the DMA
      mapping, but used skb_tailroom(skb) for the size we tell to the hardware in the
      descriptor itself. The problem is that skb_tailroom(skb) can give us a larger
      value than the size we set up for DMA before. This allows the hardware to write
      into memory locations not set up for DMA. In practice this should rarely happen
      because all packets should be smaller than the maximum 802.11 packet size.
      
      On the tested platform rx_bufsize is 2528, and we allocated an skb of 2559
      bytes length (including padding for cache alignment) but sbk_tailroom() was
      2592. Just consistently use rx_bufsize for all RX DMA memory sizes.
      
      Also use the return value of the descriptor setup function.
      
      Cc: stable@kernel.org
      Signed-off-by: NBruno Randolf <br1@einfach.org>
      Reviewed-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b5eae9ff
  12. 12 5月, 2010 1 次提交
    • L
      ath5k: drop warning on jumbo frames · 9637e516
      Luis R. Rodriguez 提交于
      Jumbo frames are not supported, and if they are seen it is likely
      a bogus frame so just silently discard them instead of warning on
      them all time. Also, instead of dropping them immediately though
      move the check *after* we check for all sort of frame errors. This
      should enable us to discard these frames if the hardware picks
      other bogus items first. Lets see if we still get those jumbo
      counters increasing still with this.
      
      Jumbo frames would happen if we tell hardware we can support
      a small 802.11 chunks of DMA'd frame, hardware would split RX'd
      frames into parts and we'd have to reconstruct them in software.
      This is done with USB due to the bulk size but with ath5k we
      already provide a good limit to hardware and this should not be
      happening.
      
      This is reported quite often and if it fills the logs then this
      needs to be addressed and to avoid spurious reports.
      
      Cc: stable@kernel.org
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9637e516
  13. 01 5月, 2010 1 次提交
  14. 29 4月, 2010 1 次提交
  15. 20 4月, 2010 1 次提交
  16. 15 4月, 2010 2 次提交
    • B
      ath5k: treat RXORN as non-fatal · 87d77c4e
      Bruno Randolf 提交于
      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: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      87d77c4e
    • B
      ath5k: Use high bitrates for ACK/CTS · 0edc9a67
      Bruno Randolf 提交于
      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: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0edc9a67
  17. 09 4月, 2010 1 次提交