1. 06 10月, 2010 3 次提交
    • H
      rt2x00: rework tx status handling in rt2800pci · 96c3da7d
      Helmut Schaa 提交于
      This patch changes the way tx status reports are handled by rt2800pci.
      Previously rt2800pci would sometimes lose tx status reports as the
      TX_STA_FIFO register is a fifo of 16 entries that can overflow in case
      we don't read it often/fast enough. Since interrupts are disabled in the
      device during the execution of the interrupt thread it happend sometimes
      under high network and CPU load that processing took too long and a few
      tx status reports were dropped by the hw.
      
      To fix this issue the TX_STA_FIFO register is read directly in the
      interrupt handler and stored in a kfifo which is large enough to hold
      all status reports of all used tx queues.
      
      To process the status reports a new tasklet txstatus_tasklet is used.
      Using the already used interrupt thread is not possible since we don't
      want to disable the TX_FIFO_STATUS interrupt while processing them and
      it is not possible to schedule the interrupt thread multiple times for
      execution. A tasklet instead can be scheduled multiple times which
      allows to leave the TX_FIFO_STATUS interrupt enabled while a previously
      scheduled tasklet is still executing.
      
      In short: All other interrupts are handled in the interrupt thread as
      before. Only the TX_FIFO_STATUS interrupt is partly handled in the
      interrupt handler and finished in the according tasklet.
      
      One drawback of this patch is that it duplicates some code from
      rt2800lib. However, that can be cleaned up in the future once the
      rt2800usb and rt2800pci tx status handling converge more.
      
      Using this patch on a Ralink RT3052 embedded board gives me a reliable
      wireless connection even under high CPU and network load. I've
      transferred several gigabytes without any queue lockups.
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      96c3da7d
    • H
    • H
      rt2x00: Don't overwrite beacon buffers in pairwise key setup · 2a0cfeb8
      Helmut Schaa 提交于
      rt2800 devices use parts of the pariwise key table to store the beacon
      frames for beacon 6 and 7. To not overwrite the beacon frame buffers
      limit the number of entries we store in the pairwise key table to 222.
      
      Also add some descriptive comments about this shared memory usage.
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2a0cfeb8
  2. 15 9月, 2010 6 次提交
  3. 01 9月, 2010 10 次提交
  4. 26 8月, 2010 9 次提交
  5. 17 8月, 2010 10 次提交
  6. 05 8月, 2010 1 次提交
  7. 28 7月, 2010 1 次提交
    • S
      rt2500usb: disallow to set WEP key with non zero index · 98ec6218
      Stanislaw Gruszka 提交于
      On our hardware (050d:7050 Belkin Components F5D7050 Wireless G Adapter),
      setting any WEP key with non zero index, cause rx frames corruption.
      
      Note: perhaps (I did not check) this can be fixed differently - by using
      hw_key_idx the same as true MAC key index. But according to the comment in
      rt2x00mac_set_key():
      
      "the hardware requires keys to be assigned in correct order (When key 1
      is provided but key 0 is not, then the key is not found by the hardware
      during RX)"
      
      this will be quite problematic. Since WEP should not be used, disabling
      hardware crypto offload for it will not hurt much. Beside static
      one key WEP will still be offloaded.
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      98ec6218