linux-stable.git/drivers/net, branch linux-2.6.38.y

p54usb: add zoom 4410 usbid

2011-06-03T01:34:30+00:00

commit 9368a9a2378ab721f82f59430a135b4ce4ff5109 upstream.

Reported-by: Mark Davis 
Signed-off-by: Christian Lamparter 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

bonding: prevent deadlock on slave store with alb mode (v3)

2011-06-03T01:34:02+00:00

[ Upstream commit 9fe0617d9b6d21f700ee9e658e1c9fe3be2fb402 ]

This soft lockup was recently reported:

[root@dell-per715-01 ~]# echo +bond5 > /sys/class/net/bonding_masters
[root@dell-per715-01 ~]# echo +eth1 > /sys/class/net/bond5/bonding/slaves
bonding: bond5: doing slave updates when interface is down.
bonding bond5: master_dev is not up in bond_enslave
[root@dell-per715-01 ~]# echo -eth1 > /sys/class/net/bond5/bonding/slaves
bonding: bond5: doing slave updates when interface is down.

BUG: soft lockup - CPU#12 stuck for 60s! [bash:6444]
CPU 12:
Modules linked in: bonding autofs4 hidp rfcomm l2cap bluetooth lockd sunrpc
be2d
Pid: 6444, comm: bash Not tainted 2.6.18-262.el5 #1
RIP: 0010:[]  []
.text.lock.spinlock+0x26/00
RSP: 0018:ffff810113167da8  EFLAGS: 00000286
RAX: ffff810113167fd8 RBX: ffff810123a47800 RCX: 0000000000ff1025
RDX: 0000000000000000 RSI: ffff810123a47800 RDI: ffff81021b57f6f8
RBP: ffff81021b57f500 R08: 0000000000000000 R09: 000000000000000c
R10: 00000000ffffffff R11: ffff81011d41c000 R12: ffff81021b57f000
R13: 0000000000000000 R14: 0000000000000282 R15: 0000000000000282
FS:  00002b3b41ef3f50(0000) GS:ffff810123b27940(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00002b3b456dd000 CR3: 000000031fc60000 CR4: 00000000000006e0

Call Trace:
 [] _spin_lock_bh+0x9/0x14
 [] :bonding:tlb_clear_slave+0x22/0xa1
 [] :bonding:bond_alb_deinit_slave+0xba/0xf0
 [] :bonding:bond_release+0x1b4/0x450
 [] __down_write_nested+0x12/0x92
 [] :bonding:bonding_store_slaves+0x25c/0x2f7
 [] sysfs_write_file+0xb9/0xe8
 [] vfs_write+0xce/0x174
 [] sys_write+0x45/0x6e
 [] tracesys+0xd5/0xe0

It occurs because we are able to change the slave configuarion of a bond while
the bond interface is down.  The bonding driver initializes some data structures
only after its ndo_open routine is called.  Among them is the initalization of
the alb tx and rx hash locks.  So if we add or remove a slave without first
opening the bond master device, we run the risk of trying to lock/unlock a
spinlock that has garbage for data in it, which results in our above softlock.

Note that sometimes this works, because in many cases an unlocked spinlock has
the raw_lock parameter initialized to zero (meaning that the kzalloc of the
net_device private data is equivalent to calling spin_lock_init), but thats not
true in all cases, and we aren't guaranteed that condition, so we need to pass
the relevant spinlocks through the spin_lock_init function.

Fix it by moving the spin_lock_init calls for the tx and rx hashtable locks to
the ndo_init path, so they are ready for use by the bond_store_slaves path.

Change notes:
v2) Based on conversation with Jay and Nicolas it seems that the ability to
enslave devices while the bond master is down should be safe to do.  As such
this is an outlier bug, and so instead we'll just initalize the errant spinlocks
in the init path rather than the open path, solving the problem.  We'll also
remove the warnings about the bond being down during enslave operations, since
it should be safe

v3) Fix spelling error

Signed-off-by: Neil Horman 
Reported-by: jtluka@redhat.com
CC: Jay Vosburgh 
CC: Andy Gospodarek 
CC: nicolas.2p.debian@gmail.com
CC: "David S. Miller" 
Signed-off-by: Jay Vosburgh 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvlan: fix panic if lowerdev in a bond

2011-06-03T01:33:56+00:00

[ Upstream commit d93515611bbc70c2fe4db232e5feb448ed8e4cc9 ]

commit a35e2c1b6d905 (macvlan: use rx_handler_data pointer to store
macvlan_port pointer V2) added a bug in macvlan_port_create()

Steps to reproduce the bug:

# ifenslave bond0 eth0 eth1

# ip link add link eth0 up name eth0#1 type macvlan
->error EBUSY

# ip link add link eth0 up name eth0#1 type macvlan
->panic

