1. 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
  2. 16 6月, 2009 6 次提交
  3. 11 6月, 2009 1 次提交
  4. 04 6月, 2009 6 次提交
    • V
      ath9k: Fix write callback of 'debug' which configures debug mask · 581f725c
      Vasanthakumar Thiagarajan 提交于
      Handle error condition on copy_from_user() properly and
      make sure a NUL terminated char[] is sent to strict_strtoul()
      for proper conversion.
      Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      581f725c
    • 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
    • J
      ath9k: Add sanity check for beacon_int in adhoc/mesh case · 546256fb
      Jouni Malinen 提交于
      It looks like mac80211 can request the driver to start beaconing with
      a beacon interval of zero in some cases (at least for mesh point). This
      does not sound correct and something may need to be fixed in
      mac80211. However, taken into account the unpleasantness of getting
      stuck in an infinite busy loop with rtnl_lock held, let's add a quick
      workaround in the driver to avoid the worst symptom while someone more
      familiar with the mesh implementation can figure out what should be done
      with mac80211 as far as beacon interval configuration is concerned.
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      546256fb
    • J
      ath9k: Add "debug" file to debugfs · 2493928e
      Jeff Hansen 提交于
      This patch adds the debug file to the ath9k debugfs, which lets you modify
      the debug_mask at runtime, without having to reload the ath9k module.
      Signed-off-by: NJeff Hansen <x@jeffhansen.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2493928e
    • J
      ath9k: Combine legacy and 11n rc statistics · bedf087a
      Jeff Hansen 提交于
      This patch combines the legacy and 11n rcstats into one, using the normal
      rate table indices instead of two separate indices for each mode.  Legacy
      rates also get all of the PER and retry information, now, too.
      Signed-off-by: NJeff Hansen <x@jeffhansen.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bedf087a
    • J
      ath9k: Reset SC_OP_TSF_RESET flag after stuck beacon · b74444f8
      Jeff Hansen 提交于
      I have a TrendNet 652-BRP running OpenWRT + ath9k very well.  The only
      problem is that the beacon gets stuck maybe once a day.  After
      Vasanthakumar Thiagarajan's "ath9k: cleanup beacon parameters
      configuration" patch, ath9k would nearly re-configure the beacons after it
      detected the stuck beacon, and did a reset.  But it would fail the
      SC_OP_TSF_RESET check in ath_beacon_config_ap.  This patch gets the beacon
      fully reconfigured after the reset.
      Signed-off-by: NJeff Hansen <x@jeffhansen.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b74444f8
  5. 23 5月, 2009 3 次提交
  6. 21 5月, 2009 14 次提交
  7. 12 5月, 2009 2 次提交
  8. 07 5月, 2009 6 次提交
  9. 25 4月, 2009 1 次提交
    • J
      wireless: remove some (bogus?) 'may be used uninitialized' warnings · d3feaf5a
      John W. Linville 提交于
      net/mac80211/tx.c: In function ‘ieee80211_tx_h_select_key’:
      net/mac80211/tx.c:448: warning: ‘key’ may be used uninitialized in this function
      
      drivers/net/wireless/ath/ath9k/rc.c: In function ‘ath_rc_rate_getidx’:
      drivers/net/wireless/ath/ath9k/rc.c:815: warning: ‘nextindex’ may be used uninitialized in this function
      
      drivers/net/wireless/hostap/hostap_plx.c: In function ‘prism2_plx_probe’:
      drivers/net/wireless/hostap/hostap_plx.c:438: warning: ‘cor_index’ may be used uninitialized in this function
      drivers/net/wireless/hostap/hostap_plx.c:438: warning: ‘cor_offset’ may be used uninitialized in this function
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d3feaf5a