1. 17 8月, 2010 1 次提交
    • I
      rt2x00: Move USB tx/rx done handling to workqueue · 7e613e16
      Ivo van Doorn 提交于
      Move all TX and RX completion handling into a work structure,
      which is handeled on the mac80211 workqueue. This simplifies
      the code in rt2x00lib since it no longer needs to check if the
      device is USB or PCI to decide which mac80211 function should be used.
      
      In the watchdog some changes are needed since it can no longer rely
      on the TX completion function to be run while looping through the
      entries. (Both functions now work on the same workqueue, so this
      would deadlock). So the watchdog now waits for the URB to return,
      and handle the TX status report directly.
      
      As a side-effect, the debugfs entry for the RX queue now correctly
      displays the positions of the INDEX and INDEX_DONE counters. This
      also implies that it is not possible to perform checks like queue_empty()
      and queue_full() on the RX queue.
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7e613e16
  2. 13 7月, 2010 6 次提交
  3. 01 7月, 2010 1 次提交
  4. 03 6月, 2010 5 次提交
  5. 11 5月, 2010 1 次提交
  6. 17 4月, 2010 1 次提交
  7. 13 4月, 2010 2 次提交
  8. 16 2月, 2010 3 次提交
  9. 09 2月, 2010 1 次提交
  10. 06 1月, 2010 1 次提交
  11. 29 12月, 2009 2 次提交
  12. 22 12月, 2009 1 次提交
  13. 29 11月, 2009 1 次提交
  14. 17 11月, 2009 1 次提交
  15. 14 11月, 2009 1 次提交
  16. 12 11月, 2009 2 次提交
  17. 07 11月, 2009 3 次提交
  18. 28 10月, 2009 1 次提交
  19. 09 9月, 2009 1 次提交
    • I
      rt2x00: Hardcode TX ack timeout and consume time · 4789666e
      Ivo van Doorn 提交于
      The calculated values for the ACK timeout and ACK
      consume time are different then the values as
      used by the Legacy drivers.
      
      After testing from James Ledwith it appeared that
      the calculated values caused a high amount of TX
      failures, and the values from the Legacy drivers
      were the most optimal to prevent TX failure due to
      excessive retries.
      
      The symptoms of this problem:
       - Rate control module always falls back to 1Mbs
       - Low throughput when bitrate was fixed
      
      Possible side-effects (not confirmed but highly likely)
       - Problems with DHCP
       - Broken connections due to lack of probe response
      
      This should fix at least:
      Kernel bugzilla reports: [13362], [13009], [9273]
      Fedora bugzilla reports: [443203]
      but possible some additional bugs as well.
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4789666e
  20. 20 8月, 2009 3 次提交
  21. 14 8月, 2009 2 次提交