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

igb: Fix lack of flush after register write and before delay

2011-08-29T20:29:16+00:00

commit 064b43304ed8ede8e13ff7b4338d09fd37bcffb1 upstream.

Register writes followed by a delay are required to have a flush
before the delay in order to commit the values to the register.  Without
the flush, the code following the delay may not function correctly.

Reported-by: Tong Ho 
Reported-by: Guenter Roeck 
Signed-off-by: Carolyn Wyborny 
Tested-by:  Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

rt2x00: fix order of entry flags modification

2011-08-29T20:29:16+00:00

commit df71c9cfceea801e7e26e2c74241758ef9c042e5 upstream.

In rt2800usb_work_txdone we check flags in order:

- ENTRY_OWNER_DEVICE_DATA
- ENTRY_DATA_STATUS_PENDING
- ENTRY_DATA_IO_FAILED

Modify flags in separate order in rt2x00usb_interrupt_txdone, to avoid
processing entries in _txdone with wrong flags or skip processing
ready entries.

Reported-by: Justin Piszcz 
Signed-off-by: Stanislaw Gruszka 
Acked-by: Ivo van Doorn 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath5k: fix error handling in ath5k_beacon_send

2011-08-17T17:55:53+00:00

commit bdc71bc59231f5542af13b5061b9ab124d093050 upstream.

This cleans up error handling for the beacon in case of dma mapping
failure.  We need to free the skb when dma mapping fails instead of
nulling and leaking the pointer, and we should bail out to avoid
giving the hardware the bad descriptor.

Finally, we need to perform the null check after trying to update
the beacon, or else beacons will never be sent after a single
mapping failure.

Signed-off-by: Bob Copeland 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k: fix a misprint which leads to incorrect calibration

2011-08-16T01:31:43+00:00

commit 118c9db51e7acaf8f16deae8311cce6588b83e31 upstream.

This patch addresses an issue with incorrect HW register
AR_PHY_TX_IQCAL_CORR_COEFF_B1 definition which leads to incorrect clibration.

Signed-off-by: Alex Hacker 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k_hw: Fix incorrect Tx control power in AR9003 template

2011-08-16T01:31:43+00:00

commit 15052f81d255eac44e745bc630b36aa86779ad9d upstream.

CTL power data incorrect in ctlPowerData_2G field of ar9300_eeprom.
Setting incorrect CTL power in calibration is causing lower tx power.
Tx power was reported as 3dBm while operating in channel 6 HT40+/
in channel 11 HT40- due to CTL powers in the calibration is set to
zero.

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

dp83640: increase receive time stamp buffer size

2011-08-16T01:31:42+00:00

commit 8028837d71ba9904b17281b40f94b93e947fbe38 upstream.

The dp83640 buffers receive time stamps from special PHY status frames,
matching them to received PTP packets in a work queue. Because the timeout
for orphaned time stamps is so long and the buffer is so small, the driver
can drop time stamps under moderate PTP traffic.

This commit fixes the issue by decreasing the timeout to (at least) one
timer tick and increasing the buffer size.

Signed-off-by: Richard Cochran 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

gianfar: fix fiper alignment after resetting the time

2011-08-16T01:31:42+00:00

commit cbc056602c7c63620c86904c431ff6b61e029dcc upstream.

After resetting the time, the PPS signals on the FIPER output channels
are incorrectly offset from the clock time, as can be readily verified
by a looping back the FIPER to the external time stamp input.

Despite its name, setting the "Fiper Realignment Disable" bit seems to
fix the problem, at least on the P2020.

Also, following the example code from the Freescale BSP, it is not really
necessary to disable and re-enable the timer in order to reprogram the
FIPER. (The documentation is rather unclear on this point. It seems that
writing to the alarm register also disables the FIPER.)

Signed-off-by: Richard Cochran 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

e1000e: alternate MAC address does not work on device id 0x1060

2011-08-16T01:31:42+00:00

commit c407bee8a56d874b91f3e4ee790660959ff1a25e upstream.

This issue is present all the way back to 2.6.34 kernels.

Signed-off-by: Bruce Allan 
Tested-by: Jeffrey Pieper 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

iwlagn: 5000 do not support idle mode

2011-08-16T01:31:39+00:00

commit f35291082294ca6737953bbe4e9491ede04ab822 upstream.

5000 series has issue supporting power save idle mode:
commit	9dc2153315650eae220898668b6aa56a25c130be

iwlwifi: always support idle mode for agn devices

For agn devices, always support idle mode which help power
consumption in idle unassociated state.

the above changes cause 5000 become not stable when power management is "on"

http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2312

Reported-by: Devin J. Pohly 
Signed-off-by: Wey-Yi Guy 
Signed-off-by: John W. Linville 
Signed-off-by: Devin J. Pohly 
Signed-off-by: Greg Kroah-Hartman

r8169: Add support for D-Link 530T rev C1 (Kernel Bug 38862)

2011-08-16T01:31:39+00:00

[ Upstream commit 93a3aa25933461d76141179fc94aa32d5f9d954a ]

The D-Link DGE-530T rev C1 is a re-badged Realtek 8169 named DLG10028C,
unlike the previous revisions which were skge based.  It is probably
the same as the discontinued DGE-528T (0x4300) other than the PCI ID.

The PCI ID is 0x1186:0x4302.

Adding it to r8169.c where 0x1186:0x4300 is already found makes the card
be detected and work.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=38862

Signed-off-by: Len Sorensen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman