1. 14 6月, 2012 1 次提交
    • E
      wlcore: send EAPOLs with basic rate policy · 8f1a8684
      Eyal Shapira 提交于
      EAPOLs are sent at high rates as they are considered
      data packets. Some APs like Motorola Symbol AP7131 and AP650
      don't respond well to these rates and don't respond with
      EAPOL 3/4 consistently. When sending EAPOL 2/4 at 54Mbps
      we've seen approx 30% success rate in getting EAPOL 3/4 response
      while using 11Mbps we got 100% success.
      To increase the chances of successful 4-Way handshake with
      such APs, send EAPOLs with basic rate policy in order to avoid
      high rates.
      Signed-off-by: NEyal Shapira <eyal@wizery.com>
      Signed-off-by: NLuciano Coelho <coelho@ti.com>
      8f1a8684
  2. 07 6月, 2012 6 次提交
  3. 05 6月, 2012 4 次提交
  4. 12 4月, 2012 13 次提交
  5. 08 3月, 2012 1 次提交
  6. 28 2月, 2012 3 次提交
    • A
      wl12xx: flush all Tx queues on tx_flush timeout · 18aa755b
      Arik Nemtsov 提交于
      Ensure our queues are empty at the end of a tx_flush(), in case we
      timeout on passively waiting for them. This makes sure no left-overs are
      transmitted when we are on the wrong channel.
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Signed-off-by: NLuciano Coelho <coelho@ti.com>
      18aa755b
    • A
      wl12xx: avoid starving the system hlid · 49c9cd26
      Arik Nemtsov 提交于
      Re-factor the Tx scheduler so that the system_hlid is taken into account
      before restarting an iteration over the wlvifs. Previously this
      hlid had a lower priority and would starve if some wlvif had many
      packets.
      In addition avoid iterating over wlvifs past last_wlvif when performing
      the a second pass. If we had packets in those wlvifs they would have
      been found earlier.
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Signed-off-by: NLuciano Coelho <coelho@ti.com>
      49c9cd26
    • A
      wl12xx: reset link Tx queues when freeing it · 6246ca00
      Arik Nemtsov 提交于
      Before, the link was first freed (invalidating it in the map), and later
      on vif removal, all valid wlvif-related links were reset. Since these
      links were already invalid, we failed to reset them.
      The bug was made worse by op_stop, which set the tx_queue_count to 0
      arbitrarily. This resulted in a negative tx_queue_count in some scenarios.
      
      Fix this by resetting the Tx-queues of a link when freeing it. Add a
      WARN_ON and reset all link Tx-queues in op_stop, to avoid a negative
      tx_queue_count.
      
      [changed WARN_ON to WARN_ON_ONCE -- Luca]
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Signed-off-by: NLuciano Coelho <coelho@ti.com>
      6246ca00
  7. 15 2月, 2012 5 次提交
  8. 15 12月, 2011 1 次提交
  9. 10 12月, 2011 1 次提交
  10. 01 12月, 2011 1 次提交
  11. 08 11月, 2011 3 次提交
  12. 12 10月, 2011 1 次提交