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

rtl8187: New USB ID's for RTL8187L

2009-03-17T00:32:05+00:00

commit 046ee5d26ac91316a8ac0a29c0b33139dc9da20d upstream.

Add new USB ID codes. These come from two postings on forums and
mailing lists, and four are derived from the .inf that accompanies
the latest Realtek Windows driver for the RTL8187L.

Thanks to Viktor Ilijašić  and Xose Vazquez
Perez  for reporting these new ID's.

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

zd1211rw: treat MAXIM_NEW_RF(0x08) as UW2453_RF(0x09) for TP-Link WN322/422G

2009-02-17T17:28:46+00:00

commit efb43f4b2ccf8066abc3920a0e6858e4350a65c7 upstream.

Three people (Petr Mensik 
["si" should be U+0161 U+00ED], Stephen Ho 
on zd1211-devs and Ismael Ojeda Perez 
on linux-wireless) reported success in getting TP-Link WN322G/WN422G
working by treating MAXIM_NEW_RF(0x08) as UW2453_RF(0x09) for rf
chip hardware initialization.

Signed-off-by: Hin-Tak Leung 
Tested-by: Petr Mensik 
Tested-by: Stephen Ho 
Tested-by: Ismael Ojeda Perez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

zd1211rw: adding 0ace:0xa211 as a ZD1211 device

2009-02-17T17:28:46+00:00

commit 14990c69b5f51dd57b4e0e2373de50239ac861e2 upstream.

Christoph Biedl  reported success
in the sourceforge zd1211 mailing list on this addition. This product ID
was supported by the vendor driver ZD1211LnxDrv 2.22.0.0 (and possibly
earlier) and it probably should have been added earlier.

Signed-off-by: Hin-Tak Leung 
Tested-by: Christoph Biedl 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ipw2200: fix scanning while associated

2009-02-12T17:50:36+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

p54usb: rewriting rx/tx routines to make use of usb_anchor's facilities

2009-02-06T21:47:22+00:00

commit dd397dc9dddfa2149a1bbc9e52ac7d5630737cec upstream

Alan Stern found several flaws in p54usb's implementation and annotated:
"usb_kill_urb() and similar routines do not expect an URB's completion
routine to deallocate it.  This is almost obvious -- if the URB is deallocated
before the completion routine returns then there's no way for usb_kill_urb
to detect when the URB actually is complete."

This patch addresses all known limitations in the old implementation and fixes
khub's "use-after-freed" hang, when SLUB debug's poisoning option is enabled.

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

p54: fix p54_read_eeprom to cope with tx_hdr_len

2009-02-06T21:47:20+00:00

commit b92f30d65aeb0502e2ed8beb80c8465578b40002 upstream

This patch fixes a regression in "p54: move eeprom code into common library"
7cb770729ba895f73253dfcd46c3fcba45d896f9

Some of p54usb's devices need a little headroom for the transportation and
this was forgotten in the eeprom change.

Signed-off-by: Christian Lamparter 
Signed-off-by: Greg Kroah-Hartman

p54: fix lm87 checksum endianness

2009-02-06T21:47:20+00:00

commit c91276592695e13d1b52eab572551017cbf96ee7 upstream

This fixes the checksum calculation for lm87 firmwares
on big endian platforms, the device treats the data as
an array of 32-bit little endian values so the driver
needs to do that as well.

Signed-off-by: Johannes Berg 
Acked-by: Christian Lamparter 
Signed-off-by: John W. Linville

iwlwifi: fix rs_get_rate WARN_ON()

2009-02-06T21:47:20+00:00

commit c338ba3ca5bef2df2082d9e8d336ff7b2880c326 upstream.

In ieee80211_sta structure there is u64 supp_rates[IEEE80211_NUM_BANDS]
this is filled with all support rate from assoc_resp.  If we associate
with G-band AP only supp_rates of G-band will be set the other band
supp_rates will be set to 0. If the user type this command
this will cause mac80211 to set to new channel, mac80211
does not disassociate in setting new channel, so the active
band is now A-band. then in handling the new essid mac80211 will
kick in the assoc steps which involve sending disassociation frame.
in this mac80211 will WARN_ON sta->supp_rates[A_BAND] == 0.

