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

ipw2200: fix scanning while associated

2009-02-12T17:31:13+00:00

commit 14a4dfe2ff8c353f59ae8324059ded1cfe22c7d9 upstream.

This patch fixes sporadic firmware restarts when scanning while associated.

The firmware will quietly cancel a scan (while associated) if the dwell time
for a channel to be scanned is larger than the time it may stay away from the
operating channel (because of DTIM catching). Unfortunately the driver is not
notified about the canceled scan and therefore the scan watchdog timeout will
be hit and the driver causes a firmware restart which results in
disassociation. This mainly happens on passive channels which use a dwell time
of 120 whereas a typical beacon interval is around 100.

The patch changes the dwell time for passive channels to be slightly smaller
than the actual beacon interval to work around the firmware issue. Furthermore
the number of allowed beacon misses is increased from one to three as otherwise
most scans (while associated) won't complete successfully.

However scanning while associated will still fail in corner cases such as a
beacon intervals below 30.

Signed-off-by: Helmut Schaa 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtl8187: Fix error in setting OFDM power settings for RTL8187L

2009-02-02T16:28:15+00:00

commit eb83bbf57429ab80f49b413e3e44d3b19c3fdc5a upstream.

After reports of poor performance, a review of the latest vendor driver
(rtl8187_linux_26.1025.0328.2007) for RTL8187L devices was undertaken.

A difference was found in the code used to index the OFDM power tables. When
the Linux driver was changed, my unit works at a much greater range than
before. I think this fixes Bugzilla #12380 and has been tested by at least
two other users.

Signed-off-by: Larry Finger 
Tested-by: Martín Ernesto Barreyro 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtl8187: Add termination packet to prevent stall

2009-02-02T16:28:10+00:00

commit 2fcbab044a3faf4d4a6e269148dd1f188303b206 upstream.

The RTL8187 and RTL8187B devices can stall unless an explicit termination
packet is sent.

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

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

rt2x00: add USB ID for the Linksys WUSB200.

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

commit 3be36ae223271f9c2cfbe7406846c8fdcd2f50c3 upstream.

add USB ID for the Linksys WUSB200 Wireless-G Business USB Adapter to
rt73usb.

Signed-off-by: Stefan Lippers-Hollmann 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

p54usb: Add USB ID for Thomson Speedtouch 121g

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

commit 878e6a432f85690a2c0d88d96f177e54ff1d4a57 upstream.

Add the USB ID for Thomson Speedtouch 121g to p54usb.

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

iwlwifi: use GFP_KERNEL to allocate Rx SKB memory

2009-01-18T18:35:27+00:00

commit f1bc4ac61f2c08515afd80c6dc3962aa6d0b138b upstream.

Previously we allocate Rx SKB with GFP_ATOMIC flag. This is because we need
to hold a spinlock to protect the two rx_used and rx_free lists operation
in the rxq.

	spin_lock();
	...
	element = rxq->rx_used.next;
	element->skb = alloc_skb(..., GFP_ATOMIC);
	list_del(element);
	list_add_tail(&element->list, &rxq->rx_free);
	...
	spin_unlock();

After spliting the rx_used delete and rx_free insert into two operations,
we don't require the skb allocation in an atomic context any more (the
function itself is scheduled in a workqueue).

	spin_lock();
	...
	element = rxq->rx_used.next;
	list_del(element);
	...
	spin_unlock();
	...
	element->skb = alloc_skb(..., GFP_KERNEL);
	...
	spin_lock()
	...
	list_add_tail(&element->list, &rxq->rx_free);
	...
	spin_unlock();

This patch should fix the "iwlagn: Can not allocate SKB buffers" warning
we see recently.

Signed-off-by: Zhu Yi 
Acked-by: Tomas Winkler 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlagn: downgrade BUG_ON in interrupt

2009-01-14T17:44:03+00:00

commit 55d6a3cd0cc85ed90c39cf32e16f622bd003117b upstream.

This BUG_ON really shouldn't trigger, but if it does, as on my machine,
it leaves you wondering what happened because you won't see it. Let's
instead leak a bit of state and memory and at least make it possible to
report it to the kerneloops project to track it.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Cc: François Valenduc 
Signed-off-by: Greg Kroah-Hartman

iwlagn: fix RX skb alignment

2008-12-18T17:13:38+00:00

commit 4018517a1a69a85c3d61b20fa02f187b80773137 upstream.

So I dug deeper into the DMA problems I had with iwlagn and a kind soul
helped me in that he said something about pci-e alignment and mentioned
the iwl_rx_allocate function to check for crossing 4KB boundaries. Since
there's 8KB A-MPDU support, crossing 4k boundaries didn't seem like
something the device would fail with, but when I looked into the
function for a minute anyway I stumbled over this little gem:

	BUG_ON(rxb->dma_addr & (~DMA_BIT_MASK(36) & 0xff));

Clearly, that is a totally bogus check, one would hope the compiler
removes it entirely. (Think about it)

After fixing it, I obviously ran into it, nothing guarantees the
alignment the way you want it,  because of the way skbs and their
headroom are allocated. I won't explain that here nor double-check that
I'm right, that goes beyond what most of the CC'ed people care about.

So then I came up with the patch below, and so far my system has
survived minutes with 64K pages, when it would previously fail in
seconds. And I haven't seen a single instance of the TX bug either. But
when you see the patch it'll be pretty obvious to you why.

This should fix the following reported kernel bugs:

http://bugzilla.kernel.org/show_bug.cgi?id=11596
http://bugzilla.kernel.org/show_bug.cgi?id=11393
http://bugzilla.kernel.org/show_bug.cgi?id=11983

I haven't checked if there are any elsewhere, but I suppose RHBZ will
have a few instances too...

I'd like to ask anyone who is CC'ed (those are people I know ran into
the bug) to try this patch.

I am convinced that this patch is correct in spirit, but I haven't
understood why, for example, there are so many unmap calls. I'm not
entirely convinced that this is the only bug leading to the TX reply
errors.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: clean key table in iwl_clear_stations_table function

2008-12-18T17:13:37+00:00

commit 40a9a8299116297429298e8fcee08235134883f7 upstream.

This patch cleans uCode key table bit map iwl_clear_stations_table
since all stations are cleared also the key table must be.

Since the keys are not removed properly on suspend by mac80211
this may result in exhausting key table on resume leading
to memory corruption during removal

This patch also fixes a memory corruption problem reported in
http://marc.info/?l=linux-wireless&m=122641417231586&w=2 and tracked in
http://bugzilla.kernel.org/show_bug.cgi?id=12040.

When the key is removed a second time the offset is set to 255 - this
index is not valid for the ucode_key_table and corrupts the eeprom pointer
(which is 255 bits from ucode_key_table).

Signed-off-by: Tomas Winkler 
Signed-off-by: Zhu Yi 
Reported-by: Carlos R. Mafra 
Reported-by: Lukas Hejtmanek 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman