Linux wireless drivers development
 help / color / mirror / Atom feed
From: Mohammed Shafi Shajakhan <mohammed@codeaurora.org>
To: Ben Greear <greearb@candelatech.com>
Cc: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>,
	ath10k@lists.infradead.org, linux-wireless@vger.kernel.org,
	Tamizh chelvam <c_traja@qti.qualcomm.com>
Subject: Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later
Date: Sun, 26 Jun 2016 00:23:50 +0530	[thread overview]
Message-ID: <20160625185350.GA25330@atheros-ThinkPad-T61> (raw)
In-Reply-To: <576C1861.7020402@candelatech.com>

Hello Ben,

On Thu, Jun 23, 2016 at 10:12:01AM -0700, Ben Greear wrote:
> On 06/23/2016 09:40 AM, Mohammed Shafi Shajakhan wrote:
> >From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> >
> >For chipsets like QCA99X0, IPQ4019 and later we are not getting proper
> >NULL func status (always acked/successs !!) when hostapd does a
> >PROBE_CLIENT via nullfunc frames when the station is powered off
> >abruptly (inactive timer probes client via null func after the inactive
> >time reaches beyond the threshold). Fix this by disabling the workaround
> >(getting the ACK status of NULL func frames by sending via HTT mgmt-tx
> >  path) introduced by the change ("ath10k: fix beacon loss handling ")
> >for QCA99X0 and later chipsets. The normal tx path provides the proper
> >ACK status for NULL data frames. As of now disable this workaround for
> >chipsets QCA99X0 and later, once the 10.1 firmware is obselete we can
> >completely get rid of this workaround for all the chipsets
> 
> Did you see my fix for the tx-status that Kalle posted about recently?
> That fixed my problem with 9980, but I normally test status with tx over
> the htt mgt path instead of wmi path, so possibly that makes a difference.

[shafi] Yes Kalle suggested to try your change (BTW we were not aware that you
already discovered this problem !!), https://patchwork.kernel.org/patch/8460831/
but ..


"[ 747.803652] ath10k_pci 0000:01:00.0: htt tx completion msdu_id 0 discard 0
no_ack 0 success 1"

"[ 747.803843] ath10k_pci 0001:01:00.0: htt tx completion msdu_id 0 discard 0
no_ack 0 success 1"

to be more precise looks like we hit this path for MSG type 0xE,( management Tx
completion indication) path(status ok ??) for null func frame without ACK

case HTT_MGMT_TX_STATUS_OK:
	tx_done.status = HTT_TX_COMPL_STATE_ACK;
	break;


a) The success bit being 'set' without the fix so the change you had mentioned may not help
for the upstreamed f/w, should we  give a shot with your change as well to
confirm it ?

b) and also the workaround is for older firmware which got fixed in
10.2.4 and 10.4, if you can help us that 10.1 also reports NULL func frame
status properly via normal data path, we can probably get rid of this workaround
once and for all ? thoughts ?

regards,
shafi

  reply	other threads:[~2016-06-25 18:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-23 16:40 [PATCH 1/2] ath10k: Replace warning with an error message if HTT op version is unset Mohammed Shafi Shajakhan
2016-06-23 16:40 ` [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later Mohammed Shafi Shajakhan
2016-06-23 17:12   ` Ben Greear
2016-06-25 18:53     ` Mohammed Shafi Shajakhan [this message]
2016-06-26  0:27       ` Ben Greear
2016-06-30 10:25         ` Valo, Kalle
2016-07-05 15:21           ` Ben Greear
2016-07-08 11:00             ` Mohammed Shafi Shajakhan
2016-06-27  9:27   ` Michal Kazior
2016-06-27 14:36     ` Mohammed Shafi Shajakhan
2016-06-28  6:48       ` Michal Kazior
2016-06-29  9:47         ` Mohammed Shafi Shajakhan
     [not found]           ` <CAD2nsn3TOSaOCmm5YT6_D+aaoH9=pagQamDDz2VT+nKrFH0K8g@mail.gmail.com>
     [not found]             ` <900ae7541c5a4194a2f73479e1dd8bb2@aphydexm01b.ap.qualcomm.com>
2016-07-20 12:22               ` Michal Kazior
2016-07-20 16:27                 ` Mohammed Shafi Shajakhan
2016-07-08  6:54 ` [1/2] ath10k: Replace warning with an error message if HTT op version is unset Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160625185350.GA25330@atheros-ThinkPad-T61 \
    --to=mohammed@codeaurora.org \
    --cc=ath10k@lists.infradead.org \
    --cc=c_traja@qti.qualcomm.com \
    --cc=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mohammed@qti.qualcomm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox