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

e1000e: fix pci-device enable-counter balance

2013-03-14T18:29:50+00:00

commit 4e0855dff094b0d56d6b5b271e0ce7851cc1e063 upstream.

This patch removes redundant and unbalanced pci_disable_device() from
__e1000_shutdown(). pci_clear_master() is enough, device can go into
suspended state with elevated enable_cnt.

Bug was introduced in commit 23606cf5d1192c2b17912cb2ef6e62f9b11de133
("e1000e / PCI / PM: Add basic runtime PM support (rev. 4)") in v2.6.35

Signed-off-by: Konstantin Khlebnikov 
Cc: Bruce Allan 
Acked-by: Rafael J. Wysocki 
Tested-by: Borislav Petkov 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

ath9k_hw: improve reset reliability after errors

2013-03-14T18:29:43+00:00

commit 3412f2f086ea7531378fabe756bd4a1109994ae6 upstream.

On many different chips, important aspects of the MAC state are not
fully cleared by a warm reset. This can show up as tx/rx hangs, those
annoying "DMA failed to stop in 10 ms..." messages or other quirks.

On AR933x, the chip can occasionally get stuck in a way that only a
driver unload/reload or a reboot would bring it back to life.

With this patch, a full reset is issued when bringing the chip out of
FULL-SLEEP state (after idle), or if either Rx or Tx was not shut down
properly. This makes the DMA related error messages disappear completely
in my tests on AR933x, and the chip does not get stuck anymore.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k: fix RSSI dummy marker value

2013-03-14T18:29:43+00:00

commit a3d63cadbad97671d740a9698acc2c95d1ca6e79 upstream.

RSSI is being stored internally as s8 in several places. The indication
of an unset RSSI value, ATH_RSSI_DUMMY_MARKER, was supposed to have been
set to 127, but ended up being set to 0x127 because of a code cleanup
mistake. This could lead to invalid signal strength values in a few
places.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mwifiex: correct sleep delay counter

2013-03-14T18:29:43+00:00

commit 3e7a4ff7c5b6423ddb644df9c41b8b6d2fb79d30 upstream.

Maximum delay for waking up card is 50 ms. Because of typo in
counter, this delay goes to 500ms. This patch fixes the bug.

Signed-off-by: Avinash Patil 
Signed-off-by: Amitkumar Karwar 
Signed-off-by: Yogesh Ashok Powar 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k_hw: fix calibration issues on chainmask that don't include chain 0

2013-03-03T22:06:43+00:00

commit 4a8f199508d79ff8a7d1e22f47b912baaf225336 upstream.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: CAI Qian 
Reviewed-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

xen-netback: cancel the credit timer when taking the vif down

2013-02-28T14:59:06+00:00

[ Upstream commit 3e55f8b306cf305832a4ac78aa82e1b40e818ece ]

If the credit timer is left armed after calling
xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
the vif which will then oops as vif->netbk == NULL.

This may happen both in the fatal error path and during normal
disconnection from the front end.

The sequencing during shutdown is critical to ensure that: a)
vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
is not freed.

1. Mark as unschedulable (netif_carrier_off()).
2. Synchronously cancel the timer.
3. Remove the vif from the schedule list.
4. Remove it from it netback thread group.
5. Wait for vif->refcnt to become 0.

Signed-off-by: David Vrabel 
Acked-by: Ian Campbell 
Reported-by: Christopher S. Aker 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

xen-netback: correctly return errors from netbk_count_requests()

2013-02-28T14:59:06+00:00

[ Upstream commit 35876b5ffc154c357476b2c3bdab10feaf4bd8f0 ]

netbk_count_requests() could detect an error, call
netbk_fatal_tx_error() but return 0.  The vif may then be used
afterwards (e.g., in a call to netbk_tx_error().

Since netbk_fatal_tx_error() could set vif->refcnt to 1, the vif may
be freed immediately after the call to netbk_fatal_tx_error() (e.g.,
if the vif is also removed).

Netback thread              Xenwatch thread
-------------------------------------------
netbk_fatal_tx_err()        netback_remove()
                              xenvif_disconnect()
                                ...
                                free_netdev()
netbk_tx_err() Oops!

Signed-off-by: Wei Liu 
Signed-off-by: Jan Beulich 
Signed-off-by: David Vrabel 
Reported-by: Christopher S. Aker 
Acked-by: Ian Campbell 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

p54usb: corrected USB ID for T-Com Sinus 154 data II

2013-02-28T14:59:02+00:00

commit 008e33f733ca51acb2dd9d88ea878693b04d1d2a upstream.

Corrected USB ID for T-Com Sinus 154 data II. ISL3887-based. The
device was tested in managed mode with no security, WEP 128
bit and WPA-PSK (TKIP) with firmware 2.13.1.0.lm87.arm (md5sum:
7d676323ac60d6e1a3b6d61e8c528248). It works.

Signed-off-by: Tomasz Guszkowski 
Acked-By: Christian Lamparter 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: usb: allocate URB control message setup_packet and data buffer separately

2013-02-28T14:59:00+00:00

commit bc6b89237acb3dee6af6e64e51a18255fef89cc2 upstream.

rtlwifi allocates both setup_packet and data buffer of control message urb,
using shared kmalloc in _usbctrl_vendorreq_async_write. Structure used for
allocating is:
	struct {
		u8 data[254];
		struct usb_ctrlrequest dr;
	};

Because 'struct usb_ctrlrequest' is __packed, setup packet is unaligned and
DMA mapping of both 'data' and 'dr' confuses ARM/sunxi, leading to memory
corruptions and freezes.

Patch changes setup packet to be allocated separately.

[v2]:
 - Use WARN_ON_ONCE instead of WARN_ON

Signed-off-by: Jussi Kivilinna 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: rtl8192cu: Add new USB ID

2013-02-28T14:59:00+00:00

commit 8708aac79e4572ba673d7a21e94ddca9f3abb7fc upstream.

A new model of the RTL8188CUS has appeared.

Reported-and-tested-by: Thomas Rosenkrantz 
Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman