linux-stable.git/drivers/net/wireless, branch linux-2.6.36.y

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

ath9k: Fix bug in delimiter padding computation

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

commit 39ec2997c374b528cdbf65099b6d6b8593a67f7f upstream.

There is a roundng error in delimiter padding computation
which causes severe throughput drop with some of AR9003.

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

ath9k: move the PCU lock to the sc structure

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

commit 4bdd1e978ede034c1211957eb17eaf50de00d234 upstream.

The PCU lock should be used to contend TX DMA as well,
this will be done next.

This is part of a series of patches which fix stopping
TX DMA completley when requested on the driver.
For more details about this issue refer to this thread:

http://marc.info/?l=linux-wireless&m=128629803703756&w=2

Tested-by:  Ben Greear 
Cc: Kyungwan Nam 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k: simplify hw reset locking

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

commit 9d94674ab754be0e275120a183670ead435f9c0d upstream.

The new PCU lock is better placed so we can just contend
against that when trying to reset hardware.

This is part of a series of patches which fix stopping
TX DMA completley when requested on the driver.
For more details about this issue refer to this thread:

http://marc.info/?l=linux-wireless&m=128629803703756&w=2

Tested-by:  Ben Greear 
Cc: Kyungwan Nam 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville