1. 08 12月, 2010 2 次提交
  2. 19 11月, 2010 1 次提交
  3. 10 11月, 2010 1 次提交
  4. 28 7月, 2010 1 次提交
  5. 15 6月, 2010 1 次提交
  6. 22 5月, 2010 1 次提交
  7. 17 4月, 2010 1 次提交
  8. 07 4月, 2010 1 次提交
  9. 03 2月, 2010 1 次提交
  10. 02 2月, 2010 1 次提交
  11. 15 1月, 2010 1 次提交
  12. 13 1月, 2010 1 次提交
  13. 08 1月, 2010 1 次提交
  14. 29 12月, 2009 1 次提交
  15. 31 10月, 2009 2 次提交
  16. 08 10月, 2009 4 次提交
  17. 09 9月, 2009 5 次提交
  18. 20 8月, 2009 1 次提交
  19. 14 8月, 2009 1 次提交
  20. 05 8月, 2009 1 次提交
  21. 28 7月, 2009 1 次提交
  22. 19 6月, 2009 1 次提交
    • J
      ath9k: Fix PCI FATAL interrupts by restoring RETRY_TIMEOUT disabling · f0214843
      Jouni Malinen 提交于
      An earlier commit, 'ath9k: remove dummy PCI "retry timeout" fix', removed
      code that was documented to disable RETRY_TIMEOUT register (PCI reg
      0x41) since it was claimed to be a no-op. However, it turns out that
      there are some combinations of hosts and ath9k-supported cards for
      which this is not a no-op (reg 0x41 has value 0x80, not 0) and this
      code (or something similar) is needed. In such cases, the driver may
      be next to unusable due to very frequent PCI FATAL interrupts from the
      card.
      
      Reverting the earlier commit, i.e., restoring the RETRY_TIMEOUT
      disabling, seems to resolve the issue. Since the removal of this code
      was not based on any known issue and was purely a cleanup change, the
      safest option here is to just revert that commit. Should there be
      desire to clean this up in the future, the change will need to be
      tested with a more complete coverage of cards and host systems.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=13483
      
      Cc: stable@kernel.org
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f0214843
  23. 04 6月, 2009 1 次提交
    • J
      rfkill: rewrite · 19d337df
      Johannes Berg 提交于
      This patch completely rewrites the rfkill core to address
      the following deficiencies:
      
       * all rfkill drivers need to implement polling where necessary
         rather than having one central implementation
      
       * updating the rfkill state cannot be done from arbitrary
         contexts, forcing drivers to use schedule_work and requiring
         lots of code
      
       * rfkill drivers need to keep track of soft/hard blocked
         internally -- the core should do this
      
       * the rfkill API has many unexpected quirks, for example being
         asymmetric wrt. alloc/free and register/unregister
      
       * rfkill can call back into a driver from within a function the
         driver called -- this is prone to deadlocks and generally
         should be avoided
      
       * rfkill-input pointlessly is a separate module
      
       * drivers need to #ifdef rfkill functions (unless they want to
         depend on or select RFKILL) -- rfkill should provide inlines
         that do nothing if it isn't compiled in
      
       * the rfkill structure is not opaque -- drivers need to initialise
         it correctly (lots of sanity checking code required) -- instead
         force drivers to pass the right variables to rfkill_alloc()
      
       * the documentation is hard to read because it always assumes the
         reader is completely clueless and contains way TOO MANY CAPS
      
       * the rfkill code needlessly uses a lot of locks and atomic
         operations in locked sections
      
       * fix LED trigger to actually change the LED when the radio state
         changes -- this wasn't done before
      Tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      19d337df
  24. 23 4月, 2009 1 次提交
  25. 14 4月, 2009 1 次提交
  26. 28 3月, 2009 2 次提交
  27. 06 3月, 2009 1 次提交
    • J
      ath9k: Add data structure for supporting virtual radio/wiphy operation · bce048d7
      Jouni Malinen 提交于
      This is the initial step in allowing ath9k to register multiple
      virtual radios (wiphys). The goal of virtual radios is to allow the
      same radio to be shared for multiple virtual interfaces that may
      operate on different channels. The mac80211 virtual interface support
      is designed only for single channel operation and as such, it is not
      suitable for this type of use. Anyway, it can be used on top of the
      virtual radio concept, if desired (e.g., use two virtual radios to
      handle two channels and then add multiple mac80211 virtual interfaces
      on top of each virtual radio).
      
      The new struct ath_wiphy is now registered as the driver data
      structure for wiphy. This structure has a pointer to the shared (among
      virtual wiphys of the same physical radio) struct ath_softc data. The
      primary wiphy maintains the allocated memory for ath_softc. Secondary
      (virtual) wiphys will only allocate the new ath_wiphy structure.
      
      Registration of secondary wiphys is added in a separate patch.
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bce048d7
  28. 28 2月, 2009 2 次提交
  29. 14 2月, 2009 1 次提交