This fixes:
http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1822
http://www.kerneloops.org/searchweek.php?search=rs_get_rate

Signed-off-by: mohamed abbas 
Signed-off-by: Reinette Chatre 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

orinoco: move kmalloc(..., GFP_KERNEL) outside spinlock in orinoco_ioctl_set_genie

2009-02-06T21:47:18+00:00

commit 7fe99c4e28ab54eada8aa456b417114e6ef21587 upstream

orinoco: move kmalloc(..., GFP_KERNEL) outside spinlock in orinoco_ioctl_set_genie

[   56.923623] BUG: sleeping function called from invalid context at /home/bor/src/linux-git/mm/slub.c:1599
[   56.923644] in_atomic(): 0, irqs_disabled(): 1, pid: 3031, name: wpa_supplicant
[   56.923656] 2 locks held by wpa_supplicant/3031:
[   56.923662]  #0:  (rtnl_mutex){--..}, at: [] rtnl_lock+0xf/0x20
[   56.923703]  #1:  (&priv->lock){++..}, at: [] orinoco_ioctl_set_genie+0x52/0x130 [orinoco]
[   56.923782] irq event stamp: 910
[   56.923788] hardirqs last  enabled at (909): [] __kmalloc+0x7b/0x140
[   56.923820] hardirqs last disabled at (910): [] _spin_lock_irqsave+0x19/0x80
[   56.923847] softirqs last  enabled at (880): [] __do_softirq+0xc4/0x110
[   56.923865] softirqs last disabled at (871): [] do_softirq+0x8e/0xe0
[   56.923895] Pid: 3031, comm: wpa_supplicant Not tainted 2.6.29-rc2-1avb #1
[   56.923905] Call Trace:
[   56.923919]  [] ? do_softirq+0x8e/0xe0
[   56.923941]  [] __might_sleep+0xd2/0x100
[   56.923952]  [] __kmalloc+0xd7/0x140
[   56.923963]  [] ? _spin_lock_irqsave+0x6a/0x80
[   56.923981]  [] ? orinoco_ioctl_set_genie+0x79/0x130 [orinoco]
[   56.923999]  [] ? orinoco_ioctl_set_genie+0x52/0x130 [orinoco]
[   56.924017]  [] orinoco_ioctl_set_genie+0x79/0x130 [orinoco]
[   56.924036]  [] ? copy_from_user+0x35/0x130
[   56.924061]  [] ioctl_standard_call+0x196/0x380
[   56.924085]  [] ? __dev_get_by_name+0x85/0xb0
[   56.924096]  [] wext_handle_ioctl+0x14f/0x230
[   56.924113]  [] ? orinoco_ioctl_set_genie+0x0/0x130 [orinoco]
[   56.924132]  [] dev_ioctl+0x495/0x570
[   56.924155]  [] ? sys_sendto+0xa5/0xd0
[   56.924171]  [] ? mark_held_locks+0x48/0x90
[   56.924183]  [] ? sock_ioctl+0x0/0x280
[   56.924193]  [] sock_ioctl+0xfd/0x280
[   56.924203]  [] ? sock_ioctl+0x0/0x280
[   56.924235]  [] vfs_ioctl+0x20/0x80
[   56.924246]  [] do_vfs_ioctl+0x72/0x570
[   56.924257]  [] ? sys_send+0x32/0x40
[   56.924268]  [] ? sys_socketcall+0x1d0/0x2a0
[   56.924280]  [] ? sysenter_exit+0xf/0x16
[   56.924292]  [] sys_ioctl+0x39/0x70
[   56.924302]  [] sysenter_do_call+0x12/0x31

Signed-off-by: Andrey Borzenkov 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtl8187: Fix error in setting OFDM power settings for RTL8187L

2009-02-02T17:53:25+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