1. 05 Oct, 2010 1 commit
  2. 28 Sep, 2010 5 commits
  3. 27 Sep, 2010 1 commit
  4. 21 Sep, 2010 11 commits
  5. 16 Sep, 2010 3 commits
  6. 14 Sep, 2010 1 commit
  7. 30 Aug, 2010 1 commit
  8. 27 Aug, 2010 2 commits
  9. 25 Aug, 2010 2 commits
  10. 24 Aug, 2010 6 commits
  11. 16 Aug, 2010 1 commit
  12. 13 Aug, 2010 1 commit
    • Maxim Levitsky's avatar
      ath5k: disable ASPM L0s for all cards · 6ccf15a1
      Maxim Levitsky authored
      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
      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: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarMaxim Levitsky <maximlevitsky@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  13. 26 Jul, 2010 1 commit
  14. 14 Jul, 2010 3 commits
    • Bruno Randolf's avatar
      ath5k: clean up rxlink handling · b3f194e5
      Bruno Randolf authored
      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
      Here is an example how this could happen (thanks Bob!):
      cpu 0:                                      cpu 1:
      sc->rxlink = NULL;   /* just in case */
                                                    // following doesn't link used
                                                    // buffer to prev.
      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: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Bob Copeland's avatar
      ath5k: disable tasklets during reset · 450464de
      Bob Copeland authored
      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
      In the future we can convert the tasklets to threaded
      interrupt handlers to simplify things.
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Acked-by: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Bob Copeland's avatar
      ath5k: move reset to mac80211 workqueue · 5faaff74
      Bob Copeland authored
      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: default avatarBob Copeland <me@bobcopeland.com>
      Acked-by: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  15. 28 Jun, 2010 1 commit