linux-toradex.git/drivers/net/wireless, branch v2.6.27.4

ath9k: fix oops on trying to hold the wrong spinlock

2008-10-22T21:21:12+00:00

commit a477e4e6d48d3ac7c7a75bad40585cb391e5c237 upstream

We were trying to hold the wrong spinlock due to a typo
on IEEE80211_BAR_CTL_TID_S's definition. We use this to
compute the tid number and then hold this this tid number's
spinlock.

Tested-by: Steven Noonan 
Signed-off-by: Vasanthakumar Thiagarajan 
Signed-off-by: Sujith 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k/mac80211: disallow fragmentation in ath9k, report to userspace

2008-10-22T21:21:05+00:00

commit 4233df6b748193d45f79fb7448991a473061a65d upstream

As I've reported, ath9k currently fails utterly when fragmentation
is enabled. This makes ath9k "support" hardware fragmentation by
not supporting fragmentation at all to avoid the double-free issue.
The patch also changes mac80211 to report errors from the driver
operation to userspace.

That hack in ath9k should be removed once the rate control algorithm
it has is fixed, and we can at that time consider removing the hw
fragmentation support entirely since it's not used by any driver.

Signed-off-by: Johannes Berg 
Acked-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

b43legacy: Fix failure in rate-adjustment mechanism

2008-10-18T17:49:12+00:00

commit c6a2afdacccd56cc0be8e9a7977f0ed1509069f6 upstream
Date: Sat, 6 Sep 2008 16:51:22 -0500
Subject: b43legacy: Fix failure in rate-adjustment mechanism

A coding error present since b43legacy was incorporated into the
kernel has prevented the driver from using the rate-setting mechanism
of mac80211. The driver has been forced to remain at a 1 Mb/s rate.

Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

libertas: clear current command on card removal

2008-10-18T17:49:12+00:00

commit 71b35f3abeb8f7f7e0afd7573424540cc5aae2d5 upstream

If certain commands were in-flight when the card was pulled or the
driver rmmod-ed, cleanup would block on the work queue stopping, but the
work queue was in turn blocked on the current command being canceled,
which didn't happen.  Fix that.

Signed-off-by: Dan Williams 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k: disable MIB interrupts to fix interrupt storm

2008-09-24T19:55:24+00:00

Enabling the MIB interrupts has proven to cause an
interrupt storm after 7 hours of run. We will make use of the
MIB interrupt once we have ANI supported added so for now
to cure this we disable the interrupt.

The interrupt storm can be seen as follows after 7 hours of run
as reported by  Steven Noonan :

18:28:38          sum   1106.00
18:28:39          sum   1037.62
18:28:40          sum   1069.00
18:28:41          sum   1167.00
18:28:42          sum   1155.00
18:28:43          sum   1339.00
18:28:44          sum  18355.00
18:28:45          sum  17845.45
18:28:46          sum  15285.00
18:28:47          sum  17511.00
18:28:48          sum  17568.69
18:28:49          sum  17704.04
18:28:50          sum  18566.67
18:28:51          sum  18913.13

at 18:28:44 the MIB interrupt kicked off and caused huge
latency which can be seen even on a video he submitted:

http://www.youtube.com/watch?v=4GeCx1gZMpA

Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville

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

2008-09-22T22:29:05+00:00

ath9k: Fix IRQ nobody cared issue with ath9k

2008-09-22T21:22:15+00:00

IRQs should be disabled before calling free_irq. Also flush pending
IRQs. Pasted the kernel log message for reference.

kernel: irq 17: nobody cared (try booting with the "irqpoll" option)
kernel:  [] __report_bad_irq+0x2e/0x6f
kernel:  [] note_interrupt+0x1b5/0x207
kernel:  [] ? handle_IRQ_event+0x21/0x48
kernel:  [] handle_fasteoi_irq+0x8e/0xad
kernel:  [] do_IRQ+0x6c/0x84
kernel:  [] common_interrupt+0x23/0x28
kernel:  [] ? acpi_idle_enter_simple+0x198/0x205
kernel:  [] ? menu_select+0x5c/0x78
kernel:  [] cpuidle_idle_call+0x59/0x89
kernel:  [] cpu_idle+0xae/0xcf
kernel:  [] rest_init+0x4e/0x50
kernel:  =======================
kernel: handlers:
kernel: [] (ath_isr+0x0/0x13a [ath9k])
kernel: Disabling IRQ #17

Signed-off-by: Senthil Balasubramanian 
Tested-by: Steven Noonan 
Signed-off-by: John W. Linville

wireless: zd1211rw: add device ID fix wifi dongle "trust nw-3100"

2008-09-22T20:52:51+00:00

akpm: taken from http://bugzilla.kernel.org/show_bug.cgi?id=11587

I bought the wifi dongle trust nw-3100 wich is in fact a zd1211rw.  Its
hardware id was missing in the sources, adding it made it work flawlessly.

Cc: Daniel Drake 
Cc: Ulrich Kunitz 
Cc: Johannes Berg 
Signed-off-by: Andrew Morton 
Signed-off-by: John W. Linville

ath9k: connectivity is lost after Group rekeying is done

2008-09-22T20:52:50+00:00

Connectivtiy is lost after Group rekeying is done. The keytype
maintained by ath9k is reset when group key is updated. Though
sc_keytype can be reset only for broadcast key the proper fix
would be to use mac80211 provided key type from txinfo during
xmit and get rid of sc_keytype from ath9k ath_softc.

Signed-off-by: Vasanthakumar Thiagarajan 
Signed-off-by: Senthil Balasubramanian 
Tested-by: Steven Noonan 
Signed-off-by: John W. Linville

Revert "b43/b43legacy: add RFKILL_STATE_HARD_BLOCKED support"

2008-09-17T02:32:30+00:00

This reverts commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f, which as
Larry Finger reports causes the radio LED on his system to no longer
respond to rfkill switch events.

Reported-by: Larry Finger 
Requested-by: John W. Linville 
Signed-off-by: Linus Torvalds