Fix: Dont set IFF_MACVLAN_PORT in error case.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bonding: 802.3ad - fix agg_device_up

2011-06-03T01:33:53+00:00

[ Upstream commit 2430af8b7fa37ac0be102c77f9dc6ee669d24ba9 ]

The slave member of struct aggregator does not necessarily point
to a slave which is part of the aggregator. It points to the
slave structure containing the aggregator structure, while
completely different slaves (or no slaves at all) may be part of
the aggregator.

The agg_device_up() function wrongly uses agg->slave to find the state
of the aggregator.  Use agg->lag_ports->slave instead. The bug has
been introduced by commit 4cd6fe1c6483cde93e2ec91f58b7af9c9eea51ad
("bonding: fix link down handling in 802.3ad mode").

Signed-off-by: Jiri Bohac 
Signed-off-by: Jay Vosburgh 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: fix bugs in change_interface

2011-06-03T01:33:48+00:00

commit a2b76b3b31568da9d281a393845f17689594ccdf upstream.

If change_interface gets invoked during a firmware
restart, it may crash; prevent that from happening
by checking if ctx->vif is assigned.

Additionally, in my initial commit I forgot to set
the vif->p2p variable correctly, so fix that too.

Signed-off-by: Johannes Berg 
Signed-off-by: Wey-Yi Guy 
Signed-off-by: Greg Kroah-Hartman

iwlagn: fix iwl_is_any_associated

2011-06-03T01:33:41+00:00

commit 054ec924944912413e4ee927b8cf02f476d08783 upstream.

The function iwl_is_any_associated() was intended
to check both contexts, but due to an oversight
it only checks the BSS context. This leads to a
problem with scanning since the passive dwell
time isn't restricted appropriately and a scan
that includes passive channels will never finish
if only the PAN context is associated since the
default dwell time of 120ms won't fit into the
normal 100 TU DTIM interval.

Fix the function by using for_each_context() and
also reorganise the other functions a bit to take
advantage of each other making the code easier to
read.

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

ath9k_hw: Fix STA connection issues with AR9380 (XB113).

2011-06-03T01:33:39+00:00

commit be0e6aa5a0c487a2a0880dda8bc70f7f1860fc39 upstream.

XB113 (AR9380) 3x3 SB 5G only cards were failing to connect to APs
due to incorrect xpabiaslevel configuration. fix it.

Cc: Ray Li 
Cc: Kathy Giori 
Cc: Aeolus Yang 
Cc: compat@orbit-lab.org
Signed-off-by: Senthil Balasubramanian 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k_hw: fix dual band assumption for XB113

2011-06-03T01:33:39+00:00

commit 9ba7f4f5eba5f4b44c7796bbad29f8ec3a7d5864 upstream.

The XB113 cards are single band, 5 GHz-only, but the
default settings were configured to assume it was dual
band. Users of these cards then would see 2.4 GHz channels
but you would never get any scan results from these channels
given that the radio is not present.

Cc: Fiona Cain 
Cc: Ray Li 
Cc: Kathy Giori 
Cc: Aeolus Yang 
Cc: Dan Friedman 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k_hw: fix power for the HT40 duplicate frames

2011-06-03T01:33:38+00:00

commit cf3a03b9c99a0b2715741d116f50f513f545bb2d upstream.

With AR9003 at about ~ 10 feet from an AP that uses RTS / CTS you
will be able to associate but not not get data through given that
the power for the rates used was set too low. This increases the
power and permits data connectivity at longer distances from
access points when connected with HT40. Without this you will not
get any data through when associated to APs configured in HT40
at about more than 10 feet away.

Cc: Fiona Cain 
Cc: Zhen Xie 
Cc: Kathy Giori 
Cc: Neha Choksi 
Cc: Wayne Daniel 
Cc: Gaurav Jauhar 
Cc: Samira Naraghi 
CC: Ashok Chennupati 
Cc: Lance Zimmerman 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k_hw: do noise floor calibration only on required chains

2011-06-03T01:33:38+00:00

commit 28ef6450f0182f95c4f50aaa0ab2043a09c72b0a upstream.

At present the noise floor calibration is processed in supported
control and extension chains rather than required chains.
Unnccesarily doing nfcal in all supported chains leads to
invalid nf readings on extn chains and these invalid values
got updated into history buffer. While loading those values
from history buffer is moving the chip to deaf state.

This issue was observed in AR9002/AR9003 chips while doing
associate/dissociate in HT40 mode and interface up/down
in iterative manner. After some iterations, the chip was moved
to deaf state. Somehow the pci devices are recovered by poll work
after chip reset. Raading the nf values in all supported extension chains
when the hw is not yet configured in HT40 mode results invalid values.

Signed-off-by: Rajkumar Manoharan 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman