[PATCH 1/3] ath10k: fix calibration init sequence of qca99x0

[PATCH 1/3] ath10k: fix calibration init sequence of qca99x0

[Rajkumar Manoharan]

pre-calibration is meant for qca4019 which contains only caldata
whereas calibration file is used by ar9888 and qca99x0 that contains
both board data and caldata. So by definition both pre-cal-file and
cal-file can not coexist. Keeping them in shared memory (union), is
breaking boot sequence of qca99x0. Fix it by storing both binaries
in separate memories. This issue is reported in ipq8064 platform which
includes caldata in flash memory.

Reported-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.h | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index b6c157e..a7d04bc 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -725,10 +725,8 @@ struct ath10k {
 	const void *firmware_data;
 	size_t firmware_len;
 
-	union {
-		const struct firmware *pre_cal_file;
-		const struct firmware *cal_file;
-	};
+	const struct firmware *pre_cal_file;
+	const struct firmware *cal_file;
 
 	struct {
 		const void *firmware_codeswap_data;
-- 
2.7.4

[PATCH 1/3] ath10k: fix calibration init sequence of qca99x0

[Rajkumar Manoharan]

pre-calibration is meant for qca4019 which contains only caldata
whereas calibration file is used by ar9888 and qca99x0 that contains
both board data and caldata. So by definition both pre-cal-file and
cal-file can not coexist. Keeping them in shared memory (union), is
breaking boot sequence of qca99x0. Fix it by storing both binaries
in separate memories. This issue is reported in ipq8064 platform which
includes caldata in flash memory.

Reported-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.h | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index b6c157e..a7d04bc 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -725,10 +725,8 @@ struct ath10k {
 	const void *firmware_data;
 	size_t firmware_len;
 
-	union {
-		const struct firmware *pre_cal_file;
-		const struct firmware *cal_file;
-	};
+	const struct firmware *pre_cal_file;
+	const struct firmware *cal_file;
 
 	struct {
 		const void *firmware_codeswap_data;
-- 
2.7.4


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH 2/3] ath10k: remove unnecessary warning for probe response drops

[Rajkumar Manoharan]

qca99x0 and qca4019 solutions limit probe responses transmissions.
Logging warning message for each probe response drop is flooding
kernel log unnecessary with " failed to increase tx mgmt pending
count: -16, dropping". Hence reducing log level to debug.

Reported-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index ed00853..a7aafb35c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3994,8 +3994,8 @@ static void ath10k_mac_op_tx(struct ieee80211_hw *hw,
 
 		ret = ath10k_htt_tx_mgmt_inc_pending(htt, is_mgmt, is_presp);
 		if (ret) {
-			ath10k_warn(ar, "failed to increase tx mgmt pending count: %d, dropping\n",
-				    ret);
+			ath10k_dbg(ar, ATH10K_DBG_MAC, "failed to increase tx mgmt pending count: %d, dropping\n",
+				   ret);
 			ath10k_htt_tx_dec_pending(htt);
 			spin_unlock_bh(&ar->htt.tx_lock);
 			ieee80211_free_txskb(ar->hw, skb);
-- 
2.7.4

[PATCH 2/3] ath10k: remove unnecessary warning for probe response drops

[Rajkumar Manoharan]

qca99x0 and qca4019 solutions limit probe responses transmissions.
Logging warning message for each probe response drop is flooding
kernel log unnecessary with " failed to increase tx mgmt pending
count: -16, dropping". Hence reducing log level to debug.

Reported-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index ed00853..a7aafb35c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3994,8 +3994,8 @@ static void ath10k_mac_op_tx(struct ieee80211_hw *hw,
 
 		ret = ath10k_htt_tx_mgmt_inc_pending(htt, is_mgmt, is_presp);
 		if (ret) {
-			ath10k_warn(ar, "failed to increase tx mgmt pending count: %d, dropping\n",
-				    ret);
+			ath10k_dbg(ar, ATH10K_DBG_MAC, "failed to increase tx mgmt pending count: %d, dropping\n",
+				   ret);
 			ath10k_htt_tx_dec_pending(htt);
 			spin_unlock_bh(&ar->htt.tx_lock);
 			ieee80211_free_txskb(ar->hw, skb);
-- 
2.7.4


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 2/3] ath10k: remove unnecessary warning for probe response drops

[Ben Greear]

On 03/30/2016 08:42 AM, Rajkumar Manoharan wrote:
> qca99x0 and qca4019 solutions limit probe responses transmissions.
> Logging warning message for each probe response drop is flooding
> kernel log unnecessary with " failed to increase tx mgmt pending
> count: -16, dropping". Hence reducing log level to debug.

Is there any realistic way to see this message if we are not running
many vAP on one radio?

I guess many probe requests or other management frames could also
cause this problem?

Thanks,
Ben

> Reported-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
> ---
>   drivers/net/wireless/ath/ath10k/mac.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index ed00853..a7aafb35c 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -3994,8 +3994,8 @@ static void ath10k_mac_op_tx(struct ieee80211_hw *hw,
>
>   		ret = ath10k_htt_tx_mgmt_inc_pending(htt, is_mgmt, is_presp);
>   		if (ret) {
> -			ath10k_warn(ar, "failed to increase tx mgmt pending count: %d, dropping\n",
> -				    ret);
> +			ath10k_dbg(ar, ATH10K_DBG_MAC, "failed to increase tx mgmt pending count: %d, dropping\n",
> +				   ret);
>   			ath10k_htt_tx_dec_pending(htt);
>   			spin_unlock_bh(&ar->htt.tx_lock);
>   			ieee80211_free_txskb(ar->hw, skb);
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH 2/3] ath10k: remove unnecessary warning for probe response drops

[Ben Greear]

On 03/30/2016 08:42 AM, Rajkumar Manoharan wrote:
> qca99x0 and qca4019 solutions limit probe responses transmissions.
> Logging warning message for each probe response drop is flooding
> kernel log unnecessary with " failed to increase tx mgmt pending
> count: -16, dropping". Hence reducing log level to debug.

Is there any realistic way to see this message if we are not running
many vAP on one radio?

I guess many probe requests or other management frames could also
cause this problem?

Thanks,
Ben

> Reported-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
> ---
>   drivers/net/wireless/ath/ath10k/mac.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index ed00853..a7aafb35c 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -3994,8 +3994,8 @@ static void ath10k_mac_op_tx(struct ieee80211_hw *hw,
>
>   		ret = ath10k_htt_tx_mgmt_inc_pending(htt, is_mgmt, is_presp);
>   		if (ret) {
> -			ath10k_warn(ar, "failed to increase tx mgmt pending count: %d, dropping\n",
> -				    ret);
> +			ath10k_dbg(ar, ATH10K_DBG_MAC, "failed to increase tx mgmt pending count: %d, dropping\n",
> +				   ret);
>   			ath10k_htt_tx_dec_pending(htt);
>   			spin_unlock_bh(&ar->htt.tx_lock);
>   			ieee80211_free_txskb(ar->hw, skb);
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 2/3] ath10k: remove unnecessary warning for probe response drops

[Rajkumar Manoharan]

On 2016-03-31 22:27, Ben Greear wrote:
> On 03/30/2016 08:42 AM, Rajkumar Manoharan wrote:
>> qca99x0 and qca4019 solutions limit probe responses transmissions.
>> Logging warning message for each probe response drop is flooding
>> kernel log unnecessary with " failed to increase tx mgmt pending
>> count: -16, dropping". Hence reducing log level to debug.
> 
> Is there any realistic way to see this message if we are not running
> many vAP on one radio?
> 
As of now this message can be seen only with qca99x0 which has 24 as 
max_probe_resp_desc_thres. Only possible way in single vAP is that in 
congested environment when DUT is receiving probe requests more 
frequently.

> I guess many probe requests or other management frames could also
> cause this problem?
> 
Exactly.

-Rajkumar

Re: [PATCH 2/3] ath10k: remove unnecessary warning for probe response drops

[Rajkumar Manoharan]

On 2016-03-31 22:27, Ben Greear wrote:
> On 03/30/2016 08:42 AM, Rajkumar Manoharan wrote:
>> qca99x0 and qca4019 solutions limit probe responses transmissions.
>> Logging warning message for each probe response drop is flooding
>> kernel log unnecessary with " failed to increase tx mgmt pending
>> count: -16, dropping". Hence reducing log level to debug.
> 
> Is there any realistic way to see this message if we are not running
> many vAP on one radio?
> 
As of now this message can be seen only with qca99x0 which has 24 as 
max_probe_resp_desc_thres. Only possible way in single vAP is that in 
congested environment when DUT is receiving probe requests more 
frequently.

> I guess many probe requests or other management frames could also
> cause this problem?
> 
Exactly.

-Rajkumar

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH 3/3] ath10k: fix unconditional num_mpdus_ready subtraction

[Rajkumar Manoharan]

Decrement num_mpdus_ready only when rx amsdu is processed successfully.
Not doing so, will result in leak and impact stabilty under low memory
cases.

Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 96a7417..9696c2e 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2412,14 +2412,12 @@ static void ath10k_htt_txrx_compl_task(unsigned long ptr)
 	struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
 	struct ath10k *ar = htt->ar;
 	struct htt_tx_done tx_done = {};
-	struct sk_buff_head rx_q;
 	struct sk_buff_head rx_ind_q;
 	struct sk_buff_head tx_ind_q;
 	struct sk_buff *skb;
 	unsigned long flags;
 	int num_mpdus;
 
-	__skb_queue_head_init(&rx_q);
 	__skb_queue_head_init(&rx_ind_q);
 	__skb_queue_head_init(&tx_ind_q);
 
@@ -2448,11 +2446,13 @@ static void ath10k_htt_txrx_compl_task(unsigned long ptr)
 	ath10k_mac_tx_push_pending(ar);
 
 	num_mpdus = atomic_read(&htt->num_mpdus_ready);
-	atomic_sub(num_mpdus, &htt->num_mpdus_ready);
 
-	while (num_mpdus--) {
+	while (num_mpdus) {
 		if (ath10k_htt_rx_handle_amsdu(htt))
 			break;
+
+		num_mpdus--;
+		atomic_dec(&htt->num_mpdus_ready);
 	}
 
 	while ((skb = __skb_dequeue(&rx_ind_q))) {
-- 
2.7.4

[PATCH 3/3] ath10k: fix unconditional num_mpdus_ready subtraction

[Rajkumar Manoharan]

Decrement num_mpdus_ready only when rx amsdu is processed successfully.
Not doing so, will result in leak and impact stabilty under low memory
cases.

Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 96a7417..9696c2e 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2412,14 +2412,12 @@ static void ath10k_htt_txrx_compl_task(unsigned long ptr)
 	struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
 	struct ath10k *ar = htt->ar;
 	struct htt_tx_done tx_done = {};
-	struct sk_buff_head rx_q;
 	struct sk_buff_head rx_ind_q;
 	struct sk_buff_head tx_ind_q;
 	struct sk_buff *skb;
 	unsigned long flags;
 	int num_mpdus;
 
-	__skb_queue_head_init(&rx_q);
 	__skb_queue_head_init(&rx_ind_q);
 	__skb_queue_head_init(&tx_ind_q);
 
@@ -2448,11 +2446,13 @@ static void ath10k_htt_txrx_compl_task(unsigned long ptr)
 	ath10k_mac_tx_push_pending(ar);
 
 	num_mpdus = atomic_read(&htt->num_mpdus_ready);
-	atomic_sub(num_mpdus, &htt->num_mpdus_ready);
 
-	while (num_mpdus--) {
+	while (num_mpdus) {
 		if (ath10k_htt_rx_handle_amsdu(htt))
 			break;
+
+		num_mpdus--;
+		atomic_dec(&htt->num_mpdus_ready);
 	}
 
 	while ((skb = __skb_dequeue(&rx_ind_q))) {
-- 
2.7.4


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 3/3] ath10k: fix unconditional num_mpdus_ready subtraction

[Ben Greear]

On 03/30/2016 08:42 AM, Rajkumar Manoharan wrote:
> Decrement num_mpdus_ready only when rx amsdu is processed successfully.
> Not doing so, will result in leak and impact stabilty under low memory
> cases.

Should this patch be rebased on top of the "ath10k: process htt rx indication as batch mode" patch?

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH 3/3] ath10k: fix unconditional num_mpdus_ready subtraction

[Ben Greear]

On 03/30/2016 08:42 AM, Rajkumar Manoharan wrote:
> Decrement num_mpdus_ready only when rx amsdu is processed successfully.
> Not doing so, will result in leak and impact stabilty under low memory
> cases.

Should this patch be rebased on top of the "ath10k: process htt rx indication as batch mode" patch?

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 3/3] ath10k: fix unconditional num_mpdus_ready subtraction

[Rajkumar Manoharan]

On 2016-04-01 00:22, Ben Greear wrote:
> On 03/30/2016 08:42 AM, Rajkumar Manoharan wrote:
>> Decrement num_mpdus_ready only when rx amsdu is processed 
>> successfully.
>> Not doing so, will result in leak and impact stabilty under low memory
>> cases.
> 
> Should this patch be rebased on top of the "ath10k: process htt rx
> indication as batch mode" patch?
> 
It should be on top of "ath10k: speedup htt rx descriptor processing for 
rx_ind". Instead of sending next version of original series, i sent it 
as follow up.

-Rajkumar

Re: [PATCH 3/3] ath10k: fix unconditional num_mpdus_ready subtraction

[Rajkumar Manoharan]

On 2016-04-01 00:22, Ben Greear wrote:
> On 03/30/2016 08:42 AM, Rajkumar Manoharan wrote:
>> Decrement num_mpdus_ready only when rx amsdu is processed 
>> successfully.
>> Not doing so, will result in leak and impact stabilty under low memory
>> cases.
> 
> Should this patch be rebased on top of the "ath10k: process htt rx
> indication as batch mode" patch?
> 
It should be on top of "ath10k: speedup htt rx descriptor processing for 
rx_ind". Instead of sending next version of original series, i sent it 
as follow up.

-Rajkumar



_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 3/3] ath10k: fix unconditional num_mpdus_ready subtraction

[Valo, Kalle]

Rajkumar Manoharan <rmanohar@codeaurora.org> writes:

> On 2016-04-01 00:22, Ben Greear wrote:
>> On 03/30/2016 08:42 AM, Rajkumar Manoharan wrote:
>>> Decrement num_mpdus_ready only when rx amsdu is processed
>>> successfully.
>>> Not doing so, will result in leak and impact stabilty under low memory
>>> cases.
>>
>> Should this patch be rebased on top of the "ath10k: process htt rx
>> indication as batch mode" patch?
>>
> It should be on top of "ath10k: speedup htt rx descriptor processing
> for rx_ind". Instead of sending next version of original series, i
> sent it as follow up.

Should this commit log have a fixes line like this:

Fixes: 59465fe46ef1 ("ath10k: speedup htt rx descriptor processing for tx completion")

-- 
Kalle Valo

Re: [PATCH 3/3] ath10k: fix unconditional num_mpdus_ready subtraction

[Valo, Kalle]

Rajkumar Manoharan <rmanohar@codeaurora.org> writes:

> On 2016-04-01 00:22, Ben Greear wrote:
>> On 03/30/2016 08:42 AM, Rajkumar Manoharan wrote:
>>> Decrement num_mpdus_ready only when rx amsdu is processed
>>> successfully.
>>> Not doing so, will result in leak and impact stabilty under low memory
>>> cases.
>>
>> Should this patch be rebased on top of the "ath10k: process htt rx
>> indication as batch mode" patch?
>>
> It should be on top of "ath10k: speedup htt rx descriptor processing
> for rx_ind". Instead of sending next version of original series, i
> sent it as follow up.

Should this commit log have a fixes line like this:

Fixes: 59465fe46ef1 ("ath10k: speedup htt rx descriptor processing for tx completion")

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 3/3] ath10k: fix unconditional num_mpdus_ready subtraction

[Valo, Kalle]

Rajkumar Manoharan <rmanohar@qti.qualcomm.com> writes:

> Decrement num_mpdus_ready only when rx amsdu is processed successfully.
> Not doing so, will result in leak and impact stabilty under low memory
> cases.
>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
> ---
>  drivers/net/wireless/ath/ath10k/htt_rx.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
> index 96a7417..9696c2e 100644
> --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
> +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
> @@ -2412,14 +2412,12 @@ static void ath10k_htt_txrx_compl_task(unsigned long ptr)
>  	struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
>  	struct ath10k *ar = htt->ar;
>  	struct htt_tx_done tx_done = {};
> -	struct sk_buff_head rx_q;
>  	struct sk_buff_head rx_ind_q;
>  	struct sk_buff_head tx_ind_q;
>  	struct sk_buff *skb;
>  	unsigned long flags;
>  	int num_mpdus;
>  
> -	__skb_queue_head_init(&rx_q);
>  	__skb_queue_head_init(&rx_ind_q);
>  	__skb_queue_head_init(&tx_ind_q);

I guess you are removing the unused rx_q just as a cleanup? It's good
practise to mention that in the commit log (or better yet in a separate
patch).

-- 
Kalle Valo

Re: [PATCH 3/3] ath10k: fix unconditional num_mpdus_ready subtraction

[Valo, Kalle]

Rajkumar Manoharan <rmanohar@qti.qualcomm.com> writes:

> Decrement num_mpdus_ready only when rx amsdu is processed successfully.
> Not doing so, will result in leak and impact stabilty under low memory
> cases.
>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
> ---
>  drivers/net/wireless/ath/ath10k/htt_rx.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
> index 96a7417..9696c2e 100644
> --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
> +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
> @@ -2412,14 +2412,12 @@ static void ath10k_htt_txrx_compl_task(unsigned long ptr)
>  	struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
>  	struct ath10k *ar = htt->ar;
>  	struct htt_tx_done tx_done = {};
> -	struct sk_buff_head rx_q;
>  	struct sk_buff_head rx_ind_q;
>  	struct sk_buff_head tx_ind_q;
>  	struct sk_buff *skb;
>  	unsigned long flags;
>  	int num_mpdus;
>  
> -	__skb_queue_head_init(&rx_q);
>  	__skb_queue_head_init(&rx_ind_q);
>  	__skb_queue_head_init(&tx_ind_q);

I guess you are removing the unused rx_q just as a cleanup? It's good
practise to mention that in the commit log (or better yet in a separate
patch).

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 3/3] ath10k: fix unconditional num_mpdus_ready subtraction

[Rajkumar Manoharan]

On 2016-04-05 18:18, Valo, Kalle wrote:
> Rajkumar Manoharan <rmanohar@qti.qualcomm.com> writes:
> 
>> Decrement num_mpdus_ready only when rx amsdu is processed 
>> successfully.
>> Not doing so, will result in leak and impact stabilty under low memory
>> cases.
>> 
>> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
>> ---
>>  drivers/net/wireless/ath/ath10k/htt_rx.c | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
>> b/drivers/net/wireless/ath/ath10k/htt_rx.c
>> index 96a7417..9696c2e 100644
>> --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
>> +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
>> @@ -2412,14 +2412,12 @@ static void 
>> ath10k_htt_txrx_compl_task(unsigned long ptr)
>>  	struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
>>  	struct ath10k *ar = htt->ar;
>>  	struct htt_tx_done tx_done = {};
>> -	struct sk_buff_head rx_q;
>>  	struct sk_buff_head rx_ind_q;
>>  	struct sk_buff_head tx_ind_q;
>>  	struct sk_buff *skb;
>>  	unsigned long flags;
>>  	int num_mpdus;
>> 
>> -	__skb_queue_head_init(&rx_q);
>>  	__skb_queue_head_init(&rx_ind_q);
>>  	__skb_queue_head_init(&tx_ind_q);
> 
> I guess you are removing the unused rx_q just as a cleanup? It's good
> practise to mention that in the commit log (or better yet in a separate
> patch).

update the commit log and send next version.

-Rajkumar

Re: [PATCH 3/3] ath10k: fix unconditional num_mpdus_ready subtraction

[Rajkumar Manoharan]

On 2016-04-05 18:18, Valo, Kalle wrote:
> Rajkumar Manoharan <rmanohar@qti.qualcomm.com> writes:
> 
>> Decrement num_mpdus_ready only when rx amsdu is processed 
>> successfully.
>> Not doing so, will result in leak and impact stabilty under low memory
>> cases.
>> 
>> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
>> ---
>>  drivers/net/wireless/ath/ath10k/htt_rx.c | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
>> b/drivers/net/wireless/ath/ath10k/htt_rx.c
>> index 96a7417..9696c2e 100644
>> --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
>> +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
>> @@ -2412,14 +2412,12 @@ static void 
>> ath10k_htt_txrx_compl_task(unsigned long ptr)
>>  	struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
>>  	struct ath10k *ar = htt->ar;
>>  	struct htt_tx_done tx_done = {};
>> -	struct sk_buff_head rx_q;
>>  	struct sk_buff_head rx_ind_q;
>>  	struct sk_buff_head tx_ind_q;
>>  	struct sk_buff *skb;
>>  	unsigned long flags;
>>  	int num_mpdus;
>> 
>> -	__skb_queue_head_init(&rx_q);
>>  	__skb_queue_head_init(&rx_ind_q);
>>  	__skb_queue_head_init(&tx_ind_q);
> 
> I guess you are removing the unused rx_q just as a cleanup? It's good
> practise to mention that in the commit log (or better yet in a separate
> patch).

update the commit log and send next version.

-Rajkumar

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 1/3] ath10k: fix calibration init sequence of qca99x0

[Valo, Kalle]

Rajkumar Manoharan <rmanohar@qti.qualcomm.com> writes:

> pre-calibration is meant for qca4019 which contains only caldata
> whereas calibration file is used by ar9888 and qca99x0 that contains
> both board data and caldata. So by definition both pre-cal-file and
> cal-file can not coexist. Keeping them in shared memory (union), is
> breaking boot sequence of qca99x0. Fix it by storing both binaries
> in separate memories. This issue is reported in ipq8064 platform which
> includes caldata in flash memory.
>
> Reported-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>

I added the fixes line in the pending branch:

Fixes: 3d9195ea19e4 ("ath10k: incorporate qca4019 cal data download sequence")

-- 
Kalle Valo

Re: [PATCH 1/3] ath10k: fix calibration init sequence of qca99x0

[Valo, Kalle]

Rajkumar Manoharan <rmanohar@qti.qualcomm.com> writes:

> pre-calibration is meant for qca4019 which contains only caldata
> whereas calibration file is used by ar9888 and qca99x0 that contains
> both board data and caldata. So by definition both pre-cal-file and
> cal-file can not coexist. Keeping them in shared memory (union), is
> breaking boot sequence of qca99x0. Fix it by storing both binaries
> in separate memories. This issue is reported in ipq8064 platform which
> includes caldata in flash memory.
>
> Reported-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>

I added the fixes line in the pending branch:

Fixes: 3d9195ea19e4 ("ath10k: incorporate qca4019 cal data download sequence")

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 1/3] ath10k: fix calibration init sequence of qca99x0

[Rajkumar Manoharan]

On 2016-04-05 18:10, Valo, Kalle wrote:
> Rajkumar Manoharan <rmanohar@qti.qualcomm.com> writes:
> 
>> pre-calibration is meant for qca4019 which contains only caldata
>> whereas calibration file is used by ar9888 and qca99x0 that contains
>> both board data and caldata. So by definition both pre-cal-file and
>> cal-file can not coexist. Keeping them in shared memory (union), is
>> breaking boot sequence of qca99x0. Fix it by storing both binaries
>> in separate memories. This issue is reported in ipq8064 platform which
>> includes caldata in flash memory.
>> 
>> Reported-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
>> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
> 
> I added the fixes line in the pending branch:
> 
> Fixes: 3d9195ea19e4 ("ath10k: incorporate qca4019 cal data download 
> sequence")

Thanks.

-Rajkumar

Re: [PATCH 1/3] ath10k: fix calibration init sequence of qca99x0

[Rajkumar Manoharan]

On 2016-04-05 18:10, Valo, Kalle wrote:
> Rajkumar Manoharan <rmanohar@qti.qualcomm.com> writes:
> 
>> pre-calibration is meant for qca4019 which contains only caldata
>> whereas calibration file is used by ar9888 and qca99x0 that contains
>> both board data and caldata. So by definition both pre-cal-file and
>> cal-file can not coexist. Keeping them in shared memory (union), is
>> breaking boot sequence of qca99x0. Fix it by storing both binaries
>> in separate memories. This issue is reported in ipq8064 platform which
>> includes caldata in flash memory.
>> 
>> Reported-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
>> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
> 
> I added the fixes line in the pending branch:
> 
> Fixes: 3d9195ea19e4 ("ath10k: incorporate qca4019 cal data download 
> sequence")

Thanks.

-Rajkumar

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k