Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 19 10月, 2013 1 次提交
  3. 15 10月, 2013 2 次提交
  5. 27 9月, 2013 1 次提交
  7. 13 6月, 2013 1 次提交
  9. 26 3月, 2013 1 次提交
  11. 07 3月, 2013 1 次提交
  13. 11 12月, 2012 1 次提交
    • F
      ath9k_hw: Fix signal strength / channel noise reporting · b7c0c238
      由 Felix Fietkau 提交于 
      While AR_PHY_CCA_NOM_VAL_* does contain the expected internal noise floor
for a chip measured in clean air, it refers to the lowest expected reading.

Depending on the frequency, this measurement can vary by about 6db, thus
causing a higher reported channel noise and signal strength.

Factor in the 6db offset when converting internal noisefloor to channel noise.

This patch makes the reported values more accurate for all chips without
affecting NF calibration behavior.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b7c0c238
  15. 30 10月, 2012 1 次提交
  17. 27 3月, 2012 1 次提交
  19. 11 1月, 2012 1 次提交
  21. 20 12月, 2011 1 次提交
  23. 01 11月, 2011 1 次提交
  25. 25 8月, 2011 1 次提交
  27. 09 8月, 2011 1 次提交
    • F
      ath9k_hw: calculate a much better approximation of channel noise · f23fba49
      由 Felix Fietkau 提交于 
      Currently ath9k presents the internal calibrated noise floor as channel
noise measurement, however this results in highly chip specific values
that are only useful as relative measurements but do not resemble any
real channel noise values.

In order to give a much better approximation of the real channel noise,
add the difference between the measured noise floor and the nominal
chip specific noise floor to the default minimum channel noise value,
which is currently used to calculate the signal strength from the RSSI
value. This may not be 100% accurate, but it's much better than what's
there before.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f23fba49
  29. 20 5月, 2011 1 次提交
  31. 11 5月, 2011 1 次提交
  33. 06 5月, 2011 1 次提交
    • R
      ath9k_hw: do noise floor calibration only on required chains · 28ef6450
      由 Rajkumar Manoharan 提交于 
      At present the noise floor calibration is processed in supported
control and extension chains rather than required chains.
Unnccesarily doing nfcal in all supported chains leads to
invalid nf readings on extn chains and these invalid values
got updated into history buffer. While loading those values
from history buffer is moving the chip to deaf state.

This issue was observed in AR9002/AR9003 chips while doing
associate/dissociate in HT40 mode and interface up/down
in iterative manner. After some iterations, the chip was moved
to deaf state. Somehow the pci devices are recovered by poll work
after chip reset. Raading the nf values in all supported extension chains
when the hw is not yet configured in HT40 mode results invalid values.

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      28ef6450
  35. 12 3月, 2011 1 次提交
  37. 20 1月, 2011 1 次提交
  39. 08 12月, 2010 1 次提交
  41. 07 10月, 2010 2 次提交
  43. 06 10月, 2010 1 次提交
  45. 17 8月, 2010 2 次提交
    • F
      ath9k: use AP beacon miss as a trigger for fast recalibration · 70cf1533
      由 Felix Fietkau 提交于 
      When beacons get stuck in AP mode, the most likely cause is interference.
Such interference can often go on for a while, and too many consecutive
beacon misses can lead to connected clients getting dropped.

Since connected clients might not be subjected to the same interference
if that happens to be very local, the AP should try to deal with it as
good as it can. One way to do this is to trigger an NF calibration with
automatic baseband update right after the beacon miss. In my tests with
very strong interference, this allowed the AP to continue transmitting
beacons after only 2-3 misses, which allows a normal client to stay
connected.

With some of the newer - really sensitive - chips, the maximum noise
floor limit is very low, which can be problematic during very strong
interference. To avoid an endless loop of stuck beacons -> nfcal ->
periodic calibration -> stuck beacons, the beacon miss event also sets
a flag, which allows the calibration code to bypass the chip specific
maximum NF value. This flag is automatically cleared, as soon as the
first NF median goes back below the limits for all chains.

In my tests, this allowed an ath9k AP to survive very strong interference
(measured NF: -68, or sometimes even higher) without losing connectivity
to its clients. Even under these conditions, I was able to transmit
several mbits/s through the interface.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      70cf1533
    • F
      ath9k_hw: apply the noise floor validation to the median instead of single · 2292ca6d
      由 Felix Fietkau 提交于 
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2292ca6d
  47. 05 8月, 2010 3 次提交
    • F
      ath9k_hw: fix a noise floor calibration related race condition · 4254bc1c
      由 Felix Fietkau 提交于 
      On AR5008-AR9002, other forms of calibration must not be started while
the noise floor calibration is running, as this can create invalid
readings which were sometimes not even recoverable by any further
calibration attempts.

This patch also ensures that the result of noise floor measurements
are processed faster and also allows the result of the initial
calibration on reset to make it into the NF history buffer
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4254bc1c
    • F
      ath9k_hw: clean up per-channel calibration data · 20bd2a09
      由 Felix Fietkau 提交于 
      The noise floor history buffer is currently not kept per channel, which
can lead to problems when changing channels from a clean channel to a
noisy one. Also when switching from HT20 to HT40, the noise floor
history buffer is full of measurements, but none of them contain data
for the extension channel, which it needs quite a bit of time to recover
from.

This patch puts all the per-channel calibration data into a single data
structure, and gives the the driver control over whether that is used
per-channel or even not used for some channels.

For ath9k_htc, I decided to keep this per-channel in order to avoid
creating regressions.

For ath9k, the data is kept only for the operating channel, which saves
some space. ath9k_hw takes care of wiping old data when the operating
channel or its channel flags change.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      20bd2a09
    • F
      ath9k_hw: clean up and fix initial noise floor calibration · 00c86590
      由 Felix Fietkau 提交于 
      On AR9003 the initial noise floor calibration is currently triggered
at the end of the reset without allowing the hardware to update the
baseband settings. This could potentially make scans in noisy
environments a bit more unreliable, so use the same calibration
sequence that is used on AR9002.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Acked-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      00c86590
  49. 27 7月, 2010 2 次提交
  51. 13 7月, 2010 1 次提交
    • F
      ath9k: merge noisefloor load implementations · bbacee13
      由 Felix Fietkau 提交于 
      AR5008+ and AR9003 currently use two separate implementations of the
ath9k_hw_loadnf function. There are three main differences:

 - PHY registers for AR9003 are different
 - AR9003 always uses 3 chains, earlier versions are more selective
 - The AR9003 variant contains a fix for NF load timeouts

This patch merges the two implementations into one, storing the
register array in the ath_hw struct. The fix for NF load timeouts is
not just relevant for AR9003, but also important for earlier hardware,
so it's better to just keep one common implementation.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bbacee13
  53. 03 7月, 2010 2 次提交
  55. 14 5月, 2010 1 次提交
    • J
      drivers/net: Remove unnecessary returns from void function()s · a4b77097
      由 Joe Perches 提交于 
      This patch removes from drivers/net/ all the unnecessary
return; statements that precede the last closing brace of
void functions.

It does not remove the returns that are immediately
preceded by a label as gcc doesn't like that.

It also does not remove null void functions with return.

Done via:
$ grep -rP --include=*.[ch] -l "return;\n}" net/ | \
  xargs perl -i -e 'local $/ ; while (<>) { s/\n[ \t\n]+return;\n}/\n}/g; print; }'

with some cleanups by hand.

Compile tested x86 allmodconfig only.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a4b77097
  57. 17 4月, 2010 5 次提交