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

ath9k: quiet harmless ForceXPAon messages

2009-01-25T00:36:25+00:00

This is a port of one line of upstream patch
f1dc56003b23d2d5bb5a756de6b1633a76c9e697

The "ForceXPAon" messages on ath9k were not meant to be printed
regularly, lets quiet them as this can happen quite frequently
(scans) and will fill the logs with tons of these messages.

Signed-off-by: Sujith 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Greg Kroah-Hartman

ath9k: correct expected max RX buffer size

2008-12-05T18:55:15+00:00

commit b4b6cda2298b0c9a0af902312184b775b8867c65 upstream

We should only tell the hardware its capable of DMA'ing
to us only what we asked dev_alloc_skb(). Prior to this
it is possible a large RX'd frame could have corrupted
DMA data but for us but we were saved only because we
were previously also pci_map_single()'ing the same large
value. The issue prior to this though was we were unmapping
a smaller amount which the prior DMA patch fixed.

Signed-off-by: Bennyam Malavazi 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Greg Kroah-Hartman

ath9k: Fix SW-IOMMU bounce buffer starvation

2008-12-05T18:55:15+00:00

commit ca0c7e5101fd4f37fed8e851709f08580b92fbb3 upstream.

This should fix the SW-IOMMU bounce buffer starvation
seen ok kernel.org bugzilla 11811:

http://bugzilla.kernel.org/show_bug.cgi?id=11811

Users on MacBook Pro 3.1/MacBook v2 would see something like:

DMA: Out of SW-IOMMU space for 4224 bytes at device 0000:0b:00.0

Unfortunately its only easy to trigger on MacBook Pro 3.1/MacBook v2
so far so its difficult to debug (even with swiotlb=force).

We were pci_unmap_single()'ing less bytes than what we called
for with pci_map_single() and as such we were starving
the swiotlb from its 64MB amount of bounce buffers. We remain
consistent and now always use sc->rxbufsize for RX. While at
it we update the beacon DMA maps as well to only use the data
portion of the skb, previous to this we were pci_map_single()'ing
more data for beaconing than what we tell the hardware it can use,
therefore pushing more iotlb abuse.

Still not sure why this is so easily triggerable on
MacBook Pro 3.1, it may be the hardware configuration
tends to use more memory > 3GB mark for DMA.

Signed-off-by: Maciej Zenczykowski 
Signed-off-by: Bennyam Malavazi 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Greg Kroah-Hartman

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

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

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

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

ath9k: Assign seq# when mac80211 requests this

2008-09-11T15:10:28+00:00

Use TX control flag IEEE80211_TX_CTL_ASSIGN_SEQ as a request to update
the seq# for the frames. This will likely require some further cleanup
to get seq# correctly for Beacons vs. other frames and also potentially
for multiple BSSes. Anyway, this is better than ending up sending out
most frames with seq# 0.

(This is a backport of patch w/ same title already in net-next-2.6.
It is verified to fix http://bugzilla.kernel.org/show_bug.cgi?id=11394
and it should be acceptable for -rc due to the driver being new
in 2.6.27.)

Signed-off-by: Jouni Malinen 
Signed-off-by: John W. Linville

ath9k: Fix TX control flag use for no ACK and RTS/CTS

2008-09-03T19:32:44+00:00

Signed-off-by: Jouni Malinen 
Signed-off-by: John W. Linville