1. 20 8月, 2009 1 次提交
  2. 14 8月, 2009 1 次提交
  3. 05 8月, 2009 1 次提交
  4. 30 7月, 2009 2 次提交
  5. 28 7月, 2009 3 次提交
  6. 25 7月, 2009 7 次提交
    • L
      ath9k: disable radio when all devices are marked idle · 64839170
      Luis R. Rodriguez 提交于
      This uses the new configuration changes indicated up by
      mac80211 when all interfaces are marked idle. We need to do
      a little more work as we have our own set of virtual
      wiphys within ath9k.
      
      Only when all virtual wiphys are inactive do we allow an idle
      state change for a wiphy to trigger disabling the radio.
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      64839170
    • G
      ath9k: serialize ath9k_ps_{wakeup,restore} calls · 709ade9e
      Gabor Juhos 提交于
      These functions are changing the power mode of the chip, but this may
      have unpredictable effects, if another code are trying to set the power
      mode via 'ath9k_hw_setpower' in the same time from another context.
      
      Changes-licensed-under: ISC
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      709ade9e
    • G
      ath9k: uninline ath9k_ps_{wakeup,restore} functions · 0bc0798b
      Gabor Juhos 提交于
      Uninline these functions before we add functional changes to them.
      
      Changes-licensed-under: ISC
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0bc0798b
    • G
      ath9k: serialize ath9k_hw_setpower calls · 04717ccd
      Gabor Juhos 提交于
      Because ath9k_setpower is called from various contexts, we have to
      protect it against concurrent calls.
      
      Changes-licensed-under: ISC
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      04717ccd
    • S
      ath9k: Fix TX hang issue with Atheros chipsets · 164ace38
      Senthil Balasubramanian 提交于
      The hardware doesn't generate interrupts in some cases and so work
      around this by monitoring the TX status periodically and reset the
      chip if required.
      
      This behavior of the hardware not generating the TX interrupts can
      be noticed through ath9k debugfs interrupt statistics when heavy
      traffic is being sent from STA to AP. One can easily see this behavior
      when the STA is transmitting at a higher rates. The interrupt statistics
      in the debugfs interface clearly shows that only RX interrupts alone
      being generated and TX being stuck.
      
      TX should be monitored through a timer and reset the chip only when
      frames are queued to the hardware but TX interrupts are not generated
      for the same even after one second. Also, we shouldn't remove holding
      descriptor from AC queue if it happens to be the only descriptor and
      schedule TX aggregation regarless of queue depth as it improves
      scheduling of AMPDUs from software to hardware queue.
      Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
      Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      164ace38
    • S
      ath9k: Manipulate and report the correct RSSI · a59b5a5e
      Senthil Balasubramanian 提交于
      RSSI reported by the RX descriptor requires little manipulation.
      Manipulate and report the correct RSSI to the stack. This will
      fix the improper signal levels reported by iwconfig iw dev wlanX
      station dump. Also the Link Quality reported seems to be varying
      (falls to zero also sometimes) when iperf is run from STA to AP.
      
      Also use the default noise floor for now as the one reported
      during the caliberation seems to be wrong.
      
      The Signal and Link Quality before this patch (taken while TX is
      in progress from STA to AP)
      
      09:59:13.285428037 Link Quality=29/70  Signal level=-81 dBm
      09:59:13.410660084 Link Quality=20/70  Signal level=-90 dBm
      09:59:13.586864392 Link Quality=21/70  Signal level=-89 dBm
      09:59:13.710296281 Link Quality=21/70  Signal level=-89 dBm
      09:59:13.821683064 Link Quality=25/70  Signal level=-85 dBm
      09:59:13.933402989 Link Quality=24/70  Signal level=-86 dBm
      09:59:14.045839276 Link Quality=26/70  Signal level=-84 dBm
      09:59:14.193926673 Link Quality=23/70  Signal level=-87 dBm
      09:59:14.306230262 Link Quality=31/70  Signal level=-79 dBm
      09:59:14.419459667 Link Quality=26/70  Signal level=-84 dBm
      09:59:14.530711167 Link Quality=37/70  Signal level=-73 dBm
      09:59:14.642593962 Link Quality=29/70  Signal level=-81 dBm
      09:59:14.754361169 Link Quality=21/70  Signal level=-89 dBm
      09:59:14.866217355 Link Quality=21/70  Signal level=-89 dBm
      09:59:14.976963623 Link Quality=28/70  Signal level=-82 dBm
      09:59:15.089149809 Link Quality=26/70  Signal level=-84 dBm
      09:59:15.205039887 Link Quality=27/70  Signal level=-83 dBm
      09:59:15.316368003 Link Quality=23/70  Signal level=-87 dBm
      09:59:15.427684036 Link Quality=36/70  Signal level=-74 dBm
      09:59:15.539756380 Link Quality=21/70  Signal level=-89 dBm
      09:59:15.650549093 Link Quality=22/70  Signal level=-88 dBm
      09:59:15.761171672 Link Quality=32/70  Signal level=-78 dBm
      09:59:15.872793750 Link Quality=23/70  Signal level=-87 dBm
      09:59:15.984421694 Link Quality=22/70  Signal level=-88 dBm
      09:59:16.097315093 Link Quality=21/70  Signal level=-89 dBm
      
      The link quality and signal level after this patch (take while
      TX is in progress from STA to AP)
      
      17:21:25.627848091 Link Quality=65/70  Signal level=-45 dBm
      17:21:25.762805607 Link Quality=65/70  Signal level=-45 dBm
      17:21:25.875521888 Link Quality=66/70  Signal level=-44 dBm
      17:21:25.987468448 Link Quality=66/70  Signal level=-44 dBm
      17:21:26.100628151 Link Quality=66/70  Signal level=-44 dBm
      17:21:26.213129671 Link Quality=66/70  Signal level=-44 dBm
      17:21:26.324923070 Link Quality=65/70  Signal level=-45 dBm
      17:21:26.436831357 Link Quality=65/70  Signal level=-45 dBm
      17:21:26.610356973 Link Quality=65/70  Signal level=-45 dBm
      17:21:26.723340047 Link Quality=65/70  Signal level=-45 dBm
      17:21:26.835715293 Link Quality=64/70  Signal level=-46 dBm
      17:21:26.949542748 Link Quality=64/70  Signal level=-46 dBm
      17:21:27.062261613 Link Quality=65/70  Signal level=-45 dBm
      17:21:27.174511563 Link Quality=64/70  Signal level=-46 dBm
      17:21:27.287616232 Link Quality=64/70  Signal level=-46 dBm
      17:21:27.400598119 Link Quality=64/70  Signal level=-46 dBm
      17:21:27.511381404 Link Quality=64/70  Signal level=-46 dBm
      17:21:27.624530421 Link Quality=65/70  Signal level=-45 dBm
      17:21:27.737807109 Link Quality=64/70  Signal level=-46 dBm
      17:21:27.850861352 Link Quality=65/70  Signal level=-45 dBm
      17:21:27.963369436 Link Quality=64/70  Signal level=-46 dBm
      17:21:28.076582289 Link Quality=64/70  Signal level=-46 dBm
      Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
      Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a59b5a5e
    • L
      ath9k: cleanup try count for MRR in rate control · dd190183
      Luis R. Rodriguez 提交于
      This has no functional change and just cleans up the code
      to be more legible and removes a useless variable for
      Multi Rate Retry.
      
      For regular frames we use 2 retries for MRR segments [0-2].
      For the last MRR segment [3] we use 4.
      
      MRR[0] = 2
      MRR[1] = 2
      MRR[2] = 2
      MRR[3] = 4
      
      Cc: Derek Smithies <derek@indranet.co.nz>
      Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      dd190183
  7. 11 7月, 2009 2 次提交
  8. 16 6月, 2009 2 次提交
  9. 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
  10. 23 5月, 2009 1 次提交
  11. 21 5月, 2009 3 次提交
  12. 07 5月, 2009 3 次提交
  13. 23 4月, 2009 8 次提交
  14. 14 4月, 2009 1 次提交
  15. 28 3月, 2009 3 次提交
  16. 17 3月, 2009 1 次提交