1. 07 4月, 2010 1 次提交
  2. 16 2月, 2010 2 次提交
  3. 09 2月, 2010 1 次提交
  4. 29 12月, 2009 1 次提交
  5. 29 11月, 2009 2 次提交
  6. 17 11月, 2009 1 次提交
  7. 12 11月, 2009 2 次提交
  8. 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
  9. 20 8月, 2009 1 次提交
  10. 14 8月, 2009 1 次提交
  11. 25 7月, 2009 1 次提交
  12. 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
  13. 11 7月, 2009 1 次提交
  14. 04 6月, 2009 1 次提交
  15. 23 5月, 2009 1 次提交
  16. 07 5月, 2009 2 次提交
  17. 06 3月, 2009 1 次提交
  18. 28 2月, 2009 1 次提交
  19. 10 2月, 2009 1 次提交
  20. 30 1月, 2009 9 次提交
  21. 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
  22. 05 12月, 2008 2 次提交
  23. 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
  24. 22 11月, 2008 2 次提交
    • I
      rt2x00: Fix race condition when using inderect registers · 8ff48a8b
      Ivo van Doorn 提交于
      Indirect registers require multiple calls to the CSR
      register in order to access the indirect registers.
      This must be protected under a lock to prevent race
      conditions which could cause invalid data to
      be returned when reading from the indirect register or silent
      failures when writing data to the indirect register.
      
      USB drivers where already protected under a mutex,
      so rename the mutex and make PCI drivers use the mutex
      as well.
      This now means that BBP and RF registers are no longer
      accessible in interrupt context. That is not a bad
      situation since the slow behavior of accessing
      those registers means we don't _want_ to access them
      in interrupt context either.
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8ff48a8b
    • I
      rt2x00: Optimize get_duration / get_duration_res · bad13639
      Ivo van Doorn 提交于
      We can optimize get_duration and get_duration_res
      by making them a macro. They are really simple
      calculation handlers so this doesn't matter much.
      
      Often (especially in rt2400pci and rt2500pci,
      the arguments are hardcoded, and the result value
      is passed into other hardcoded values.
      
      By making the functions a macro GCC can
      optimize the entire thing much better.
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bad13639