linux-toradex.git/drivers/net, branch v2.6.36.4

net/fec: fix MMFR_OP type in fec_enet_mdio_write

2011-02-17T22:47:28+00:00

commit 862f0982eadcea0e114576c57ea426d3d51a69a6 upstream.

FEC_MMFR_OP_WRITE should be used than FEC_MMFR_OP_READ in
a mdio write operation.

It's probably a typo introduced by commit:

e6b043d512fa8d9a3801bf5d72bfa3b8fc3b3cc8
netdev/fec.c: add phylib supporting to enable carrier detection (v2)

Signed-off-by: Shawn Guo 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ixgbe: fix for 82599 erratum on Header Splitting

2011-02-17T22:47:16+00:00

commit a124339ad28389093ed15eca990d39c51c5736cc upstream.

We have found a hardware erratum on 82599 hardware that can lead to
unpredictable behavior when Header Splitting mode is enabled.  So
we are no longer enabling this feature on affected hardware.

Please see the 82599 Specification Update for more information.

Signed-off-by: Don Skidmore 
Tested-by: Stephen Ko 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

virtio_net: Add schedule check to napi_enable call

2011-02-17T22:47:13+00:00

commit 3e9d08ec0a68f6faf718d5a7e050fe5ca0ba004f upstream.

Under harsh testing conditions, including low memory, the guest would
stop receiving packets. With this patch applied we no longer see any
problems in the driver while performing these tests for extended periods
of time.

Make sure napi is scheduled subsequent to each napi_enable.

Signed-off-by: Bruce Rogers 
Signed-off-by: Olaf Kirch 
Signed-off-by: Rusty Russell 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

p54: fix sequence no. accounting off-by-one error

2011-02-17T22:47:09+00:00

commit 3b5c5827d1f80ad8ae844a8b1183f59ddb90fe25 upstream.

P54_HDR_FLAG_DATA_OUT_SEQNR is meant to tell the
firmware that "the frame's sequence number has
already been set by the application."

Whereas IEEE80211_TX_CTL_ASSIGN_SEQ is set for
frames which lack a valid sequence number and
either the driver or firmware has to assign one.

Yup, it's the exact opposite!

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

ath9k_hw: Fix system hang when resuming from S3/S4

2011-02-17T22:46:54+00:00

commit 5b64aa72ead6f8be488d2be7af579f0d69fb7a6e upstream.

The bit 6 & 7 of AR_WA (0x4004) should be enabled only
for the chips that are supporting L0s functionality
while resuming back from S3/S4.

Enabling these bits for AR9280 is causing system hang
within a few S3/S4-resume cycles.

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

ath9k_hw: disabled PAPRD for AR9003

2011-02-17T22:46:54+00:00

commit 6f4810101a629b31b5427872a09ea092cfc5c4bd upstream.

AR9003's PAPRD was enabled prematurely, and is causing some
large discrepancies on throughput and network connectivity.
For example downlink (RX) throughput against an AR9280 AP
can vary widlely from 43-73 Mbit/s while disabling this
gets AR9382 (2x2) up to around 93 Mbit/s in a 2.4 GHz HT20 setup.

Cc: Paul Shaw 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k_hw: do PA offset calibration only on longcal interval

2011-02-17T22:46:53+00:00

commit 811ea256b30b37091b5bbf41517404cf98ab56c1 upstream.

The power detector adc offset calibration has to be done
on 4 minutes interval (longcal * pa_skip_count). But the commit
"ath9k_hw: fix a noise floor calibration related race condition"
makes the PA calibration executed more frequently beased on
nfcal_pending value. Running PAOffset calibration lesser than
longcal interval doesn't help anything and the worse part is that
it causes NF load timeouts and RX deaf conditions.

In a very noisy environment, where the distance b/w AP & station
is ~10 meter and running a downlink udp traffic with frequent
background scan causes "Timeout while waiting for nf to load:
AR_PHY_AGC_CONTROL=0x40d1a" and moves the chip into deaf state.
This issue was originaly reported in Android platform where
the network-manager application does bgscan more frequently
on AR9271 chips. (AR9285 family usb device).

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

ath9k: fix beacon restart on channel change

2011-02-17T22:46:53+00:00

commit 1186488b4a4d4871e40cb1604ba3ede3d4b7cc90 upstream.

Restart the beacon timers only if the beacon
was already configured. Otherwise beacons timers
are restarted unnecessarily in unassociated state too.

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

ath9k: fix aphy / wiphy idle mismatch

2011-02-17T22:46:52+00:00

commit afe68d0a8f5961652e26cea39d74e2cc820de841 upstream.

ath9k supports its own set of virtual wiphys, and it uses
the mac80211 idle notifications to know when a device needs
to be idle or not. We recently changed ath9k to force idle
on driver stop() and on resume but forgot to take into account
ath9k's own virtual wiphy idle states. These are used internally
by ath9k to check if the device's radio should be powered down
on each idle call. Without this change its possible that the
device could have been forced off but the virtual wiphy idle
was left on.

Cc: Paul Stewart 
Cc: Amod Bodas 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k: fix assumptions for idle calls on suspend/resume

2011-02-17T22:46:52+00:00

commit a08e7ade9ddf4fe79576f953cc5c1725e944d26c upstream.

mac80211 will notify drivers when to go idle and ath9k
assumed that it would get further notifications for idle
states after a device stop() config call but as per agreed
semantics the idle state of the radio is left up to driver
after mac80211 issues the stop() callback. The driver is
resposnbile for ensuring the device remains idle after
that even between suspend / resume calls.

This fixes suspend/resume when you issue suspend and resume
twice on ath9k when ath9k_stop() was already called. We need
to put the radio to full sleep in order for resume to work
correctly.

What might seem fishy is we are turning the radio off
after resume. The reason why we do this is because we know
we should not have anything enabled after a mac80211 tells
us to stop(), if we resume and never get a start() we won't
get another stop() by mac80211 so to be safe always bring
the 802.11 device with the radio disabled after resume,
this ensures that if we suspend we already have the radio
disabled and only a start() will ever trigger it on.

Cc: Paul Stewart 
Cc: Amod Bodas 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman