linux-toradex.git/drivers/net/wireless, branch v3.2.29

USB: rtl8187: remove __devinit* from the struct usb_device_id table

2012-09-12T02:37:11+00:00

commit a3433179d0822ccfa8e80aa4d1d52843bd2dcc63 upstream.

This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.

Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.

Reported-by: Fengguang Wu 
Reported-by: Bjørn Mork 
CC: Herton Ronaldo Krzesinski 
CC: Hin-Tak Leung 
CC: Larry Finger 
CC: "John W. Linville" 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

USB: p54usb: remove __devinit* from the struct usb_device_id table

2012-09-12T02:37:10+00:00

commit b9c4167cbbafddac3462134013bc15e63e4c53ef upstream.

This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.

Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.

Reported-by: Fengguang Wu 
Reported-by: Bjørn Mork 
CC: Christian Lamparter 
CC: "John W. Linville" 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

ath9k: fix decrypt_error initialization in ath_rx_tasklet()

2012-09-12T02:37:00+00:00

commit e1352fde5682ab1bdd2a9e5d75c22d1fe210ef77 upstream.

ath_rx_tasklet() calls ath9k_rx_skb_preprocess() and ath9k_rx_skb_postprocess()
in a loop over the received frames. The decrypt_error flag is
initialized to false
just outside ath_rx_tasklet() loop. ath9k_rx_accept(), called by
ath9k_rx_skb_preprocess(),
only sets decrypt_error to true and never to false.
Then ath_rx_tasklet() calls ath9k_rx_skb_postprocess() and passes
decrypt_error to it.
So, after a decryption error, in ath9k_rx_skb_postprocess(), we can
have a leftover value
from another processed frame. In that case, the frame will not be marked with
RX_FLAG_DECRYPTED even if it is decrypted correctly.
When using CCMP encryption this issue can lead to connection stuck
because of CCMP
PN corruption and a waste of CPU time since mac80211 tries to decrypt an already
deciphered frame with ieee80211_aes_ccm_decrypt.
Fix the issue initializing decrypt_error flag at the begging of the
ath_rx_tasklet() loop.

Signed-off-by: Lorenzo Bianconi 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

iwlwifi: disable greenfield transmissions as a workaround

2012-08-19T17:15:31+00:00

commit 50e2a30cf6fcaeb2d27360ba614dd169a10041c5 upstream.

There's a bug that causes the rate scaling to get stuck
when it has to use single-stream rates with a peer that
can do GF and SGI; the two are incompatible so we can't
use them together, but that causes the algorithm to not
work at all, it always rejects updates.

Disable greenfield for now to prevent that problem.

Reviewed-by: Emmanuel Grumbach 
Tested-by: Cesar Eduardo Barros 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

rt61pci: fix NULL pointer dereference in config_lna_gain

2012-08-19T17:15:30+00:00

commit deee0214def5d8a32b8112f11d9c2b1696e9c0cb upstream.

We can not pass NULL libconf->conf->channel to rt61pci_config() as it
is dereferenced unconditionally in rt61pci_config_lna_gain() subroutine.

Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=44361

Reported-and-tested-by: 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

ath9k: Add PID/VID support for AR1111

2012-08-19T17:15:29+00:00

commit d4e5979c0da95791aa717c18e162540c7a596360 upstream.

AR1111 is same as AR9485. The h/w
difference between them is quite insignificant,
Felix suggests only very few baseband features
may not be available in AR1111. The h/w code for
AR9485 is already present, so AR1111 should
work fine with the addition of its PID/VID.

Cc: Felix Bitterli 
Reported-by: Tim Bentley 
Signed-off-by: Mohammed Shafi Shajakhan 
Tested-by: Tim Bentley 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

rtlwifi: rtl8192cu: Change buffer allocation for synchronous reads

2012-08-19T17:15:27+00:00

commit 3ce4d85b76010525adedcc2555fa164bf706a2f3 upstream.

In commit a7959c1, the USB part of rtlwifi was switched to convert
_usb_read_sync() to using a preallocated buffer rather than one
that has been acquired using kmalloc. Although this routine is named
as though it were synchronous, there seem to be simultaneous users,
and the selection of the index to the data buffer is not multi-user
safe. This situation is addressed by adding a new spinlock. The routine
cannot sleep, thus a mutex is not allowed.

Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

rt2x00: Add support for BUFFALO WLI-UC-GNM2 to rt2800usb.

2012-08-09T23:25:14+00:00

commit a769f9577232afe2c754606a83aad85127e7052a upstream.

This is a RT3070 based device.

Signed-off-by: Jeongdo Son 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

rtlwifi: rtl8192de: Fix phy-based version calculation

2012-08-02T13:37:51+00:00

commit f1b00f4dab29b57bdf1bc03ef12020b280fd2a72 upstream.

Commit d83579e2a50ac68389e6b4c58b845c702cf37516 incorporated some
changes from the vendor driver that made it newly important that the
calculated hardware version correctly include the CHIP_92D bit, as all
of the IS_92D_* macros were changed to depend on it.  However, this bit
was being unset for dual-mac, dual-phy devices.  The vendor driver
behavior was modified to not do this, but unfortunately this change was
not picked up along with the others.  This caused scanning in the 2.4GHz
band to be broken, and possibly other bugs as well.

This patch brings the version calculation logic in parity with the
vendor driver in this regard, and in doing so fixes the regression.
However, the version calculation code in general continues to be largely
incoherent and messy, and needs to be cleaned up.

Signed-off-by: Forest Bond 
Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

mwifiex: correction in mcs index check

2012-08-02T13:37:47+00:00

commit fe020120cb863ba918c6d603345342a880272c4d upstream.

mwifiex driver supports 2x2 chips as well. Hence valid mcs values
are 0 to 15. The check for mcs index is corrected in this patch.

For example: if 40MHz is enabled and mcs index is 11, "iw link"
command would show "tx bitrate: 108.0 MBit/s" without this patch.
Now it shows "tx bitrate: 108.0 MBit/s MCS 11 40Mhz" with the patch.

Signed-off-by: Amitkumar Karwar 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings