linux-toradex.git/drivers/net/wireless, branch v2.6.27.8 Linux kernel for Apalis and Colibri modules rtl8187: Add USB ID for Belkin F5D7050 with RTL8187B chip 2008-12-05T18:55:22+00:00 Florent Fourcot florent.fourcot@enst-bretagne.fr 2008-10-13T23:34:26+00:00 ebbaa421af0341f1a0806bb4eb8384c0d3628441 commit eaca90dab6ab9853223029deffdd226f41b2028c upstream. The Belkin F5D7050rev5000de (id 050d:705e) has the Realtek RTL8187B chip and works with the 2.6.27 driver. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit eaca90dab6ab9853223029deffdd226f41b2028c upstream.

The Belkin F5D7050rev5000de (id 050d:705e) has the Realtek RTL8187B chip
and works with the 2.6.27 driver.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
rtl8187: add device ID 0bda:8198 2008-12-05T18:55:22+00:00 John W. Linville linville@tuxdriver.com 2008-10-10T18:16:46+00:00 6ddaffb84f759dd8d4c0fd36aa597de889b6de71 commit 746db510395e32ff57b9f8582e520df6b3fac618 upstream. Reported by zOOmER.gm@gmail.com to work here: http://bugzilla.kernel.org/show_bug.cgi?id=11728 Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: Zoomer <zoomer.gm@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 746db510395e32ff57b9f8582e520df6b3fac618 upstream.

Reported by zOOmER.gm@gmail.com to work here:

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

Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Zoomer <zoomer.gm@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ath9k: correct expected max RX buffer size 2008-12-05T18:55:15+00:00 Luis R. Rodriguez lrodriguez@atheros.com 2008-12-02T20:51:21+00:00 0c089be68ac41ca6e0e38dea22af8b91c52d1ee0 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 <Bennyam.Malavazi@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
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 <Bennyam.Malavazi@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ath9k: Fix SW-IOMMU bounce buffer starvation 2008-12-05T18:55:15+00:00 Luis R. Rodriguez lrodriguez@Atheros.com 2008-12-02T20:51:20+00:00 c5353210bb519a01e54cdcefd940234b0e70984c 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 <zenczykowski@gmail.com> Signed-off-by: Bennyam Malavazi <Bennyam.Malavazi@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
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 <zenczykowski@gmail.com>
Signed-off-by: Bennyam Malavazi <Bennyam.Malavazi@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
rtl8187 : support for Sitecom WL-168 0001 v4 2008-11-20T22:54:46+00:00 Bob Jolliffe bobjolliffe@gmail.com 2008-11-12T20:16:59+00:00 0e20e2321f460f1842683d1a5f7f9de519fb129a commit f3c769185a28b7947d97b3552a977102c1fac3f2 upstream. the Sitecom 0001 v4 with product id 0x0df6:0028, uses Realtek's RTL8187B and work fine with new 2.6.27 driver. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit f3c769185a28b7947d97b3552a977102c1fac3f2 upstream.

the Sitecom 0001 v4 with product id 0x0df6:0028, uses Realtek's
RTL8187B and work fine with new 2.6.27 driver.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
rtl8187: Add Abocom USB ID 2008-11-20T22:54:46+00:00 Ivan Kuten ivan.kuten@promwad.com 2008-11-11T01:39:25+00:00 51ceb068bb72f4e948ccb1a896f4ef8cc647d1e0 commit 8f7c41d4cec91cdbfa89b4a77d5a628938875366 upstream. Signed-off-by: Ivan Kuten <ivan.kuten@promwad.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 8f7c41d4cec91cdbfa89b4a77d5a628938875366 upstream.

Signed-off-by: Ivan Kuten <ivan.kuten@promwad.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
hostap: pad the skb->cb usage in lieu of a proper fix 2008-11-20T22:54:44+00:00 Johannes Berg johannes@sipsolutions.net 2008-11-12T21:54:22+00:00 2b233b842dfb434bfc946bbd97ec475a01b89000 commit f7cd168645dda3e9067f24fabbfa787f9a237488 upstream. Like mac80211 did, this driver makes 'clever' use of skb->cb to pass information along with an skb as it is requeued from the virtual device to the physical wireless device. Unfortunately, that trick no longer works... Unlike mac80211, code complexity and driver apathy makes this hack the best option we have in the short run. Hopefully someone will eventually be motivated to code a proper fix before all the effected hardware dies. (Above text by me. Johannes officially disavows all knowledge of this hack. -- JWL) Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit f7cd168645dda3e9067f24fabbfa787f9a237488 upstream.

Like mac80211 did, this driver makes 'clever' use of skb->cb to pass
information along with an skb as it is requeued from the virtual device
to the physical wireless device.  Unfortunately, that trick no longer
works...

Unlike mac80211, code complexity and driver apathy makes this hack
the best option we have in the short run.  Hopefully someone will
eventually be motivated to code a proper fix before all the effected
hardware dies.

