linux-stable.git/drivers/net/wireless/rt2x00/rt2x00dev.c, branch linux-3.4.y

rt2x00: fix rfkill regression on rt2500pci

2014-07-09T17:51:20+00:00

commit 616a8394b5df8c88f4dd416f4527439a4e365034 upstream.

As reported by Niels, starting rfkill polling during device probe
(commit e2bc7c5, generally sane change) broke rfkill on rt2500pci
device. I considered that bug as some initalization issue, which
should be fixed on rt2500pci specific code. But after several
attempts (see bug report for details) we fail to find working solution.
Hence I decided to revert to old behaviour on rt2500pci to fix
regression.

Additionally patch also unregister rfkill on device remove instead
of ifconfig down, what was another issue introduced by bad commit.

Bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=73821

Fixes: e2bc7c5f3cb8 ("rt2x00: Fix rfkill_polling register function.")
Bisected-by: Niels 
Reported-and-tested-by: Niels 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rt2x00: error in configurations with mesh support disabled

2013-03-28T19:12:28+00:00

commit 6ef9e2f6d12ce9e2120916804d2ddd46b954a70b upstream.

If CONFIG_MAC80211_MESH is not set, cfg80211 will now allow advertising
interface combinations with NL80211_IFTYPE_MESH_POINT present.
Add appropriate ifdefs to avoid running into errors.

[Backported for 3.8-stable. Removed code of simultaneous AP and mesh
mode added in 4a5fc6d 3.9-rc1.]

Signed-off-by: Felix Fietkau 
Acked-by: Gertjan van Wingerde 
Signed-off-by: John W. Linville 
Signed-off-by: Lingzhu Xiang 
Reviewed-by: CAI Qian 
Signed-off-by: Greg Kroah-Hartman

rt2800usb: Added rx packet length validity check

2012-10-02T17:30:20+00:00

commit efd5d6b03bd9c9e0df646c56fb5f4f3e25e5c1ac upstream.

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.

Signed-off-by: Sergei Poselenov 
Acked-by: Ivo van Doorn 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

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

rt2x00: fix a possible NULL pointer dereference

2012-02-21T19:45:25+00:00

The 'rt2x00lib_probe_dev' function tries to
allocate the workqueue. If the allocation
fails, 'rt2x00_lib_remove_dev' is called on
the error path. Because 'rt2x00dev->workqueue'
is NULL in this case, the 'destroy_workqueue'
call will cause a NULL pointer dereference.

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