2008-10-29 12:46:30 +08:00
|
|
|
/*
|
2011-05-17 16:06:18 +08:00
|
|
|
* Copyright (c) 2008-2011 Atheros Communications Inc.
|
2008-10-29 12:46:30 +08:00
|
|
|
*
|
|
|
|
* Permission to use, copy, modify, and/or distribute this software for any
|
|
|
|
* purpose with or without fee is hereby granted, provided that the above
|
|
|
|
* copyright notice and this permission notice appear in all copies.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
|
|
|
|
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
|
|
|
|
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
|
|
|
|
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
|
|
|
|
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
|
|
|
|
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
|
|
|
|
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
2009-09-13 17:42:02 +08:00
|
|
|
#include "hw.h"
|
2010-04-16 05:38:49 +08:00
|
|
|
#include "hw-ops.h"
|
2011-05-28 04:14:23 +08:00
|
|
|
#include <linux/export.h>
|
2008-10-29 12:46:30 +08:00
|
|
|
|
2010-04-16 05:39:00 +08:00
|
|
|
/* Common calibration code */
|
|
|
|
|
2008-10-29 12:46:30 +08:00
|
|
|
|
|
|
|
static int16_t ath9k_hw_get_nf_hist_mid(int16_t *nfCalBuffer)
|
|
|
|
{
|
|
|
|
int16_t nfval;
|
|
|
|
int16_t sort[ATH9K_NF_CAL_HIST_MAX];
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
for (i = 0; i < ATH9K_NF_CAL_HIST_MAX; i++)
|
|
|
|
sort[i] = nfCalBuffer[i];
|
|
|
|
|
|
|
|
for (i = 0; i < ATH9K_NF_CAL_HIST_MAX - 1; i++) {
|
|
|
|
for (j = 1; j < ATH9K_NF_CAL_HIST_MAX - i; j++) {
|
|
|
|
if (sort[j] > sort[j - 1]) {
|
|
|
|
nfval = sort[j];
|
|
|
|
sort[j] = sort[j - 1];
|
|
|
|
sort[j - 1] = nfval;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
nfval = sort[(ATH9K_NF_CAL_HIST_MAX - 1) >> 1];
|
|
|
|
|
|
|
|
return nfval;
|
|
|
|
}
|
|
|
|
|
2010-08-02 21:53:13 +08:00
|
|
|
static struct ath_nf_limits *ath9k_hw_get_nf_limits(struct ath_hw *ah,
|
|
|
|
struct ath9k_channel *chan)
|
|
|
|
{
|
|
|
|
struct ath_nf_limits *limit;
|
|
|
|
|
|
|
|
if (!chan || IS_CHAN_2GHZ(chan))
|
|
|
|
limit = &ah->nf_2g;
|
|
|
|
else
|
|
|
|
limit = &ah->nf_5g;
|
|
|
|
|
|
|
|
return limit;
|
|
|
|
}
|
|
|
|
|
|
|
|
static s16 ath9k_hw_get_default_nf(struct ath_hw *ah,
|
|
|
|
struct ath9k_channel *chan)
|
|
|
|
{
|
|
|
|
return ath9k_hw_get_nf_limits(ah, chan)->nominal;
|
|
|
|
}
|
|
|
|
|
2013-10-11 20:09:54 +08:00
|
|
|
s16 ath9k_hw_getchan_noise(struct ath_hw *ah, struct ath9k_channel *chan,
|
|
|
|
s16 nf)
|
2011-07-28 20:08:56 +08:00
|
|
|
{
|
|
|
|
s8 noise = ATH_DEFAULT_NOISE_FLOOR;
|
|
|
|
|
2013-10-11 20:09:54 +08:00
|
|
|
if (nf) {
|
|
|
|
s8 delta = nf - ATH9K_NF_CAL_NOISE_THRESH -
|
2011-07-28 20:08:56 +08:00
|
|
|
ath9k_hw_get_default_nf(ah, chan);
|
|
|
|
if (delta > 0)
|
|
|
|
noise += delta;
|
|
|
|
}
|
|
|
|
return noise;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(ath9k_hw_getchan_noise);
|
2010-08-02 21:53:13 +08:00
|
|
|
|
|
|
|
static void ath9k_hw_update_nfcal_hist_buffer(struct ath_hw *ah,
|
ath9k: use AP beacon miss as a trigger for fast recalibration
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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-08-02 21:53:14 +08:00
|
|
|
struct ath9k_hw_cal_data *cal,
|
2008-10-29 12:46:30 +08:00
|
|
|
int16_t *nfarray)
|
|
|
|
{
|
ath9k: use AP beacon miss as a trigger for fast recalibration
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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-08-02 21:53:14 +08:00
|
|
|
struct ath_common *common = ath9k_hw_common(ah);
|
2010-08-02 21:53:13 +08:00
|
|
|
struct ath_nf_limits *limit;
|
ath9k: use AP beacon miss as a trigger for fast recalibration
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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-08-02 21:53:14 +08:00
|
|
|
struct ath9k_nfcal_hist *h;
|
|
|
|
bool high_nf_mid = false;
|
2011-05-04 22:07:17 +08:00
|
|
|
u8 chainmask = (ah->rxchainmask << 3) | ah->rxchainmask;
|
2008-10-29 12:46:30 +08:00
|
|
|
int i;
|
|
|
|
|
ath9k: use AP beacon miss as a trigger for fast recalibration
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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-08-02 21:53:14 +08:00
|
|
|
h = cal->nfCalHist;
|
2010-08-02 21:53:13 +08:00
|
|
|
limit = ath9k_hw_get_nf_limits(ah, ah->curchan);
|
|
|
|
|
2008-10-29 12:46:30 +08:00
|
|
|
for (i = 0; i < NUM_NF_READINGS; i++) {
|
2011-05-04 22:07:17 +08:00
|
|
|
if (!(chainmask & (1 << i)) ||
|
2011-08-13 12:58:16 +08:00
|
|
|
((i >= AR5416_MAX_CHAINS) && !IS_CHAN_HT40(ah->curchan)))
|
2011-05-04 22:07:17 +08:00
|
|
|
continue;
|
|
|
|
|
2008-10-29 12:46:30 +08:00
|
|
|
h[i].nfCalBuffer[h[i].currIndex] = nfarray[i];
|
|
|
|
|
|
|
|
if (++h[i].currIndex >= ATH9K_NF_CAL_HIST_MAX)
|
|
|
|
h[i].currIndex = 0;
|
|
|
|
|
|
|
|
if (h[i].invalidNFcount > 0) {
|
2010-07-02 06:09:50 +08:00
|
|
|
h[i].invalidNFcount--;
|
|
|
|
h[i].privNF = nfarray[i];
|
2008-10-29 12:46:30 +08:00
|
|
|
} else {
|
|
|
|
h[i].privNF =
|
|
|
|
ath9k_hw_get_nf_hist_mid(h[i].nfCalBuffer);
|
|
|
|
}
|
2010-08-02 21:53:13 +08:00
|
|
|
|
ath9k: use AP beacon miss as a trigger for fast recalibration
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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-08-02 21:53:14 +08:00
|
|
|
if (!h[i].privNF)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (h[i].privNF > limit->max) {
|
|
|
|
high_nf_mid = true;
|
|
|
|
|
2011-12-16 06:55:53 +08:00
|
|
|
ath_dbg(common, CALIBRATE,
|
2010-12-03 11:12:37 +08:00
|
|
|
"NFmid[%d] (%d) > MAX (%d), %s\n",
|
|
|
|
i, h[i].privNF, limit->max,
|
2013-09-11 19:06:31 +08:00
|
|
|
(test_bit(NFCAL_INTF, &cal->cal_flags) ?
|
2010-12-03 11:12:37 +08:00
|
|
|
"not corrected (due to interference)" :
|
|
|
|
"correcting to MAX"));
|
ath9k: use AP beacon miss as a trigger for fast recalibration
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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-08-02 21:53:14 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Normally we limit the average noise floor by the
|
|
|
|
* hardware specific maximum here. However if we have
|
|
|
|
* encountered stuck beacons because of interference,
|
|
|
|
* we bypass this limit here in order to better deal
|
|
|
|
* with our environment.
|
|
|
|
*/
|
2013-09-11 19:06:31 +08:00
|
|
|
if (!test_bit(NFCAL_INTF, &cal->cal_flags))
|
ath9k: use AP beacon miss as a trigger for fast recalibration
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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-08-02 21:53:14 +08:00
|
|
|
h[i].privNF = limit->max;
|
|
|
|
}
|
2008-10-29 12:46:30 +08:00
|
|
|
}
|
ath9k: use AP beacon miss as a trigger for fast recalibration
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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-08-02 21:53:14 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If the noise floor seems normal for all chains, assume that
|
|
|
|
* there is no significant interference in the environment anymore.
|
|
|
|
* Re-enable the enforcement of the NF maximum again.
|
|
|
|
*/
|
|
|
|
if (!high_nf_mid)
|
2013-09-11 19:06:31 +08:00
|
|
|
clear_bit(NFCAL_INTF, &cal->cal_flags);
|
2008-10-29 12:46:30 +08:00
|
|
|
}
|
|
|
|
|
2010-04-16 05:38:58 +08:00
|
|
|
static bool ath9k_hw_get_nf_thresh(struct ath_hw *ah,
|
2016-04-12 21:56:15 +08:00
|
|
|
enum nl80211_band band,
|
2010-04-16 05:38:58 +08:00
|
|
|
int16_t *nft)
|
2008-10-29 12:46:30 +08:00
|
|
|
{
|
2008-12-24 07:58:41 +08:00
|
|
|
switch (band) {
|
2016-04-12 21:56:15 +08:00
|
|
|
case NL80211_BAND_5GHZ:
|
2009-02-09 15:57:24 +08:00
|
|
|
*nft = (int8_t)ah->eep_ops->get_eeprom(ah, EEP_NFTHRESH_5);
|
2008-10-29 12:46:30 +08:00
|
|
|
break;
|
2016-04-12 21:56:15 +08:00
|
|
|
case NL80211_BAND_2GHZ:
|
2009-02-09 15:57:24 +08:00
|
|
|
*nft = (int8_t)ah->eep_ops->get_eeprom(ah, EEP_NFTHRESH_2);
|
2008-10-29 12:46:30 +08:00
|
|
|
break;
|
|
|
|
default:
|
2008-12-24 07:58:41 +08:00
|
|
|
BUG_ON(1);
|
2008-10-29 12:46:30 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2010-04-16 05:39:00 +08:00
|
|
|
void ath9k_hw_reset_calibration(struct ath_hw *ah,
|
|
|
|
struct ath9k_cal_list *currCal)
|
2008-10-29 12:46:30 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
ath9k_hw_setup_calibration(ah, currCal);
|
|
|
|
|
|
|
|
currCal->calState = CAL_RUNNING;
|
|
|
|
|
|
|
|
for (i = 0; i < AR5416_MAX_CHAINS; i++) {
|
2009-02-09 15:57:26 +08:00
|
|
|
ah->meas0.sign[i] = 0;
|
|
|
|
ah->meas1.sign[i] = 0;
|
|
|
|
ah->meas2.sign[i] = 0;
|
|
|
|
ah->meas3.sign[i] = 0;
|
2008-10-29 12:46:30 +08:00
|
|
|
}
|
|
|
|
|
2009-02-09 15:57:26 +08:00
|
|
|
ah->cal_samples = 0;
|
2008-10-29 12:46:30 +08:00
|
|
|
}
|
|
|
|
|
2008-12-24 07:58:42 +08:00
|
|
|
/* This is done for the currently configured channel */
|
2009-02-09 15:57:12 +08:00
|
|
|
bool ath9k_hw_reset_calvalid(struct ath_hw *ah)
|
2008-10-29 12:46:30 +08:00
|
|
|
{
|
2009-09-13 17:42:02 +08:00
|
|
|
struct ath_common *common = ath9k_hw_common(ah);
|
2009-04-14 00:26:56 +08:00
|
|
|
struct ath9k_cal_list *currCal = ah->cal_list_curr;
|
2008-10-29 12:46:30 +08:00
|
|
|
|
2010-07-31 06:12:00 +08:00
|
|
|
if (!ah->caldata)
|
2008-12-24 07:58:42 +08:00
|
|
|
return true;
|
2008-10-29 12:46:30 +08:00
|
|
|
|
|
|
|
if (!AR_SREV_9100(ah) && !AR_SREV_9160_10_OR_LATER(ah))
|
2008-12-24 07:58:42 +08:00
|
|
|
return true;
|
2008-10-29 12:46:30 +08:00
|
|
|
|
|
|
|
if (currCal == NULL)
|
2008-12-24 07:58:42 +08:00
|
|
|
return true;
|
2008-10-29 12:46:30 +08:00
|
|
|
|
|
|
|
if (currCal->calState != CAL_DONE) {
|
2011-12-16 06:55:53 +08:00
|
|
|
ath_dbg(common, CALIBRATE, "Calibration state incorrect, %d\n",
|
2010-12-03 11:12:37 +08:00
|
|
|
currCal->calState);
|
2008-12-24 07:58:42 +08:00
|
|
|
return true;
|
2008-10-29 12:46:30 +08:00
|
|
|
}
|
|
|
|
|
2010-10-04 01:07:16 +08:00
|
|
|
if (!(ah->supp_cals & currCal->calData->calType))
|
2008-12-24 07:58:42 +08:00
|
|
|
return true;
|
2008-10-29 12:46:30 +08:00
|
|
|
|
2011-12-16 06:55:53 +08:00
|
|
|
ath_dbg(common, CALIBRATE, "Resetting Cal %d state for channel %u\n",
|
2013-10-12 05:31:01 +08:00
|
|
|
currCal->calData->calType, ah->curchan->chan->center_freq);
|
2008-10-29 12:46:30 +08:00
|
|
|
|
2010-07-31 06:12:00 +08:00
|
|
|
ah->caldata->CalValid &= ~currCal->calData->calType;
|
2008-10-29 12:46:30 +08:00
|
|
|
currCal->calState = CAL_WAITING;
|
|
|
|
|
2008-12-24 07:58:42 +08:00
|
|
|
return false;
|
2008-10-29 12:46:30 +08:00
|
|
|
}
|
2009-09-24 11:07:00 +08:00
|
|
|
EXPORT_SYMBOL(ath9k_hw_reset_calvalid);
|
2008-10-29 12:46:30 +08:00
|
|
|
|
2010-07-31 03:02:09 +08:00
|
|
|
void ath9k_hw_start_nfcal(struct ath_hw *ah, bool update)
|
2008-10-29 12:46:30 +08:00
|
|
|
{
|
2010-07-31 06:12:01 +08:00
|
|
|
if (ah->caldata)
|
2013-09-11 19:06:31 +08:00
|
|
|
set_bit(NFCAL_PENDING, &ah->caldata->cal_flags);
|
2010-07-31 06:12:01 +08:00
|
|
|
|
2008-10-29 12:46:30 +08:00
|
|
|
REG_SET_BIT(ah, AR_PHY_AGC_CONTROL,
|
|
|
|
AR_PHY_AGC_CONTROL_ENABLE_NF);
|
2010-07-31 03:02:09 +08:00
|
|
|
|
|
|
|
if (update)
|
|
|
|
REG_CLR_BIT(ah, AR_PHY_AGC_CONTROL,
|
2008-10-29 12:46:30 +08:00
|
|
|
AR_PHY_AGC_CONTROL_NO_UPDATE_NF);
|
2010-07-31 03:02:09 +08:00
|
|
|
else
|
|
|
|
REG_SET_BIT(ah, AR_PHY_AGC_CONTROL,
|
|
|
|
AR_PHY_AGC_CONTROL_NO_UPDATE_NF);
|
|
|
|
|
2008-10-29 12:46:30 +08:00
|
|
|
REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NF);
|
|
|
|
}
|
|
|
|
|
2014-10-25 23:19:30 +08:00
|
|
|
int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel *chan)
|
2010-07-11 21:44:42 +08:00
|
|
|
{
|
2010-07-31 06:12:00 +08:00
|
|
|
struct ath9k_nfcal_hist *h = NULL;
|
2010-07-11 21:44:42 +08:00
|
|
|
unsigned i, j;
|
2010-07-23 10:31:56 +08:00
|
|
|
u8 chainmask = (ah->rxchainmask << 3) | ah->rxchainmask;
|
2010-07-11 21:44:42 +08:00
|
|
|
struct ath_common *common = ath9k_hw_common(ah);
|
2010-07-31 06:12:00 +08:00
|
|
|
s16 default_nf = ath9k_hw_get_default_nf(ah, chan);
|
2016-02-05 09:45:50 +08:00
|
|
|
u32 bb_agc_ctl = REG_READ(ah, AR_PHY_AGC_CONTROL);
|
2010-07-11 21:44:42 +08:00
|
|
|
|
2010-07-31 06:12:00 +08:00
|
|
|
if (ah->caldata)
|
|
|
|
h = ah->caldata->nfCalHist;
|
2010-07-11 21:44:42 +08:00
|
|
|
|
2015-03-23 02:29:54 +08:00
|
|
|
ENABLE_REG_RMW_BUFFER(ah);
|
2010-07-11 21:44:42 +08:00
|
|
|
for (i = 0; i < NUM_NF_READINGS; i++) {
|
|
|
|
if (chainmask & (1 << i)) {
|
2010-07-31 06:12:00 +08:00
|
|
|
s16 nfval;
|
|
|
|
|
2013-10-12 05:31:01 +08:00
|
|
|
if ((i >= AR5416_MAX_CHAINS) && !IS_CHAN_HT40(chan))
|
2011-05-04 22:07:17 +08:00
|
|
|
continue;
|
|
|
|
|
2010-07-31 06:12:00 +08:00
|
|
|
if (h)
|
|
|
|
nfval = h[i].privNF;
|
|
|
|
else
|
|
|
|
nfval = default_nf;
|
|
|
|
|
2015-03-23 02:29:54 +08:00
|
|
|
REG_RMW(ah, ah->nf_regs[i],
|
|
|
|
(((u32) nfval << 1) & 0x1ff), 0x1ff);
|
2010-07-11 21:44:42 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-02-05 09:45:50 +08:00
|
|
|
/*
|
|
|
|
* stop NF cal if ongoing to ensure NF load completes immediately
|
|
|
|
* (or after end rx/tx frame if ongoing)
|
|
|
|
*/
|
|
|
|
if (bb_agc_ctl & AR_PHY_AGC_CONTROL_NF) {
|
|
|
|
REG_CLR_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NF);
|
|
|
|
REG_RMW_BUFFER_FLUSH(ah);
|
|
|
|
ENABLE_REG_RMW_BUFFER(ah);
|
|
|
|
}
|
|
|
|
|
2010-07-11 21:44:42 +08:00
|
|
|
/*
|
|
|
|
* Load software filtered NF value into baseband internal minCCApwr
|
|
|
|
* variable.
|
|
|
|
*/
|
|
|
|
REG_CLR_BIT(ah, AR_PHY_AGC_CONTROL,
|
|
|
|
AR_PHY_AGC_CONTROL_ENABLE_NF);
|
|
|
|
REG_CLR_BIT(ah, AR_PHY_AGC_CONTROL,
|
|
|
|
AR_PHY_AGC_CONTROL_NO_UPDATE_NF);
|
|
|
|
REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NF);
|
2015-03-23 02:29:54 +08:00
|
|
|
REG_RMW_BUFFER_FLUSH(ah);
|
2010-07-11 21:44:42 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Wait for load to complete, should be fast, a few 10s of us.
|
2016-02-05 09:45:50 +08:00
|
|
|
* The max delay was changed from an original 250us to 22.2 msec.
|
|
|
|
* This would increase timeout to the longest possible frame
|
|
|
|
* (11n max length 22.1 msec)
|
2010-07-11 21:44:42 +08:00
|
|
|
*/
|
2016-02-05 09:45:50 +08:00
|
|
|
for (j = 0; j < 22200; j++) {
|
2010-07-11 21:44:42 +08:00
|
|
|
if ((REG_READ(ah, AR_PHY_AGC_CONTROL) &
|
2016-02-05 09:45:50 +08:00
|
|
|
AR_PHY_AGC_CONTROL_NF) == 0)
|
2010-07-11 21:44:42 +08:00
|
|
|
break;
|
|
|
|
udelay(10);
|
|
|
|
}
|
|
|
|
|
2016-02-05 09:45:50 +08:00
|
|
|
/*
|
|
|
|
* Restart NF so it can continue.
|
|
|
|
*/
|
|
|
|
if (bb_agc_ctl & AR_PHY_AGC_CONTROL_NF) {
|
|
|
|
ENABLE_REG_RMW_BUFFER(ah);
|
|
|
|
if (bb_agc_ctl & AR_PHY_AGC_CONTROL_ENABLE_NF)
|
|
|
|
REG_SET_BIT(ah, AR_PHY_AGC_CONTROL,
|
|
|
|
AR_PHY_AGC_CONTROL_ENABLE_NF);
|
|
|
|
if (bb_agc_ctl & AR_PHY_AGC_CONTROL_NO_UPDATE_NF)
|
|
|
|
REG_SET_BIT(ah, AR_PHY_AGC_CONTROL,
|
|
|
|
AR_PHY_AGC_CONTROL_NO_UPDATE_NF);
|
|
|
|
REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NF);
|
|
|
|
REG_RMW_BUFFER_FLUSH(ah);
|
|
|
|
}
|
|
|
|
|
2010-07-11 21:44:42 +08:00
|
|
|
/*
|
|
|
|
* We timed out waiting for the noisefloor to load, probably due to an
|
|
|
|
* in-progress rx. Simply return here and allow the load plenty of time
|
|
|
|
* to complete before the next calibration interval. We need to avoid
|
|
|
|
* trying to load -50 (which happens below) while the previous load is
|
|
|
|
* still in progress as this can cause rx deafness. Instead by returning
|
|
|
|
* here, the baseband nf cal will just be capped by our present
|
|
|
|
* noisefloor until the next calibration timer.
|
|
|
|
*/
|
2016-02-05 09:45:50 +08:00
|
|
|
if (j == 22200) {
|
2011-12-16 06:55:53 +08:00
|
|
|
ath_dbg(common, ANY,
|
2010-12-03 11:12:37 +08:00
|
|
|
"Timeout while waiting for nf to load: AR_PHY_AGC_CONTROL=0x%x\n",
|
|
|
|
REG_READ(ah, AR_PHY_AGC_CONTROL));
|
2014-10-25 23:19:30 +08:00
|
|
|
return -ETIMEDOUT;
|
2010-07-11 21:44:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Restore maxCCAPower register parameter again so that we're not capped
|
|
|
|
* by the median we just loaded. This will be initial (and max) value
|
|
|
|
* of next noise floor calibration the baseband does.
|
|
|
|
*/
|
2015-03-23 02:29:54 +08:00
|
|
|
ENABLE_REG_RMW_BUFFER(ah);
|
2010-07-11 21:44:42 +08:00
|
|
|
for (i = 0; i < NUM_NF_READINGS; i++) {
|
|
|
|
if (chainmask & (1 << i)) {
|
2013-10-12 05:31:01 +08:00
|
|
|
if ((i >= AR5416_MAX_CHAINS) && !IS_CHAN_HT40(chan))
|
2011-05-04 22:07:17 +08:00
|
|
|
continue;
|
|
|
|
|
2015-03-23 02:29:54 +08:00
|
|
|
REG_RMW(ah, ah->nf_regs[i],
|
|
|
|
(((u32) (-50) << 1) & 0x1ff), 0x1ff);
|
2010-07-11 21:44:42 +08:00
|
|
|
}
|
|
|
|
}
|
2015-03-23 02:29:54 +08:00
|
|
|
REG_RMW_BUFFER_FLUSH(ah);
|
2014-10-25 23:19:30 +08:00
|
|
|
|
|
|
|
return 0;
|
2010-07-11 21:44:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-07-02 06:09:50 +08:00
|
|
|
static void ath9k_hw_nf_sanitize(struct ath_hw *ah, s16 *nf)
|
|
|
|
{
|
|
|
|
struct ath_common *common = ath9k_hw_common(ah);
|
|
|
|
struct ath_nf_limits *limit;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (IS_CHAN_2GHZ(ah->curchan))
|
|
|
|
limit = &ah->nf_2g;
|
|
|
|
else
|
|
|
|
limit = &ah->nf_5g;
|
|
|
|
|
|
|
|
for (i = 0; i < NUM_NF_READINGS; i++) {
|
|
|
|
if (!nf[i])
|
|
|
|
continue;
|
|
|
|
|
2011-12-16 06:55:53 +08:00
|
|
|
ath_dbg(common, CALIBRATE,
|
2010-12-03 11:12:37 +08:00
|
|
|
"NF calibrated [%s] [chain %d] is %d\n",
|
|
|
|
(i >= 3 ? "ext" : "ctl"), i % 3, nf[i]);
|
2010-07-02 06:09:51 +08:00
|
|
|
|
2012-03-15 08:38:04 +08:00
|
|
|
if (nf[i] > limit->max) {
|
2011-12-16 06:55:53 +08:00
|
|
|
ath_dbg(common, CALIBRATE,
|
2010-12-03 11:12:37 +08:00
|
|
|
"NF[%d] (%d) > MAX (%d), correcting to MAX\n",
|
2012-03-15 08:38:04 +08:00
|
|
|
i, nf[i], limit->max);
|
2010-07-02 06:09:50 +08:00
|
|
|
nf[i] = limit->max;
|
|
|
|
} else if (nf[i] < limit->min) {
|
2011-12-16 06:55:53 +08:00
|
|
|
ath_dbg(common, CALIBRATE,
|
2010-12-03 11:12:37 +08:00
|
|
|
"NF[%d] (%d) < MIN (%d), correcting to NOM\n",
|
|
|
|
i, nf[i], limit->min);
|
2010-07-02 06:09:50 +08:00
|
|
|
nf[i] = limit->nominal;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-07-31 06:12:01 +08:00
|
|
|
bool ath9k_hw_getnf(struct ath_hw *ah, struct ath9k_channel *chan)
|
2008-10-29 12:46:30 +08:00
|
|
|
{
|
2009-09-13 17:42:02 +08:00
|
|
|
struct ath_common *common = ath9k_hw_common(ah);
|
2008-10-29 12:46:30 +08:00
|
|
|
int16_t nf, nfThresh;
|
|
|
|
int16_t nfarray[NUM_NF_READINGS] = { 0 };
|
|
|
|
struct ath9k_nfcal_hist *h;
|
2008-12-24 07:58:41 +08:00
|
|
|
struct ieee80211_channel *c = chan->chan;
|
2010-07-31 06:12:00 +08:00
|
|
|
struct ath9k_hw_cal_data *caldata = ah->caldata;
|
|
|
|
|
2008-10-29 12:46:30 +08:00
|
|
|
if (REG_READ(ah, AR_PHY_AGC_CONTROL) & AR_PHY_AGC_CONTROL_NF) {
|
2011-12-16 06:55:53 +08:00
|
|
|
ath_dbg(common, CALIBRATE,
|
2010-12-03 11:12:37 +08:00
|
|
|
"NF did not complete in calibration window\n");
|
2010-07-31 06:12:01 +08:00
|
|
|
return false;
|
2010-09-29 23:15:27 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ath9k_hw_do_getnf(ah, nfarray);
|
|
|
|
ath9k_hw_nf_sanitize(ah, nfarray);
|
|
|
|
nf = nfarray[0];
|
|
|
|
if (ath9k_hw_get_nf_thresh(ah, c->band, &nfThresh)
|
|
|
|
&& nf > nfThresh) {
|
2011-12-16 06:55:53 +08:00
|
|
|
ath_dbg(common, CALIBRATE,
|
2010-12-03 11:12:37 +08:00
|
|
|
"noise floor failed detected; detected %d, threshold %d\n",
|
|
|
|
nf, nfThresh);
|
2010-09-29 23:15:27 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!caldata) {
|
|
|
|
chan->noisefloor = nf;
|
|
|
|
return false;
|
2008-10-29 12:46:30 +08:00
|
|
|
}
|
|
|
|
|
2010-07-31 06:12:00 +08:00
|
|
|
h = caldata->nfCalHist;
|
2013-09-11 19:06:31 +08:00
|
|
|
clear_bit(NFCAL_PENDING, &caldata->cal_flags);
|
ath9k: use AP beacon miss as a trigger for fast recalibration
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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-08-02 21:53:14 +08:00
|
|
|
ath9k_hw_update_nfcal_hist_buffer(ah, caldata, nfarray);
|
2010-09-29 23:15:27 +08:00
|
|
|
chan->noisefloor = h[0].privNF;
|
2013-10-11 20:09:54 +08:00
|
|
|
ah->noise = ath9k_hw_getchan_noise(ah, chan, chan->noisefloor);
|
2010-07-31 06:12:01 +08:00
|
|
|
return true;
|
2008-10-29 12:46:30 +08:00
|
|
|
}
|
2012-01-09 18:07:53 +08:00
|
|
|
EXPORT_SYMBOL(ath9k_hw_getnf);
|
2008-10-29 12:46:30 +08:00
|
|
|
|
2010-07-31 06:12:00 +08:00
|
|
|
void ath9k_init_nfcal_hist_buffer(struct ath_hw *ah,
|
|
|
|
struct ath9k_channel *chan)
|
2008-10-29 12:46:30 +08:00
|
|
|
{
|
2010-07-31 06:12:00 +08:00
|
|
|
struct ath9k_nfcal_hist *h;
|
|
|
|
s16 default_nf;
|
2008-10-29 12:46:30 +08:00
|
|
|
int i, j;
|
2010-07-02 06:09:50 +08:00
|
|
|
|
2011-01-15 03:31:22 +08:00
|
|
|
ah->caldata->channel = chan->channel;
|
2013-03-04 15:12:52 +08:00
|
|
|
ah->caldata->channelFlags = chan->channelFlags;
|
2010-07-31 06:12:00 +08:00
|
|
|
h = ah->caldata->nfCalHist;
|
|
|
|
default_nf = ath9k_hw_get_default_nf(ah, chan);
|
2008-10-29 12:46:30 +08:00
|
|
|
for (i = 0; i < NUM_NF_READINGS; i++) {
|
2010-07-31 06:12:00 +08:00
|
|
|
h[i].currIndex = 0;
|
|
|
|
h[i].privNF = default_nf;
|
|
|
|
h[i].invalidNFcount = AR_PHY_CCA_FILTERWINDOW_LENGTH;
|
2008-10-29 12:46:30 +08:00
|
|
|
for (j = 0; j < ATH9K_NF_CAL_HIST_MAX; j++) {
|
2010-07-31 06:12:00 +08:00
|
|
|
h[i].nfCalBuffer[j] = default_nf;
|
2008-10-29 12:46:30 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
ath9k: use AP beacon miss as a trigger for fast recalibration
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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-08-02 21:53:14 +08:00
|
|
|
|
|
|
|
void ath9k_hw_bstuck_nfcal(struct ath_hw *ah)
|
|
|
|
{
|
|
|
|
struct ath9k_hw_cal_data *caldata = ah->caldata;
|
|
|
|
|
|
|
|
if (unlikely(!caldata))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If beacons are stuck, the most likely cause is interference.
|
|
|
|
* Triggering a noise floor calibration at this point helps the
|
|
|
|
* hardware adapt to a noisy environment much faster.
|
|
|
|
* To ensure that we recover from stuck beacons quickly, let
|
|
|
|
* the baseband update the internal NF value itself, similar to
|
|
|
|
* what is being done after a full reset.
|
|
|
|
*/
|
2013-09-11 19:06:31 +08:00
|
|
|
if (!test_bit(NFCAL_PENDING, &caldata->cal_flags))
|
ath9k: use AP beacon miss as a trigger for fast recalibration
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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-08-02 21:53:14 +08:00
|
|
|
ath9k_hw_start_nfcal(ah, true);
|
|
|
|
else if (!(REG_READ(ah, AR_PHY_AGC_CONTROL) & AR_PHY_AGC_CONTROL_NF))
|
|
|
|
ath9k_hw_getnf(ah, ah->curchan);
|
|
|
|
|
2013-09-11 19:06:31 +08:00
|
|
|
set_bit(NFCAL_INTF, &caldata->cal_flags);
|
ath9k: use AP beacon miss as a trigger for fast recalibration
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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-08-02 21:53:14 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(ath9k_hw_bstuck_nfcal);
|
|
|
|
|