(Above text by me.  Johannes officially disavows all knowledge of this
hack. -- JWL)

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ath5k: Fix reset sequence for AR5212 in general and RF5111 in particular 2008-11-20T22:54:42+00:00 Elias Oltmanns eo@nebensachen.de 2008-11-12T10:30:10+00:00 96e1cb2535bff4fad43471d95fa2ae5d68fac673 commit 7d19267b8d1e12c0baebf9be96e04cddffe63f67 upstream Take care to handle register 0xa228 exactly as in the HAL released by Atheros. This change is required to make ath5k work again on my system since commit 2203d6be (ath5k: Misc hw_reset updates), thus fixing a regression in 2.6.27 and therefore hopefully eligible for inclusion into a stable release. v2: Only overwrite initial register values on later revisions of AR5212 chips. v3: Use standard macros to manipulate the register. Signed-off-by: Elias Oltmanns <eo@nebensachen.de> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 7d19267b8d1e12c0baebf9be96e04cddffe63f67 upstream

Take care to handle register 0xa228 exactly as in the HAL released by
Atheros. This change is required to make ath5k work again on my system
since commit 2203d6be (ath5k: Misc hw_reset updates), thus fixing a
regression in 2.6.27 and therefore hopefully eligible for inclusion into
a stable release.

v2: Only overwrite initial register values on later revisions of AR5212
    chips.
v3: Use standard macros to manipulate the register.

Signed-off-by: Elias Oltmanns <eo@nebensachen.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ath5k: fix suspend-related oops on rmmod 2008-11-20T22:54:42+00:00 Elias Oltmanns eo@nebensachen.de 2008-11-12T10:28:39+00:00 cfce2256fc569c37640eb2ea3204c9b1f02aef4f Cumulative patch backporting the following two commits from upstream: commit 8bdd5b9c6bd53add260756b6673a0545fbdbba21 upstream Author: Bob Copeland <me@bobcopeland.com> Based on a patch by Elias Oltmanns, we call ath5k_init in resume even if we didn't previously open the device. Besides starting up the device unnecessarily, this also causes an oops on rmmod because mac80211 will not invoke ath5k_stop and softirqs are left running after the module has been unloaded. Add a new state bit, ATH_STAT_STARTED, to indicate that we have been started up. commit bc1b32d6bdd2d6f3fbee9a7c01c9b099f11c579c upstream Author: Elias Oltmanns <eo@nebensachen.de> After a s2ram / resume cycle, resetting the key cache does not work unless it is deferred until after the hardware has been reinitialised by a call to ath5k_hw_reset(). This fixes a regression introduced by "ath5k: fix suspend-related oops on rmmod". Reported-by: Toralf Förster <toralf.foerster@gmx.de> Signed-off-by: Elias Oltmanns <eo@nebensachen.de> Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Cumulative patch backporting the following two commits from upstream:

commit 8bdd5b9c6bd53add260756b6673a0545fbdbba21 upstream
Author: Bob Copeland <me@bobcopeland.com>

Based on a patch by Elias Oltmanns, we call ath5k_init in resume even
if we didn't previously open the device.  Besides starting up the
device unnecessarily, this also causes an oops on rmmod because
mac80211 will not invoke ath5k_stop and softirqs are left running after
the module has been unloaded.  Add a new state bit, ATH_STAT_STARTED,
to indicate that we have been started up.

commit bc1b32d6bdd2d6f3fbee9a7c01c9b099f11c579c upstream
Author: Elias Oltmanns <eo@nebensachen.de>

After a s2ram / resume cycle, resetting the key cache does not work
unless it is deferred until after the hardware has been reinitialised by
a call to ath5k_hw_reset(). This fixes a regression introduced by
"ath5k: fix suspend-related oops on rmmod".

Reported-by: Toralf Förster <toralf.foerster@gmx.de>
Signed-off-by: Elias Oltmanns <eo@nebensachen.de>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
iwlagn: avoid sleep in softirq context 2008-11-20T22:54:42+00:00 John W. Linville linville@tuxdriver.com 2008-10-30T18:12:21+00:00 c72a32e1819c184c16008ab772d414fd2107575b commit 964d2777438bf7687324243d38ade538d9bbfe3c upstream. __ieee80211_tasklet_handler -> __ieee80211_rx -> __ieee80211_rx_handle_packet -> ieee80211_invoke_rx_handlers -> ieee80211_rx_h_decrypt -> ieee80211_crypto_tkip_decrypt -> ieee80211_tkip_decrypt_data -> iwl4965_mac_update_tkip_key -> iwl_scan_cancel_timeout -> msleep Ooops! Avoid the sleep by changing iwl_scan_cancel_timeout with iwl_scan_cancel and simply returning on failure if the scan persists. This will cause hardware decryption to fail and we'll handle a few more frames with software decryption. Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: Holger Macht <hmacht@novell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 964d2777438bf7687324243d38ade538d9bbfe3c upstream.

__ieee80211_tasklet_handler -> __ieee80211_rx ->
	__ieee80211_rx_handle_packet -> ieee80211_invoke_rx_handlers ->
	ieee80211_rx_h_decrypt -> ieee80211_crypto_tkip_decrypt ->
	ieee80211_tkip_decrypt_data -> iwl4965_mac_update_tkip_key ->
	iwl_scan_cancel_timeout -> msleep

Ooops!

Avoid the sleep by changing iwl_scan_cancel_timeout with
iwl_scan_cancel and simply returning on failure if the scan persists.
This will cause hardware decryption to fail and we'll handle a few more
frames with software decryption.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Holger Macht <hmacht@novell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>