From: Ben Greear <greearb@candelatech.com>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
ath10k <ath10k@lists.infradead.org>
Subject: Re: Question on beacon-miss offloading.
Date: Tue, 16 Jun 2015 14:55:10 -0700 [thread overview]
Message-ID: <55809B3E.10300@candelatech.com> (raw)
In-Reply-To: <CA+BoTQ=jYu2BV1rkaLwF_d5ZdDgsiws0TrWE7NGXmRsz8hMFVA@mail.gmail.com>
On 06/15/2015 10:29 PM, Michal Kazior wrote:
>> This patch below (with firmware fix to make it actually pay attention
>> to this special TID in station mode), fixes the null-func to be non-qos
>> frames and get immediate ack. This in turn seems to fix the disconnect
>> issue I was facing, though I need to test some more to be sure.
>>
>> This seem reasonable, maybe even for upstream?
>>
>> [greearb@ben-dt2 ath10k]$ git diff
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>> index 6ca48e3..610447e 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -2213,6 +2213,9 @@ static u8 ath10k_tx_h_get_tid(struct ieee80211_hdr *hdr)
>> if (ieee80211_is_mgmt(hdr->frame_control))
>> return HTT_DATA_TX_EXT_TID_MGMT;
>>
>> + if (ieee80211_is_nullfunc(hdr->frame_control))
>> + return HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST;
>> +
>
> That's weird.. QoS NullFunc frames are already converted to non-QoS
> frames, see ath10k_tx_h_nwifi():
True, but the 4.0.4 kernel sends down non-qos null-func frames as far
as I can tell, at least when doing connection probing.
In my case, my kernel was sending non-qos nullfunc frame to firmware, but then
firmware stuck it on BE queue and made it QoS.
> /* Some firmware revisions don't handle sending QoS NullFunc well.
> * These frames are mainly used for CQM purposes so it doesn't really
> * matter whether QoS NullFunc or NullFunc are sent.
> */
> hdr = (void *)skb->data;
> if (ieee80211_is_qos_nullfunc(hdr->frame_control))
> cb->htt.tid = HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST;
>
> Or is it that ath10k_tx_h_get_tid() has a bug that ends up assigning
> an invalid tid for non-QoS NullFunc frames? If so I guess your patch
> would be okay with some comments/commit-log explaining why/what was
> wrong.
I tried very recent upstream ath kernel, and stock firmware-2.bin, and it
seems to generate null-func frames fine. I'll go back at look at my
recent FW and kernel changes in more detail now that I understand the problem
better and see if I can figure out what is going on...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2015-06-16 21:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-11 21:07 Question on beacon-miss offloading Ben Greear
2015-06-11 23:38 ` Ben Greear
2015-06-12 6:03 ` Michal Kazior
2015-06-12 13:29 ` Ben Greear
2015-06-12 14:10 ` Krishna Chaitanya
2015-06-12 15:22 ` Ben Greear
2015-06-12 15:37 ` Ben Greear
2015-06-15 5:36 ` Michal Kazior
2015-06-15 15:35 ` Ben Greear
2015-06-15 19:45 ` Ben Greear
2015-06-16 5:29 ` Michal Kazior
2015-06-16 21:55 ` Ben Greear [this message]
2015-06-16 23:06 ` Ben Greear
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=55809B3E.10300@candelatech.com \
--to=greearb@candelatech.com \
--cc=ath10k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=michal.kazior@tieto.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;
as well as URLs for NNTP newsgroup(s).