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

usbnet: smsc95xx: fix suspend failure

2013-03-14T18:26:35+00:00

commit 7643721471117d5f62ca36f328d3dc8d84af4402 upstream.

The three below functions:

	smsc95xx_enter_suspend0()
	smsc95xx_enter_suspend1()
	smsc95xx_enter_suspend2()

return > 0 in case of success, so they will cause smsc95xx_suspend()
to return > 0 and cause suspend failure.

The bug is introduced in commit 3b9f7d(smsc95xx: fix error handling
in suspend failure case).

Signed-off-by: Ming Lei 
Cc: Steve Glendinning 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tg3: Update link_up flag for phylib devices

2013-03-14T18:26:25+00:00

commit 84421b99cedc3443e76d2a594f3c815d5cb9a8e1 upstream.

Commit f4a46d1f46a8fece34edd2023e054072b02e110d introduced a bug where
the ifconfig stats would remain 0 for phylib devices. This is due to
tp->link_up flag never becoming true causing tg3_periodic_fetch_stats()
to return.

The link_up flag was being updated in tg3_test_and_report_link_chg()
after setting up the phy. This function however, is not called for
phylib devices since the driver does not do the phy setup.

This patch moves the link_up flag update into the common
tg3_link_report() function that gets called for phylib devices as well
for non phylib devices when the link state changes.

To avoid updating link_up twice, we replace tg3_carrier_...() calls that
are followed by tg3_link_report(), with netif_carrier_...(). We can then
remove the unused tg3_carrier_on() function.

Reported-by: OGAWA Hirofumi 
Signed-off-by: Nithin Nayak Sujir 
Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

e1000e: fix pci-device enable-counter balance

2013-03-14T18:26:25+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:26:22+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_htc: fix signal strength handling issues

2013-03-14T18:26:22+00:00

commit 838f427955dcfd16858b0108ce29029da0d56a4e upstream.

The ath9k commit 2ef167557c0a26c88162ecffb017bfcc51eb7b29
(ath9k: fix signal strength reporting issues) fixed an issue where the
reported per-frame signal strength reported to mac80211 was being
overwritten with an internal average. The same issue is also present
in ath9k_htc.
In addition to preventing the driver from overwriting the value, this
commit also ensures that the internal average (which is used for ANI)
only tracks beacons of the AP that we're connected to.

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:26:21+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

libertas: fix crash for SD8688

2013-03-14T18:26:21+00:00

commit 466026989f112e0546ca39ab00a759af82dbe83a upstream.

For SD8688, FUNC_INIT command is queued before fw_ready flag is
set. This causes the following crash as lbs_thread blocks any
command if fw_ready is not set.

[  209.338953] [] (__schedule+0x610/0x764) from [] (__lbs_cmd+0xb8/0x130 [libertas])
[  209.348340] [] (__lbs_cmd+0xb8/0x130 [libertas]) from [] (if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio])
[  209.360136] [] (if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio]) from [] (if_sdio_power_on+0x18c/0x20c [libertas_sdio])
[  209.373052] [] (if_sdio_power_on+0x18c/0x20c [libertas_sdio]) from [] (if_sdio_probe+0x200/0x31c [libertas_sdio])
[  209.385316] [] (if_sdio_probe+0x200/0x31c [libertas_sdio]) from [] (sdio_bus_probe+0x94/0xfc [mmc_core])
[  209.396748] [] (sdio_bus_probe+0x94/0xfc [mmc_core]) from [] (driver_probe_device+0x12c/0x348)
[  209.407214] [] (driver_probe_device+0x12c/0x348) from [] (__driver_attach+0x78/0x9c)
[  209.416798] [] (__driver_attach+0x78/0x9c) from [] (bus_for_each_dev+0x50/0x88)
[  209.425946] [] (bus_for_each_dev+0x50/0x88) from [] (bus_add_driver+0x108/0x268)
[  209.435180] [] (bus_add_driver+0x108/0x268) from [] (driver_register+0xa4/0x134)
[  209.444426] [] (driver_register+0xa4/0x134) from [] (if_sdio_init_module+0x1c/0x3c [libertas_sdio])
[  209.455339] [] (if_sdio_init_module+0x1c/0x3c [libertas_sdio]) from [] (do_one_initcall+0x98/0x174)
[  209.466236] [] (do_one_initcall+0x98/0x174) from [] (load_module+0x1c5c/0x1f80)
[  209.475390] [] (load_module+0x1c5c/0x1f80) from [] (sys_init_module+0x104/0x128)
[  209.484632] [] (sys_init_module+0x104/0x128) from [] (ret_fast_syscall+0x0/0x38)

Fix it by setting fw_ready flag prior to queuing FUNC_INIT command.

Reported-by: Lubomir Rintel 
Tested-by: Lubomir Rintel 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mwifiex: correct sleep delay counter

2013-03-14T18:26:20+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

iwlwifi: always copy first 16 bytes of commands

2013-03-14T18:26:14+00:00

commit 8a964f44e01ad3bbc208c3e80d931ba91b9ea786 upstream.

The FH hardware will always write back to the scratch field
in commands, even host commands not just TX commands, which
can overwrite parts of the command. This is problematic if
the command is re-used (with IWL_HCMD_DFL_NOCOPY) and can
cause calibration issues.

Address this problem by always putting at least the first
16 bytes into the buffer we also use for the command header
and therefore make the DMA engine write back into this.

For commands that are smaller than 16 bytes also always map
enough memory for the DMA engine to write back to.

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

b43: Fix lockdep splat on module unload

2013-03-03T22:03:33+00:00

commit 63a02ce1c5c59baa40b99756492e3ec8d6b51483 upstream.

On unload, b43 produces a lockdep warning that can be summarized in the
following way:

 ======================================================
 [ INFO: possible circular locking dependency detected ]
 3.8.0-wl+ #117 Not tainted
 -------------------------------------------------------
 modprobe/5557 is trying to acquire lock:
  ((&wl->firmware_load)){+.+.+.}, at: [] flush_work+0x0/0x2a0

 but task is already holding lock:
  (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x20

 which lock already depends on the new lock.
 [ INFO: possible circular locking dependency detected ]
 ======================================================

The full output is available at http://lkml.indiana.edu/hypermail/linux/kernel/1302.3/00060.html.
To summarize, commit 6b6fa58 added a 'cancel_work_sync(&wl->firmware_load)'
call in the wrong place.

The fix is to move the cancel_work_sync() call to b43_bcma_remove() and
b43_ssb_remove(). Thanks to Johannes Berg and Michael Buesch for help in
diagnosing the log output.

Signed-off-by: Larry Finger 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman