* Re: [PATCH v4] Bluetooth: btmrvl: add calibration data download support
From: Mike Frysinger @ 2013-09-14 4:04 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-bluetooth, Marcel Holtmann, Gustavo Padovan, Johan Hedberg,
linux-wireless, Hyuckjoo Lee, Amitkumar Karwar
In-Reply-To: <1379115162-10194-1-git-send-email-bzhao@marvell.com>
On Fri, Sep 13, 2013 at 7:32 PM, Bing Zhao wrote:
> --- a/drivers/bluetooth/btmrvl_main.c
> +++ b/drivers/bluetooth/btmrvl_main.c
>
> +static int btmrvl_parse_cal_cfg(const u8 *src, u32 len, u8 *dst, u32 dst_size)
would be nice if you put a comment above this func explaining the
expected format. otherwise, we see arbitrary parsing with no idea if
it's correct.
> + while ((s - src) < len) {
> + if (isspace(*s)) {
> + s++;
> + continue;
> + }
> +
> + if (isxdigit(*s)) {
> + if ((d - dst) >= dst_size) {
> + BT_ERR("calibration data file too big!!!");
> + return -EINVAL;
> + }
> +
> + memcpy(tmp, s, 2);
> +
> + ret = kstrtou8(tmp, 16, d++);
> + if (ret < 0)
> + return ret;
> +
> + s += 2;
> + } else {
> + s++;
> + }
> + }
so if it's a space, you skip it. if it's a hexdigit, you parse two
bytes. if it's anything else, you skip it. i'd imagine the "non
space and non hexdigit" case should throw a warning if not reject the
file out right. otherwise, if you want to keep this logic, punt the
explicit "isspace" check.
you might also copy one more byte than you should ? your limit is "(s
- src) < len", yet the isxdigit code always copies two bytes.
> +static int btmrvl_load_cal_data(struct btmrvl_private *priv,
> + u8 *config_data)
> +{
> + struct sk_buff *skb;
> + struct btmrvl_cmd *cmd;
> + int i;
> +
> + skb = bt_skb_alloc(sizeof(*cmd), GFP_ATOMIC);
maybe i'm unfamiliar with bluetooth and this is common, but why is
your code so special as to require GFP_ATOMIC allocations ?
> + for (i = 4; i < BT_CMD_DATA_SIZE; i++)
> + cmd->data[i] = config_data[(i/4)*8 - 1 - i];
style nit, but there should be spacing around those math operators.
ignoring the fact that this is some funky funky buffer offsets.
i = 4
config_data[(4 / 4) * 8 - 1 - 4] ->
config_data[8 - 1 - 4] ->
config_data[3]
i = 5
config_data[(5 / 4) * 8 - 1 - 5] ->
config_data[8 - 1 - 5] ->
config_data[2]
i = 6
config_data[(6 / 4) * 8 - 1 - 6] ->
config_data[8 - 1 - 6] ->
config_data[1]
i = 7
config_data[(7 / 4) * 8 - 1 - 7] ->
config_data[8 - 1 - 7] ->
config_data[0]
i = 8
config_data[(8 / 4) * 8 - 1 - 8] ->
config_data[16 - 1 - 8] ->
config_data[7]
i = {4,5,6,7} -> config_data[{3,2,1,0}]
i = {8,9,10,11} -> config_data[{7,6,5,4}]
that really could do with a comment explaining the mapping of input
bytes to output bytes.
-mike
^ permalink raw reply
* How to change my current WiFi Driver to ath9k.
From: Abbas Chunawala @ 2013-09-14 5:49 UTC (permalink / raw)
To: linux-wireless
Hi List,
Greetings.
I have a madWiFi Driver
I would like to replace it with ath9k driver.
Which files will i need to remove from the host stack and which will i
have to add.
Particularly there are also files like art.ko ath_hal.ko etc. etc.
By the way i have cross compiled the ath9k driver but the problem lies
that i am not able to figure out the dependencies.
Thanks
Regards
Abbas Chunawala
(System Level Solutions (I) Pvt. Ltd. )
^ permalink raw reply
* guidance on struct alignment for rtl8192cu driver
From: Jason Andrews @ 2013-09-14 5:36 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
I'm using an ASUS USB N13 on an ARM platform with the rtl8192cu driver.
Linux kernel is 3.10 so I probably don't have the latest and greatest driver.
When I booted I got an ARM alignment trap caused by the driver.
I determined the cause was the 1st argument to spin_lock_irqsave() has an unaligned address.
By trial-and-error I found that if I edit wifi.h and insert 2 dummy bytes into the rtl_priv struct just above priv (last variable) the locks work and the driver works fine.
What is the recommended way to make sure the last variable in the rtl_priv struct (u8 priv[0]) is aligned on a 4 byte boundary so the driver works on ARM machines?
Regards,
Jason
^ permalink raw reply
* [PATCH 3.12] ath9k: fix stale flag handling on buffer clone
From: Felix Fietkau @ 2013-09-14 13:46 UTC (permalink / raw)
To: linux-wireless; +Cc: linville
Fixes a regression from commit
"ath9k: shrink a few data structures by reordering fields"
When cloning a buffer, the stale flag (part of bf_state now) needs to be
reset after copying the state to prevent tx processing hangs.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 35b515f..a749e0f 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -399,6 +399,7 @@ static struct ath_buf* ath_clone_txbuf(struct ath_softc *sc, struct ath_buf *bf)
tbf->bf_buf_addr = bf->bf_buf_addr;
memcpy(tbf->bf_desc, bf->bf_desc, sc->sc_ah->caps.tx_desc_len);
tbf->bf_state = bf->bf_state;
+ tbf->bf_state.stale = false;
return tbf;
}
--
1.8.0.2
^ permalink raw reply related
* Re: guidance on struct alignment for rtl8192cu driver
From: Larry Finger @ 2013-09-14 14:08 UTC (permalink / raw)
To: Jason Andrews; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <985A2B0C3F73B74792F35D4098E1CA7CB143670E93@MAILSJ3.global.cadence.com>
On 09/14/2013 12:36 AM, Jason Andrews wrote:
> I'm using an ASUS USB N13 on an ARM platform with the rtl8192cu driver.
> Linux kernel is 3.10 so I probably don't have the latest and greatest driver.
>
> When I booted I got an ARM alignment trap caused by the driver.
>
> I determined the cause was the 1st argument to spin_lock_irqsave() has an unaligned address.
>
> By trial-and-error I found that if I edit wifi.h and insert 2 dummy bytes into the rtl_priv struct just above priv (last variable) the locks work and the driver works fine.
>
> What is the recommended way to make sure the last variable in the rtl_priv struct (u8 priv[0]) is aligned on a 4 byte boundary so the driver works on ARM machines?
There are a lot of improvements for this driver in 3.11. The backports release
has that code. In addition, I am currently working at improving the power
management for 3.13.
The presence of unaligned variables that cause alignment traps on ARM does not
surprise me as I test only on x86 and ppc architectures. I now own a Raspberry
Pi and I will soon be testing with it as well.
What does surprise me is that the first argument in all the calls to
spin_lock_irqsave() are contained within the rtl_locks struct and everything
there should be aligned. Perhaps some ARM expert will know why aligning the last
item in the rtl_priv struct fixes the problem.
As far as I know, the proper way to do a 4-byte alignment is as in the following
patch:
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/wifi.h
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/wifi.h
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/wifi.h
@@ -2057,7 +2057,7 @@ struct rtl_priv {
that it points to the data allocated
beyond this structure like:
rtl_pci_priv or rtl_usb_priv */
- u8 priv[0];
+ u8 __aligned(4) priv[0];
};
#define rtl_priv(hw) (((struct rtl_priv *)(hw)->priv))
Larry
^ permalink raw reply
* [PATCH 3.12] ath9k: do not link bf_next across multiple A-MPDUs
From: Felix Fietkau @ 2013-09-14 15:02 UTC (permalink / raw)
To: linux-wireless; +Cc: linville
This might trip up tx completion processing, although the condition that
triggers this should not (yet) occur in practice.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index a749e0f..5849960 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1951,7 +1951,9 @@ static void ath_tx_txqaddbuf(struct ath_softc *sc, struct ath_txq *txq,
if (bf_is_ampdu_not_probing(bf))
txq->axq_ampdu_depth++;
- bf = bf->bf_lastbf->bf_next;
+ bf_last = bf->bf_lastbf;
+ bf = bf_last->bf_next;
+ bf_last->bf_next = NULL;
}
}
}
--
1.8.0.2
^ permalink raw reply related
* rtl8192cu: notes on investigating power issues
From: Mark Cave-Ayland @ 2013-09-14 16:09 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
Hi Larry,
I spent some time yesterday evening adding various debugging statements
around the driver to get a feel for what was happening, with some
success. Included below are my notes from testing.
The key appears to be the calculation of the dig (transmitter gain?)
value, for which the function chain looks like this:
1) rtl92c_dm_ctrl_initgain_by_rssi() sets the dig value
This value controls the power output from the transmitter and should lie
between DM_DIG_MIN and DM_DIG_MAX (note the *higher* the number, the
*lower* the power output). Setting the penultimate line to read
"digtable->cur_igvalue = DM_DIG_MIN" appears to force maximum power and
actually gives me a working connection.
Displaying various values in this function showed that the problem was
that I had an exceptionally high value of digtable->rssi_val_min which
was much higher than DM_DIG_MAX and so had the effect of disabling the
radio.
2) rtl92c_dm_dynamic_bb_powersaving() sets digtable->rssi_val_min
This is actually done by a simple assignment "dm_pstable->rssi_val_min =
rtlpriv->dm.undec_sm_pwdb".
3) _rtl92c_process_pwdb() sets rltpriv->dm.undec_sm_pwdb
This value is updated by comparing the existing value with the current
value of pstats->rx_pwdb_all. If there is a difference, then slide the
new value towards pstats->rx_pwdb_all and then use it to update
rltpriv->dm.undec_sm_pwdb.
4) _rtl92c_query_rxphystatus() sets pstats->rx_pwdb_all
pstats->rx_pwdb_all was set to be a percentage conversion of the current
antenna power read from the radio.
What was happening in my case:
1) pstats->rx_pwdb_all was mostly set to 100 (%) due to high signal strength
2) rltpriv->dm.undec_sm_pwdb would then slide towards a high value
(around 0x40-0x4d) within a few seconds
3) Hence digtable->rssi_val_min would tend to hover at around the same level
4) digtable->cur_igvalue would be set to the same high value (> 0x3f or
DM_DIG_MAX), therefore disabling the radio and disconnecting from the AP
Unfortunately I'm not particularly familiar with these types of power
calculations (and there weren't many comments explaining how they
worked), but the one thing that didn't seem right is that
pstats->rx_pwdb_all claims to be a *percentage* and yet
rtl92c_dm_dynamic_bb_powersaving() uses it as the basis to set the
*value* of dm_pstable->rssi_val_min.
ATB,
Mark.
^ permalink raw reply
* Re: [PATCH 6/7] rtlwifi: Fix smatch warnings in usb.c
From: Sergei Shtylyov @ 2013-09-14 19:44 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, netdev
In-Reply-To: <1379094304-22041-7-git-send-email-Larry.Finger@lwfinger.net>
Hello.
On 09/13/2013 09:45 PM, Larry Finger wrote:
> Smatch displays the following:
> CHECK drivers/net/wireless/rtlwifi/usb.c
> drivers/net/wireless/rtlwifi/usb.c:458 _rtl_usb_rx_process_agg() warn: assigning (-98) to unsigned variable 'stats.noise'
> drivers/net/wireless/rtlwifi/usb.c:503 _rtl_usb_rx_process_noagg() warn: assigning (-98) to unsigned variable 'stats.noise'
> drivers/net/wireless/rtlwifi/usb.c:596 _rtl_rx_get_padding() info: ignoring unreachable code.
> drivers/net/wireless/rtlwifi/usb.c:596 _rtl_rx_get_padding() info: ignoring unreachable code.
> The negative number to an unsigned quantity is fixed by adding 256 to -98
> to get the equivalent negative number.
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> drivers/net/wireless/rtlwifi/usb.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
> diff --git a/drivers/net/wireless/rtlwifi/usb.c b/drivers/net/wireless/rtlwifi/usb.c
> index e56778c..9f3dcb8 100644
> --- a/drivers/net/wireless/rtlwifi/usb.c
> +++ b/drivers/net/wireless/rtlwifi/usb.c
[...]
> @@ -582,12 +582,15 @@ static void _rtl_rx_work(unsigned long param)
> static unsigned int _rtl_rx_get_padding(struct ieee80211_hdr *hdr,
> unsigned int len)
> {
> +#if NET_IP_ALIGN != 0
> unsigned int padding = 0;
> +#endif
>
> /* make function no-op when possible */
> - if (NET_IP_ALIGN == 0 || len < sizeof(*hdr))
> + if (NET_IP_ALIGN == 0 || len < sizeof(struct ieee80211_hdr))
Why this collateral and undocumented change? What does it achieve?
> return 0;
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/7] rtlwifi: rtl8192de: Fix smatch warnings in rtl8192de/hw.c
From: Sergei Shtylyov @ 2013-09-14 19:59 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, netdev
In-Reply-To: <1379094304-22041-3-git-send-email-Larry.Finger@lwfinger.net>
Hello.
On 09/13/2013 09:44 PM, Larry Finger wrote:
> Smatch lists the following:
> CHECK drivers/net/wireless/rtlwifi/rtl8192de/hw.c
> drivers/net/wireless/rtlwifi/rtl8192de/hw.c:1200 rtl92de_set_qos() info: ignoring unreachable code.
> drivers/net/wireless/rtlwifi/rtl8192de/hw.c:1200 rtl92de_set_qos() info: ignoring unreachable code.
> Dead code is removed.
It is instead commented out, including non-dead code it seems...
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> drivers/net/wireless/rtlwifi/rtl8192de/hw.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
> index 7dd8f6d..c9b0894 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
> @@ -1194,6 +1194,7 @@ void rtl92d_linked_set_reg(struct ieee80211_hw *hw)
> * mac80211 will send pkt when scan */
> void rtl92de_set_qos(struct ieee80211_hw *hw, int aci)
> {
> +/*
> struct rtl_priv *rtlpriv = rtl_priv(hw);
> rtl92d_dm_init_edca_turbo(hw);
> return;
Shouldn't the comment start here (and *return* removed)? It's also
better to remove the dead code than just to comment it out.
> @@ -1213,6 +1214,7 @@ void rtl92de_set_qos(struct ieee80211_hw *hw, int aci)
> RT_ASSERT(false, "invalid aci: %d !\n", aci);
> break;
> }
> + */
> }
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 6/7] rtlwifi: Fix smatch warnings in usb.c
From: Larry Finger @ 2013-09-14 20:26 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linville, linux-wireless, netdev
In-Reply-To: <5234BCB6.6050508@cogentembedded.com>
On 09/14/2013 02:44 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 09/13/2013 09:45 PM, Larry Finger wrote:
>
>> Smatch displays the following:
>> CHECK drivers/net/wireless/rtlwifi/usb.c
>> drivers/net/wireless/rtlwifi/usb.c:458 _rtl_usb_rx_process_agg() warn:
>> assigning (-98) to unsigned variable 'stats.noise'
>> drivers/net/wireless/rtlwifi/usb.c:503 _rtl_usb_rx_process_noagg() warn:
>> assigning (-98) to unsigned variable 'stats.noise'
>> drivers/net/wireless/rtlwifi/usb.c:596 _rtl_rx_get_padding() info: ignoring
>> unreachable code.
>> drivers/net/wireless/rtlwifi/usb.c:596 _rtl_rx_get_padding() info: ignoring
>> unreachable code.
>
>> The negative number to an unsigned quantity is fixed by adding 256 to -98
>> to get the equivalent negative number.
>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> ---
>> drivers/net/wireless/rtlwifi/usb.c | 10 +++++++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>
>> diff --git a/drivers/net/wireless/rtlwifi/usb.c
>> b/drivers/net/wireless/rtlwifi/usb.c
>> index e56778c..9f3dcb8 100644
>> --- a/drivers/net/wireless/rtlwifi/usb.c
>> +++ b/drivers/net/wireless/rtlwifi/usb.c
> [...]
>> @@ -582,12 +582,15 @@ static void _rtl_rx_work(unsigned long param)
>> static unsigned int _rtl_rx_get_padding(struct ieee80211_hdr *hdr,
>> unsigned int len)
>> {
>> +#if NET_IP_ALIGN != 0
>> unsigned int padding = 0;
>> +#endif
>>
>> /* make function no-op when possible */
>> - if (NET_IP_ALIGN == 0 || len < sizeof(*hdr))
>> + if (NET_IP_ALIGN == 0 || len < sizeof(struct ieee80211_hdr))
>
> Why this collateral and undocumented change? What does it achieve?
>
>> return 0;
It does not change a thing. Further up the code is "struct ieee80211_hdr *hdr".
This change was one I tried during the fixes, and I forgot to remove it.
Larry
^ permalink raw reply
* Re: [PATCH 2/7] rtlwifi: rtl8192de: Fix smatch warnings in rtl8192de/hw.c
From: Larry Finger @ 2013-09-14 20:30 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linville, linux-wireless, netdev
In-Reply-To: <5234C03A.2070701@cogentembedded.com>
On 09/14/2013 02:59 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 09/13/2013 09:44 PM, Larry Finger wrote:
>
>> Smatch lists the following:
>> CHECK drivers/net/wireless/rtlwifi/rtl8192de/hw.c
>> drivers/net/wireless/rtlwifi/rtl8192de/hw.c:1200 rtl92de_set_qos() info:
>> ignoring unreachable code.
>> drivers/net/wireless/rtlwifi/rtl8192de/hw.c:1200 rtl92de_set_qos() info:
>> ignoring unreachable code.
>
>> Dead code is removed.
>
> It is instead commented out, including non-dead code it seems...
>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> ---
>> drivers/net/wireless/rtlwifi/rtl8192de/hw.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
>> b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
>> index 7dd8f6d..c9b0894 100644
>> --- a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
>> +++ b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
>> @@ -1194,6 +1194,7 @@ void rtl92d_linked_set_reg(struct ieee80211_hw *hw)
>> * mac80211 will send pkt when scan */
>> void rtl92de_set_qos(struct ieee80211_hw *hw, int aci)
>> {
>> +/*
>> struct rtl_priv *rtlpriv = rtl_priv(hw);
>> rtl92d_dm_init_edca_turbo(hw);
>> return;
>
> Shouldn't the comment start here (and *return* removed)? It's also
> better to remove the dead code than just to comment it out.
That would leave some unused variables.
>> @@ -1213,6 +1214,7 @@ void rtl92de_set_qos(struct ieee80211_hw *hw, int aci)
>> RT_ASSERT(false, "invalid aci: %d !\n", aci);
>> break;
>> }
>> + */
>> }
I'm not sure what that unreachable code might do, thus I saved it as a comment
for possible future use. I need to do further evaluation on this fragment, and
probably consult with the Realtek engineers.
Larry
^ permalink raw reply
* mac80211 and kernel 3.8.13 1/2 speed as with madwifi and kernel 2.6.23
From: Beat Meier @ 2013-09-14 20:38 UTC (permalink / raw)
To: linux-wireless
Hello
I'm trying to use again mac driver instead of old madwifi driver for
atheros cards.
I have following problem.
On Clients using mac80211 (wpa_supplicant) it's just fine but if you use
it with hostapd you have about 1/2 speed
as with madwifi. Problem could be also kernel<->wireless driver issue.
With madwifi I'm using an old kernel 2.6.23 (voyage-0.5 distribution)
and with mac80211 a new kernel 3.8.13 (voyage-0.9.1)
Example:
5.5km 5.8GHz link 2xAlix board, 2xWLM54AGP23 card, 2x Hyperlink 27dbi
grids, wireless card speed set to 24M
to get max. signal on this cards...
Signal on both sites is -60
With madwifi driver on both site you get 12.8Mbps/14.5Mbps download/upload
madwifi driver on server, mac80211 on client you still get 13.4/13.8Mbps
BUT if you use mac80211 on ap master mode with hostap you get only
7Mbps/5.5Mbps.
Tried all 4 constellation (old/new, new/old, new/new and old/old) and
the issue is only
if the hostapt is running with new kernel/mac80211
Same stuff on other links with other cards like CM9.
What I have seen is that with madwifi driver the cpu is 90-100% cpu
usage with ksoftirqd
with mac80211 not...
Could this be a kernel interrupt issue? Are there several policies which
changed with kernel?
Anyone having same issue?
Greetings and thanks
^ permalink raw reply
* mac80211 and kernel 3.8.13 1/2 speed as with madwifi and kernel 2.6.23
From: Beat Meier @ 2013-09-14 20:38 UTC (permalink / raw)
To: linux-wireless
Hello
I'm trying to use again mac driver instead of old madwifi driver for
atheros cards.
I have following problem.
On Clients using mac80211 (wpa_supplicant) it's just fine but if you use
it with hostapd you have about 1/2 speed
as with madwifi. Problem could be also kernel<->wireless driver issue.
With madwifi I'm using an old kernel 2.6.23 (voyage-0.5 distribution)
and with mac80211 a new kernel 3.8.13 (voyage-0.9.1)
Example:
5.5km 5.8GHz link 2xAlix board, 2xWLM54AGP23 card, 2x Hyperlink 27dbi
grids, wireless card speed set to 24M
to get max. signal on this cards...
Signal on both sites is -60
With madwifi driver on both site you get 12.8Mbps/14.5Mbps download/upload
madwifi driver on server, mac80211 on client you still get 13.4/13.8Mbps
BUT if you use mac80211 on ap master mode with hostap you get only
7Mbps/5.5Mbps.
Tried all 4 constellation (old/new, new/old, new/new and old/old) and
the issue is only
if the hostapt is running with new kernel/mac80211
Same stuff on other links with other cards like CM9.
What I have seen is that with madwifi driver the cpu is 90-100% cpu
usage with ksoftirqd
with mac80211 not...
Could this be a kernel interrupt issue? Are there several policies which
changed with kernel?
Anyone having same issue?
Greetings and thanks
^ permalink raw reply
* Re: [PATCH 07/12] wireless: wil6210: remove unnecessary pci_set_drvdata()
From: Vladimir Kondratiev @ 2013-09-15 7:46 UTC (permalink / raw)
To: Jingoo Han; +Cc: 'John W. Linville', linux-wireless, wil6210
In-Reply-To: <00b801ceae18$8e5498c0$aafdca40$%han@samsung.com>
On Tuesday, September 10, 2013 08:26:13 PM Jingoo Han wrote:
> The driver core clears the driver data to NULL after device_release
> or on probe failure. Thus, it is not needed to manually clear the
> device driver data to NULL.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> ---
> drivers/net/wireless/ath/wil6210/pcie_bus.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/wil6210/pcie_bus.c b/drivers/net/wireless/ath/wil6210/pcie_bus.c
> index eb1dc7a..eeceab3 100644
> --- a/drivers/net/wireless/ath/wil6210/pcie_bus.c
> +++ b/drivers/net/wireless/ath/wil6210/pcie_bus.c
> @@ -197,7 +197,6 @@ static void wil_pcie_remove(struct pci_dev *pdev)
> pci_iounmap(pdev, wil->csr);
> pci_release_region(pdev, 0);
> pci_disable_device(pdev);
> - pci_set_drvdata(pdev, NULL);
> }
>
> static DEFINE_PCI_DEVICE_TABLE(wil6210_pcie_ids) = {
>
Here is my
Acked-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Olivier Reuland @ 2013-09-15 8:17 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <522DFF83.6000605@lwfinger.net>
Hi,
I'm facing the same issue with a slightly different device: "ID 0b05:17ab
ASUSTek Computer, Inc. USB-N13 802.11n Network Adapter (rev. B1) [Realtek
RTL8192CU]". I'm also using Ubuntu, Saucy: "Linux desktop 3.11.0-7-generic
#13-Ubuntu SMP Tue Sep 10 20:55:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux".
Sep 15 19:59:07 desktop NetworkManager[791]: <info> Config: added 'ssid'
value 'MyWiFi'
Sep 15 19:59:07 desktop NetworkManager[791]: <info> Config: added
'scan_ssid' value '1'
Sep 15 19:59:07 desktop NetworkManager[791]: <info> Config: added 'key_mgmt'
value 'WPA-PSK'
Sep 15 19:59:07 desktop NetworkManager[791]: <info> Config: added 'psk'
value '<omitted>'
Disconnect/reconnect cycle every 20-30 seconds.
Disconnect to fail every few minutes.
Sep 15 20:07:18 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associated -> 4-way handshake
Sep 15 20:07:19 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: 4-way handshake -> completed
Sep 15 20:07:50 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: completed -> disconnected
Sep 15 20:07:50 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: disconnected -> scanning
Sep 15 20:07:50 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: scanning -> authenticating
Sep 15 20:07:50 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: authenticating -> associating
Sep 15 20:07:51 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associating -> associated
Sep 15 20:07:51 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associated -> 4-way handshake
Sep 15 20:07:52 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: 4-way handshake -> completed
Sep 15 20:08:02 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: completed -> disconnected
Sep 15 20:08:02 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: disconnected -> scanning
Sep 15 20:08:02 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: scanning -> authenticating
Sep 15 20:08:03 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: authenticating -> disconnected
Sep 15 20:08:03 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: disconnected -> scanning
Sep 15 20:08:04 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: scanning -> authenticating
Sep 15 20:08:04 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: authenticating -> associating
Sep 15 20:08:04 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associating -> associated
Sep 15 20:08:04 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associated -> 4-way handshake
Sep 15 20:08:16 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: 4-way handshake -> disconnected
Sep 15 20:08:16 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: disconnected -> inactive
[FAILED JUST HERE]
Sep 15 20:08:29 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: inactive -> scanning
Sep 15 20:08:29 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: scanning -> authenticating
Sep 15 20:08:30 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: authenticating -> associating
Sep 15 20:08:30 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associating -> associated
Sep 15 20:08:30 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associated -> 4-way handshake
Sep 15 20:08:30 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: 4-way handshake -> completed
Sep 15 20:09:06 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: completed -> disconnected
Sep 15 20:09:06 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: disconnected -> scanning
Sep 15 20:09:07 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: scanning -> authenticating
Sep 15 20:09:07 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: authenticating -> associating
Sep 15 20:09:07 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associating -> associated
Sep 15 20:09:07 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associated -> 4-way handshake
Sep 15 20:09:07 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: 4-way handshake -> completed
Sep 15 20:09:26 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: completed -> disconnected
Sep 15 20:09:26 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: disconnected -> scanning
Sep 15 20:09:27 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: scanning -> authenticating
Sep 15 20:09:27 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: authenticating -> disconnected
Sep 15 20:09:27 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: disconnected -> scanning
Sep 15 20:09:28 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: scanning -> authenticating
Sep 15 20:09:28 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: authenticating -> disconnected
Sep 15 20:09:28 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: disconnected -> scanning
Sep 15 20:09:35 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: scanning -> authenticating
Sep 15 20:09:35 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: authenticating -> associating
Sep 15 20:09:35 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associating -> associated
Sep 15 20:09:35 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associated -> 4-way handshake
Sep 15 20:09:35 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: 4-way handshake -> completed
Sep 15 20:09:42 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: completed -> disconnected
Sep 15 20:09:42 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: disconnected -> scanning
Sep 15 20:09:43 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: scanning -> authenticating
Sep 15 20:09:43 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: authenticating -> disconnected
Sep 15 20:09:43 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: disconnected -> scanning
Sep 15 20:09:44 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: scanning -> authenticating
Sep 15 20:09:44 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: authenticating -> associating
Sep 15 20:09:44 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associating -> associated
Sep 15 20:09:44 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associated -> 4-way handshake
Sep 15 20:09:44 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: 4-way handshake -> completed
Sep 15 20:09:58 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: completed -> disconnected
Sep 15 20:09:58 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: disconnected -> scanning
Sep 15 20:09:59 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: scanning -> authenticating
Sep 15 20:09:59 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: authenticating -> disconnected
Sep 15 20:09:59 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: disconnected -> scanning
Sep 15 20:10:00 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: scanning -> authenticating
Sep 15 20:10:00 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: authenticating -> associating
Sep 15 20:10:00 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associating -> associated
Sep 15 20:10:00 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associated -> 4-way handshake
Sep 15 20:10:00 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: 4-way handshake -> completed
Sep 15 20:10:16 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: completed -> disconnected
Sep 15 20:10:16 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: disconnected -> scanning
Sep 15 20:10:17 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: scanning -> authenticating
Sep 15 20:10:17 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: authenticating -> disconnected
Sep 15 20:10:17 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: disconnected -> scanning
Sep 15 20:10:24 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: scanning -> authenticating
Sep 15 20:10:24 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: authenticating -> associating
Sep 15 20:10:24 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associating -> associated
Sep 15 20:10:24 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: associated -> 4-way handshake
Sep 15 20:10:30 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: 4-way handshake -> disconnected
Sep 15 20:10:30 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: disconnected -> inactive
[FAILS AGAIN HERE]
The interesting part is probably:
Sep 15 20:10:30 desktop kernel: [ 4778.434695] wlan0: Connection to AP
9c:c7:a6:1c:dc:a5 lost
Sep 15 20:10:30 desktop wpa_supplicant[6415]: wlan0: WPA: 4-Way Handshake
failed - pre-shared key may be incorrect
Sep 15 20:10:30 desktop wpa_supplicant[6415]: wlan0: CTRL-EVENT-DISCONNECTED
bssid=9c:c7:a6:1c:dc:a5 reason=4
Sep 15 20:10:30 desktop kernel: [ 4778.454580] cfg80211: Calling CRDA to
update world regulatory domain
Sep 15 20:10:30 desktop NetworkManager[791]: <info> (wlan0): supplicant
interface state: 4-way handshake -> disconnected
Sep 15 20:10:30 desktop NetworkManager[791]: <info> Activation
(wlan0/wireless): disconnected during association, asking for new key.
Sep 15 20:10:30 desktop NetworkManager[791]: <info> (wlan0): device state
change: activated -> need-auth (reason 'supplicant-disconnect') [100 60 8]
Let me know if there is anything I can do to help
Olivier
^ permalink raw reply
* RE: [Ilw] [RFC 0/5] mac80211/iwlwifi: quiesce before restart hw
From: Grumbach, Emmanuel @ 2013-09-15 8:31 UTC (permalink / raw)
To: Stanislaw Gruszka, ilw@linux.intel.com; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1379068568-27552-1-git-send-email-sgruszka@redhat.com>
> Here is continuation of short discussion I started here:
> http://marc.info/?l=linux-wireless&m=137724899704012&w=2
>
> I made patches which do quiesce and that can be used by iwlwifi restart
> procedure to avoid calling iwlwifi methods by mac80211 while firmware is not
> alive.
>
> But honestly, I'm not happy with that work. It does not fix root of the
> problem (microcode errors/hangs) and seems to be just to much
> complication to avoid warnings, which are consequence of firmware
> malfunction. So I just prefer to remove WARN_ONCE(trans->state !=
> IWL_TRANS_FW_ALIVE) and replace it by ordinary IWL_WARN(), which does
> not generate auto bug reports.
>
> Regarding firmware problems debugging, perhaps ftrace can be used for
> that. iwlwifi has already tracing capabilities. Allow to gather log using trace-
> cmd and call tracing_off() when firmware error will happen, perhaps will
> allow to debug firmware problems efficiently.
> If you think that's right we could add WARN_ONCE on firmware error to have
> automatic bug reports. Then we could ask user for the trace to debug and
> solve the issue. Would that work for you?
>
Yes - definitely. We have enough debug information in place in other places. Patch is coming (will go through regular tunnel).
BTW - I guess a dump_stack doesn't trigger the abrt, does it?
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Larry Finger @ 2013-09-15 13:50 UTC (permalink / raw)
To: Olivier Reuland; +Cc: linux-wireless
In-Reply-To: <loom.20130915T101439-276@post.gmane.org>
On 09/15/2013 03:17 AM, Olivier Reuland wrote:
> Hi,
>
> I'm facing the same issue with a slightly different device: "ID 0b05:17ab
> ASUSTek Computer, Inc. USB-N13 802.11n Network Adapter (rev. B1) [Realtek
> RTL8192CU]". I'm also using Ubuntu, Saucy: "Linux desktop 3.11.0-7-generic
> #13-Ubuntu SMP Tue Sep 10 20:55:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux".
--snip--
>
> Let me know if there is anything I can do to help
There is a known problem with the dynamic power management code for this chip.
Unfortunately, the problem does not affect my system. At the moment, my device
that uses rtl8192cu has been connected for 12 hours with no disconnects. The
only evidence of a bug here is poor performance.
Please describe your setup. What AP are you using? Is it an 802.11n or an
802.11g connection? How far is your station from the AP? Are there any obstacles
such as walls in the way? What is the signal strength as shown by iwconfig?
Larry
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Mark Cave-Ayland @ 2013-09-15 17:48 UTC (permalink / raw)
To: Larry Finger; +Cc: Olivier Reuland, linux-wireless
In-Reply-To: <5235BB3B.5030800@lwfinger.net>
On 15/09/13 14:50, Larry Finger wrote:
> There is a known problem with the dynamic power management code for this
> chip. Unfortunately, the problem does not affect my system. At the
> moment, my device that uses rtl8192cu has been connected for 12 hours
> with no disconnects. The only evidence of a bug here is poor performance.
Did my email to the list yesterday provide any further clues at all? I
know that you're looking at re-working the power code, but if there is
any chance of a stop-gap fix for 3.12 then I know it would be greatly
appreciated :)
ATB,
Mark.
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Larry Finger @ 2013-09-15 20:26 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: Olivier Reuland, linux-wireless
In-Reply-To: <5235F2D0.6090505@ilande.co.uk>
On 09/15/2013 12:48 PM, Mark Cave-Ayland wrote:
> On 15/09/13 14:50, Larry Finger wrote:
>
>> There is a known problem with the dynamic power management code for this
>> chip. Unfortunately, the problem does not affect my system. At the
>> moment, my device that uses rtl8192cu has been connected for 12 hours
>> with no disconnects. The only evidence of a bug here is poor performance.
>
> Did my email to the list yesterday provide any further clues at all? I know that
> you're looking at re-working the power code, but if there is any chance of a
> stop-gap fix for 3.12 then I know it would be greatly appreciated :)
Yes, you provided some clues, but as I have no knowledge of the internal
workings of the chips, I dare not set parameters willy-nilly as that might cause
chips to burn out and fail.
The vendor driver provides better performance for my device than does rtl8192cu.
I would provide the patches needed to compile it on a modern kernel; however, it
causes a kernel panic whenever you try to unload it. I have no time nor
inclination to debug that. Thus no one should use it unless you want to fix that
problem.
I am trying to change the in-kernel dm code to match the vendor driver. That is
difficult as nearly every variable is renamed.
Any patches will be pushed when they are ready, and not before. I will, however,
provide them for testing. It remains to be seen if any such patches will be
suitable for 3.12 and backporting to 3.11.
Larry
^ permalink raw reply
* iwlwifi (5100 AGN) AP mode (experimental?)
From: Niccolò Belli @ 2013-09-15 20:33 UTC (permalink / raw)
To: linux-wireless; +Cc: ilw
Hi,
I read[1] iwlwifi should have experimental support for AP mode.
Unfortunately ap mode isn't listed:
laptop ~ # iw list | grep -i ap
Capabilities: 0x1072
Capabilities: 0x1072
* start_ap
* set_noack_map
* AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80
0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70
0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
HT Capability overrides:
Do I need a special firmware/kernel version? I'm using 3.11.0 and
linux-firmware-20130728.
Thanks,
Niccolò
[1]http://wireless.kernel.org/en/users/Drivers/iwlwifi
--
http://www.linuxsystems.it
^ permalink raw reply
* [PATCH 1/3] ath9k: Fix NF calibration for single stream cards
From: Sujith Manoharan @ 2013-09-16 5:06 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Rather than using the chip ID to read only chain-0 CCA
registers and avoid reading chain-1, use the RX chainmask
instead. There are some 1-stream PCI devices based on AR9287
such as TL-WN751ND. Improper NF calibration might result in
DMA errors/timeouts.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.c b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
index 7a5569b..17970d4 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
@@ -485,7 +485,7 @@ static void ar9002_hw_do_getnf(struct ath_hw *ah,
if (IS_CHAN_HT40(ah->curchan))
nfarray[3] = sign_extend32(nf, 8);
- if (AR_SREV_9285(ah) || AR_SREV_9271(ah))
+ if (!(ah->rxchainmask & BIT(1)))
return;
nf = MS(REG_READ(ah, AR_PHY_CH1_CCA), AR9280_PHY_CH1_MINCCA_PWR);
--
1.8.4
^ permalink raw reply related
* [PATCH 2/3] ath9k: Handle FATAL interrupts correctly
From: Sujith Manoharan @ 2013-09-16 5:07 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1379308021-20891-1-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
When a FATAL interrupt is received, a full chip reset is
required, which is done in the main tasklet. But since
the reset routine is scheduled as a work item, make sure
that interrupts are not enabled in the tasklet before the
reset is done.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/main.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index e4f6590..cdb3b1e 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -362,6 +362,13 @@ void ath9k_tasklet(unsigned long data)
type = RESET_TYPE_BB_WATCHDOG;
ath9k_queue_reset(sc, type);
+
+ /*
+ * Increment the ref. counter here so that
+ * interrupts are enabled in the reset routine.
+ */
+ atomic_inc(&ah->intr_ref_cnt);
+ ath_dbg(common, ANY, "FATAL: Skipping interrupts\n");
goto out;
}
@@ -400,10 +407,9 @@ void ath9k_tasklet(unsigned long data)
ath9k_btcoex_handle_interrupt(sc, status);
-out:
/* re-enable hardware interrupt */
ath9k_hw_enable_interrupts(ah);
-
+out:
spin_unlock(&sc->sc_pcu_lock);
ath9k_ps_restore(sc);
}
--
1.8.4
^ permalink raw reply related
* [PATCH 3/3] ath9k: Remove incorrect diversity initialization
From: Sujith Manoharan @ 2013-09-16 5:07 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1379308021-20891-1-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Fast antenna diversity is required only for single chain
chips and the diversity initialization is done in the
per-family board setup routines. Enabling of diversity
should be done based on the calibrated EEPROM/OTP data,
doing it for all chips is incorrect.
Remove the code that sets the fast_div bit for all cards, since
the documentation for the AR_PHY_CCK_DETECT register says:
reg 642: sig_detect_cck
enable_ant_fast_div : Only used for single chain chips.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 3 ---
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
index 9e4e2a6..cb6435e 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
@@ -631,9 +631,6 @@ static void ar5008_hw_override_ini(struct ath_hw *ah,
REG_WRITE(ah, AR_PCU_MISC_MODE2, val);
}
- REG_SET_BIT(ah, AR_PHY_CCK_DETECT,
- AR_PHY_CCK_DETECT_BB_ENABLE_ANT_FAST_DIV);
-
if (AR_SREV_9280_20_OR_LATER(ah))
return;
/*
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index ec37213..0131ba2 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -632,9 +632,6 @@ static void ar9003_hw_override_ini(struct ath_hw *ah)
AR_PCU_MISC_MODE2_CFP_IGNORE;
REG_WRITE(ah, AR_PCU_MISC_MODE2, val);
- REG_SET_BIT(ah, AR_PHY_CCK_DETECT,
- AR_PHY_CCK_DETECT_BB_ENABLE_ANT_FAST_DIV);
-
if (AR_SREV_9462(ah) || AR_SREV_9565(ah)) {
REG_WRITE(ah, AR_GLB_SWREG_DISCONT_MODE,
AR_GLB_SWREG_DISCONT_EN_BT_WLAN);
--
1.8.4
^ permalink raw reply related
* [PATCH] ath9k: Fix regression in LNA diversity
From: Sujith Manoharan @ 2013-09-16 5:57 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, stable
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
The commit "ath9k: Optimize LNA check" tried
to use the "rs_firstaggr" flag to optimize the LNA
combining algorithm when processing subframes in
an A-MPDU. This doesn't appear to work well in practice,
so revert it and use the old method of relying on
"rs_moreaggr".
Cc: stable@vger.kernel.org
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 4ee472a..ab9e3a8 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1270,13 +1270,6 @@ static void ath9k_antenna_check(struct ath_softc *sc,
return;
/*
- * All MPDUs in an aggregate will use the same LNA
- * as the first MPDU.
- */
- if (rs->rs_isaggr && !rs->rs_firstaggr)
- return;
-
- /*
* Change the default rx antenna if rx diversity
* chooses the other antenna 3 times in a row.
*/
--
1.8.4
^ permalink raw reply related
* ath9k pending patches
From: Sujith Manoharan @ 2013-09-16 6:04 UTC (permalink / raw)
To: linux-wireless; +Cc: John Linville
Hi,
Stable patches (includes Felix's TX fixes):
http://msujith.org/patches/wl/Sep-16-2013/ath9k-pending-stable.patch
Patches for -next:
http://msujith.org/patches/wl/Sep-16-2013/ath9k-pending-next.patch
Sujith
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox