linux-stable.git/drivers/net/wireless/rt2x00/rt2x00dev.c, branch v3.6

rt2800usb: Added rx packet length validity check

2012-09-05T18:53:36+00:00

On our system (ARM Cortex-M3 SOC running linux-2.6.33)
frequent crashes were observed in the rt2800usb module
because of the invalid length of the received packet (3392,
46920...). This patch adds the sanity check on the packet
legth. Also, changed WARNING to ERROR in rt2x00lib_rxdone()
so that the bad packet condition would be noticed.

The fix was tested on the latest compat-wireless-3.5.1-1-snpc.

Cc: stable@vger.kernel.org
Signed-off-by: Sergei Poselenov 
Acked-by: Ivo van Doorn 
Signed-off-by: John W. Linville

rt2x00: claim RSN IBSS support

2012-06-06T19:18:18+00:00

Similar like other drivers, do not configure group keys to the hardware
(on Ad-Hoc mode) to make IBSS RSN work.

Signed-off-by: Stanislaw Gruszka 
Acked-by: Helmut Schaa 
Signed-off-by: John W. Linville

rt2x00: Use GFP_KERNEL for rx buffer allocation on USB devices

2012-04-23T19:35:29+00:00

Since the RX path on USB devices is handled in process context we can
use GFP_KERNEL for RX buffer allocation. This should reduce the
likelihood of allocation failures.

Signed-off-by: Helmut Schaa 
Acked-by: Gertjan van Wingerde 
Tested-By: Marc Dietrich 
Signed-off-by: John W. Linville

rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails

2012-04-17T18:57:13+00:00

There are connection stalls or very poor throughputs with rt2800
hardware using 802.11n in AP mode since patch "mac80211: retry sending
failed BAR frames later instead of tearing down aggr"[1][2].

Since rt2800 hardware is not able to correctly report the tx status of
BAR frames, this patch removes as workaround the existing error handling
on AP side, which lets mac80211 send a BAR when an AMPDU subframe fails.

As a result, most wifi clients (aside from Intel STAs on Windows)
instead will timeout now the reorder buffer and request the lost frame
again.

The correct solution would be, to tear down BA session on AP side.

This patch was born on the basis of "[RFT] rt2x00: Tear down BA
session on QoS frame failure"[3].

Thanks to Helmut Schaa for his support!

[1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304
[2] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=f0425beda4d404a6e751439b562100b902ba9c98
[3] http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/569

Signed-off-by: Andreas Hartmann 
Acked-by: Helmut Schaa 
Signed-off-by: John W. Linville

rt2x00: Fix rfkill_polling register function.

2012-04-10T18:14:28+00:00

  Move rt2x00rfkill_register(rt2x00dev) to rt2x00lib_probe_dev
  function. It fixes of starting rfkill_poll function at the
  right time if sets hard rfkill block and reboot. rt2x00mac_rfkill_poll
  should be starting before bringing up the wireless interface.

Signed-off-by: Chen, Chien-Chia 
Acked-by: Helmut Schaa 
CC: Kevin Chou 
Signed-off-by: John W. Linville

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2012-03-19T03:29:41+00:00

rt2x00: rt2800usb: rework txstatus code

2012-03-15T17:40:31+00:00

Currently we read tx status register after each urb data transfer. As
callback procedure also trigger reading, that causing we have many
"threads" of reading status. To prevent that introduce TX_STATUS_READING
flags, and check if we are already in process of sequential reading
TX_STA_FIFO, before requesting new reads.

Change timer to hrtimer, that make TX_STA_FIFO overruns less possible.
Use 200 us for initial timeout, and then reschedule in 100 us period,
this values probably have to be tuned.

Make changes on txdone work. Schedule it from
rt2800usb_tx_sta_fifo_read_completed() callback when first valid status
show up. Check in callback if tx status timeout happens, and schedule
work on that condition too. That make possible to remove tx status
timeout from generic watchdog. I moved that to rt2800usb.

Loop in txdone work, that should prevent situation when we queue work,
which is already processed, and after finish work is not rescheduled
again.

Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville

rt2x00: fix random stalls

2012-03-12T18:00:17+00:00

Is possible that we stop queue and then do not wake up it again,
especially when packets are transmitted fast. That can be easily
reproduced with modified tx queue entry_num to some small value e.g. 16.

If mac80211 already hold local->queue_stop_reason_lock, then we can wait
on that lock in both rt2x00queue_pause_queue() and
rt2x00queue_unpause_queue(). After drooping ->queue_stop_reason_lock
is possible that __ieee80211_wake_queue() will be performed before
__ieee80211_stop_queue(), hence we stop queue and newer wake up it
again.

Another race condition is possible when between rt2x00queue_threshold()
check and rt2x00queue_pause_queue() we will process all pending tx
buffers on different cpu. This might happen if for example interrupt
will be triggered on cpu performing rt2x00mac_tx().

To prevent race conditions serialize pause/unpause by queue->tx_lock.

Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka 
Acked-by: Gertjan van Wingerde 
Signed-off-by: John W. Linville

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless

2012-02-29T19:53:21+00:00

rt2x00:Add VCO recalibration

2012-02-27T19:05:44+00:00

Signed-off-by: John Li 
Acked-by: Gertjan van Wingerde 
Acked-by: Ivo van Doorn 
Signed-off-by: John W. Linville