1. 09 4月, 2010 1 次提交
  2. 07 4月, 2010 1 次提交
  3. 31 3月, 2010 1 次提交
  4. 16 2月, 2010 2 次提交
  5. 09 2月, 2010 1 次提交
  6. 29 12月, 2009 1 次提交
  7. 29 11月, 2009 2 次提交
  8. 17 11月, 2009 1 次提交
  9. 12 11月, 2009 2 次提交
  10. 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
  11. 20 8月, 2009 1 次提交
  12. 14 8月, 2009 1 次提交
  13. 25 7月, 2009 1 次提交
  14. 22 7月, 2009 1 次提交
    • A
      rt2x00: Fix chipset detection for rt2500usb · 7adfd5c7
      Andy Whitcroft 提交于
      The commit below changed the semantics of rt2x00_check_rev so that it no
      longer checked the bottom 4 bits of the rev were non-zero.  During that
      conversion this part of the check was not propogated to the rt2500usb
      initialisation.
      
          commit 358623c2
          Author: Ivo van Doorn <ivdoorn@gmail.com>
          Date:   Tue May 5 19:46:08 2009 +0200
      
              rt2x00: Simplify rt2x00_check_rev
      
      Without this check rt73 devices are miss recognised as rt2500 devices and
      two drivers are loaded.  Preventing the device being used.  Reinstate this
      check.
      Signed-off-by: NAndy Whitcroft <apw@canonical.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7adfd5c7
  15. 11 7月, 2009 1 次提交
  16. 04 6月, 2009 1 次提交
  17. 23 5月, 2009 1 次提交
  18. 07 5月, 2009 2 次提交
  19. 06 3月, 2009 1 次提交
  20. 28 2月, 2009 1 次提交
  21. 10 2月, 2009 1 次提交
  22. 30 1月, 2009 9 次提交
  23. 13 1月, 2009 2 次提交
    • I
      rt2x00: Fix rt2500usb HW crypto: WEP 128 & AES · f1dd2b23
      Ivo van Doorn 提交于
      The TXD_W0_CIPHER field is a 1-bit field. It only acts as boolean value
      to indicate if the frame must be encrypted or not.
      
      The way rt2x00_set_field32() worked it would grab the least signifcant bit
      from txdesc->cipher and use that as value. Because of that WEP 64 and TKIP
      worked since they had odd-numbered values, while WEP 128 and AES were
      even numbers and didn't work.
      
      Correctly booleanize the txdecs->cipher value to allow the hardware to
      encrypt the outgoing data. After this we can enable HW crypto by default again.
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f1dd2b23
    • I
      Fix rt2500usb HW crypto: TKIP · f3d340c1
      Ivo van Doorn 提交于
      rt2500usb doesn't strip the IV/ICV data from received frames,
      so we don't need to set the RX_FLAG_IV_STRIPPED flag.
      We do need to set the RX_FLAG_MMIC_STRIPPED flag for all
      encryption types since the MMIC has been removed from the frame.
      
      After this patch TKIP Hardware crypto works for rt2500usb.
      WEP and AES are still failing.
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f3d340c1
  24. 05 12月, 2008 2 次提交
  25. 26 11月, 2008 2 次提交
    • I
      rt2x00: Detect USB BULK in/out endpoints · f1ca2167
      Ivo van Doorn 提交于
      Instead of hardcoding the used in/out endpoints
      we should detect them by walking through all
      available endpoints.
      
      rt2800usb will gain the most out of this, because
      the legacy drivers indicate that there are multiple
      endpoints available.
      However this code might benefit at least rt73usb as
      well for the MIMO queues, and if we are really lucky
      rt2500usb will benefit because for the TX and PRIO
      queues.
      
      Even if rt2500usb and rt73usb do not get better performance
      after this patch, the endpoint detection still belongs to
      rt2x00usb, and it shouldn't hurt to always try to detect
      the available endpoints.
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f1ca2167
    • I
      rt2x00: Cleanup indirect register access · c9c3b1a5
      Ivo van Doorn 提交于
      All code which accessed indirect registers was similar
      in respect to the for-loop, the given timeout, etc.
      Move it into a seperate function, which for PCI drivers
      can be moved into rt2x00pci.
      
      This allows us to cleanup the cleanup the code further
      by removing the goto statementsand making the codepath
      look a bit nicer.
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c9c3b1a5