linux-stable.git/drivers/net, branch v3.7.3

Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"

2013-01-17T16:46:46+00:00

commit ab9d6e4ffe192427ce9e93d4f927b0faaa8a941e upstream.

This revert:

commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f
Author: Andreas Hartmann 
Date:   Tue Apr 17 00:25:28 2012 +0200

    rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails

To fix problem workaround by above commit use
IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL flag (see change log for
"mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL" patch).

Resolve: https://bugzilla.kernel.org/show_bug.cgi?id=42828
Bisected-by: Francisco Pina Martins 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

b43: Fix firmware loading when driver is built into the kernel

2013-01-17T16:46:37+00:00

commit 5e20a4b53094651d80f856ff55a916b999dbb57a upstream.

Recent versions of udev cause synchronous firmware loading from the
probe routine to fail because the request to user space would time
out. The original fix for b43 (commit 6b6fa58) moved the firmware
load from the probe routine to a work queue, but it still used synchronous
firmware loading. This method is OK when b43 is built as a module;
however, it fails when the driver is compiled into the kernel.

This version changes the code to load the initial firmware file
using request_firmware_nowait(). A completion event is used to
hold the work queue until that file is available. This driver
reads several firmware files - the remainder can be read synchronously.
On some test systems, the async read fails; however, a following synch
read works, thus the async failure falls through to the sync try.

Reported-and-Tested by: Felix Janda 
Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mwifiex: check wait_event_interruptible return value

2013-01-17T16:46:36+00:00

commit 9c969d8ccb1e17bd20742f4ac9f00c1a64487234 upstream.

wait_event_interruptible function returns -ERESTARTSYS if it's
interrupted by a signal. Driver should check the return value
and handle this case properly.

In mwifiex_wait_queue_complete() routine, as we are now checking
wait_event_interruptible return value, the condition check is not
required. Also, we have removed mwifiex_cancel_pending_ioctl()
call to avoid a chance of sending second command to FW by other path
as soon as we clear current command node. FW can not handle two
commands simultaneously.

Signed-off-by: Bing Zhao 
Signed-off-by: Amitkumar Karwar 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: fix the reclaimed packet tracking upon flush queue

2013-01-17T16:46:36+00:00

commit f590dcec944552f9a4a61155810f3abd17d6465d upstream.

There's a bug in the currently released firmware version,
the sequence control in the Tx response isn't updated in
all cases. Take it from the packet as a workaround.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: fix PCIe interrupt handle return value

2013-01-17T16:46:36+00:00

commit 392d4cad7907f6cb4ffc85e135a01abfddc89027 upstream.

By accident, commit eb6476441bc2fecf6232a87d0313a85f8e3da7f4
("iwlwifi: protect use_ict with irq_lock") changed the return
value of the iwl_pcie_isr() function in case it handles an
interrupt -- it now returns IRQ_NONE instead of IRQ_HANDLED.

Put back the correct return value.

Reviewed-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: fix parsing rsn ie for ap mode.

2013-01-17T16:46:22+00:00

commit 619c5a9ad54e6bbdafd16d1cdc6c049403710540 upstream.

RSN IEs got incorrectly parsed and therefore ap mode using WPA2
security was not working.

Reviewed-by: Arend Van Spriel 
Reviewed-by: Pieter-Paul Giesberts 
Signed-off-by: Hante Meuleman 
Signed-off-by: Arend van Spriel 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

xen/netfront: improve truesize tracking

2013-01-17T16:46:22+00:00

commit d9a58a782e396a0f04e8445b7ba3763c8a48c7fe upstream.

Using RX_COPY_THRESHOLD is incorrect if the SKB is actually smaller
than that. We have already accounted for this in
NETFRONT_SKB_CB(skb)->pull_to so use that instead.

Fixes WARN_ON from skb_try_coalesce.

Signed-off-by: Ian Campbell 
Cc: Sander Eikelenboom 
Cc: Konrad Rzeszutek Wilk 
Cc: annie li 
Cc: xen-devel@lists.xen.org
Cc: netdev@vger.kernel.org
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

i2400m: add Intel 6150 device IDs

2013-01-17T16:46:09+00:00

commit 999a7c5776a0ed2133645fa7e008bec05bda9254 upstream.

Add device IDs for WiMAX function of Intel 6150 cards.

Signed-off-by: Dan Williams 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

mlx4_core: Fix potential deadlock in mlx4_eq_int()

2013-01-17T16:45:58+00:00

commit 311f813a2daefcba03f706a692fe0c67888d7622 upstream.

The slave_state_lock spinlock is used in both interrupt context and
process context, hence irq locking must be used.  Found by lockdep.

Signed-off-by: Jack Morgenstein 
Signed-off-by: Or Gerlitz 
Signed-off-by: Roland Dreier 
Signed-off-by: Greg Kroah-Hartman

carl9170: fix -EINVAL bailout during init with !CONFIG_MAC80211_MESH

2013-01-17T16:45:55+00:00

commit 6c653f66772c39c5e25db715bbd4730596fccd9e upstream.

Sean reported that as of 3.7, his AR9170 device no longer works
because the driver fails during initialization. He noted this
is due to:
"In carl9170/fw.c, ar->hw->wiphy is tagged with
NL80211_IFTYPE_MESH_POINT support if the firmware has Content
after Beacon Queuing. This is both in interface_modes and the
only iface_combinations entry.

If CONFIG_MAC80211_MESH is not set, ieee80211_register_hw
removes NL80211_IFTYPE_MESH_POINT from interface_modes, but
not iface_combinations.

wiphy_register then checks to see if every interface type in
every interface combination is in interface_modes.
NL80211_IFTYPE_MESH_POINT was removed, so you get a WARN_ON
warning and it returns -EINVAL, giving up."

Unfortunately, the iface_combination (types) feature bitmap
in ieee80211_iface_limit is part of a const member in the
ieee80211_iface_combination struct. Hence, the MESH_POINT
feature flag can't be masked by wiphy_register in the
same way as interface_modes in ieee80211_register_hw.

Reported-by: Sean Patrick Santos 
Signed-off-by: Christian Lamparter 
Tested-by: Sean Patrick Santos 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman