From mohammed at codeaurora.org  Wed Jun  1 02:08:05 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Wed, 1 Jun 2016 14:38:05 +0530
Subject: [PATCH v2] ath10k: Fix 10.4 extended peer stats update
In-Reply-To: <87r3cicaxi.fsf@qca.qualcomm.com>
References: <1464339926-12136-1-git-send-email-mohammed@qca.qualcomm.com>
 <87vb1ucten.fsf@qca.qualcomm.com>
 <20160531133700.GB3146@atheros-ThinkPad-T61>
 <87r3cicaxi.fsf@qca.qualcomm.com>
Message-ID: <20160601090805.GA7773@atheros-ThinkPad-T61>

Hello,

On Tue, May 31, 2016 at 06:57:52PM +0000, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan <mohammed at codeaurora.org> writes:
> 
> >> > +void ath10k_sta_update_rx_duration(struct ath10k *ar,
> >> > +				   struct ath10k_fw_stats *stats)
> >> > +{
> >> > +	struct ath10k_fw_file *fw_file = &ar->normal_mode_fw.fw_file;
> >> > +
> >> > +	if (fw_file->wmi_op_version < ATH10K_FW_WMI_OP_VERSION_10_4)
> >> > +		ath10k_sta_update_stats_rx_duration(ar, &stats->peers);
> >> > +	else
> >> > +		ath10k_sta_update_extd_stats_rx_duration(ar,
> >> > +							 &stats->peers_extd);
> >> > +}
> >> 
> >> _Ideally_ wmi_op_version should be used only in ath10k_wmi_attach() and
> >> nowhere else. Isn't there any other way to detect this scenario? For
> >> example, what if you store stats_id to struct ath10k_fw_stats and do
> >> something like this:
> >> 
> >> if (stats->stats_id & WMI_10_4_STAT_PEER_EXTD)
> >> 	ath10k_sta_update_extd_stats_rx_duration(ar,
> >> 						 &stats->peers_extd);
> >> else
> >> 	ath10k_sta_update_stats_rx_duration(ar, &stats->peers);
> >> 
> >> Would that work?
> >
> > [shafi] I am also thinking to re-use (ar->fw_stats_req_mask & WMI_10_4_STAT_PEER_EXTD)
> > it might work, but will it conflict vdev stats WMI_STAT_VDEV (though its not currently
> > supported for 10.2 )
> 
> Can you describe more how they conflict?

[shafi] 'WMI_STAT_VDEV' and 'WMI_10_4_STAT_PEER_EXTD' are having the same value
BIT(3), though as of now we are only 'WMI_10_4_STAT_PEER_EXTD' for 10.4

> 
> > let me know your thoughts about this, seems extended stats was
> > implemented for 10.4 wmi version so i made it explicit
> 
> I don't like hard coding features like this based on wmi_op_version as
> that might create problems managing the firmware interfaces in the
> future. The simplest is if we can automatically runtime detect if
> firmware uses the extended version or not.
>
[shafi] Sure i come up with something else to address this in v3.

regards
shafi


From pommnitz at yahoo.com  Wed Jun  1 04:34:10 2016
From: pommnitz at yahoo.com (Joerg Pommnitz)
Date: Wed, 1 Jun 2016 11:34:10 +0000 (UTC)
Subject: Please don't puke: Modifying Frame Version, Beacon and
 Probe-Response values
In-Reply-To: <CAJ-VmokXt-V9JGL4E4jcL+u+gfvVJ-rFGP5H1bzTFkUr39mhtQ@mail.gmail.com>
References: <loom.20160531T102350-834@post.gmane.org>
 <CA+BoTQ=NjABLfzMjc-5+wKEvesKsyMJDheZRu8_eR=XD8zic7Q@mail.gmail.com>
 <CAJ-VmokXt-V9JGL4E4jcL+u+gfvVJ-rFGP5H1bzTFkUr39mhtQ@mail.gmail.com>
Message-ID: <855019245.2902911.1464780850322.JavaMail.yahoo@mail.yahoo.com>

Hi Adrian,
does "hardware assist...will likely not work" mean "forget it, won't work"
or "so it would have to be implemented in software instead"?


 -- Regards       Joerg



> Adrian Chadd <adrian at freebsd.org> schrieb am 17:53 Dienstag, 31.Mai 2016:
> > Hi,
> 
> The other thing to keep in mind is the hardware assist for things like
> TIM parsing, wakeup, etc will likely not work. :)
> 
> 
> 
> -a
> 
> 
> 
> On 31 May 2016 at 03:50, Michal Kazior <michal.kazior at tieto.com> wrote:
>>  On 31 May 2016 at 10:44, jpo <pommnitz at yahoo.com> wrote:
>>>  Hello all,
>>>  to implement a "Stealth feature", e.g. the WLAN network does 
> not show up in
>>>  normal Scans, we modified the Frame version, Beacon and Probe-Response
>>>  values for an old ATH5K card running on the now dormant Madwifi driver.
>>>  Question: Is the same thing even POSSIBLE with ath10k? My main concern 
> is,
>>>  that the firmware just won't handle non-standard values.
>>> 
>>>  Can somebody who understands the division of labor between mac80211, 
> ath10k,
>>>  the firmware and the hardware suppress his or her gag reflex long 
> enough to
>>>  think about this?
>> 
>>  First and foremost you'll need to use firmware with 
> "raw-mode" support
>>  - otherwise firmware just craps over frame headers. Some 10.2.4
>>  support it - you can look into the mailing list archive for some
>>  discussions.
>> 
>>  Not sure if Rx will work though as firmware-controlled Rx filters may
>>  prevent you from receiving frames with crazy frame_control values.
>>  You'll need to check this out yourself. Some firmware revisions might
>>  have RX_FILTER wmi command support but this isn't used/documented
>>  anywhere and it's questionable how much it allows you to override.
>> 
>>  Whatever you find it'd be nice if you post whatever you find out (for
>>  posterity :)
>> 
>> 
>>  Micha?
>> 
>>  _______________________________________________
>>  ath10k mailing list
>>  ath10k at lists.infradead.org
>>  http://lists.infradead.org/mailman/listinfo/ath10k
>


From kvalo at qca.qualcomm.com  Wed Jun  1 06:00:40 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Wed, 1 Jun 2016 13:00:40 +0000
Subject: [PATCH v2] ath10k: Fix 10.4 extended peer stats update
In-Reply-To: <20160601090805.GA7773@atheros-ThinkPad-T61> (Mohammed Shafi
 Shajakhan's message of "Wed, 1 Jun 2016 14:38:05 +0530")
References: <1464339926-12136-1-git-send-email-mohammed@qca.qualcomm.com>
 <87vb1ucten.fsf@qca.qualcomm.com>
 <20160531133700.GB3146@atheros-ThinkPad-T61>
 <87r3cicaxi.fsf@qca.qualcomm.com>
 <20160601090805.GA7773@atheros-ThinkPad-T61>
Message-ID: <877fe92he0.fsf@kamboji.qca.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at codeaurora.org> writes:

> Hello,
>
> On Tue, May 31, 2016 at 06:57:52PM +0000, Valo, Kalle wrote:
>> Mohammed Shafi Shajakhan <mohammed at codeaurora.org> writes:
>> 
>> >> > +void ath10k_sta_update_rx_duration(struct ath10k *ar,
>> >> > +				   struct ath10k_fw_stats *stats)
>> >> > +{
>> >> > +	struct ath10k_fw_file *fw_file = &ar->normal_mode_fw.fw_file;
>> >> > +
>> >> > +	if (fw_file->wmi_op_version < ATH10K_FW_WMI_OP_VERSION_10_4)
>> >> > +		ath10k_sta_update_stats_rx_duration(ar, &stats->peers);
>> >> > +	else
>> >> > +		ath10k_sta_update_extd_stats_rx_duration(ar,
>> >> > +							 &stats->peers_extd);
>> >> > +}
>> >> 
>> >> _Ideally_ wmi_op_version should be used only in ath10k_wmi_attach() and
>> >> nowhere else. Isn't there any other way to detect this scenario? For
>> >> example, what if you store stats_id to struct ath10k_fw_stats and do
>> >> something like this:
>> >> 
>> >> if (stats->stats_id & WMI_10_4_STAT_PEER_EXTD)
>> >> 	ath10k_sta_update_extd_stats_rx_duration(ar,
>> >> 						 &stats->peers_extd);
>> >> else
>> >> 	ath10k_sta_update_stats_rx_duration(ar, &stats->peers);
>> >> 
>> >> Would that work?
>> >
>> > [shafi] I am also thinking to re-use (ar->fw_stats_req_mask & WMI_10_4_STAT_PEER_EXTD)
>> > it might work, but will it conflict vdev stats WMI_STAT_VDEV (though its not currently
>> > supported for 10.2 )
>> 
>> Can you describe more how they conflict?
>
> [shafi] 'WMI_STAT_VDEV' and 'WMI_10_4_STAT_PEER_EXTD' are having the same value
> BIT(3), though as of now we are only 'WMI_10_4_STAT_PEER_EXTD' for 10.4

Ah. But that's easy to solve, for example you could use a bool instead.

-- 
Kalle Valo

From mohammed at codeaurora.org  Wed Jun  1 08:12:38 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Wed, 1 Jun 2016 20:42:38 +0530
Subject: [PATCH v2] ath10k: Fix 10.4 extended peer stats update
In-Reply-To: <877fe92he0.fsf@kamboji.qca.qualcomm.com>
References: <1464339926-12136-1-git-send-email-mohammed@qca.qualcomm.com>
 <87vb1ucten.fsf@qca.qualcomm.com>
 <20160531133700.GB3146@atheros-ThinkPad-T61>
 <87r3cicaxi.fsf@qca.qualcomm.com>
 <20160601090805.GA7773@atheros-ThinkPad-T61>
 <877fe92he0.fsf@kamboji.qca.qualcomm.com>
Message-ID: <20160601151238.GA9766@atheros-ThinkPad-T61>

On Wed, Jun 01, 2016 at 01:00:40PM +0000, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan <mohammed at codeaurora.org> writes:
> 
> > Hello,
> >
> > On Tue, May 31, 2016 at 06:57:52PM +0000, Valo, Kalle wrote:
> >> Mohammed Shafi Shajakhan <mohammed at codeaurora.org> writes:
> >> 
> >> >> > +void ath10k_sta_update_rx_duration(struct ath10k *ar,
> >> >> > +				   struct ath10k_fw_stats *stats)
> >> >> > +{
> >> >> > +	struct ath10k_fw_file *fw_file = &ar->normal_mode_fw.fw_file;
> >> >> > +
> >> >> > +	if (fw_file->wmi_op_version < ATH10K_FW_WMI_OP_VERSION_10_4)
> >> >> > +		ath10k_sta_update_stats_rx_duration(ar, &stats->peers);
> >> >> > +	else
> >> >> > +		ath10k_sta_update_extd_stats_rx_duration(ar,
> >> >> > +							 &stats->peers_extd);
> >> >> > +}
> >> >> 
> >> >> _Ideally_ wmi_op_version should be used only in ath10k_wmi_attach() and
> >> >> nowhere else. Isn't there any other way to detect this scenario? For
> >> >> example, what if you store stats_id to struct ath10k_fw_stats and do
> >> >> something like this:
> >> >> 
> >> >> if (stats->stats_id & WMI_10_4_STAT_PEER_EXTD)
> >> >> 	ath10k_sta_update_extd_stats_rx_duration(ar,
> >> >> 						 &stats->peers_extd);
> >> >> else
> >> >> 	ath10k_sta_update_stats_rx_duration(ar, &stats->peers);
> >> >> 
> >> >> Would that work?
> >> >
> >> > [shafi] I am also thinking to re-use (ar->fw_stats_req_mask & WMI_10_4_STAT_PEER_EXTD)
> >> > it might work, but will it conflict vdev stats WMI_STAT_VDEV (though its not currently
> >> > supported for 10.2 )
> >> 
> >> Can you describe more how they conflict?
> >
> > [shafi] 'WMI_STAT_VDEV' and 'WMI_10_4_STAT_PEER_EXTD' are having the same value
> > BIT(3), though as of now we are only 'WMI_10_4_STAT_PEER_EXTD' for 10.4
> 
> Ah. But that's easy to solve, for example you could use a bool instead.
>
[shafi] sure thanks will do the same, i had a similar change in my mind as well
!


From adrian at freebsd.org  Wed Jun  1 12:18:37 2016
From: adrian at freebsd.org (Adrian Chadd)
Date: Wed, 1 Jun 2016 12:18:37 -0700
Subject: Please don't puke: Modifying Frame Version, Beacon and
 Probe-Response values
In-Reply-To: <855019245.2902911.1464780850322.JavaMail.yahoo@mail.yahoo.com>
References: <loom.20160531T102350-834@post.gmane.org>
 <CA+BoTQ=NjABLfzMjc-5+wKEvesKsyMJDheZRu8_eR=XD8zic7Q@mail.gmail.com>
 <CAJ-VmokXt-V9JGL4E4jcL+u+gfvVJ-rFGP5H1bzTFkUr39mhtQ@mail.gmail.com>
 <855019245.2902911.1464780850322.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAJ-VmokmAduSkLar6vhL58CPU9BkbQGVeqiqneJRMgSNtuJSMw@mail.gmail.com>

Hi,

Likely a mix of both. Eg, the RX filter stuff as mentioned above may
mean that you need to listen to /all/ frames for a BSS, rather than
just say data and beacon frames. If the beacon frame matching logic
checks the frame version, you need to listen to /all/ of the frames.

For power management things, it's likely none of that will work, so
you can't use things like auto-sleep based on beacon traffic / timers
/ TIM bitmap - you'd have to keep the NIC awake all the time.



-adrian


On 1 June 2016 at 04:34, Joerg Pommnitz <pommnitz at yahoo.com> wrote:
> Hi Adrian,
> does "hardware assist...will likely not work" mean "forget it, won't work"
> or "so it would have to be implemented in software instead"?
>
>
>  -- Regards       Joerg
>
>
>
>> Adrian Chadd <adrian at freebsd.org> schrieb am 17:53 Dienstag, 31.Mai 2016:
>> > Hi,
>>
>> The other thing to keep in mind is the hardware assist for things like
>> TIM parsing, wakeup, etc will likely not work. :)
>>
>>
>>
>> -a
>>
>>
>>
>> On 31 May 2016 at 03:50, Michal Kazior <michal.kazior at tieto.com> wrote:
>>>  On 31 May 2016 at 10:44, jpo <pommnitz at yahoo.com> wrote:
>>>>  Hello all,
>>>>  to implement a "Stealth feature", e.g. the WLAN network does
>> not show up in
>>>>  normal Scans, we modified the Frame version, Beacon and Probe-Response
>>>>  values for an old ATH5K card running on the now dormant Madwifi driver.
>>>>  Question: Is the same thing even POSSIBLE with ath10k? My main concern
>> is,
>>>>  that the firmware just won't handle non-standard values.
>>>>
>>>>  Can somebody who understands the division of labor between mac80211,
>> ath10k,
>>>>  the firmware and the hardware suppress his or her gag reflex long
>> enough to
>>>>  think about this?
>>>
>>>  First and foremost you'll need to use firmware with
>> "raw-mode" support
>>>  - otherwise firmware just craps over frame headers. Some 10.2.4
>>>  support it - you can look into the mailing list archive for some
>>>  discussions.
>>>
>>>  Not sure if Rx will work though as firmware-controlled Rx filters may
>>>  prevent you from receiving frames with crazy frame_control values.
>>>  You'll need to check this out yourself. Some firmware revisions might
>>>  have RX_FILTER wmi command support but this isn't used/documented
>>>  anywhere and it's questionable how much it allows you to override.
>>>
>>>  Whatever you find it'd be nice if you post whatever you find out (for
>>>  posterity :)
>>>
>>>
>>>  Micha?
>>>
>>>  _______________________________________________
>>>  ath10k mailing list
>>>  ath10k at lists.infradead.org
>>>  http://lists.infradead.org/mailman/listinfo/ath10k
>>


From greearb at candelatech.com  Wed Jun  1 12:29:34 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 1 Jun 2016 12:29:34 -0700
Subject: Please don't puke: Modifying Frame Version, Beacon and
 Probe-Response values
In-Reply-To: <CAJ-VmokmAduSkLar6vhL58CPU9BkbQGVeqiqneJRMgSNtuJSMw@mail.gmail.com>
References: <loom.20160531T102350-834@post.gmane.org>
 <CA+BoTQ=NjABLfzMjc-5+wKEvesKsyMJDheZRu8_eR=XD8zic7Q@mail.gmail.com>
 <CAJ-VmokXt-V9JGL4E4jcL+u+gfvVJ-rFGP5H1bzTFkUr39mhtQ@mail.gmail.com>
 <855019245.2902911.1464780850322.JavaMail.yahoo@mail.yahoo.com>
 <CAJ-VmokmAduSkLar6vhL58CPU9BkbQGVeqiqneJRMgSNtuJSMw@mail.gmail.com>
Message-ID: <574F379E.7050704@candelatech.com>

On 06/01/2016 12:18 PM, Adrian Chadd wrote:
> Hi,
>
> Likely a mix of both. Eg, the RX filter stuff as mentioned above may
> mean that you need to listen to /all/ frames for a BSS, rather than
> just say data and beacon frames. If the beacon frame matching logic
> checks the frame version, you need to listen to /all/ of the frames.
>
> For power management things, it's likely none of that will work, so
> you can't use things like auto-sleep based on beacon traffic / timers
> / TIM bitmap - you'd have to keep the NIC awake all the time.

I'm guessing little of this is in hardware, aside from rx filters,
so probably a few tweaks to the firmware would handle much of this...

And, if for AP mode, then the NIC is always awake anyway, right?

Thanks,
Ben

>
>
>
> -adrian
>
>
> On 1 June 2016 at 04:34, Joerg Pommnitz <pommnitz at yahoo.com> wrote:
>> Hi Adrian,
>> does "hardware assist...will likely not work" mean "forget it, won't work"
>> or "so it would have to be implemented in software instead"?
>>
>>
>>   -- Regards       Joerg
>>
>>
>>
>>> Adrian Chadd <adrian at freebsd.org> schrieb am 17:53 Dienstag, 31.Mai 2016:
>>>> Hi,
>>>
>>> The other thing to keep in mind is the hardware assist for things like
>>> TIM parsing, wakeup, etc will likely not work. :)
>>>
>>>
>>>
>>> -a
>>>
>>>
>>>
>>> On 31 May 2016 at 03:50, Michal Kazior <michal.kazior at tieto.com> wrote:
>>>>   On 31 May 2016 at 10:44, jpo <pommnitz at yahoo.com> wrote:
>>>>>   Hello all,
>>>>>   to implement a "Stealth feature", e.g. the WLAN network does
>>> not show up in
>>>>>   normal Scans, we modified the Frame version, Beacon and Probe-Response
>>>>>   values for an old ATH5K card running on the now dormant Madwifi driver.
>>>>>   Question: Is the same thing even POSSIBLE with ath10k? My main concern
>>> is,
>>>>>   that the firmware just won't handle non-standard values.
>>>>>
>>>>>   Can somebody who understands the division of labor between mac80211,
>>> ath10k,
>>>>>   the firmware and the hardware suppress his or her gag reflex long
>>> enough to
>>>>>   think about this?
>>>>
>>>>   First and foremost you'll need to use firmware with
>>> "raw-mode" support
>>>>   - otherwise firmware just craps over frame headers. Some 10.2.4
>>>>   support it - you can look into the mailing list archive for some
>>>>   discussions.
>>>>
>>>>   Not sure if Rx will work though as firmware-controlled Rx filters may
>>>>   prevent you from receiving frames with crazy frame_control values.
>>>>   You'll need to check this out yourself. Some firmware revisions might
>>>>   have RX_FILTER wmi command support but this isn't used/documented
>>>>   anywhere and it's questionable how much it allows you to override.
>>>>
>>>>   Whatever you find it'd be nice if you post whatever you find out (for
>>>>   posterity :)
>>>>
>>>>
>>>>   Micha?
>>>>
>>>>   _______________________________________________
>>>>   ath10k mailing list
>>>>   ath10k at lists.infradead.org
>>>>   http://lists.infradead.org/mailman/listinfo/ath10k
>>>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>


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



From adrian at freebsd.org  Wed Jun  1 12:33:31 2016
From: adrian at freebsd.org (Adrian Chadd)
Date: Wed, 1 Jun 2016 12:33:31 -0700
Subject: Please don't puke: Modifying Frame Version, Beacon and
 Probe-Response values
In-Reply-To: <574F379E.7050704@candelatech.com>
References: <loom.20160531T102350-834@post.gmane.org>
 <CA+BoTQ=NjABLfzMjc-5+wKEvesKsyMJDheZRu8_eR=XD8zic7Q@mail.gmail.com>
 <CAJ-VmokXt-V9JGL4E4jcL+u+gfvVJ-rFGP5H1bzTFkUr39mhtQ@mail.gmail.com>
 <855019245.2902911.1464780850322.JavaMail.yahoo@mail.yahoo.com>
 <CAJ-VmokmAduSkLar6vhL58CPU9BkbQGVeqiqneJRMgSNtuJSMw@mail.gmail.com>
 <574F379E.7050704@candelatech.com>
Message-ID: <CAJ-Vmon5N9FtRR-B-DYYXaVweR8G1cycDX6KtQV_bFhT0H2bQw@mail.gmail.com>

On 1 June 2016 at 12:29, Ben Greear <greearb at candelatech.com> wrote:
> On 06/01/2016 12:18 PM, Adrian Chadd wrote:
>>
>> Hi,
>>
>> Likely a mix of both. Eg, the RX filter stuff as mentioned above may
>> mean that you need to listen to /all/ frames for a BSS, rather than
>> just say data and beacon frames. If the beacon frame matching logic
>> checks the frame version, you need to listen to /all/ of the frames.
>>
>> For power management things, it's likely none of that will work, so
>> you can't use things like auto-sleep based on beacon traffic / timers
>> / TIM bitmap - you'd have to keep the NIC awake all the time.
>
>
> I'm guessing little of this is in hardware, aside from rx filters,
> so probably a few tweaks to the firmware would handle much of this...

Right.

> And, if for AP mode, then the NIC is always awake anyway, right?

Right. But say, P2P/STA mode and no AP mode? Different story. (I'm
assuming he has clients AND APs..)

Also, for ath10k chips, maybe it'll all need to be in raw mode? I
don't know what the hardware encap/decap engines will do if you try
passing it intentionally different frames like this.



-adrian


From greearb at candelatech.com  Wed Jun  1 12:43:08 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 1 Jun 2016 12:43:08 -0700
Subject: Please don't puke: Modifying Frame Version, Beacon and
 Probe-Response values
In-Reply-To: <CAEvAWuHgna4cdgkhQrQY4xo4XyaCAhkkf1zo8iDA_Gqgjc1Jeg@mail.gmail.com>
References: <loom.20160531T102350-834@post.gmane.org>
 <CA+BoTQ=NjABLfzMjc-5+wKEvesKsyMJDheZRu8_eR=XD8zic7Q@mail.gmail.com>
 <CAJ-VmokXt-V9JGL4E4jcL+u+gfvVJ-rFGP5H1bzTFkUr39mhtQ@mail.gmail.com>
 <855019245.2902911.1464780850322.JavaMail.yahoo@mail.yahoo.com>
 <CAJ-VmokmAduSkLar6vhL58CPU9BkbQGVeqiqneJRMgSNtuJSMw@mail.gmail.com>
 <574F379E.7050704@candelatech.com>
 <CAJ-Vmon5N9FtRR-B-DYYXaVweR8G1cycDX6KtQV_bFhT0H2bQw@mail.gmail.com>
 <CAEvAWuHgna4cdgkhQrQY4xo4XyaCAhkkf1zo8iDA_Gqgjc1Jeg@mail.gmail.com>
Message-ID: <574F3ACC.3040008@candelatech.com>

On 06/01/2016 12:38 PM, J?rg Pommnitz wrote:
> This is about IBSS mode. The nodes form an ad-hoc backbone. Clients use normal, standard conforming APs.

So, about IBSS.  Only ancient QCA firmware and 'CT' firmware supports IBSS as far as I know.

I was never able to get RSN to work with IBSS reliably in CT firmware, so it would have to be un-encrypted
traffic.  And, AMSDU + IBSS has hardware bugs, evidently, so firmware will disable AMSDU for you.

That said, adding a few more hacks for fake beacon ids might not make it any worse :)

Thanks,
Ben


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



From greearb at candelatech.com  Wed Jun  1 12:37:47 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 1 Jun 2016 12:37:47 -0700
Subject: Please don't puke: Modifying Frame Version, Beacon and
 Probe-Response values
In-Reply-To: <CAJ-Vmon5N9FtRR-B-DYYXaVweR8G1cycDX6KtQV_bFhT0H2bQw@mail.gmail.com>
References: <loom.20160531T102350-834@post.gmane.org>
 <CA+BoTQ=NjABLfzMjc-5+wKEvesKsyMJDheZRu8_eR=XD8zic7Q@mail.gmail.com>
 <CAJ-VmokXt-V9JGL4E4jcL+u+gfvVJ-rFGP5H1bzTFkUr39mhtQ@mail.gmail.com>
 <855019245.2902911.1464780850322.JavaMail.yahoo@mail.yahoo.com>
 <CAJ-VmokmAduSkLar6vhL58CPU9BkbQGVeqiqneJRMgSNtuJSMw@mail.gmail.com>
 <574F379E.7050704@candelatech.com>
 <CAJ-Vmon5N9FtRR-B-DYYXaVweR8G1cycDX6KtQV_bFhT0H2bQw@mail.gmail.com>
Message-ID: <574F398B.3020909@candelatech.com>

On 06/01/2016 12:33 PM, Adrian Chadd wrote:
> On 1 June 2016 at 12:29, Ben Greear <greearb at candelatech.com> wrote:
>> On 06/01/2016 12:18 PM, Adrian Chadd wrote:
>>>
>>> Hi,
>>>
>>> Likely a mix of both. Eg, the RX filter stuff as mentioned above may
>>> mean that you need to listen to /all/ frames for a BSS, rather than
>>> just say data and beacon frames. If the beacon frame matching logic
>>> checks the frame version, you need to listen to /all/ of the frames.
>>>
>>> For power management things, it's likely none of that will work, so
>>> you can't use things like auto-sleep based on beacon traffic / timers
>>> / TIM bitmap - you'd have to keep the NIC awake all the time.
>>
>>
>> I'm guessing little of this is in hardware, aside from rx filters,
>> so probably a few tweaks to the firmware would handle much of this...
>
> Right.
>
>> And, if for AP mode, then the NIC is always awake anyway, right?
>
> Right. But say, P2P/STA mode and no AP mode? Different story. (I'm
> assuming he has clients AND APs..)

Yeah, I'm less sure about that.  I still bet a few firmware tweaks
would resolve issues...surely the hardware is not baking a lot of
wifi frame constants into it's ROM...

> Also, for ath10k chips, maybe it'll all need to be in raw mode? I
> don't know what the hardware encap/decap engines will do if you try
> passing it intentionally different frames like this.

Beacons and probe responses are not encrypted anyway, so probably doesn't
need to disable hw-crypt.  Might be a fairly long tail of effort to
find every last place that makes some assumption on the values
though...

Thanks,
Ben

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



From mohammed at qti.qualcomm.com  Thu Jun  2 00:13:22 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Thu, 2 Jun 2016 12:43:22 +0530
Subject: [PATCH v3] ath10k: Fix 10.4 extended peer stats update
Message-ID: <1464851602-12969-1-git-send-email-mohammed@qca.qualcomm.com>

From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

10.4 'extended peer stats' will be not be appended with normal peer stats
data and they shall be coming in separate chunks. Fix this by maintaining
a separate linked list 'extender peer stats' for 10.4 and update
rx_duration for per station statistics. Also parse through beacon filter
(if enabled), to make sure we parse the extended peer stats properly.
This issue was exposed when more than one client is connected and
extended peer stats for 10.4 is enabled

The order for the stats is as below
S - standard peer stats, E- extended peer stats, B - beacon filter stats

{S1, S2, S3..} -> {B1, B2, B3..}(if available) -> {E1, E2, E3..}

Fixes: f9575793d44c ("ath10k: enable parsing per station rx duration for 10.4")
Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
---
[v1: addressed line wrap around comment from Kalle]
[v2: fixed ; in dummy inline function definition - thanks Sven Eckelmann]
[v3: removed wmi-op-version suggested by Kalle, introduced fw specifi hw param for extd_stats]

 drivers/net/wireless/ath/ath10k/core.c        |    3 ++
 drivers/net/wireless/ath/ath10k/core.h        |    9 +++++
 drivers/net/wireless/ath/ath10k/debug.c       |   18 ++++++++-
 drivers/net/wireless/ath/ath10k/debug.h       |    8 ++--
 drivers/net/wireless/ath/ath10k/debugfs_sta.c |   32 ++++++++++++++-
 drivers/net/wireless/ath/ath10k/wmi.c         |   53 ++++++++++++++++++-------
 drivers/net/wireless/ath/ath10k/wmi.h         |   14 ++++++-
 7 files changed, 117 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 9ccb69c..bfa96ac 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -181,6 +181,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
 			.board_size = QCA99X0_BOARD_DATA_SZ,
 			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+			.extd_peer_stats = true,
 		},
 	},
 	{
@@ -203,6 +204,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board = QCA9984_HW_1_0_BOARD_DATA_FILE,
 			.board_size = QCA99X0_BOARD_DATA_SZ,
 			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+			.extd_peer_stats = true,
 		},
 	},
 	{
@@ -261,6 +263,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
 			.board_size = QCA4019_BOARD_DATA_SZ,
 			.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
+			.extd_peer_stats = true,
 		},
 	},
 };
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index bbc4e0f..da9b2a9 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -165,6 +165,13 @@ struct ath10k_fw_stats_peer {
 	u32 rx_duration;
 };
 
+struct ath10k_fw_extd_stats_peer {
+	struct list_head list;
+
+	u8 peer_macaddr[ETH_ALEN];
+	u32 rx_duration;
+};
+
 struct ath10k_fw_stats_vdev {
 	struct list_head list;
 
@@ -259,6 +266,7 @@ struct ath10k_fw_stats {
 	struct list_head pdevs;
 	struct list_head vdevs;
 	struct list_head peers;
+	struct list_head peers_extd;
 };
 
 #define ATH10K_TPC_TABLE_TYPE_FLAG	1
@@ -752,6 +760,7 @@ struct ath10k {
 			const char *board;
 			size_t board_size;
 			size_t board_ext_size;
+			bool extd_peer_stats;
 		} fw;
 	} hw_params;
 
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 8fbb8f2..001c0a1 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -313,6 +313,16 @@ static void ath10k_fw_stats_peers_free(struct list_head *head)
 	}
 }
 
+static void ath10k_fw_extd_stats_peers_free(struct list_head *head)
+{
+	struct ath10k_fw_extd_stats_peer *i, *tmp;
+
+	list_for_each_entry_safe(i, tmp, head, list) {
+		list_del(&i->list);
+		kfree(i);
+	}
+}
+
 static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
 {
 	spin_lock_bh(&ar->data_lock);
@@ -320,6 +330,7 @@ static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
 	ath10k_fw_stats_pdevs_free(&ar->debug.fw_stats.pdevs);
 	ath10k_fw_stats_vdevs_free(&ar->debug.fw_stats.vdevs);
 	ath10k_fw_stats_peers_free(&ar->debug.fw_stats.peers);
+	ath10k_fw_extd_stats_peers_free(&ar->debug.fw_stats.peers_extd);
 	spin_unlock_bh(&ar->data_lock);
 }
 
@@ -334,6 +345,7 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
 	INIT_LIST_HEAD(&stats.pdevs);
 	INIT_LIST_HEAD(&stats.vdevs);
 	INIT_LIST_HEAD(&stats.peers);
+	INIT_LIST_HEAD(&stats.peers_extd);
 
 	spin_lock_bh(&ar->data_lock);
 	ret = ath10k_wmi_pull_fw_stats(ar, skb, &stats);
@@ -354,7 +366,7 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
 	 *     delivered which is treated as end-of-data and is itself discarded
 	 */
 	if (ath10k_peer_stats_enabled(ar))
-		ath10k_sta_update_rx_duration(ar, &stats.peers);
+		ath10k_sta_update_rx_duration(ar, &stats);
 
 	if (ar->debug.fw_stats_done) {
 		if (!ath10k_peer_stats_enabled(ar))
@@ -396,6 +408,8 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
 
 		list_splice_tail_init(&stats.peers, &ar->debug.fw_stats.peers);
 		list_splice_tail_init(&stats.vdevs, &ar->debug.fw_stats.vdevs);
+		list_splice_tail_init(&stats.peers_extd,
+				      &ar->debug.fw_stats.peers_extd);
 	}
 
 	complete(&ar->debug.fw_stats_complete);
@@ -407,6 +421,7 @@ free:
 	ath10k_fw_stats_pdevs_free(&stats.pdevs);
 	ath10k_fw_stats_vdevs_free(&stats.vdevs);
 	ath10k_fw_stats_peers_free(&stats.peers);
+	ath10k_fw_extd_stats_peers_free(&stats.peers_extd);
 
 	spin_unlock_bh(&ar->data_lock);
 }
@@ -2330,6 +2345,7 @@ int ath10k_debug_create(struct ath10k *ar)
 	INIT_LIST_HEAD(&ar->debug.fw_stats.pdevs);
 	INIT_LIST_HEAD(&ar->debug.fw_stats.vdevs);
 	INIT_LIST_HEAD(&ar->debug.fw_stats.peers);
+	INIT_LIST_HEAD(&ar->debug.fw_stats.peers_extd);
 
 	return 0;
 }
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 75c89e3..dc549c4 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -154,10 +154,12 @@ ath10k_debug_get_new_fw_crash_data(struct ath10k *ar)
 #ifdef CONFIG_MAC80211_DEBUGFS
 void ath10k_sta_add_debugfs(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
 			    struct ieee80211_sta *sta, struct dentry *dir);
-void ath10k_sta_update_rx_duration(struct ath10k *ar, struct list_head *peer);
+void ath10k_sta_update_rx_duration(struct ath10k *ar,
+				   struct ath10k_fw_stats *stats);
 #else
-static inline void ath10k_sta_update_rx_duration(struct ath10k *ar,
-						 struct list_head *peer)
+static inline
+void ath10k_sta_update_rx_duration(struct ath10k *ar,
+				   struct ath10k_fw_stats *stats)
 {
 }
 #endif /* CONFIG_MAC80211_DEBUGFS */
diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
index 67ef75b..af3d49a 100644
--- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
+++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
@@ -18,7 +18,27 @@
 #include "wmi-ops.h"
 #include "debug.h"
 
-void ath10k_sta_update_rx_duration(struct ath10k *ar, struct list_head *head)
+static void ath10k_sta_update_extd_stats_rx_duration(struct ath10k *ar,
+						     struct list_head *head)
+{
+	struct ieee80211_sta *sta;
+	struct ath10k_fw_extd_stats_peer *peer;
+	struct ath10k_sta *arsta;
+
+	rcu_read_lock();
+	list_for_each_entry(peer, head, list) {
+		sta = ieee80211_find_sta_by_ifaddr(ar->hw, peer->peer_macaddr,
+						   NULL);
+		if (!sta)
+			continue;
+		arsta = (struct ath10k_sta *)sta->drv_priv;
+		arsta->rx_duration += (u64)peer->rx_duration;
+	}
+	rcu_read_unlock();
+}
+
+static void ath10k_sta_update_stats_rx_duration(struct ath10k *ar,
+						struct list_head *head)
 {	struct ieee80211_sta *sta;
 	struct ath10k_fw_stats_peer *peer;
 	struct ath10k_sta *arsta;
@@ -35,6 +55,16 @@ void ath10k_sta_update_rx_duration(struct ath10k *ar, struct list_head *head)
 	rcu_read_unlock();
 }
 
+void ath10k_sta_update_rx_duration(struct ath10k *ar,
+				   struct ath10k_fw_stats *stats)
+{
+	if (ar->hw_params.fw.extd_peer_stats)
+		ath10k_sta_update_stats_rx_duration(ar, &stats->peers);
+	else
+		ath10k_sta_update_extd_stats_rx_duration(ar,
+							 &stats->peers_extd);
+}
+
 static ssize_t ath10k_dbg_sta_read_aggr_mode(struct file *file,
 					     char __user *user_buf,
 					     size_t count, loff_t *ppos)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 6279ab4..5f2d423 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2924,6 +2924,7 @@ static int ath10k_wmi_10_4_op_pull_fw_stats(struct ath10k *ar,
 	u32 num_pdev_ext_stats;
 	u32 num_vdev_stats;
 	u32 num_peer_stats;
+	u32 num_bcnflt_stats;
 	u32 stats_id;
 	int i;
 
@@ -2934,6 +2935,7 @@ static int ath10k_wmi_10_4_op_pull_fw_stats(struct ath10k *ar,
 	num_pdev_ext_stats = __le32_to_cpu(ev->num_pdev_ext_stats);
 	num_vdev_stats = __le32_to_cpu(ev->num_vdev_stats);
 	num_peer_stats = __le32_to_cpu(ev->num_peer_stats);
+	num_bcnflt_stats = __le32_to_cpu(ev->num_bcnflt_stats);
 	stats_id = __le32_to_cpu(ev->stats_id);
 
 	for (i = 0; i < num_pdev_stats; i++) {
@@ -2974,32 +2976,55 @@ static int ath10k_wmi_10_4_op_pull_fw_stats(struct ath10k *ar,
 	/* fw doesn't implement vdev stats */
 
 	for (i = 0; i < num_peer_stats; i++) {
-		const struct wmi_10_4_peer_extd_stats *src;
+		const struct wmi_10_4_peer_stats *src;
 		struct ath10k_fw_stats_peer *dst;
-		int stats_len;
-		bool extd_peer_stats = !!(stats_id & WMI_10_4_STAT_PEER_EXTD);
-
-		if (extd_peer_stats)
-			stats_len = sizeof(struct wmi_10_4_peer_extd_stats);
-		else
-			stats_len = sizeof(struct wmi_10_4_peer_stats);
 
 		src = (void *)skb->data;
-		if (!skb_pull(skb, stats_len))
+		if (!skb_pull(skb, sizeof(*src)))
 			return -EPROTO;
 
 		dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
 		if (!dst)
 			continue;
 
-		ath10k_wmi_10_4_pull_peer_stats(&src->common, dst);
-		/* FIXME: expose 10.4 specific values */
-		if (extd_peer_stats)
-			dst->rx_duration = __le32_to_cpu(src->rx_duration);
-
+		ath10k_wmi_10_4_pull_peer_stats(src, dst);
 		list_add_tail(&dst->list, &stats->peers);
 	}
 
+	for (i = 0; i < num_bcnflt_stats; i++) {
+		const struct wmi_10_4_bss_bcn_filter_stats *src;
+
+		src = (void *)skb->data;
+		if (!skb_pull(skb, sizeof(*src)))
+			return -EPROTO;
+
+		/* FIXME: expose values to userspace
+		 *
+		 * Note: Even though this loop seems to do nothing it is
+		 * required to parse following sub-structures properly.
+		 */
+	}
+
+	if ((stats_id & WMI_10_4_STAT_PEER_EXTD) == 0)
+		return 0;
+
+	for (i = 0; i < num_peer_stats; i++) {
+		const struct wmi_10_4_peer_extd_stats *src;
+		struct ath10k_fw_extd_stats_peer *dst;
+
+		src = (void *)skb->data;
+		if (!skb_pull(skb, sizeof(*src)))
+			return -EPROTO;
+
+		dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
+		if (!dst)
+			continue;
+
+		ether_addr_copy(dst->peer_macaddr, src->peer_macaddr.addr);
+		dst->rx_duration = __le32_to_cpu(src->rx_duration);
+		list_add_tail(&dst->list, &stats->peers_extd);
+	}
+
 	return 0;
 }
 
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 90f594e..3ef4688 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4340,7 +4340,6 @@ struct wmi_10_4_peer_stats {
 } __packed;
 
 struct wmi_10_4_peer_extd_stats {
-	struct wmi_10_4_peer_stats common;
 	struct wmi_mac_addr peer_macaddr;
 	__le32 inactive_time;
 	__le32 peer_chain_rssi;
@@ -4348,6 +4347,19 @@ struct wmi_10_4_peer_extd_stats {
 	__le32 reserved[10];
 } __packed;
 
+struct wmi_10_4_bss_bcn_stats {
+	__le32 vdev_id;
+	__le32 bss_bcns_dropped;
+	__le32 bss_bcn_delivered;
+} __packed;
+
+struct wmi_10_4_bss_bcn_filter_stats {
+	__le32 bcns_dropped;
+	__le32 bcns_delivered;
+	__le32 active_filters;
+	struct wmi_10_4_bss_bcn_stats bss_stats;
+} __packed;
+
 struct wmi_10_2_pdev_ext_stats {
 	__le32 rx_rssi_comb;
 	__le32 rx_rssi[4];
-- 
1.7.9.5



From mohammed at qti.qualcomm.com  Thu Jun  2 00:23:54 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Thu, 2 Jun 2016 12:53:54 +0530
Subject: [PATCH v2 1/2] ath10k: remove duplicate and unused rx rate flags
Message-ID: <1464852235-13110-1-git-send-email-mohammed@qca.qualcomm.com>

From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

All these flags are not used and their use is completely
covered by 'ath10k_hw_rate_ofdm', 'ath10k_hw_rate_cck',
and RX_PPDU_START_RATE_FLAG

Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
Patchwork-Id: 9129361
Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/rx_desc.h |   39 -----------------------------
 1 file changed, 39 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/rx_desc.h b/drivers/net/wireless/ath/ath10k/rx_desc.h
index 9ceebea..034e7a5 100644
--- a/drivers/net/wireless/ath/ath10k/rx_desc.h
+++ b/drivers/net/wireless/ath/ath10k/rx_desc.h
@@ -656,26 +656,6 @@ struct rx_msdu_end {
  *		Reserved: HW should fill with zero.  FW should ignore.
  */
 
-#define RX_PPDU_START_SIG_RATE_SELECT_OFDM 0
-#define RX_PPDU_START_SIG_RATE_SELECT_CCK  1
-
-#define RX_PPDU_START_SIG_RATE_OFDM_48 0
-#define RX_PPDU_START_SIG_RATE_OFDM_24 1
-#define RX_PPDU_START_SIG_RATE_OFDM_12 2
-#define RX_PPDU_START_SIG_RATE_OFDM_6  3
-#define RX_PPDU_START_SIG_RATE_OFDM_54 4
-#define RX_PPDU_START_SIG_RATE_OFDM_36 5
-#define RX_PPDU_START_SIG_RATE_OFDM_18 6
-#define RX_PPDU_START_SIG_RATE_OFDM_9  7
-
-#define RX_PPDU_START_SIG_RATE_CCK_LP_11  0
-#define RX_PPDU_START_SIG_RATE_CCK_LP_5_5 1
-#define RX_PPDU_START_SIG_RATE_CCK_LP_2   2
-#define RX_PPDU_START_SIG_RATE_CCK_LP_1   3
-#define RX_PPDU_START_SIG_RATE_CCK_SP_11  4
-#define RX_PPDU_START_SIG_RATE_CCK_SP_5_5 5
-#define RX_PPDU_START_SIG_RATE_CCK_SP_2   6
-
 #define HTT_RX_PPDU_START_PREAMBLE_LEGACY        0x04
 #define HTT_RX_PPDU_START_PREAMBLE_HT            0x08
 #define HTT_RX_PPDU_START_PREAMBLE_HT_WITH_TXBF  0x09
@@ -711,25 +691,6 @@ struct rx_msdu_end {
 /* No idea what this flag means. It seems to be always set in rate. */
 #define RX_PPDU_START_RATE_FLAG BIT(3)
 
-enum rx_ppdu_start_rate {
-	RX_PPDU_START_RATE_OFDM_48M = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_OFDM_48M,
-	RX_PPDU_START_RATE_OFDM_24M = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_OFDM_24M,
-	RX_PPDU_START_RATE_OFDM_12M = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_OFDM_12M,
-	RX_PPDU_START_RATE_OFDM_6M  = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_OFDM_6M,
-	RX_PPDU_START_RATE_OFDM_54M = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_OFDM_54M,
-	RX_PPDU_START_RATE_OFDM_36M = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_OFDM_36M,
-	RX_PPDU_START_RATE_OFDM_18M = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_OFDM_18M,
-	RX_PPDU_START_RATE_OFDM_9M  = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_OFDM_9M,
-
-	RX_PPDU_START_RATE_CCK_LP_11M  = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_CCK_LP_11M,
-	RX_PPDU_START_RATE_CCK_LP_5_5M = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_CCK_LP_5_5M,
-	RX_PPDU_START_RATE_CCK_LP_2M   = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_CCK_LP_2M,
-	RX_PPDU_START_RATE_CCK_LP_1M   = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_CCK_LP_1M,
-	RX_PPDU_START_RATE_CCK_SP_11M  = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_CCK_SP_11M,
-	RX_PPDU_START_RATE_CCK_SP_5_5M = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_CCK_SP_5_5M,
-	RX_PPDU_START_RATE_CCK_SP_2M   = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_CCK_SP_2M,
-};
-
 struct rx_ppdu_start {
 	struct {
 		u8 pri20_mhz;
-- 
1.7.9.5



From mohammed at qti.qualcomm.com  Thu Jun  2 00:23:55 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Thu, 2 Jun 2016 12:53:55 +0530
Subject: [PATCH v2 2/2] ath10k: fix CCK h/w rates for QCA99X0 and newer
 chipsets
In-Reply-To: <1464852235-13110-1-git-send-email-mohammed@qca.qualcomm.com>
References: <1464852235-13110-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <1464852235-13110-2-git-send-email-mohammed@qca.qualcomm.com>

From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

CCK hardware table mapping from QCA99X0 onwards got revised.
The CCK hardware rate values are in a proper order wrt. to
rate and preamble as below

ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
ATH10K_HW_RATE_REV2_CCK_LP_2M = 2,
ATH10K_HW_RATE_REV2_CCK_LP_5_5M = 3,
ATH10K_HW_RATE_REV2_CCK_LP_11M = 4,
ATH10K_HW_RATE_REV2_CCK_SP_2M = 5,
ATH10K_HW_RATE_REV2_CCK_SP_5_5M = 6,
ATH10K_HW_RATE_REV2_CCK_SP_11M = 7,

This results in reporting of rx frames (with CCK rates)
totally wrong for QCA99X0, QCA4019. Fix this by having
separate CCK rate table for these chipsets with rev2 suffix
and registering the correct rate mapping to mac80211 based on
the new hw_param (introduced) 'cck_rate_map_rev2' which shall
be true for any newchipsets from QCA99X0 onwards

Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
---
[v2: Enabled the fix for QCA9984 - thanks Kalle]

 drivers/net/wireless/ath/ath10k/core.c |    3 +++
 drivers/net/wireless/ath/ath10k/core.h |    6 +++++
 drivers/net/wireless/ath/ath10k/hw.h   |   10 ++++++++
 drivers/net/wireless/ath/ath10k/mac.c  |   39 ++++++++++++++++++++++++++++++--
 4 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index a003980..2692243 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -148,6 +148,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.uart_pin = 7,
 		.otp_exe_param = 0x00000700,
 		.continuous_frag_desc = true,
+		.cck_rate_map_rev2 = true,
 		.channel_counters_freq_hz = 150000,
 		.max_probe_resp_desc_thres = 24,
 		.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
@@ -170,6 +171,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.uart_pin = 7,
 		.otp_exe_param = 0x00000700,
 		.continuous_frag_desc = true,
+		.cck_rate_map_rev2 = true,
 		.channel_counters_freq_hz = 150000,
 		.max_probe_resp_desc_thres = 24,
 		.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
@@ -227,6 +229,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.has_shifted_cc_wraparound = true,
 		.otp_exe_param = 0x0010000,
 		.continuous_frag_desc = true,
+		.cck_rate_map_rev2 = true,
 		.channel_counters_freq_hz = 125000,
 		.max_probe_resp_desc_thres = 24,
 		.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 1852e0e..04cea23 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -716,6 +716,12 @@ struct ath10k {
 		 */
 		bool continuous_frag_desc;
 
+		/* CCK hardware rate table mapping for the newer chipsets
+		 * like QCA99X0, QCA4019 got revised. The CCK h/w rate values
+		 * are in a proper order with respect to the rate/preamble
+		 */
+		bool cck_rate_map_rev2;
+
 		u32 channel_counters_freq_hz;
 
 		/* Mgmt tx descriptors threshold for limiting probe response
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index f41c91c..4ed5be9 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -326,6 +326,16 @@ enum ath10k_hw_rate_cck {
 	ATH10K_HW_RATE_CCK_SP_2M,
 };
 
+enum ath10k_hw_rate_rev2_cck {
+	ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
+	ATH10K_HW_RATE_REV2_CCK_LP_2M,
+	ATH10K_HW_RATE_REV2_CCK_LP_5_5M,
+	ATH10K_HW_RATE_REV2_CCK_LP_11M,
+	ATH10K_HW_RATE_REV2_CCK_SP_2M,
+	ATH10K_HW_RATE_REV2_CCK_SP_5_5M,
+	ATH10K_HW_RATE_REV2_CCK_SP_11M,
+};
+
 enum ath10k_hw_4addr_pad {
 	ATH10K_HW_4ADDR_PAD_AFTER,
 	ATH10K_HW_4ADDR_PAD_BEFORE,
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 1dd415d..e7162db 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -62,6 +62,32 @@ static struct ieee80211_rate ath10k_rates[] = {
 	{ .bitrate = 540, .hw_value = ATH10K_HW_RATE_OFDM_54M },
 };
 
+static struct ieee80211_rate ath10k_rates_rev2[] = {
+	{ .bitrate = 10,
+	  .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_1M },
+	{ .bitrate = 20,
+	  .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_2M,
+	  .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_2M,
+	  .flags = IEEE80211_RATE_SHORT_PREAMBLE },
+	{ .bitrate = 55,
+	  .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_5_5M,
+	  .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_5_5M,
+	  .flags = IEEE80211_RATE_SHORT_PREAMBLE },
+	{ .bitrate = 110,
+	  .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_11M,
+	  .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_11M,
+	  .flags = IEEE80211_RATE_SHORT_PREAMBLE },
+
+	{ .bitrate = 60, .hw_value = ATH10K_HW_RATE_OFDM_6M },
+	{ .bitrate = 90, .hw_value = ATH10K_HW_RATE_OFDM_9M },
+	{ .bitrate = 120, .hw_value = ATH10K_HW_RATE_OFDM_12M },
+	{ .bitrate = 180, .hw_value = ATH10K_HW_RATE_OFDM_18M },
+	{ .bitrate = 240, .hw_value = ATH10K_HW_RATE_OFDM_24M },
+	{ .bitrate = 360, .hw_value = ATH10K_HW_RATE_OFDM_36M },
+	{ .bitrate = 480, .hw_value = ATH10K_HW_RATE_OFDM_48M },
+	{ .bitrate = 540, .hw_value = ATH10K_HW_RATE_OFDM_54M },
+};
+
 #define ATH10K_MAC_FIRST_OFDM_RATE_IDX 4
 
 #define ath10k_a_rates (ath10k_rates + ATH10K_MAC_FIRST_OFDM_RATE_IDX)
@@ -70,6 +96,9 @@ static struct ieee80211_rate ath10k_rates[] = {
 #define ath10k_g_rates (ath10k_rates + 0)
 #define ath10k_g_rates_size (ARRAY_SIZE(ath10k_rates))
 
+#define ath10k_g_rates_rev2 (ath10k_rates_rev2 + 0)
+#define ath10k_g_rates_rev2_size (ARRAY_SIZE(ath10k_rates_rev2))
+
 static bool ath10k_mac_bitrate_is_cck(int bitrate)
 {
 	switch (bitrate) {
@@ -7696,8 +7725,14 @@ int ath10k_mac_register(struct ath10k *ar)
 		band = &ar->mac.sbands[NL80211_BAND_2GHZ];
 		band->n_channels = ARRAY_SIZE(ath10k_2ghz_channels);
 		band->channels = channels;
-		band->n_bitrates = ath10k_g_rates_size;
-		band->bitrates = ath10k_g_rates;
+
+		if (ar->hw_params.cck_rate_map_rev2) {
+			band->n_bitrates = ath10k_g_rates_rev2_size;
+			band->bitrates = ath10k_g_rates_rev2;
+		} else {
+			band->n_bitrates = ath10k_g_rates_size;
+			band->bitrates = ath10k_g_rates;
+		}
 
 		ar->hw->wiphy->bands[NL80211_BAND_2GHZ] = band;
 	}
-- 
1.7.9.5



From e0926020 at student.tuwien.ac.at  Thu Jun  2 00:27:05 2016
From: e0926020 at student.tuwien.ac.at (Stefan Feirer)
Date: Thu, 2 Jun 2016 09:27:05 +0200
Subject: Support of 802.11k
Message-ID: <574FDFC9.1070801@student.tuwien.ac.at>

Hello,

I'm currently working on my master thesis at vienna university of 
technology.
Topic of my work is building a prototype to measure wifi roaming 
performance with 802.11k (Radio Resouce Management) and 802.11r protocol 
amendments.
My hardware setup uses the PCIe Wifi Card Compex WLE600VX with QCA9882 
Chipset and ath10k_pci kernel module.
Operating System is Ubuntu 15.10 with Kernel Version 4.2.

With my setup 802.11r is working well with wpa_supplicant but I'm not 
able to get 802.11k working.
As I already mentioned I'm using the ath10k kernel module with firmware 
version 10.2.4.45.

I suppose 802.11k (RRM) is not working because it is not supported by 
the firmware.
The reason of my guess is the following:
When I looked through the ath10k source code for RRM support I found out 
that in the file wmi.c there are the structs
  - wmi_cmd_map
  - wmi_10x_cmd_map
  - wmi_10_2_4_cmd_map

In the last two the function bcn_tmpl_cmdid and prb_tmpl_cmdid both are 
not supported (and I use firmware version 10.2.4) and these use the 
struct wmi_bcn_prb_info (wmi.h) which includes the rrm info.

This leads me to two questions:
- Am I right, that the firmware does not support 802.11k or should 
802.11k be supported by the QCA9882 Chipset and the atheros firmware and 
kernel modules?
- Are there any atheros wifi modules which were successfully tested with 
802.11k?

Hopefully someone can help me with this!
Thanks
Stefan Feirer



From vthiagar at qti.qualcomm.com  Thu Jun  2 05:20:25 2016
From: vthiagar at qti.qualcomm.com (Vasanthakumar Thiagarajan)
Date: Thu, 2 Jun 2016 17:50:25 +0530
Subject: [PATCH] ath10k: Fix some of the macro definitions of HTT_RX_IND
 message
Message-ID: <1464870025-4557-1-git-send-email-vthiagar@qti.qualcomm.com>

Only five bits are defined to pass tid information in HTT_RX_IND
message, so the mask which can be used to extract tid should be 0x1f
instead of the current 0x3f. Also, macros which can be used to extract
flush_valid and release_valid bits have to be left shifted one bit less
because these information follow the tid right after. This patch does
not really fix anything functionally because these macros are not used
currently.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/htt.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 911c535..430a83e 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -485,10 +485,10 @@ struct htt_mgmt_tx_completion {
 	__le32 status;
 } __packed;
 
-#define HTT_RX_INDICATION_INFO0_EXT_TID_MASK  (0x3F)
+#define HTT_RX_INDICATION_INFO0_EXT_TID_MASK  (0x1F)
 #define HTT_RX_INDICATION_INFO0_EXT_TID_LSB   (0)
-#define HTT_RX_INDICATION_INFO0_FLUSH_VALID   (1 << 6)
-#define HTT_RX_INDICATION_INFO0_RELEASE_VALID (1 << 7)
+#define HTT_RX_INDICATION_INFO0_FLUSH_VALID   (1 << 5)
+#define HTT_RX_INDICATION_INFO0_RELEASE_VALID (1 << 6)
 
 #define HTT_RX_INDICATION_INFO1_FLUSH_START_SEQNO_MASK   0x0000003F
 #define HTT_RX_INDICATION_INFO1_FLUSH_START_SEQNO_LSB    0
-- 
1.9.1



From kvalo at qca.qualcomm.com  Thu Jun  2 06:14:27 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 2 Jun 2016 13:14:27 +0000
Subject: [RFC/RFT] ath10k: disable wake_tx_queue for older devices
In-Reply-To: <1463489221-24989-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Tue, 17 May 2016 14:47:01 +0200")
References: <1463489221-24989-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87inxrzqa5.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> Some setups suffer performance regressions with
> current wake_tx_queue implementation.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
> ---
> Hi Roman,
>
> Can you give this patch a try and see if it helps
> with your performance problems, please?

Did anyone seeing the performance regression manage to test this? It
would be good to get feedback, good or bad, before I push this to 4.7.

Full patch here:

https://patchwork.kernel.org/patch/9111981/

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Thu Jun  2 06:45:15 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 2 Jun 2016 13:45:15 +0000
Subject: [PATCH v2 1/2] ath10k: remove duplicate and unused rx rate flags
In-Reply-To: <1464852235-13110-1-git-send-email-mohammed@qca.qualcomm.com>
 (Mohammed Shafi Shajakhan's message of "Thu, 2 Jun 2016 12:53:54	+0530")
References: <1464852235-13110-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <87a8j3zout.fsf@kamboji.qca.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> writes:

> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
>
> All these flags are not used and their use is completely
> covered by 'ath10k_hw_rate_ofdm', 'ath10k_hw_rate_cck',
> and RX_PPDU_START_RATE_FLAG
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> Patchwork-Id: 9129361
> Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>

I guess you took this patch from the pending branch? :) The Patchwork-Id
line is something which my script adds for patches in the pending
branch, and removes them before applying them to ath-next, but this line
should not be visible when submitting patches.

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Thu Jun  2 06:52:24 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 2 Jun 2016 13:52:24 +0000
Subject: Bug 119151 - [regression] ath10k no longer authenitcates and freezes
 system
Message-ID: <8760trzoiw.fsf@kamboji.qca.qualcomm.com>

Hi,

there's a regression in ath10k:

https://bugzilla.kernel.org/show_bug.cgi?id=119151

Reporter bisected it to this:

5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit
commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183
Author: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
Date:   Tue Mar 22 17:22:19 2016 +0530

ath10k: combine txrx and replenish task

Since tx completion and rx indication processing are moved out
of txrx tasklet and rx ring lock contention also removed from txrx
for rx_ind messages, it would be efficient to combine both replenish
and txrx tasks. Refill threshold is adjusted for both AP135 and AP148
(low and high end systems). With this adjustment in AP135, TCP DL is
improved from 603 Mbps to 620 Mbps and UDP DL is improved from 758 Mbps
to 803 Mbps. Also no watchdog are observed on UDP BiDi.

Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>

-- 
Kalle Valo

From mohammed at qti.qualcomm.com  Thu Jun  2 07:24:41 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Thu, 2 Jun 2016 19:54:41 +0530
Subject: [PATCH v3 1/2] ath10k: remove duplicate and unused rx rate flags
Message-ID: <1464877482-14620-1-git-send-email-mohammed@qca.qualcomm.com>

From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

All these flags are not used and their use is completely
covered by 'ath10k_hw_rate_ofdm', 'ath10k_hw_rate_cck',
and RX_PPDU_START_RATE_FLAG

Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/rx_desc.h |   39 -----------------------------
 1 file changed, 39 deletions(-)

[v3: removing patch id]

diff --git a/drivers/net/wireless/ath/ath10k/rx_desc.h b/drivers/net/wireless/ath/ath10k/rx_desc.h
index 9ceebea..034e7a5 100644
--- a/drivers/net/wireless/ath/ath10k/rx_desc.h
+++ b/drivers/net/wireless/ath/ath10k/rx_desc.h
@@ -656,26 +656,6 @@ struct rx_msdu_end {
  *		Reserved: HW should fill with zero.  FW should ignore.
  */
 
-#define RX_PPDU_START_SIG_RATE_SELECT_OFDM 0
-#define RX_PPDU_START_SIG_RATE_SELECT_CCK  1
-
-#define RX_PPDU_START_SIG_RATE_OFDM_48 0
-#define RX_PPDU_START_SIG_RATE_OFDM_24 1
-#define RX_PPDU_START_SIG_RATE_OFDM_12 2
-#define RX_PPDU_START_SIG_RATE_OFDM_6  3
-#define RX_PPDU_START_SIG_RATE_OFDM_54 4
-#define RX_PPDU_START_SIG_RATE_OFDM_36 5
-#define RX_PPDU_START_SIG_RATE_OFDM_18 6
-#define RX_PPDU_START_SIG_RATE_OFDM_9  7
-
-#define RX_PPDU_START_SIG_RATE_CCK_LP_11  0
-#define RX_PPDU_START_SIG_RATE_CCK_LP_5_5 1
-#define RX_PPDU_START_SIG_RATE_CCK_LP_2   2
-#define RX_PPDU_START_SIG_RATE_CCK_LP_1   3
-#define RX_PPDU_START_SIG_RATE_CCK_SP_11  4
-#define RX_PPDU_START_SIG_RATE_CCK_SP_5_5 5
-#define RX_PPDU_START_SIG_RATE_CCK_SP_2   6
-
 #define HTT_RX_PPDU_START_PREAMBLE_LEGACY        0x04
 #define HTT_RX_PPDU_START_PREAMBLE_HT            0x08
 #define HTT_RX_PPDU_START_PREAMBLE_HT_WITH_TXBF  0x09
@@ -711,25 +691,6 @@ struct rx_msdu_end {
 /* No idea what this flag means. It seems to be always set in rate. */
 #define RX_PPDU_START_RATE_FLAG BIT(3)
 
-enum rx_ppdu_start_rate {
-	RX_PPDU_START_RATE_OFDM_48M = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_OFDM_48M,
-	RX_PPDU_START_RATE_OFDM_24M = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_OFDM_24M,
-	RX_PPDU_START_RATE_OFDM_12M = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_OFDM_12M,
-	RX_PPDU_START_RATE_OFDM_6M  = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_OFDM_6M,
-	RX_PPDU_START_RATE_OFDM_54M = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_OFDM_54M,
-	RX_PPDU_START_RATE_OFDM_36M = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_OFDM_36M,
-	RX_PPDU_START_RATE_OFDM_18M = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_OFDM_18M,
-	RX_PPDU_START_RATE_OFDM_9M  = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_OFDM_9M,
-
-	RX_PPDU_START_RATE_CCK_LP_11M  = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_CCK_LP_11M,
-	RX_PPDU_START_RATE_CCK_LP_5_5M = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_CCK_LP_5_5M,
-	RX_PPDU_START_RATE_CCK_LP_2M   = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_CCK_LP_2M,
-	RX_PPDU_START_RATE_CCK_LP_1M   = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_CCK_LP_1M,
-	RX_PPDU_START_RATE_CCK_SP_11M  = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_CCK_SP_11M,
-	RX_PPDU_START_RATE_CCK_SP_5_5M = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_CCK_SP_5_5M,
-	RX_PPDU_START_RATE_CCK_SP_2M   = RX_PPDU_START_RATE_FLAG | ATH10K_HW_RATE_CCK_SP_2M,
-};
-
 struct rx_ppdu_start {
 	struct {
 		u8 pri20_mhz;
-- 
1.7.9.5



From mohammed at codeaurora.org  Thu Jun  2 07:22:32 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Thu, 2 Jun 2016 19:52:32 +0530
Subject: [PATCH v2 1/2] ath10k: remove duplicate and unused rx rate flags
In-Reply-To: <87a8j3zout.fsf@kamboji.qca.qualcomm.com>
References: <1464852235-13110-1-git-send-email-mohammed@qca.qualcomm.com>
 <87a8j3zout.fsf@kamboji.qca.qualcomm.com>
Message-ID: <20160602142232.GA4729@atheros-ThinkPad-T61>

On Thu, Jun 02, 2016 at 01:45:15PM +0000, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> writes:
> 
> > From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> >
> > All these flags are not used and their use is completely
> > covered by 'ath10k_hw_rate_ofdm', 'ath10k_hw_rate_cck',
> > and RX_PPDU_START_RATE_FLAG
> >
> > Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> > Patchwork-Id: 9129361
> > Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>
> 
> I guess you took this patch from the pending branch? :) The Patchwork-Id
> line is something which my script adds for patches in the pending
> branch, and removes them before applying them to ath-next, but this line
> should not be visible when submitting patches.
>
[shafi] yes i am sorry :-( will send v3.

regards,
shafi


From mohammed at qti.qualcomm.com  Thu Jun  2 07:24:42 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Thu, 2 Jun 2016 19:54:42 +0530
Subject: [PATCH v3 2/2] ath10k: fix CCK h/w rates for QCA99X0 and newer
 chipsets
In-Reply-To: <1464877482-14620-1-git-send-email-mohammed@qca.qualcomm.com>
References: <1464877482-14620-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <1464877482-14620-2-git-send-email-mohammed@qca.qualcomm.com>

From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

CCK hardware table mapping from QCA99X0 onwards got revised.
The CCK hardware rate values are in a proper order wrt. to
rate and preamble as below

ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
ATH10K_HW_RATE_REV2_CCK_LP_2M = 2,
ATH10K_HW_RATE_REV2_CCK_LP_5_5M = 3,
ATH10K_HW_RATE_REV2_CCK_LP_11M = 4,
ATH10K_HW_RATE_REV2_CCK_SP_2M = 5,
ATH10K_HW_RATE_REV2_CCK_SP_5_5M = 6,
ATH10K_HW_RATE_REV2_CCK_SP_11M = 7,

This results in reporting of rx frames (with CCK rates)
totally wrong for QCA99X0, QCA4019. Fix this by having
separate CCK rate table for these chipsets with rev2 suffix
and registering the correct rate mapping to mac80211 based on
the new hw_param (introduced) 'cck_rate_map_rev2' which shall
be true for any newchipsets from QCA99X0 onwards

Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
---
[v2: Enabled the fix for QCA9984 - thanks Kalle]
[v3: removed patch id]

 drivers/net/wireless/ath/ath10k/core.c |    3 +++
 drivers/net/wireless/ath/ath10k/core.h |    6 +++++
 drivers/net/wireless/ath/ath10k/hw.h   |   10 ++++++++
 drivers/net/wireless/ath/ath10k/mac.c  |   39 ++++++++++++++++++++++++++++++--
 4 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index a003980..2692243 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -148,6 +148,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.uart_pin = 7,
 		.otp_exe_param = 0x00000700,
 		.continuous_frag_desc = true,
+		.cck_rate_map_rev2 = true,
 		.channel_counters_freq_hz = 150000,
 		.max_probe_resp_desc_thres = 24,
 		.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
@@ -170,6 +171,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.uart_pin = 7,
 		.otp_exe_param = 0x00000700,
 		.continuous_frag_desc = true,
+		.cck_rate_map_rev2 = true,
 		.channel_counters_freq_hz = 150000,
 		.max_probe_resp_desc_thres = 24,
 		.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
@@ -227,6 +229,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.has_shifted_cc_wraparound = true,
 		.otp_exe_param = 0x0010000,
 		.continuous_frag_desc = true,
+		.cck_rate_map_rev2 = true,
 		.channel_counters_freq_hz = 125000,
 		.max_probe_resp_desc_thres = 24,
 		.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 1852e0e..04cea23 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -716,6 +716,12 @@ struct ath10k {
 		 */
 		bool continuous_frag_desc;
 
+		/* CCK hardware rate table mapping for the newer chipsets
+		 * like QCA99X0, QCA4019 got revised. The CCK h/w rate values
+		 * are in a proper order with respect to the rate/preamble
+		 */
+		bool cck_rate_map_rev2;
+
 		u32 channel_counters_freq_hz;
 
 		/* Mgmt tx descriptors threshold for limiting probe response
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index f41c91c..4ed5be9 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -326,6 +326,16 @@ enum ath10k_hw_rate_cck {
 	ATH10K_HW_RATE_CCK_SP_2M,
 };
 
+enum ath10k_hw_rate_rev2_cck {
+	ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
+	ATH10K_HW_RATE_REV2_CCK_LP_2M,
+	ATH10K_HW_RATE_REV2_CCK_LP_5_5M,
+	ATH10K_HW_RATE_REV2_CCK_LP_11M,
+	ATH10K_HW_RATE_REV2_CCK_SP_2M,
+	ATH10K_HW_RATE_REV2_CCK_SP_5_5M,
+	ATH10K_HW_RATE_REV2_CCK_SP_11M,
+};
+
 enum ath10k_hw_4addr_pad {
 	ATH10K_HW_4ADDR_PAD_AFTER,
 	ATH10K_HW_4ADDR_PAD_BEFORE,
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 1dd415d..e7162db 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -62,6 +62,32 @@ static struct ieee80211_rate ath10k_rates[] = {
 	{ .bitrate = 540, .hw_value = ATH10K_HW_RATE_OFDM_54M },
 };
 
+static struct ieee80211_rate ath10k_rates_rev2[] = {
+	{ .bitrate = 10,
+	  .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_1M },
+	{ .bitrate = 20,
+	  .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_2M,
+	  .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_2M,
+	  .flags = IEEE80211_RATE_SHORT_PREAMBLE },
+	{ .bitrate = 55,
+	  .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_5_5M,
+	  .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_5_5M,
+	  .flags = IEEE80211_RATE_SHORT_PREAMBLE },
+	{ .bitrate = 110,
+	  .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_11M,
+	  .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_11M,
+	  .flags = IEEE80211_RATE_SHORT_PREAMBLE },
+
+	{ .bitrate = 60, .hw_value = ATH10K_HW_RATE_OFDM_6M },
+	{ .bitrate = 90, .hw_value = ATH10K_HW_RATE_OFDM_9M },
+	{ .bitrate = 120, .hw_value = ATH10K_HW_RATE_OFDM_12M },
+	{ .bitrate = 180, .hw_value = ATH10K_HW_RATE_OFDM_18M },
+	{ .bitrate = 240, .hw_value = ATH10K_HW_RATE_OFDM_24M },
+	{ .bitrate = 360, .hw_value = ATH10K_HW_RATE_OFDM_36M },
+	{ .bitrate = 480, .hw_value = ATH10K_HW_RATE_OFDM_48M },
+	{ .bitrate = 540, .hw_value = ATH10K_HW_RATE_OFDM_54M },
+};
+
 #define ATH10K_MAC_FIRST_OFDM_RATE_IDX 4
 
 #define ath10k_a_rates (ath10k_rates + ATH10K_MAC_FIRST_OFDM_RATE_IDX)
@@ -70,6 +96,9 @@ static struct ieee80211_rate ath10k_rates[] = {
 #define ath10k_g_rates (ath10k_rates + 0)
 #define ath10k_g_rates_size (ARRAY_SIZE(ath10k_rates))
 
+#define ath10k_g_rates_rev2 (ath10k_rates_rev2 + 0)
+#define ath10k_g_rates_rev2_size (ARRAY_SIZE(ath10k_rates_rev2))
+
 static bool ath10k_mac_bitrate_is_cck(int bitrate)
 {
 	switch (bitrate) {
@@ -7696,8 +7725,14 @@ int ath10k_mac_register(struct ath10k *ar)
 		band = &ar->mac.sbands[NL80211_BAND_2GHZ];
 		band->n_channels = ARRAY_SIZE(ath10k_2ghz_channels);
 		band->channels = channels;
-		band->n_bitrates = ath10k_g_rates_size;
-		band->bitrates = ath10k_g_rates;
+
+		if (ar->hw_params.cck_rate_map_rev2) {
+			band->n_bitrates = ath10k_g_rates_rev2_size;
+			band->bitrates = ath10k_g_rates_rev2;
+		} else {
+			band->n_bitrates = ath10k_g_rates_size;
+			band->bitrates = ath10k_g_rates;
+		}
 
 		ar->hw->wiphy->bands[NL80211_BAND_2GHZ] = band;
 	}
-- 
1.7.9.5



From kvalo at qca.qualcomm.com  Thu Jun  2 07:24:11 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 2 Jun 2016 14:24:11 +0000
Subject: Bug 119151 - [regression] ath10k no longer authenitcates and
 freezes system
In-Reply-To: <8760trzoiw.fsf@kamboji.qca.qualcomm.com> (Kalle Valo's message
 of "Thu, 02 Jun 2016 16:52:23 +0300")
References: <8760trzoiw.fsf@kamboji.qca.qualcomm.com>
Message-ID: <871t4fzn1x.fsf@kamboji.qca.qualcomm.com>

Kalle Valo <kvalo at qca.qualcomm.com> writes:

> there's a regression in ath10k:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=119151
>
> Reporter bisected it to this:
>
> 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit
> commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183
> Author: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
> Date:   Tue Mar 22 17:22:19 2016 +0530
>
> ath10k: combine txrx and replenish task
>
> Since tx completion and rx indication processing are moved out
> of txrx tasklet and rx ring lock contention also removed from txrx
> for rx_ind messages, it would be efficient to combine both replenish
> and txrx tasks. Refill threshold is adjusted for both AP135 and AP148
> (low and high end systems). With this adjustment in AP135, TCP DL is
> improved from 603 Mbps to 620 Mbps and UDP DL is improved from 758 Mbps
> to 803 Mbps. Also no watchdog are observed on UDP BiDi.
>
> Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
> Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>

Adding Mike, the bug reporter.

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Thu Jun  2 07:50:56 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 2 Jun 2016 16:50:56 +0200
Subject: ath10k: fix diag_read to collect data for larger memory
In-Reply-To: <1464187154-26687-1-git-send-email-arnagara@qti.qualcomm.com>
Message-ID: <8d461713b1d345ebb4e04fb5f6ba44be@euamsexm01a.eu.qualcomm.com>

Ashok Raj Nagarajan <arnagara at qti.qualcomm.com> wrote:
> diag_read uses dma_alloc_coherent to allocate memory requested by the
> caller. If this memory requested is larger, more than DIAG_TRANSFER_LIMIT
> (2K), then it is likely that we may not get the requested memory and we
> would fail.
> 
> To solve this, request dma_alloc_coherent for only DIAG_TRANSFER_LIMIT, and
> reuse this buffer multiple times as needed to copy the data requested in
> smaller chunks of size not more than DIAG_TRANSFER_LIMIT. Previously we
> were reading into the caller's only after getting the complete requested
> data.
> 
> Fixes: 68c03249f388 ('ath10k: convert pci_alloc_consistent() to dma_alloc_coherent()')
> Signed-off-by: Ashok Raj Nagarajan <arnagara at qti.qualcomm.com>

Thanks, 1 patch applied to ath.git:

1e56d5127d5c ath10k: fix diag_read to collect data for larger memory

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9135561/



From kvalo at qca.qualcomm.com  Thu Jun  2 07:51:53 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 2 Jun 2016 16:51:53 +0200
Subject: ath10k: Fix error while writing 'simulate_fw_crash' debugfs
In-Reply-To: <1464251262-4889-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <413fd4df25784a74af69dc37eceeefe0@euamsexm01a.eu.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> Fix invalid argument error while writing 'simulate_fw_crash',
> though the funcionality is working fine we get an error 'invalid
> argument' because 'count' value is not returned properly
> (no reason to reduce the count value for removing the newline)
> 
> Fixes the below write error:
> 
> /sys/kernel/debug/ieee80211/phy0/ath10k# echo hw-restart >
> simulate_fw_crash
> -bash: echo: write error: Invalid argument
> 
> Also move the 'conf_mutex' as it is really not required for
> fetching the userspace buffer.
> 
> Reported-by: Maharaja Kennadyrajan <c_mkenna at qti.qualcomm.com>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> Signed-off-by: Maharaja Kennadyrajan <c_mkenna at qti.qualcomm.com>

Thanks, 1 patch applied to ath.git:

f5e307515b2b ath10k: fix error while writing 'simulate_fw_crash' debugfs

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9136787/



From kvalo at qca.qualcomm.com  Thu Jun  2 07:56:51 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 2 Jun 2016 16:56:51 +0200
Subject: [1/5] ath10k: fix operating irq mode for ahb device
In-Reply-To: <20160527144559.4053-1-rmanohar@qti.qualcomm.com>
Message-ID: <cb83c96b3c154a438b0c7e90372d2984@euamsexm01a.eu.qualcomm.com>

Rajkumar Manoharan <rmanohar at qti.qualcomm.com> wrote:
> Earlier when operating irq mode is legacy, interrupts are disabled
> and re-enabled based on num_msi_intrs. commit cfe9011a05a8 ("ath10k:
> remove MSI range support") replaced num_msi_intrs by oper_irq_mode.
> Since oper_irq_mode is not initialized for ahb devices (i.e qca4019),
> device boot up is failed during probe.
> 
> Fixes: cfe9011a05a8 ("ath10k: remove MSI range support")
> Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>

Thanks, 5 patches applied to ath.git:

2e550b6d277b ath10k: fix operating irq mode for ahb device
10f8ec64a2a6 ath10k: remove unused phy_mode_to_band
b855de0f5792 ath10k: update module description
64e001f41676 ath10k: add new ATH10K_FW_FEATURE_BTCOEX_PARAM
39136248cf8d ath10k: add pdev param support to enable/disable btcoex

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9138581/



From kvalo at qca.qualcomm.com  Thu Jun  2 07:58:26 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 2 Jun 2016 16:58:26 +0200
Subject: ath10k: enable ipq4019 device probe in ahb module
In-Reply-To: <1464613883-24036-1-git-send-email-c_traja@qti.qualcomm.com>
Message-ID: <1d9f58c8d04842c19383fc5c9d84a442@euamsexm01a.eu.qualcomm.com>

c_traja at qti.qualcomm.com wrote:
> From: Raja Mani <rmani at qti.qualcomm.com>
> 
> All the necessary patches to make wifi running (over AHB)
> on ipq4019 SoC are ready now. It's good to enable
> ipq4019 wifi device probing in ahb module and
> remove work in progress debug print.
> 
> Device tree change is there in the public review by
> below commit message
> "qcom: ipq4019: add wifi nodes to ipq4019 SoC device tree"
> 
> Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>
> Signed-off-by: Raja Mani <rmani at qti.qualcomm.com>

Thanks, 1 patch applied to ath.git:

280e762e9c72 ath10k: enable ipq4019 device probe in ahb module

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9141355/



From greearb at candelatech.com  Thu Jun  2 08:21:41 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 02 Jun 2016 08:21:41 -0700
Subject: Bug 119151 - [regression] ath10k no longer authenitcates and
 freezes system
In-Reply-To: <871t4fzn1x.fsf@kamboji.qca.qualcomm.com>
References: <8760trzoiw.fsf@kamboji.qca.qualcomm.com>
 <871t4fzn1x.fsf@kamboji.qca.qualcomm.com>
Message-ID: <57504F05.3040200@candelatech.com>

On 06/02/2016 07:24 AM, Valo, Kalle wrote:
> Kalle Valo <kvalo at qca.qualcomm.com> writes:
>
>> there's a regression in ath10k:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=119151
>>
>> Reporter bisected it to this:
>>
>> 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit
>> commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183
>> Author: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
>> Date:   Tue Mar 22 17:22:19 2016 +0530
>>
>> ath10k: combine txrx and replenish task
>>
>> Since tx completion and rx indication processing are moved out
>> of txrx tasklet and rx ring lock contention also removed from txrx
>> for rx_ind messages, it would be efficient to combine both replenish
>> and txrx tasks. Refill threshold is adjusted for both AP135 and AP148
>> (low and high end systems). With this adjustment in AP135, TCP DL is
>> improved from 603 Mbps to 620 Mbps and UDP DL is improved from 758 Mbps
>> to 803 Mbps. Also no watchdog are observed on UDP BiDi.
>>
>> Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
>> Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>
>
> Adding Mike, the bug reporter.


I found a lot of problems with this code as well, and the 5 patches
starting from the URL below fixed the issues for me.

They are stuck as 'NA' in patchwork, but I don't know why.

http://lists.infradead.org/pipermail/ath10k/2016-April/007218.html

You probably need this patch as well, or ath10k will crash when you
enable the debug-mask:

http://permalink.gmane.org/gmane.linux.kernel.wireless.general/151890

It is also 'NA' in patchwork.

Thanks,
Ben

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


From kvalo at qca.qualcomm.com  Thu Jun  2 08:26:15 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 2 Jun 2016 15:26:15 +0000
Subject: Bug 119151 - [regression] ath10k no longer authenitcates and
 freezes system
In-Reply-To: <57504F05.3040200@candelatech.com> (Ben Greear's message of "Thu, 
 2 Jun 2016 08:21:41 -0700")
References: <8760trzoiw.fsf@kamboji.qca.qualcomm.com>
 <871t4fzn1x.fsf@kamboji.qca.qualcomm.com>	<57504F05.3040200@candelatech.com>
Message-ID: <87k2i7y5m2.fsf@kamboji.qca.qualcomm.com>

Ben Greear <greearb at candelatech.com> writes:

> I found a lot of problems with this code as well, and the 5 patches
> starting from the URL below fixed the issues for me.
>
> They are stuck as 'NA' in patchwork, but I don't know why.
>
> http://lists.infradead.org/pipermail/ath10k/2016-April/007218.html

ath10k has a separate patchwork instance, did you look at the correct
one? I have quite a lot of patches from you in deferred state because of
the patch bomb, but I'm hoping to go through them soon.

https://patchwork.kernel.org/project/ath10k/list/?state=10&delegate=25621&order=date

-- 
Kalle Valo

From greearb at candelatech.com  Thu Jun  2 08:32:09 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 02 Jun 2016 08:32:09 -0700
Subject: Bug 119151 - [regression] ath10k no longer authenitcates and
 freezes system
In-Reply-To: <87k2i7y5m2.fsf@kamboji.qca.qualcomm.com>
References: <8760trzoiw.fsf@kamboji.qca.qualcomm.com>	<871t4fzn1x.fsf@kamboji.qca.qualcomm.com>	<57504F05.3040200@candelatech.com>
 <87k2i7y5m2.fsf@kamboji.qca.qualcomm.com>
Message-ID: <57505179.8090509@candelatech.com>



On 06/02/2016 08:26 AM, Valo, Kalle wrote:
> Ben Greear <greearb at candelatech.com> writes:
>
>> I found a lot of problems with this code as well, and the 5 patches
>> starting from the URL below fixed the issues for me.
>>
>> They are stuck as 'NA' in patchwork, but I don't know why.
>>
>> http://lists.infradead.org/pipermail/ath10k/2016-April/007218.html
>
> ath10k has a separate patchwork instance, did you look at the correct
> one? I have quite a lot of patches from you in deferred state because of
> the patch bomb, but I'm hoping to go through them soon.
>
> https://patchwork.kernel.org/project/ath10k/list/?state=10&delegate=25621&order=date

Ok, they are deferred then.

The series of 5 is likely quite useful and fixes some nasty bugs,
and the first patch of the big bomb is also a trivial crash fix
for a regression you added (as best as I can tell).

The rest of the patch bomb is less critical, but making some progress on
that would make me feel good about working on ath10k patches again.

Thanks,
Ben

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


From mohammed at codeaurora.org  Thu Jun  2 08:34:08 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Thu, 2 Jun 2016 21:04:08 +0530
Subject: Bug 119151 - [regression] ath10k no longer authenitcates and
 freezes system
In-Reply-To: <57504F05.3040200@candelatech.com>
References: <8760trzoiw.fsf@kamboji.qca.qualcomm.com>
 <871t4fzn1x.fsf@kamboji.qca.qualcomm.com>
 <57504F05.3040200@candelatech.com>
Message-ID: <20160602153408.GA5110@atheros-ThinkPad-T61>

On Thu, Jun 02, 2016 at 08:21:41AM -0700, Ben Greear wrote:
> On 06/02/2016 07:24 AM, Valo, Kalle wrote:
> >Kalle Valo <kvalo at qca.qualcomm.com> writes:
> >
> >>there's a regression in ath10k:
> >>
> >>https://bugzilla.kernel.org/show_bug.cgi?id=119151
> >>
> >>Reporter bisected it to this:
> >>
> >>5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit
> >>commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183
> >>Author: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
> >>Date:   Tue Mar 22 17:22:19 2016 +0530
> >>
> >>ath10k: combine txrx and replenish task
> >>
> >>Since tx completion and rx indication processing are moved out
> >>of txrx tasklet and rx ring lock contention also removed from txrx
> >>for rx_ind messages, it would be efficient to combine both replenish
> >>and txrx tasks. Refill threshold is adjusted for both AP135 and AP148
> >>(low and high end systems). With this adjustment in AP135, TCP DL is
> >>improved from 603 Mbps to 620 Mbps and UDP DL is improved from 758 Mbps
> >>to 803 Mbps. Also no watchdog are observed on UDP BiDi.
> >>
> >>Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
> >>Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>
> >
> >Adding Mike, the bug reporter.
> 
> 
> I found a lot of problems with this code as well, and the 5 patches
> starting from the URL below fixed the issues for me.
> 
> They are stuck as 'NA' in patchwork, but I don't know why.
> 
> http://lists.infradead.org/pipermail/ath10k/2016-April/007218.html
> 
> You probably need this patch as well, or ath10k will crash when you
> enable the debug-mask:
> 
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/151890
> 
> It is also 'NA' in patchwork.

[shafi] i think this is already in the pending branch
https://patchwork.kernel.org/patch/9073471/

> 
> Thanks,
> Ben
> 
> -- 
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
> 
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From rmanohar at qti.qualcomm.com  Thu Jun  2 10:03:46 2016
From: rmanohar at qti.qualcomm.com (Manoharan, Rajkumar)
Date: Thu, 2 Jun 2016 17:03:46 +0000
Subject: Bug 119151 - [regression] ath10k no longer authenitcates and
 freezes system
In-Reply-To: <57504F05.3040200@candelatech.com>
References: <8760trzoiw.fsf@kamboji.qca.qualcomm.com>
 <871t4fzn1x.fsf@kamboji.qca.qualcomm.com>,<57504F05.3040200@candelatech.com>
Message-ID: <1464887026467.72937@qti.qualcomm.com>

On Thursday, June 2, 2016 8:51 PM, Ben Greear <greearb at candelatech.com> wrote:
> On 06/02/2016 07:24 AM, Valo, Kalle wrote:
>> Kalle Valo <kvalo at qca.qualcomm.com> writes:
>>
>>> there's a regression in ath10k:
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=119151
>>>
>>> Reporter bisected it to this:
>>>
>>> 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit
>>> commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183
>>> Author: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
>>> Date:   Tue Mar 22 17:22:19 2016 +0530
>>>
>>> ath10k: combine txrx and replenish task
>>>
>>> Since tx completion and rx indication processing are moved out
>>> of txrx tasklet and rx ring lock contention also removed from txrx
>>> for rx_ind messages, it would be efficient to combine both replenish
>>> and txrx tasks. Refill threshold is adjusted for both AP135 and AP148
>>> (low and high end systems). With this adjustment in AP135, TCP DL is
>>> improved from 603 Mbps to 620 Mbps and UDP DL is improved from 758 Mbps
>>> to 803 Mbps. Also no watchdog are observed on UDP BiDi.
>>>
>>> Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
>>> Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>
>>
>> Adding Mike, the bug reporter.
>
Mike,

Sorry for the regression. Since the patch combines both txrx and replenish tasklet,
it is validated in low end embedded devices like AP135 (single core 720 MHz MIPS processor).

It seems yours is octa core processor.  So CPU is not bottleneck here. Need your help to fix this issue asap. 
Can you please try reducing rx refill threshold as below. 

diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 2aa407160859..d35d3d48ae6c 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1734,7 +1734,7 @@ struct htt_rx_desc {
 
 /* Refill a bunch of RX buffers for each refill round so that FW/HW can handle
  * aggregated traffic more nicely. */
-#define ATH10K_HTT_MAX_NUM_REFILL 100
+#define ATH10K_HTT_MAX_NUM_REFILL 16

>From your log attachment from bug report, I found few timed out messages.
May 30 21:09:26 axion kernel: wlan0: deauthenticating from a0:63:91:a7:3c:9f by local choice (Reason: 3=DEAUTH_LEAVING)
May 30 21:09:32 axion kernel: ath10k_pci 0000:3c:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
May 30 21:09:35 axion kernel: ath10k_pci 0000:3c:00.0: failed to delete peer a0:63:91:a7:3c:9f for vdev 0: -110
May 30 21:09:35 axion kernel: ath10k_pci 0000:3c:00.0: found sta peer a0:63:91:a7:3c:9f entry on vdev 0 after it was supposed

Try disabling pci power save for qca6174 as below.

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 852f2c18cd11..5e3ba37a8c6a 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2979,7 +2979,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
        case QCA6164_2_1_DEVICE_ID:
        case QCA6174_2_1_DEVICE_ID:
                hw_rev = ATH10K_HW_QCA6174;
-               pci_ps = true;
+               pci_ps = false;
                pci_soft_reset = ath10k_pci_warm_reset;
                pci_hard_reset = ath10k_pci_qca6174_chip_reset;

>
> I found a lot of problems with this code as well, and the 5 patches
> starting from the URL below fixed the issues for me.
> 
Ben,

Can you please explain the sort of issues you have observed with this change?

-Rajkumar

From rmanohar at qti.qualcomm.com  Thu Jun  2 10:20:06 2016
From: rmanohar at qti.qualcomm.com (Manoharan, Rajkumar)
Date: Thu, 2 Jun 2016 17:20:06 +0000
Subject: Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath
Message-ID: <f495d218d54a4c4c859849a85f38ab0c@aphydexm01b.ap.qualcomm.com>

Found a regression in ath.git TOT that system hangs while probing qca99x0 device on x86_64 platform.
It seems the system hangs while DMA mapping of bigger memory chunks. Below are the list of memory
chucks requested by target for qca99x0 during service ready event. This issue is seen only on x86 platform.
No issues are observed on ARM platform (AP148). After reverting below commit able to bring up device on x86.

Jun  2 17:24:37 rmanohar-arch kernel: idx 0 pool_size 689816 num_units 529 unit_len 1304
Jun  2 17:24:37 rmanohar-arch kernel: idx 1 pool_size 17152 num_units 67 unit_len 256
Jun  2 17:24:37 rmanohar-arch kernel: idx 2 pool_size 68608 num_units 67 unit_len 1024
Jun  2 17:24:37 rmanohar-arch kernel: idx 3 pool_size 274432 num_units 67 unit_len 4096
Jun  2 17:24:37 rmanohar-arch kernel: idx 4 pool_size 107520 num_units 35 unit_len 3072
Jun  2 17:24:37 rmanohar-arch kernel: idx 5 pool_size 6144 num_units 1 unit_len 6144
Jun  2 17:24:37 rmanohar-arch kernel: idx 6 pool_size 865444 num_units 529 unit_len 1636

commit b057886524be060021e3cfad0ba8458c850330cd
Author: Felix Fietkau <nbd at openwrt.org>
Date:   Mon Nov 30 19:32:01 2015 +0100

    ath10k: do not use coherent memory for allocated device memory chunks
    
    Coherent memory is more expensive to allocate (and constrained on some
    architectures where it has to be pre-allocated). It is also completely
    unnecessary, since the host has no reason to even access these allocated
    memory spaces
    
    Signed-off-by: Felix Fietkau <nbd at openwrt.org>
    Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>

-Rajkumar

From greearb at candelatech.com  Thu Jun  2 10:27:22 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 2 Jun 2016 10:27:22 -0700
Subject: Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath
In-Reply-To: <f495d218d54a4c4c859849a85f38ab0c@aphydexm01b.ap.qualcomm.com>
References: <f495d218d54a4c4c859849a85f38ab0c@aphydexm01b.ap.qualcomm.com>
Message-ID: <57506C7A.7070109@candelatech.com>



On 06/02/2016 10:20 AM, Manoharan, Rajkumar wrote:
> Found a regression in ath.git TOT that system hangs while probing qca99x0 device on x86_64 platform.
> It seems the system hangs while DMA mapping of bigger memory chunks. Below are the list of memory
> chucks requested by target for qca99x0 during service ready event. This issue is seen only on x86 platform.
> No issues are observed on ARM platform (AP148). After reverting below commit able to bring up device on x86.
>
> Jun  2 17:24:37 rmanohar-arch kernel: idx 0 pool_size 689816 num_units 529 unit_len 1304
> Jun  2 17:24:37 rmanohar-arch kernel: idx 1 pool_size 17152 num_units 67 unit_len 256
> Jun  2 17:24:37 rmanohar-arch kernel: idx 2 pool_size 68608 num_units 67 unit_len 1024
> Jun  2 17:24:37 rmanohar-arch kernel: idx 3 pool_size 274432 num_units 67 unit_len 4096
> Jun  2 17:24:37 rmanohar-arch kernel: idx 4 pool_size 107520 num_units 35 unit_len 3072
> Jun  2 17:24:37 rmanohar-arch kernel: idx 5 pool_size 6144 num_units 1 unit_len 6144
> Jun  2 17:24:37 rmanohar-arch kernel: idx 6 pool_size 865444 num_units 529 unit_len 1636

We have seen similar.  But, if we enable VT-d in our BIOS, then it works, at least in
our scenarios.  I have not tried putting more than one 99x0 NIC in a system to date, so possibly
more than one would cause more issues, and I guess systems without VT-d might
fail too...

Thanks,
Ben


>
> commit b057886524be060021e3cfad0ba8458c850330cd
> Author: Felix Fietkau <nbd at openwrt.org>
> Date:   Mon Nov 30 19:32:01 2015 +0100
>
>      ath10k: do not use coherent memory for allocated device memory chunks
>
>      Coherent memory is more expensive to allocate (and constrained on some
>      architectures where it has to be pre-allocated). It is also completely
>      unnecessary, since the host has no reason to even access these allocated
>      memory spaces
>
>      Signed-off-by: Felix Fietkau <nbd at openwrt.org>
>      Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>
>
> -Rajkumar
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>


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



From greearb at candelatech.com  Thu Jun  2 10:23:45 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 2 Jun 2016 10:23:45 -0700
Subject: Bug 119151 - [regression] ath10k no longer authenitcates and
 freezes system
In-Reply-To: <1464887026467.72937@qti.qualcomm.com>
References: <8760trzoiw.fsf@kamboji.qca.qualcomm.com>
 <871t4fzn1x.fsf@kamboji.qca.qualcomm.com> <57504F05.3040200@candelatech.com>
 <1464887026467.72937@qti.qualcomm.com>
Message-ID: <57506BA1.2090303@candelatech.com>

On 06/02/2016 10:03 AM, Manoharan, Rajkumar wrote:
> On Thursday, June 2, 2016 8:51 PM, Ben Greear <greearb at candelatech.com> wrote:
>> On 06/02/2016 07:24 AM, Valo, Kalle wrote:
>>> Kalle Valo <kvalo at qca.qualcomm.com> writes:
>>>
>>>> there's a regression in ath10k:
>>>>
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=119151
>>>>
>>>> Reporter bisected it to this:
>>>>
>>>> 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit
>>>> commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183
>>>> Author: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
>>>> Date:   Tue Mar 22 17:22:19 2016 +0530
>>>>
>>>> ath10k: combine txrx and replenish task
>>>>
>>>> Since tx completion and rx indication processing are moved out
>>>> of txrx tasklet and rx ring lock contention also removed from txrx
>>>> for rx_ind messages, it would be efficient to combine both replenish
>>>> and txrx tasks. Refill threshold is adjusted for both AP135 and AP148
>>>> (low and high end systems). With this adjustment in AP135, TCP DL is
>>>> improved from 603 Mbps to 620 Mbps and UDP DL is improved from 758 Mbps
>>>> to 803 Mbps. Also no watchdog are observed on UDP BiDi.
>>>>
>>>> Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
>>>> Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>
>>>
>>> Adding Mike, the bug reporter.
>>
> Mike,
>
> Sorry for the regression. Since the patch combines both txrx and replenish tasklet,
> it is validated in low end embedded devices like AP135 (single core 720 MHz MIPS processor).
>
> It seems yours is octa core processor.  So CPU is not bottleneck here. Need your help to fix this issue asap.
> Can you please try reducing rx refill threshold as below.
>
> diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
> index 2aa407160859..d35d3d48ae6c 100644
> --- a/drivers/net/wireless/ath/ath10k/htt.h
> +++ b/drivers/net/wireless/ath/ath10k/htt.h
> @@ -1734,7 +1734,7 @@ struct htt_rx_desc {
>
>   /* Refill a bunch of RX buffers for each refill round so that FW/HW can handle
>    * aggregated traffic more nicely. */
> -#define ATH10K_HTT_MAX_NUM_REFILL 100
> +#define ATH10K_HTT_MAX_NUM_REFILL 16
>
>  From your log attachment from bug report, I found few timed out messages.
> May 30 21:09:26 axion kernel: wlan0: deauthenticating from a0:63:91:a7:3c:9f by local choice (Reason: 3=DEAUTH_LEAVING)
> May 30 21:09:32 axion kernel: ath10k_pci 0000:3c:00.0: failed to flush transmit queue (skip 0 ar-state 1): 0
> May 30 21:09:35 axion kernel: ath10k_pci 0000:3c:00.0: failed to delete peer a0:63:91:a7:3c:9f for vdev 0: -110
> May 30 21:09:35 axion kernel: ath10k_pci 0000:3c:00.0: found sta peer a0:63:91:a7:3c:9f entry on vdev 0 after it was supposed
>
> Try disabling pci power save for qca6174 as below.
>
> diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
> index 852f2c18cd11..5e3ba37a8c6a 100644
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -2979,7 +2979,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
>          case QCA6164_2_1_DEVICE_ID:
>          case QCA6174_2_1_DEVICE_ID:
>                  hw_rev = ATH10K_HW_QCA6174;
> -               pci_ps = true;
> +               pci_ps = false;
>                  pci_soft_reset = ath10k_pci_warm_reset;
>                  pci_hard_reset = ath10k_pci_qca6174_chip_reset;
>
>>
>> I found a lot of problems with this code as well, and the 5 patches
>> starting from the URL below fixed the issues for me.
>>
> Ben,
>
> Can you please explain the sort of issues you have observed with this change?

I imported a bunch of upstream patches at once, so not sure exactly what commit
caused it.  And, this was about 2 months ago...  Upon review, I'm not sure I even have
the patch this particular bug was bisected to, so maybe that is some other issue.

But, the problems I saw were deadlocks and memory corruption.  A lot of it was
because I was debugging new firmware at the time and so peer creation was failing
sometimes, and things like that.  The error handling in ath10k for this was
faulty and racy and such.  We have not seen any performance regressions,
but we mostly run on very powerful CPUs.

Please take a look at those 5 patches.  A good review would be much appreciated,
and by reading them you will better be able to see the problems I was hitting
and trying to fix.

In case you want to look at the full context of those patches, you can find
them here (around 24 patches down from the top...)

http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=summary

For now, I am sticking with 4.4 + what I pulled in, but will rebase against upstream someday
soon-ish and then we can start testing it all over again :)

Thanks,
Ben


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



From rmanohar at codeaurora.org  Thu Jun  2 10:41:57 2016
From: rmanohar at codeaurora.org (Rajkumar Manoharan)
Date: Thu, 02 Jun 2016 23:11:57 +0530
Subject: Bug 119151 - [regression] ath10k no longer authenitcates and
 freezes system
In-Reply-To: <57506BA1.2090303@candelatech.com>
References: <8760trzoiw.fsf@kamboji.qca.qualcomm.com>
 <871t4fzn1x.fsf@kamboji.qca.qualcomm.com> <57504F05.3040200@candelatech.com>
 <1464887026467.72937@qti.qualcomm.com> <57506BA1.2090303@candelatech.com>
Message-ID: <6c6f208f9abc81cb262d763f6f6d684d@codeaurora.org>

On 2016-06-02 22:53, Ben Greear wrote:
> On 06/02/2016 10:03 AM, Manoharan, Rajkumar wrote:
>> On Thursday, June 2, 2016 8:51 PM, Ben Greear 
>> <greearb at candelatech.com> wrote:
>>> On 06/02/2016 07:24 AM, Valo, Kalle wrote:
>>>> Kalle Valo <kvalo at qca.qualcomm.com> writes:
>>>> 
>>>>> there's a regression in ath10k:
>>>>> 
>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=119151
>>>>> 
>>>>> Reporter bisected it to this:
>>>>> 
>>>>> 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit
>>>>> commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183
>>>>> Author: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
>>>>> Date:   Tue Mar 22 17:22:19 2016 +0530
>>>>> 
>>>>> ath10k: combine txrx and replenish task
>>>>> 
[...]

>>> I found a lot of problems with this code as well, and the 5 patches
>>> starting from the URL below fixed the issues for me.
>>> 
>> Ben,
>> 
>> Can you please explain the sort of issues you have observed with this 
>> change?
> 
> I imported a bunch of upstream patches at once, so not sure exactly 
> what commit
> caused it.  And, this was about 2 months ago...  Upon review, I'm not
> sure I even have
> the patch this particular bug was bisected to, so maybe that is some
> other issue.
> 
Please keep track of buggy commit and report them asap.

> But, the problems I saw were deadlocks and memory corruption.  A lot of 
> it was
> because I was debugging new firmware at the time and so peer creation
> was failing
> sometimes, and things like that.  The error handling in ath10k for this 
> was
> faulty and racy and such.  We have not seen any performance 
> regressions,
> but we mostly run on very powerful CPUs.
> 
> Please take a look at those 5 patches.  A good review would be much 
> appreciated,
> and by reading them you will better be able to see the problems I was 
> hitting
> and trying to fix.
> 
Below two patches are critical and I already shared my feedback.

https://patchwork.kernel.org/patch/8727841/
https://patchwork.kernel.org/patch/9073471/

Others are LGTM.

> In case you want to look at the full context of those patches, you can 
> find
> them here (around 24 patches down from the top...)
> 
Quite a big list :)

> http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=summary
> 
> For now, I am sticking with 4.4 + what I pulled in, but will rebase
> against upstream someday
> soon-ish and then we can start testing it all over again :)
> 
Will go through the list. Better to post them to public if not.

-Rajkumar


From rmanohar at codeaurora.org  Thu Jun  2 10:46:21 2016
From: rmanohar at codeaurora.org (Rajkumar Manoharan)
Date: Thu, 02 Jun 2016 23:16:21 +0530
Subject: Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath
In-Reply-To: <57506C7A.7070109@candelatech.com>
References: <f495d218d54a4c4c859849a85f38ab0c@aphydexm01b.ap.qualcomm.com>
 <57506C7A.7070109@candelatech.com>
Message-ID: <c3facd0acc1c2f49f4a4638bf0c2a591@codeaurora.org>

On 2016-06-02 22:57, Ben Greear wrote:
> On 06/02/2016 10:20 AM, Manoharan, Rajkumar wrote:
>> Found a regression in ath.git TOT that system hangs while probing 
>> qca99x0 device on x86_64 platform.
>> It seems the system hangs while DMA mapping of bigger memory chunks. 
>> Below are the list of memory
>> chucks requested by target for qca99x0 during service ready event. 
>> This issue is seen only on x86 platform.
>> No issues are observed on ARM platform (AP148). After reverting below 
>> commit able to bring up device on x86.
>> 
>> Jun  2 17:24:37 rmanohar-arch kernel: idx 0 pool_size 689816 num_units 
>> 529 unit_len 1304
>> Jun  2 17:24:37 rmanohar-arch kernel: idx 1 pool_size 17152 num_units 
>> 67 unit_len 256
>> Jun  2 17:24:37 rmanohar-arch kernel: idx 2 pool_size 68608 num_units 
>> 67 unit_len 1024
>> Jun  2 17:24:37 rmanohar-arch kernel: idx 3 pool_size 274432 num_units 
>> 67 unit_len 4096
>> Jun  2 17:24:37 rmanohar-arch kernel: idx 4 pool_size 107520 num_units 
>> 35 unit_len 3072
>> Jun  2 17:24:37 rmanohar-arch kernel: idx 5 pool_size 6144 num_units 1 
>> unit_len 6144
>> Jun  2 17:24:37 rmanohar-arch kernel: idx 6 pool_size 865444 num_units 
>> 529 unit_len 1636
> 
> We have seen similar.  But, if we enable VT-d in our BIOS, then it
> works, at least in
> our scenarios.  I have not tried putting more than one 99x0 NIC in a
> system to date, so possibly
> more than one would cause more issues, and I guess systems without VT-d 
> might
> fail too...
> 
Yeah.. But the code should work even on non-VT-d systems. ins't it?
> 
> 
>> 
>> commit b057886524be060021e3cfad0ba8458c850330cd
>> Author: Felix Fietkau <nbd at openwrt.org>
>> Date:   Mon Nov 30 19:32:01 2015 +0100
>> 
>>      ath10k: do not use coherent memory for allocated device memory 
>> chunks
>> 
>>      Coherent memory is more expensive to allocate (and constrained on 
>> some
>>      architectures where it has to be pre-allocated). It is also 
>> completely
>>      unnecessary, since the host has no reason to even access these 
>> allocated
>>      memory spaces
>> 
>>      Signed-off-by: Felix Fietkau <nbd at openwrt.org>
>>      Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>
>> 
>> 
Ben,

Can you help to confirm this issue by disabling VT-d and bring up 
qca99x0? If it freezes, try reverting the patch.

-Rajkumar


From greearb at candelatech.com  Thu Jun  2 10:52:41 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 2 Jun 2016 10:52:41 -0700
Subject: Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath
In-Reply-To: <c3facd0acc1c2f49f4a4638bf0c2a591@codeaurora.org>
References: <f495d218d54a4c4c859849a85f38ab0c@aphydexm01b.ap.qualcomm.com>
 <57506C7A.7070109@candelatech.com>
 <c3facd0acc1c2f49f4a4638bf0c2a591@codeaurora.org>
Message-ID: <57507269.1060108@candelatech.com>

On 06/02/2016 10:46 AM, Rajkumar Manoharan wrote:
> On 2016-06-02 22:57, Ben Greear wrote:
>> On 06/02/2016 10:20 AM, Manoharan, Rajkumar wrote:
>>> Found a regression in ath.git TOT that system hangs while probing qca99x0 device on x86_64 platform.
>>> It seems the system hangs while DMA mapping of bigger memory chunks. Below are the list of memory
>>> chucks requested by target for qca99x0 during service ready event. This issue is seen only on x86 platform.
>>> No issues are observed on ARM platform (AP148). After reverting below commit able to bring up device on x86.
>>>
>>> Jun  2 17:24:37 rmanohar-arch kernel: idx 0 pool_size 689816 num_units 529 unit_len 1304
>>> Jun  2 17:24:37 rmanohar-arch kernel: idx 1 pool_size 17152 num_units 67 unit_len 256
>>> Jun  2 17:24:37 rmanohar-arch kernel: idx 2 pool_size 68608 num_units 67 unit_len 1024
>>> Jun  2 17:24:37 rmanohar-arch kernel: idx 3 pool_size 274432 num_units 67 unit_len 4096
>>> Jun  2 17:24:37 rmanohar-arch kernel: idx 4 pool_size 107520 num_units 35 unit_len 3072
>>> Jun  2 17:24:37 rmanohar-arch kernel: idx 5 pool_size 6144 num_units 1 unit_len 6144
>>> Jun  2 17:24:37 rmanohar-arch kernel: idx 6 pool_size 865444 num_units 529 unit_len 1636
>>
>> We have seen similar.  But, if we enable VT-d in our BIOS, then it
>> works, at least in
>> our scenarios.  I have not tried putting more than one 99x0 NIC in a
>> system to date, so possibly
>> more than one would cause more issues, and I guess systems without VT-d might
>> fail too...
>>
> Yeah.. But the code should work even on non-VT-d systems. ins't it?

It would be great if it did.

>>> commit b057886524be060021e3cfad0ba8458c850330cd
>>> Author: Felix Fietkau <nbd at openwrt.org>
>>> Date:   Mon Nov 30 19:32:01 2015 +0100
>>>
>>>      ath10k: do not use coherent memory for allocated device memory chunks
>>>
>>>      Coherent memory is more expensive to allocate (and constrained on some
>>>      architectures where it has to be pre-allocated). It is also completely
>>>      unnecessary, since the host has no reason to even access these allocated
>>>      memory spaces
>>>
>>>      Signed-off-by: Felix Fietkau <nbd at openwrt.org>
>>>      Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>
>>>
>>>
> Ben,
>
> Can you help to confirm this issue by disabling VT-d and bring up qca99x0? If it freezes, try reverting the patch.

At the time, I bisected to this commit as well, but I decided to just live with it
since it seemed it fixed some other bug and we had a work-around.  My understanding
is that without the patch above, some ARM systems failed to work.

Thanks,
Ben


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



From greearb at candelatech.com  Thu Jun  2 11:02:47 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 2 Jun 2016 11:02:47 -0700
Subject: Bug 119151 - [regression] ath10k no longer authenitcates and
 freezes system
In-Reply-To: <6c6f208f9abc81cb262d763f6f6d684d@codeaurora.org>
References: <8760trzoiw.fsf@kamboji.qca.qualcomm.com>
 <871t4fzn1x.fsf@kamboji.qca.qualcomm.com> <57504F05.3040200@candelatech.com>
 <1464887026467.72937@qti.qualcomm.com> <57506BA1.2090303@candelatech.com>
 <6c6f208f9abc81cb262d763f6f6d684d@codeaurora.org>
Message-ID: <575074C7.50009@candelatech.com>

On 06/02/2016 10:41 AM, Rajkumar Manoharan wrote:
> On 2016-06-02 22:53, Ben Greear wrote:
>> On 06/02/2016 10:03 AM, Manoharan, Rajkumar wrote:
>>> On Thursday, June 2, 2016 8:51 PM, Ben Greear <greearb at candelatech.com> wrote:
>>>> On 06/02/2016 07:24 AM, Valo, Kalle wrote:
>>>>> Kalle Valo <kvalo at qca.qualcomm.com> writes:
>>>>>
>>>>>> there's a regression in ath10k:
>>>>>>
>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=119151
>>>>>>
>>>>>> Reporter bisected it to this:
>>>>>>
>>>>>> 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit
>>>>>> commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183
>>>>>> Author: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
>>>>>> Date:   Tue Mar 22 17:22:19 2016 +0530
>>>>>>
>>>>>> ath10k: combine txrx and replenish task
>>>>>>
> [...]
>
>>>> I found a lot of problems with this code as well, and the 5 patches
>>>> starting from the URL below fixed the issues for me.
>>>>
>>> Ben,
>>>
>>> Can you please explain the sort of issues you have observed with this change?
>>
>> I imported a bunch of upstream patches at once, so not sure exactly what commit
>> caused it.  And, this was about 2 months ago...  Upon review, I'm not
>> sure I even have
>> the patch this particular bug was bisected to, so maybe that is some
>> other issue.
>>
> Please keep track of buggy commit and report them asap.

I posted to the list at the time.  When I was debugging this, there
were so many conflicting issues that it was hard to find a single
regression point.

>> But, the problems I saw were deadlocks and memory corruption.  A lot of it was
>> because I was debugging new firmware at the time and so peer creation
>> was failing
>> sometimes, and things like that.  The error handling in ath10k for this was
>> faulty and racy and such.  We have not seen any performance regressions,
>> but we mostly run on very powerful CPUs.
>>
>> Please take a look at those 5 patches.  A good review would be much appreciated,
>> and by reading them you will better be able to see the problems I was hitting
>> and trying to fix.
>>
> Below two patches are critical and I already shared my feedback.
>
> https://patchwork.kernel.org/patch/8727841/
> https://patchwork.kernel.org/patch/9073471/
>
> Others are LGTM.

Not sure what LGTM means.

This one fixes memory corruption:
http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=blobdiff;f=drivers/net/wireless/ath/ath10k/htt_tx.c;h=58e88d392fb56a65304db17d11a9eaf0b0397dc7;hp=07b960e9704f509b3dddf1e45730e76a4c39e51e;hb=fddb6661a0f5772853fbb9feb7232f325d5f74c5;hpb=ed1757f8345064181664e4a62e2b917e694a665e

This one fixes use-after-free memory bugs:
http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=blobdiff;f=drivers/net/wireless/ath/ath10k/mac.c;h=5e5cc9c6c1d82524b9b77a7c6d2c1341c5268732;hp=8783119b9ba84e0ddb292d521e6513bf7d68a40b;hb=5ae13cea64004afc673ecc22cd70ac51179168c6;hpb=fddb6661a0f5772853fbb9feb7232f325d5f74c5

As does this one:
http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=blobdiff;f=drivers/net/wireless/ath/ath10k/mac.c;h=020dd25752224d9786da37a6dfd10a69e646b138;hp=5e5cc9c6c1d82524b9b77a7c6d2c1341c5268732;hb=c4b9566416a5e7b8d4c446d1bad34aabcbeff9f5;hpb=9bd9c11c1a2e61261c268ac2b6d791d4f6b6fe26

>
>> In case you want to look at the full context of those patches, you can find
>> them here (around 24 patches down from the top...)
>>
> Quite a big list :)
>
>> http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=summary
>>
>> For now, I am sticking with 4.4 + what I pulled in, but will rebase
>> against upstream someday
>> soon-ish and then we can start testing it all over again :)
>>
> Will go through the list. Better to post them to public if not.

Many of these patches are related to features only in my firmware.  The ~20
patch patch-bomb was a start at adding some of the hopefully less controversial
support.  If I can ever get that upstream, then I will pick off another
set of patches and try to get them ready for upstream.

Thanks,
Ben

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



From rmanohar at qti.qualcomm.com  Fri Jun  3 08:33:27 2016
From: rmanohar at qti.qualcomm.com (Rajkumar Manoharan)
Date: Fri, 3 Jun 2016 21:03:27 +0530
Subject: [PATCH 1/2] ath10k: handle testmode events for 10.2 based firmware
Message-ID: <20160603153328.11947-1-rmanohar@qti.qualcomm.com>

Currently testmode events for 10.x firmware are processed from
10.1 wmi event processing. In order to remove 10.1 firmware support,
testmode events should be handled from 10.2 event processing.

Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 6279ab4a760e..b7fb0d76c433 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5095,6 +5095,7 @@ static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, struct sk_buff *skb)
 {
 	struct wmi_cmd_hdr *cmd_hdr;
 	enum wmi_10_2_event_id id;
+	bool consumed;
 
 	cmd_hdr = (struct wmi_cmd_hdr *)skb->data;
 	id = MS(__le32_to_cpu(cmd_hdr->cmd_id), WMI_CMD_HDR_CMD_ID);
@@ -5104,6 +5105,17 @@ static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, struct sk_buff *skb)
 
 	trace_ath10k_wmi_event(ar, id, skb->data, skb->len);
 
+	consumed = ath10k_tm_event_wmi(ar, id, skb);
+	/* Ready event must be handled normally also in UTF mode so that we
+	 * know the UTF firmware has booted, others we are just bypass WMI
+	 * events to testmode.
+	 */
+	if (consumed && id != WMI_10_2_READY_EVENTID) {
+		ath10k_dbg(ar, ATH10K_DBG_WMI,
+			   "wmi testmode consumed 0x%x\n", id);
+		goto out;
+	}
+
 	switch (id) {
 	case WMI_10_2_MGMT_RX_EVENTID:
 		ath10k_wmi_event_mgmt_rx(ar, skb);
-- 
2.8.3



From rmanohar at qti.qualcomm.com  Fri Jun  3 08:33:28 2016
From: rmanohar at qti.qualcomm.com (Rajkumar Manoharan)
Date: Fri, 3 Jun 2016 21:03:28 +0530
Subject: [PATCH 2/2] ath10k: remove 10.1 firmware support
In-Reply-To: <20160603153328.11947-1-rmanohar@qti.qualcomm.com>
References: <20160603153328.11947-1-rmanohar@qti.qualcomm.com>
Message-ID: <20160603153328.11947-2-rmanohar@qti.qualcomm.com>

Earlier qca9888 device was brought up using 10.1 firmware and then
later all firmware fixes and new features are migrated to 10.2/10.2.x
firmware branch. As all of 10.1 funtionalities are supported in 10.2
based firmware, removing 10.1 firmware support for qca9888 device.

Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c     |   4 +-
 drivers/net/wireless/ath/ath10k/mac.c      |   4 +-
 drivers/net/wireless/ath/ath10k/testmode.c |   2 +-
 drivers/net/wireless/ath/ath10k/wmi.c      | 543 +----------------------------
 drivers/net/wireless/ath/ath10k/wmi.h      | 246 -------------
 5 files changed, 8 insertions(+), 791 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index cedf127df168..156e1b8a2470 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1546,7 +1546,6 @@ static int ath10k_core_init_firmware_features(struct ath10k *ar)
 			WMI_STAT_PEER;
 		ar->max_spatial_stream = WMI_MAX_SPATIAL_STREAM;
 		break;
-	case ATH10K_FW_WMI_OP_VERSION_10_1:
 	case ATH10K_FW_WMI_OP_VERSION_10_2:
 	case ATH10K_FW_WMI_OP_VERSION_10_2_4:
 		if (ath10k_peer_stats_enabled(ar)) {
@@ -1588,6 +1587,7 @@ static int ath10k_core_init_firmware_features(struct ath10k *ar)
 		else
 			ar->htt.max_num_pending_tx = TARGET_10_4_NUM_MSDU_DESC;
 		break;
+	case ATH10K_FW_WMI_OP_VERSION_10_1:
 	case ATH10K_FW_WMI_OP_VERSION_UNSET:
 	case ATH10K_FW_WMI_OP_VERSION_MAX:
 		WARN_ON(1);
@@ -1602,7 +1602,6 @@ static int ath10k_core_init_firmware_features(struct ath10k *ar)
 		case ATH10K_FW_WMI_OP_VERSION_MAIN:
 			fw_file->htt_op_version = ATH10K_FW_HTT_OP_VERSION_MAIN;
 			break;
-		case ATH10K_FW_WMI_OP_VERSION_10_1:
 		case ATH10K_FW_WMI_OP_VERSION_10_2:
 		case ATH10K_FW_WMI_OP_VERSION_10_2_4:
 			fw_file->htt_op_version = ATH10K_FW_HTT_OP_VERSION_10_1;
@@ -1610,6 +1609,7 @@ static int ath10k_core_init_firmware_features(struct ath10k *ar)
 		case ATH10K_FW_WMI_OP_VERSION_TLV:
 			fw_file->htt_op_version = ATH10K_FW_HTT_OP_VERSION_TLV;
 			break;
+		case ATH10K_FW_WMI_OP_VERSION_10_1:
 		case ATH10K_FW_WMI_OP_VERSION_10_4:
 		case ATH10K_FW_WMI_OP_VERSION_UNSET:
 		case ATH10K_FW_WMI_OP_VERSION_MAX:
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 84a3e4902720..23109d1431a2 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5284,7 +5284,7 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw,
 		if (info->assoc) {
 			/* Workaround: Make sure monitor vdev is not running
 			 * when associating to prevent some firmware revisions
-			 * (e.g. 10.1 and 10.2) from crashing.
+			 * (e.g. 10.2) from crashing.
 			 */
 			if (ar->monitor_started)
 				ath10k_monitor_stop(ar);
@@ -7852,7 +7852,6 @@ int ath10k_mac_register(struct ath10k *ar)
 		}
 		ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_ADHOC);
 		break;
-	case ATH10K_FW_WMI_OP_VERSION_10_1:
 	case ATH10K_FW_WMI_OP_VERSION_10_2:
 	case ATH10K_FW_WMI_OP_VERSION_10_2_4:
 		ar->hw->wiphy->iface_combinations = ath10k_10x_if_comb;
@@ -7864,6 +7863,7 @@ int ath10k_mac_register(struct ath10k *ar)
 		ar->hw->wiphy->n_iface_combinations =
 			ARRAY_SIZE(ath10k_10_4_if_comb);
 		break;
+	case ATH10K_FW_WMI_OP_VERSION_10_1:
 	case ATH10K_FW_WMI_OP_VERSION_UNSET:
 	case ATH10K_FW_WMI_OP_VERSION_MAX:
 		WARN_ON(1);
diff --git a/drivers/net/wireless/ath/ath10k/testmode.c b/drivers/net/wireless/ath/ath10k/testmode.c
index 120f4234d3b0..8b8fcfc1705d 100644
--- a/drivers/net/wireless/ath/ath10k/testmode.c
+++ b/drivers/net/wireless/ath/ath10k/testmode.c
@@ -162,7 +162,7 @@ static int ath10k_tm_fetch_utf_firmware_api_1(struct ath10k *ar,
 	 * correct WMI interface.
 	 */
 
-	fw_file->wmi_op_version = ATH10K_FW_WMI_OP_VERSION_10_1;
+	fw_file->wmi_op_version = ATH10K_FW_WMI_OP_VERSION_10_2;
 	fw_file->htt_op_version = ATH10K_FW_HTT_OP_VERSION_10_1;
 	fw_file->firmware_data = fw_file->firmware->data;
 	fw_file->firmware_len = fw_file->firmware->size;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index b7fb0d76c433..70be2d40870d 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -193,172 +193,6 @@ static struct wmi_cmd_map wmi_cmd_map = {
 	.pdev_bss_chan_info_request_cmdid = WMI_CMD_UNSUPPORTED,
 };
 
-/* 10.X WMI cmd track */
-static struct wmi_cmd_map wmi_10x_cmd_map = {
-	.init_cmdid = WMI_10X_INIT_CMDID,
-	.start_scan_cmdid = WMI_10X_START_SCAN_CMDID,
-	.stop_scan_cmdid = WMI_10X_STOP_SCAN_CMDID,
-	.scan_chan_list_cmdid = WMI_10X_SCAN_CHAN_LIST_CMDID,
-	.scan_sch_prio_tbl_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_set_regdomain_cmdid = WMI_10X_PDEV_SET_REGDOMAIN_CMDID,
-	.pdev_set_channel_cmdid = WMI_10X_PDEV_SET_CHANNEL_CMDID,
-	.pdev_set_param_cmdid = WMI_10X_PDEV_SET_PARAM_CMDID,
-	.pdev_pktlog_enable_cmdid = WMI_10X_PDEV_PKTLOG_ENABLE_CMDID,
-	.pdev_pktlog_disable_cmdid = WMI_10X_PDEV_PKTLOG_DISABLE_CMDID,
-	.pdev_set_wmm_params_cmdid = WMI_10X_PDEV_SET_WMM_PARAMS_CMDID,
-	.pdev_set_ht_cap_ie_cmdid = WMI_10X_PDEV_SET_HT_CAP_IE_CMDID,
-	.pdev_set_vht_cap_ie_cmdid = WMI_10X_PDEV_SET_VHT_CAP_IE_CMDID,
-	.pdev_set_dscp_tid_map_cmdid = WMI_10X_PDEV_SET_DSCP_TID_MAP_CMDID,
-	.pdev_set_quiet_mode_cmdid = WMI_10X_PDEV_SET_QUIET_MODE_CMDID,
-	.pdev_green_ap_ps_enable_cmdid = WMI_10X_PDEV_GREEN_AP_PS_ENABLE_CMDID,
-	.pdev_get_tpc_config_cmdid = WMI_10X_PDEV_GET_TPC_CONFIG_CMDID,
-	.pdev_set_base_macaddr_cmdid = WMI_10X_PDEV_SET_BASE_MACADDR_CMDID,
-	.vdev_create_cmdid = WMI_10X_VDEV_CREATE_CMDID,
-	.vdev_delete_cmdid = WMI_10X_VDEV_DELETE_CMDID,
-	.vdev_start_request_cmdid = WMI_10X_VDEV_START_REQUEST_CMDID,
-	.vdev_restart_request_cmdid = WMI_10X_VDEV_RESTART_REQUEST_CMDID,
-	.vdev_up_cmdid = WMI_10X_VDEV_UP_CMDID,
-	.vdev_stop_cmdid = WMI_10X_VDEV_STOP_CMDID,
-	.vdev_down_cmdid = WMI_10X_VDEV_DOWN_CMDID,
-	.vdev_set_param_cmdid = WMI_10X_VDEV_SET_PARAM_CMDID,
-	.vdev_install_key_cmdid = WMI_10X_VDEV_INSTALL_KEY_CMDID,
-	.peer_create_cmdid = WMI_10X_PEER_CREATE_CMDID,
-	.peer_delete_cmdid = WMI_10X_PEER_DELETE_CMDID,
-	.peer_flush_tids_cmdid = WMI_10X_PEER_FLUSH_TIDS_CMDID,
-	.peer_set_param_cmdid = WMI_10X_PEER_SET_PARAM_CMDID,
-	.peer_assoc_cmdid = WMI_10X_PEER_ASSOC_CMDID,
-	.peer_add_wds_entry_cmdid = WMI_10X_PEER_ADD_WDS_ENTRY_CMDID,
-	.peer_remove_wds_entry_cmdid = WMI_10X_PEER_REMOVE_WDS_ENTRY_CMDID,
-	.peer_mcast_group_cmdid = WMI_10X_PEER_MCAST_GROUP_CMDID,
-	.bcn_tx_cmdid = WMI_10X_BCN_TX_CMDID,
-	.pdev_send_bcn_cmdid = WMI_10X_PDEV_SEND_BCN_CMDID,
-	.bcn_tmpl_cmdid = WMI_CMD_UNSUPPORTED,
-	.bcn_filter_rx_cmdid = WMI_10X_BCN_FILTER_RX_CMDID,
-	.prb_req_filter_rx_cmdid = WMI_10X_PRB_REQ_FILTER_RX_CMDID,
-	.mgmt_tx_cmdid = WMI_10X_MGMT_TX_CMDID,
-	.prb_tmpl_cmdid = WMI_CMD_UNSUPPORTED,
-	.addba_clear_resp_cmdid = WMI_10X_ADDBA_CLEAR_RESP_CMDID,
-	.addba_send_cmdid = WMI_10X_ADDBA_SEND_CMDID,
-	.addba_status_cmdid = WMI_10X_ADDBA_STATUS_CMDID,
-	.delba_send_cmdid = WMI_10X_DELBA_SEND_CMDID,
-	.addba_set_resp_cmdid = WMI_10X_ADDBA_SET_RESP_CMDID,
-	.send_singleamsdu_cmdid = WMI_10X_SEND_SINGLEAMSDU_CMDID,
-	.sta_powersave_mode_cmdid = WMI_10X_STA_POWERSAVE_MODE_CMDID,
-	.sta_powersave_param_cmdid = WMI_10X_STA_POWERSAVE_PARAM_CMDID,
-	.sta_mimo_ps_mode_cmdid = WMI_10X_STA_MIMO_PS_MODE_CMDID,
-	.pdev_dfs_enable_cmdid = WMI_10X_PDEV_DFS_ENABLE_CMDID,
-	.pdev_dfs_disable_cmdid = WMI_10X_PDEV_DFS_DISABLE_CMDID,
-	.roam_scan_mode = WMI_10X_ROAM_SCAN_MODE,
-	.roam_scan_rssi_threshold = WMI_10X_ROAM_SCAN_RSSI_THRESHOLD,
-	.roam_scan_period = WMI_10X_ROAM_SCAN_PERIOD,
-	.roam_scan_rssi_change_threshold =
-				WMI_10X_ROAM_SCAN_RSSI_CHANGE_THRESHOLD,
-	.roam_ap_profile = WMI_10X_ROAM_AP_PROFILE,
-	.ofl_scan_add_ap_profile = WMI_10X_OFL_SCAN_ADD_AP_PROFILE,
-	.ofl_scan_remove_ap_profile = WMI_10X_OFL_SCAN_REMOVE_AP_PROFILE,
-	.ofl_scan_period = WMI_10X_OFL_SCAN_PERIOD,
-	.p2p_dev_set_device_info = WMI_10X_P2P_DEV_SET_DEVICE_INFO,
-	.p2p_dev_set_discoverability = WMI_10X_P2P_DEV_SET_DISCOVERABILITY,
-	.p2p_go_set_beacon_ie = WMI_10X_P2P_GO_SET_BEACON_IE,
-	.p2p_go_set_probe_resp_ie = WMI_10X_P2P_GO_SET_PROBE_RESP_IE,
-	.p2p_set_vendor_ie_data_cmdid = WMI_CMD_UNSUPPORTED,
-	.ap_ps_peer_param_cmdid = WMI_10X_AP_PS_PEER_PARAM_CMDID,
-	.ap_ps_peer_uapsd_coex_cmdid = WMI_CMD_UNSUPPORTED,
-	.peer_rate_retry_sched_cmdid = WMI_10X_PEER_RATE_RETRY_SCHED_CMDID,
-	.wlan_profile_trigger_cmdid = WMI_10X_WLAN_PROFILE_TRIGGER_CMDID,
-	.wlan_profile_set_hist_intvl_cmdid =
-				WMI_10X_WLAN_PROFILE_SET_HIST_INTVL_CMDID,
-	.wlan_profile_get_profile_data_cmdid =
-				WMI_10X_WLAN_PROFILE_GET_PROFILE_DATA_CMDID,
-	.wlan_profile_enable_profile_id_cmdid =
-				WMI_10X_WLAN_PROFILE_ENABLE_PROFILE_ID_CMDID,
-	.wlan_profile_list_profile_id_cmdid =
-				WMI_10X_WLAN_PROFILE_LIST_PROFILE_ID_CMDID,
-	.pdev_suspend_cmdid = WMI_10X_PDEV_SUSPEND_CMDID,
-	.pdev_resume_cmdid = WMI_10X_PDEV_RESUME_CMDID,
-	.add_bcn_filter_cmdid = WMI_10X_ADD_BCN_FILTER_CMDID,
-	.rmv_bcn_filter_cmdid = WMI_10X_RMV_BCN_FILTER_CMDID,
-	.wow_add_wake_pattern_cmdid = WMI_10X_WOW_ADD_WAKE_PATTERN_CMDID,
-	.wow_del_wake_pattern_cmdid = WMI_10X_WOW_DEL_WAKE_PATTERN_CMDID,
-	.wow_enable_disable_wake_event_cmdid =
-				WMI_10X_WOW_ENABLE_DISABLE_WAKE_EVENT_CMDID,
-	.wow_enable_cmdid = WMI_10X_WOW_ENABLE_CMDID,
-	.wow_hostwakeup_from_sleep_cmdid =
-				WMI_10X_WOW_HOSTWAKEUP_FROM_SLEEP_CMDID,
-	.rtt_measreq_cmdid = WMI_10X_RTT_MEASREQ_CMDID,
-	.rtt_tsf_cmdid = WMI_10X_RTT_TSF_CMDID,
-	.vdev_spectral_scan_configure_cmdid =
-				WMI_10X_VDEV_SPECTRAL_SCAN_CONFIGURE_CMDID,
-	.vdev_spectral_scan_enable_cmdid =
-				WMI_10X_VDEV_SPECTRAL_SCAN_ENABLE_CMDID,
-	.request_stats_cmdid = WMI_10X_REQUEST_STATS_CMDID,
-	.set_arp_ns_offload_cmdid = WMI_CMD_UNSUPPORTED,
-	.network_list_offload_config_cmdid = WMI_CMD_UNSUPPORTED,
-	.gtk_offload_cmdid = WMI_CMD_UNSUPPORTED,
-	.csa_offload_enable_cmdid = WMI_CMD_UNSUPPORTED,
-	.csa_offload_chanswitch_cmdid = WMI_CMD_UNSUPPORTED,
-	.chatter_set_mode_cmdid = WMI_CMD_UNSUPPORTED,
-	.peer_tid_addba_cmdid = WMI_CMD_UNSUPPORTED,
-	.peer_tid_delba_cmdid = WMI_CMD_UNSUPPORTED,
-	.sta_dtim_ps_method_cmdid = WMI_CMD_UNSUPPORTED,
-	.sta_uapsd_auto_trig_cmdid = WMI_CMD_UNSUPPORTED,
-	.sta_keepalive_cmd = WMI_CMD_UNSUPPORTED,
-	.echo_cmdid = WMI_10X_ECHO_CMDID,
-	.pdev_utf_cmdid = WMI_10X_PDEV_UTF_CMDID,
-	.dbglog_cfg_cmdid = WMI_10X_DBGLOG_CFG_CMDID,
-	.pdev_qvit_cmdid = WMI_10X_PDEV_QVIT_CMDID,
-	.pdev_ftm_intg_cmdid = WMI_CMD_UNSUPPORTED,
-	.vdev_set_keepalive_cmdid = WMI_CMD_UNSUPPORTED,
-	.vdev_get_keepalive_cmdid = WMI_CMD_UNSUPPORTED,
-	.force_fw_hang_cmdid = WMI_CMD_UNSUPPORTED,
-	.gpio_config_cmdid = WMI_10X_GPIO_CONFIG_CMDID,
-	.gpio_output_cmdid = WMI_10X_GPIO_OUTPUT_CMDID,
-	.pdev_get_temperature_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_enable_adaptive_cca_cmdid = WMI_CMD_UNSUPPORTED,
-	.scan_update_request_cmdid = WMI_CMD_UNSUPPORTED,
-	.vdev_standby_response_cmdid = WMI_CMD_UNSUPPORTED,
-	.vdev_resume_response_cmdid = WMI_CMD_UNSUPPORTED,
-	.wlan_peer_caching_add_peer_cmdid = WMI_CMD_UNSUPPORTED,
-	.wlan_peer_caching_evict_peer_cmdid = WMI_CMD_UNSUPPORTED,
-	.wlan_peer_caching_restore_peer_cmdid = WMI_CMD_UNSUPPORTED,
-	.wlan_peer_caching_print_all_peers_info_cmdid = WMI_CMD_UNSUPPORTED,
-	.peer_update_wds_entry_cmdid = WMI_CMD_UNSUPPORTED,
-	.peer_add_proxy_sta_entry_cmdid = WMI_CMD_UNSUPPORTED,
-	.rtt_keepalive_cmdid = WMI_CMD_UNSUPPORTED,
-	.oem_req_cmdid = WMI_CMD_UNSUPPORTED,
-	.nan_cmdid = WMI_CMD_UNSUPPORTED,
-	.vdev_ratemask_cmdid = WMI_CMD_UNSUPPORTED,
-	.qboost_cfg_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_smart_ant_enable_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_smart_ant_set_rx_antenna_cmdid = WMI_CMD_UNSUPPORTED,
-	.peer_smart_ant_set_tx_antenna_cmdid = WMI_CMD_UNSUPPORTED,
-	.peer_smart_ant_set_train_info_cmdid = WMI_CMD_UNSUPPORTED,
-	.peer_smart_ant_set_node_config_ops_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_set_antenna_switch_table_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_set_ctl_table_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_set_mimogain_table_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_ratepwr_table_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_ratepwr_chainmsk_table_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_fips_cmdid = WMI_CMD_UNSUPPORTED,
-	.tt_set_conf_cmdid = WMI_CMD_UNSUPPORTED,
-	.fwtest_cmdid = WMI_CMD_UNSUPPORTED,
-	.vdev_atf_request_cmdid = WMI_CMD_UNSUPPORTED,
-	.peer_atf_request_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_get_ani_cck_config_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_get_ani_ofdm_config_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_reserve_ast_entry_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_get_nfcal_power_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_get_tpc_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_get_ast_info_cmdid = WMI_CMD_UNSUPPORTED,
-	.vdev_set_dscp_tid_map_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_get_info_cmdid = WMI_CMD_UNSUPPORTED,
-	.vdev_get_info_cmdid = WMI_CMD_UNSUPPORTED,
-	.vdev_filter_neighbor_rx_packets_cmdid = WMI_CMD_UNSUPPORTED,
-	.mu_cal_start_cmdid = WMI_CMD_UNSUPPORTED,
-	.set_cca_params_cmdid = WMI_CMD_UNSUPPORTED,
-	.pdev_bss_chan_info_request_cmdid = WMI_CMD_UNSUPPORTED,
-};
-
 /* 10.2.4 WMI cmd track */
 static struct wmi_cmd_map wmi_10_2_4_cmd_map = {
 	.init_cmdid = WMI_10_2_INIT_CMDID,
@@ -1575,23 +1409,6 @@ static const struct wmi_peer_flags_map wmi_peer_flags_map = {
 	.pmf = WMI_PEER_PMF,
 };
 
-static const struct wmi_peer_flags_map wmi_10x_peer_flags_map = {
-	.auth = WMI_10X_PEER_AUTH,
-	.qos = WMI_10X_PEER_QOS,
-	.need_ptk_4_way = WMI_10X_PEER_NEED_PTK_4_WAY,
-	.need_gtk_2_way = WMI_10X_PEER_NEED_GTK_2_WAY,
-	.apsd = WMI_10X_PEER_APSD,
-	.ht = WMI_10X_PEER_HT,
-	.bw40 = WMI_10X_PEER_40MHZ,
-	.stbc = WMI_10X_PEER_STBC,
-	.ldbc = WMI_10X_PEER_LDPC,
-	.dyn_mimops = WMI_10X_PEER_DYN_MIMOPS,
-	.static_mimops = WMI_10X_PEER_STATIC_MIMOPS,
-	.spatial_mux = WMI_10X_PEER_SPATIAL_MUX,
-	.vht = WMI_10X_PEER_VHT,
-	.bw80 = WMI_10X_PEER_80MHZ,
-};
-
 static const struct wmi_peer_flags_map wmi_10_2_peer_flags_map = {
 	.auth = WMI_10_2_PEER_AUTH,
 	.qos = WMI_10_2_PEER_QOS,
@@ -2689,65 +2506,6 @@ static int ath10k_wmi_main_op_pull_fw_stats(struct ath10k *ar,
 	return 0;
 }
 
-static int ath10k_wmi_10x_op_pull_fw_stats(struct ath10k *ar,
-					   struct sk_buff *skb,
-					   struct ath10k_fw_stats *stats)
-{
-	const struct wmi_stats_event *ev = (void *)skb->data;
-	u32 num_pdev_stats, num_vdev_stats, num_peer_stats;
-	int i;
-
-	if (!skb_pull(skb, sizeof(*ev)))
-		return -EPROTO;
-
-	num_pdev_stats = __le32_to_cpu(ev->num_pdev_stats);
-	num_vdev_stats = __le32_to_cpu(ev->num_vdev_stats);
-	num_peer_stats = __le32_to_cpu(ev->num_peer_stats);
-
-	for (i = 0; i < num_pdev_stats; i++) {
-		const struct wmi_10x_pdev_stats *src;
-		struct ath10k_fw_stats_pdev *dst;
-
-		src = (void *)skb->data;
-		if (!skb_pull(skb, sizeof(*src)))
-			return -EPROTO;
-
-		dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
-		if (!dst)
-			continue;
-
-		ath10k_wmi_pull_pdev_stats_base(&src->base, dst);
-		ath10k_wmi_pull_pdev_stats_tx(&src->tx, dst);
-		ath10k_wmi_pull_pdev_stats_rx(&src->rx, dst);
-		ath10k_wmi_pull_pdev_stats_extra(&src->extra, dst);
-
-		list_add_tail(&dst->list, &stats->pdevs);
-	}
-
-	/* fw doesn't implement vdev stats */
-
-	for (i = 0; i < num_peer_stats; i++) {
-		const struct wmi_10x_peer_stats *src;
-		struct ath10k_fw_stats_peer *dst;
-
-		src = (void *)skb->data;
-		if (!skb_pull(skb, sizeof(*src)))
-			return -EPROTO;
-
-		dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
-		if (!dst)
-			continue;
-
-		ath10k_wmi_pull_peer_stats(&src->old, dst);
-
-		dst->peer_rx_rate = __le32_to_cpu(src->peer_rx_rate);
-
-		list_add_tail(&dst->list, &stats->peers);
-	}
-
-	return 0;
-}
-
 static int ath10k_wmi_10_2_op_pull_fw_stats(struct ath10k *ar,
 					    struct sk_buff *skb,
 					    struct ath10k_fw_stats *stats)
@@ -4967,130 +4725,6 @@ out:
 	dev_kfree_skb(skb);
 }
 
-static void ath10k_wmi_10_1_op_rx(struct ath10k *ar, struct sk_buff *skb)
-{
-	struct wmi_cmd_hdr *cmd_hdr;
-	enum wmi_10x_event_id id;
-	bool consumed;
-
-	cmd_hdr = (struct wmi_cmd_hdr *)skb->data;
-	id = MS(__le32_to_cpu(cmd_hdr->cmd_id), WMI_CMD_HDR_CMD_ID);
-
-	if (skb_pull(skb, sizeof(struct wmi_cmd_hdr)) == NULL)
-		goto out;
-
-	trace_ath10k_wmi_event(ar, id, skb->data, skb->len);
-
-	consumed = ath10k_tm_event_wmi(ar, id, skb);
-
-	/* Ready event must be handled normally also in UTF mode so that we
-	 * know the UTF firmware has booted, others we are just bypass WMI
-	 * events to testmode.
-	 */
-	if (consumed && id != WMI_10X_READY_EVENTID) {
-		ath10k_dbg(ar, ATH10K_DBG_WMI,
-			   "wmi testmode consumed 0x%x\n", id);
-		goto out;
-	}
-
-	switch (id) {
-	case WMI_10X_MGMT_RX_EVENTID:
-		ath10k_wmi_event_mgmt_rx(ar, skb);
-		/* mgmt_rx() owns the skb now! */
-		return;
-	case WMI_10X_SCAN_EVENTID:
-		ath10k_wmi_event_scan(ar, skb);
-		break;
-	case WMI_10X_CHAN_INFO_EVENTID:
-		ath10k_wmi_event_chan_info(ar, skb);
-		break;
-	case WMI_10X_ECHO_EVENTID:
-		ath10k_wmi_event_echo(ar, skb);
-		break;
-	case WMI_10X_DEBUG_MESG_EVENTID:
-		ath10k_wmi_event_debug_mesg(ar, skb);
-		break;
-	case WMI_10X_UPDATE_STATS_EVENTID:
-		ath10k_wmi_event_update_stats(ar, skb);
-		break;
-	case WMI_10X_VDEV_START_RESP_EVENTID:
-		ath10k_wmi_event_vdev_start_resp(ar, skb);
-		break;
-	case WMI_10X_VDEV_STOPPED_EVENTID:
-		ath10k_wmi_event_vdev_stopped(ar, skb);
-		break;
-	case WMI_10X_PEER_STA_KICKOUT_EVENTID:
-		ath10k_wmi_event_peer_sta_kickout(ar, skb);
-		break;
-	case WMI_10X_HOST_SWBA_EVENTID:
-		ath10k_wmi_event_host_swba(ar, skb);
-		break;
-	case WMI_10X_TBTTOFFSET_UPDATE_EVENTID:
-		ath10k_wmi_event_tbttoffset_update(ar, skb);
-		break;
-	case WMI_10X_PHYERR_EVENTID:
-		ath10k_wmi_event_phyerr(ar, skb);
-		break;
-	case WMI_10X_ROAM_EVENTID:
-		ath10k_wmi_event_roam(ar, skb);
-		break;
-	case WMI_10X_PROFILE_MATCH:
-		ath10k_wmi_event_profile_match(ar, skb);
-		break;
-	case WMI_10X_DEBUG_PRINT_EVENTID:
-		ath10k_wmi_event_debug_print(ar, skb);
-		break;
-	case WMI_10X_PDEV_QVIT_EVENTID:
-		ath10k_wmi_event_pdev_qvit(ar, skb);
-		break;
-	case WMI_10X_WLAN_PROFILE_DATA_EVENTID:
-		ath10k_wmi_event_wlan_profile_data(ar, skb);
-		break;
-	case WMI_10X_RTT_MEASUREMENT_REPORT_EVENTID:
-		ath10k_wmi_event_rtt_measurement_report(ar, skb);
-		break;
-	case WMI_10X_TSF_MEASUREMENT_REPORT_EVENTID:
-		ath10k_wmi_event_tsf_measurement_report(ar, skb);
-		break;
-	case WMI_10X_RTT_ERROR_REPORT_EVENTID:
-		ath10k_wmi_event_rtt_error_report(ar, skb);
-		break;
-	case WMI_10X_WOW_WAKEUP_HOST_EVENTID:
-		ath10k_wmi_event_wow_wakeup_host(ar, skb);
-		break;
-	case WMI_10X_DCS_INTERFERENCE_EVENTID:
-		ath10k_wmi_event_dcs_interference(ar, skb);
-		break;
-	case WMI_10X_PDEV_TPC_CONFIG_EVENTID:
-		ath10k_wmi_event_pdev_tpc_config(ar, skb);
-		break;
-	case WMI_10X_INST_RSSI_STATS_EVENTID:
-		ath10k_wmi_event_inst_rssi_stats(ar, skb);
-		break;
-	case WMI_10X_VDEV_STANDBY_REQ_EVENTID:
-		ath10k_wmi_event_vdev_standby_req(ar, skb);
-		break;
-	case WMI_10X_VDEV_RESUME_REQ_EVENTID:
-		ath10k_wmi_event_vdev_resume_req(ar, skb);
-		break;
-	case WMI_10X_SERVICE_READY_EVENTID:
-		ath10k_wmi_event_service_ready(ar, skb);
-		return;
-	case WMI_10X_READY_EVENTID:
-		ath10k_wmi_event_ready(ar, skb);
-		break;
-	case WMI_10X_PDEV_UTF_EVENTID:
-		/* ignore utf events */
-		break;
-	default:
-		ath10k_warn(ar, "Unknown eventid: %d\n", id);
-		break;
-	}
-
-out:
-	dev_kfree_skb(skb);
-}
-
 static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, struct sk_buff *skb)
 {
 	struct wmi_cmd_hdr *cmd_hdr;
@@ -5543,71 +5177,6 @@ static struct sk_buff *ath10k_wmi_op_gen_init(struct ath10k *ar)
 	return buf;
 }
 
-static struct sk_buff *ath10k_wmi_10_1_op_gen_init(struct ath10k *ar)
-{
-	struct wmi_init_cmd_10x *cmd;
-	struct sk_buff *buf;
-	struct wmi_resource_config_10x config = {};
-	u32 len, val;
-
-	config.num_vdevs = __cpu_to_le32(TARGET_10X_NUM_VDEVS);
-	config.num_peers = __cpu_to_le32(TARGET_10X_NUM_PEERS);
-	config.num_peer_keys = __cpu_to_le32(TARGET_10X_NUM_PEER_KEYS);
-	config.num_tids = __cpu_to_le32(TARGET_10X_NUM_TIDS);
-	config.ast_skid_limit = __cpu_to_le32(TARGET_10X_AST_SKID_LIMIT);
-	config.tx_chain_mask = __cpu_to_le32(TARGET_10X_TX_CHAIN_MASK);
-	config.rx_chain_mask = __cpu_to_le32(TARGET_10X_RX_CHAIN_MASK);
-	config.rx_timeout_pri_vo = __cpu_to_le32(TARGET_10X_RX_TIMEOUT_LO_PRI);
-	config.rx_timeout_pri_vi = __cpu_to_le32(TARGET_10X_RX_TIMEOUT_LO_PRI);
-	config.rx_timeout_pri_be = __cpu_to_le32(TARGET_10X_RX_TIMEOUT_LO_PRI);
-	config.rx_timeout_pri_bk = __cpu_to_le32(TARGET_10X_RX_TIMEOUT_HI_PRI);
-	config.rx_decap_mode = __cpu_to_le32(ar->wmi.rx_decap_mode);
-	config.scan_max_pending_reqs =
-		__cpu_to_le32(TARGET_10X_SCAN_MAX_PENDING_REQS);
-
-	config.bmiss_offload_max_vdev =
-		__cpu_to_le32(TARGET_10X_BMISS_OFFLOAD_MAX_VDEV);
-
-	config.roam_offload_max_vdev =
-		__cpu_to_le32(TARGET_10X_ROAM_OFFLOAD_MAX_VDEV);
-
-	config.roam_offload_max_ap_profiles =
-		__cpu_to_le32(TARGET_10X_ROAM_OFFLOAD_MAX_AP_PROFILES);
-
-	config.num_mcast_groups = __cpu_to_le32(TARGET_10X_NUM_MCAST_GROUPS);
-	config.num_mcast_table_elems =
-		__cpu_to_le32(TARGET_10X_NUM_MCAST_TABLE_ELEMS);
-
-	config.mcast2ucast_mode = __cpu_to_le32(TARGET_10X_MCAST2UCAST_MODE);
-	config.tx_dbg_log_size = __cpu_to_le32(TARGET_10X_TX_DBG_LOG_SIZE);
-	config.num_wds_entries = __cpu_to_le32(TARGET_10X_NUM_WDS_ENTRIES);
-	config.dma_burst_size = __cpu_to_le32(TARGET_10X_DMA_BURST_SIZE);
-	config.mac_aggr_delim = __cpu_to_le32(TARGET_10X_MAC_AGGR_DELIM);
-
-	val = TARGET_10X_RX_SKIP_DEFRAG_TIMEOUT_DUP_DETECTION_CHECK;
-	config.rx_skip_defrag_timeout_dup_detection_check = __cpu_to_le32(val);
-
-	config.vow_config = __cpu_to_le32(TARGET_10X_VOW_CONFIG);
-
-	config.num_msdu_desc = __cpu_to_le32(TARGET_10X_NUM_MSDU_DESC);
-	config.max_frag_entries = __cpu_to_le32(TARGET_10X_MAX_FRAG_ENTRIES);
-
-	len = sizeof(*cmd) +
-	      (sizeof(struct host_memory_chunk) * ar->wmi.num_mem_chunks);
-
-	buf = ath10k_wmi_alloc_skb(ar, len);
-	if (!buf)
-		return ERR_PTR(-ENOMEM);
-
-	cmd = (struct wmi_init_cmd_10x *)buf->data;
-
-	memcpy(&cmd->resource_config, &config, sizeof(config));
-	ath10k_wmi_put_host_mem_chunks(ar, &cmd->mem_chunks);
-
-	ath10k_dbg(ar, ATH10K_DBG_WMI, "wmi init 10x\n");
-	return buf;
-}
-
 static struct sk_buff *ath10k_wmi_10_2_op_gen_init(struct ath10k *ar)
 {
 	struct wmi_init_cmd_10_2 *cmd;
@@ -6555,13 +6124,6 @@ ath10k_wmi_peer_assoc_fill_main(struct ath10k *ar, void *buf,
 }
 
 static void
-ath10k_wmi_peer_assoc_fill_10_1(struct ath10k *ar, void *buf,
-				const struct wmi_peer_assoc_complete_arg *arg)
-{
-	ath10k_wmi_peer_assoc_fill(ar, buf, arg);
-}
-
-static void
 ath10k_wmi_peer_assoc_fill_10_2(struct ath10k *ar, void *buf,
 				const struct wmi_peer_assoc_complete_arg *arg)
 {
@@ -6629,31 +6191,6 @@ ath10k_wmi_op_gen_peer_assoc(struct ath10k *ar,
 }
 
 static struct sk_buff *
-ath10k_wmi_10_1_op_gen_peer_assoc(struct ath10k *ar,
-				  const struct wmi_peer_assoc_complete_arg *arg)
-{
-	size_t len = sizeof(struct wmi_10_1_peer_assoc_complete_cmd);
-	struct sk_buff *skb;
-	int ret;
-
-	ret = ath10k_wmi_peer_assoc_check_arg(arg);
-	if (ret)
-		return ERR_PTR(ret);
-
-	skb = ath10k_wmi_alloc_skb(ar, len);
-	if (!skb)
-		return ERR_PTR(-ENOMEM);
-
-	ath10k_wmi_peer_assoc_fill_10_1(ar, skb->data, arg);
-
-	ath10k_dbg(ar, ATH10K_DBG_WMI,
-		   "wmi peer assoc vdev %d addr %pM (%s)\n",
-		   arg->vdev_id, arg->addr,
-		   arg->peer_reassoc ? "reassociate" : "new");
-	return skb;
-}
-
-static struct sk_buff *
 ath10k_wmi_10_2_op_gen_peer_assoc(struct ath10k *ar,
 				  const struct wmi_peer_assoc_complete_arg *arg)
 {
@@ -7696,74 +7233,6 @@ static const struct wmi_ops wmi_ops = {
 	/* .gen_pdev_enable_adaptive_cca not implemented */
 };
 
-static const struct wmi_ops wmi_10_1_ops = {
-	.rx = ath10k_wmi_10_1_op_rx,
-	.map_svc = wmi_10x_svc_map,
-	.pull_svc_rdy = ath10k_wmi_10x_op_pull_svc_rdy_ev,
-	.pull_fw_stats = ath10k_wmi_10x_op_pull_fw_stats,
-	.gen_init = ath10k_wmi_10_1_op_gen_init,
-	.gen_pdev_set_rd = ath10k_wmi_10x_op_gen_pdev_set_rd,
-	.gen_start_scan = ath10k_wmi_10x_op_gen_start_scan,
-	.gen_peer_assoc = ath10k_wmi_10_1_op_gen_peer_assoc,
-	/* .gen_pdev_get_temperature not implemented */
-
-	/* shared with main branch */
-	.pull_scan = ath10k_wmi_op_pull_scan_ev,
-	.pull_mgmt_rx = ath10k_wmi_op_pull_mgmt_rx_ev,
-	.pull_ch_info = ath10k_wmi_op_pull_ch_info_ev,
-	.pull_vdev_start = ath10k_wmi_op_pull_vdev_start_ev,
-	.pull_peer_kick = ath10k_wmi_op_pull_peer_kick_ev,
-	.pull_swba = ath10k_wmi_op_pull_swba_ev,
-	.pull_phyerr_hdr = ath10k_wmi_op_pull_phyerr_ev_hdr,
-	.pull_phyerr = ath10k_wmi_op_pull_phyerr_ev,
-	.pull_rdy = ath10k_wmi_op_pull_rdy_ev,
-	.pull_roam_ev = ath10k_wmi_op_pull_roam_ev,
-
-	.gen_pdev_suspend = ath10k_wmi_op_gen_pdev_suspend,
-	.gen_pdev_resume = ath10k_wmi_op_gen_pdev_resume,
-	.gen_pdev_set_param = ath10k_wmi_op_gen_pdev_set_param,
-	.gen_stop_scan = ath10k_wmi_op_gen_stop_scan,
-	.gen_vdev_create = ath10k_wmi_op_gen_vdev_create,
-	.gen_vdev_delete = ath10k_wmi_op_gen_vdev_delete,
-	.gen_vdev_start = ath10k_wmi_op_gen_vdev_start,
-	.gen_vdev_stop = ath10k_wmi_op_gen_vdev_stop,
-	.gen_vdev_up = ath10k_wmi_op_gen_vdev_up,
-	.gen_vdev_down = ath10k_wmi_op_gen_vdev_down,
-	.gen_vdev_set_param = ath10k_wmi_op_gen_vdev_set_param,
-	.gen_vdev_install_key = ath10k_wmi_op_gen_vdev_install_key,
-	.gen_vdev_spectral_conf = ath10k_wmi_op_gen_vdev_spectral_conf,
-	.gen_vdev_spectral_enable = ath10k_wmi_op_gen_vdev_spectral_enable,
-	/* .gen_vdev_wmm_conf not implemented */
-	.gen_peer_create = ath10k_wmi_op_gen_peer_create,
-	.gen_peer_delete = ath10k_wmi_op_gen_peer_delete,
-	.gen_peer_flush = ath10k_wmi_op_gen_peer_flush,
-	.gen_peer_set_param = ath10k_wmi_op_gen_peer_set_param,
-	.gen_set_psmode = ath10k_wmi_op_gen_set_psmode,
-	.gen_set_sta_ps = ath10k_wmi_op_gen_set_sta_ps,
-	.gen_set_ap_ps = ath10k_wmi_op_gen_set_ap_ps,
-	.gen_scan_chan_list = ath10k_wmi_op_gen_scan_chan_list,
-	.gen_beacon_dma = ath10k_wmi_op_gen_beacon_dma,
-	.gen_pdev_set_wmm = ath10k_wmi_op_gen_pdev_set_wmm,
-	.gen_request_stats = ath10k_wmi_op_gen_request_stats,
-	.gen_force_fw_hang = ath10k_wmi_op_gen_force_fw_hang,
-	.gen_mgmt_tx = ath10k_wmi_op_gen_mgmt_tx,
-	.gen_dbglog_cfg = ath10k_wmi_op_gen_dbglog_cfg,
-	.gen_pktlog_enable = ath10k_wmi_op_gen_pktlog_enable,
-	.gen_pktlog_disable = ath10k_wmi_op_gen_pktlog_disable,
-	.gen_pdev_set_quiet_mode = ath10k_wmi_op_gen_pdev_set_quiet_mode,
-	.gen_addba_clear_resp = ath10k_wmi_op_gen_addba_clear_resp,
-	.gen_addba_send = ath10k_wmi_op_gen_addba_send,
-	.gen_addba_set_resp = ath10k_wmi_op_gen_addba_set_resp,
-	.gen_delba_send = ath10k_wmi_op_gen_delba_send,
-	.fw_stats_fill = ath10k_wmi_10x_op_fw_stats_fill,
-	.get_vdev_subtype = ath10k_wmi_op_get_vdev_subtype,
-	/* .gen_bcn_tmpl not implemented */
-	/* .gen_prb_tmpl not implemented */
-	/* .gen_p2p_go_bcn_ie not implemented */
-	/* .gen_adaptive_qcs not implemented */
-	/* .gen_pdev_enable_adaptive_cca not implemented */
-};
-
 static const struct wmi_ops wmi_10_2_ops = {
 	.rx = ath10k_wmi_10_2_op_rx,
 	.pull_fw_stats = ath10k_wmi_10_2_op_pull_fw_stats,
@@ -7771,7 +7240,7 @@ static const struct wmi_ops wmi_10_2_ops = {
 	.gen_peer_assoc = ath10k_wmi_10_2_op_gen_peer_assoc,
 	/* .gen_pdev_get_temperature not implemented */
 
-	/* shared with 10.1 */
+	/* shared with 10.2.4 */
 	.map_svc = wmi_10x_svc_map,
 	.pull_svc_rdy = ath10k_wmi_10x_op_pull_svc_rdy_ev,
 	.gen_pdev_set_rd = ath10k_wmi_10x_op_gen_pdev_set_rd,
@@ -7837,7 +7306,7 @@ static const struct wmi_ops wmi_10_2_4_ops = {
 	.gen_pdev_get_temperature = ath10k_wmi_10_2_op_gen_pdev_get_temperature,
 	.gen_pdev_bss_chan_info_req = ath10k_wmi_10_2_op_gen_pdev_bss_chan_info,
 
-	/* shared with 10.1 */
+	/* shared with 10.2 */
 	.map_svc = wmi_10x_svc_map,
 	.pull_svc_rdy = ath10k_wmi_10x_op_pull_svc_rdy_ev,
 	.gen_pdev_set_rd = ath10k_wmi_10x_op_gen_pdev_set_rd,
@@ -7989,13 +7458,6 @@ int ath10k_wmi_attach(struct ath10k *ar)
 		ar->wmi.pdev_param = &wmi_10x_pdev_param_map;
 		ar->wmi.peer_flags = &wmi_10_2_peer_flags_map;
 		break;
-	case ATH10K_FW_WMI_OP_VERSION_10_1:
-		ar->wmi.cmd = &wmi_10x_cmd_map;
-		ar->wmi.ops = &wmi_10_1_ops;
-		ar->wmi.vdev_param = &wmi_10x_vdev_param_map;
-		ar->wmi.pdev_param = &wmi_10x_pdev_param_map;
-		ar->wmi.peer_flags = &wmi_10x_peer_flags_map;
-		break;
 	case ATH10K_FW_WMI_OP_VERSION_MAIN:
 		ar->wmi.cmd = &wmi_cmd_map;
 		ar->wmi.ops = &wmi_ops;
@@ -8006,6 +7468,7 @@ int ath10k_wmi_attach(struct ath10k *ar)
 	case ATH10K_FW_WMI_OP_VERSION_TLV:
 		ath10k_wmi_tlv_attach(ar);
 		break;
+	case ATH10K_FW_WMI_OP_VERSION_10_1:
 	case ATH10K_FW_WMI_OP_VERSION_UNSET:
 	case ATH10K_FW_WMI_OP_VERSION_MAX:
 		ath10k_err(ar, "unsupported WMI op version: %d\n",
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 90f594e89f94..940ce480bcb8 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -1116,217 +1116,6 @@ enum wmi_event_id {
 	WMI_GPIO_INPUT_EVENTID = WMI_EVT_GRP_START_ID(WMI_GRP_GPIO),
 };
 
-/* Command IDs and command events for 10.X firmware */
-enum wmi_10x_cmd_id {
-	WMI_10X_START_CMDID = 0x9000,
-	WMI_10X_END_CMDID = 0x9FFF,
-
-	/* initialize the wlan sub system */
-	WMI_10X_INIT_CMDID,
-
-	/* Scan specific commands */
-
-	WMI_10X_START_SCAN_CMDID = WMI_10X_START_CMDID,
-	WMI_10X_STOP_SCAN_CMDID,
-	WMI_10X_SCAN_CHAN_LIST_CMDID,
-	WMI_10X_ECHO_CMDID,
-
-	/* PDEV(physical device) specific commands */
-	WMI_10X_PDEV_SET_REGDOMAIN_CMDID,
-	WMI_10X_PDEV_SET_CHANNEL_CMDID,
-	WMI_10X_PDEV_SET_PARAM_CMDID,
-	WMI_10X_PDEV_PKTLOG_ENABLE_CMDID,
-	WMI_10X_PDEV_PKTLOG_DISABLE_CMDID,
-	WMI_10X_PDEV_SET_WMM_PARAMS_CMDID,
-	WMI_10X_PDEV_SET_HT_CAP_IE_CMDID,
-	WMI_10X_PDEV_SET_VHT_CAP_IE_CMDID,
-	WMI_10X_PDEV_SET_BASE_MACADDR_CMDID,
-	WMI_10X_PDEV_SET_DSCP_TID_MAP_CMDID,
-	WMI_10X_PDEV_SET_QUIET_MODE_CMDID,
-	WMI_10X_PDEV_GREEN_AP_PS_ENABLE_CMDID,
-	WMI_10X_PDEV_GET_TPC_CONFIG_CMDID,
-
-	/* VDEV(virtual device) specific commands */
-	WMI_10X_VDEV_CREATE_CMDID,
-	WMI_10X_VDEV_DELETE_CMDID,
-	WMI_10X_VDEV_START_REQUEST_CMDID,
-	WMI_10X_VDEV_RESTART_REQUEST_CMDID,
-	WMI_10X_VDEV_UP_CMDID,
-	WMI_10X_VDEV_STOP_CMDID,
-	WMI_10X_VDEV_DOWN_CMDID,
-	WMI_10X_VDEV_STANDBY_RESPONSE_CMDID,
-	WMI_10X_VDEV_RESUME_RESPONSE_CMDID,
-	WMI_10X_VDEV_SET_PARAM_CMDID,
-	WMI_10X_VDEV_INSTALL_KEY_CMDID,
-
-	/* peer specific commands */
-	WMI_10X_PEER_CREATE_CMDID,
-	WMI_10X_PEER_DELETE_CMDID,
-	WMI_10X_PEER_FLUSH_TIDS_CMDID,
-	WMI_10X_PEER_SET_PARAM_CMDID,
-	WMI_10X_PEER_ASSOC_CMDID,
-	WMI_10X_PEER_ADD_WDS_ENTRY_CMDID,
-	WMI_10X_PEER_REMOVE_WDS_ENTRY_CMDID,
-	WMI_10X_PEER_MCAST_GROUP_CMDID,
-
-	/* beacon/management specific commands */
-
-	WMI_10X_BCN_TX_CMDID,
-	WMI_10X_BCN_PRB_TMPL_CMDID,
-	WMI_10X_BCN_FILTER_RX_CMDID,
-	WMI_10X_PRB_REQ_FILTER_RX_CMDID,
-	WMI_10X_MGMT_TX_CMDID,
-
-	/* commands to directly control ba negotiation directly from host. */
-	WMI_10X_ADDBA_CLEAR_RESP_CMDID,
-	WMI_10X_ADDBA_SEND_CMDID,
-	WMI_10X_ADDBA_STATUS_CMDID,
-	WMI_10X_DELBA_SEND_CMDID,
-	WMI_10X_ADDBA_SET_RESP_CMDID,
-	WMI_10X_SEND_SINGLEAMSDU_CMDID,
-
-	/* Station power save specific config */
-	WMI_10X_STA_POWERSAVE_MODE_CMDID,
-	WMI_10X_STA_POWERSAVE_PARAM_CMDID,
-	WMI_10X_STA_MIMO_PS_MODE_CMDID,
-
-	/* set debug log config */
-	WMI_10X_DBGLOG_CFG_CMDID,
-
-	/* DFS-specific commands */
-	WMI_10X_PDEV_DFS_ENABLE_CMDID,
-	WMI_10X_PDEV_DFS_DISABLE_CMDID,
-
-	/* QVIT specific command id */
-	WMI_10X_PDEV_QVIT_CMDID,
-
-	/* Offload Scan and Roaming related  commands */
-	WMI_10X_ROAM_SCAN_MODE,
-	WMI_10X_ROAM_SCAN_RSSI_THRESHOLD,
-	WMI_10X_ROAM_SCAN_PERIOD,
-	WMI_10X_ROAM_SCAN_RSSI_CHANGE_THRESHOLD,
-	WMI_10X_ROAM_AP_PROFILE,
-	WMI_10X_OFL_SCAN_ADD_AP_PROFILE,
-	WMI_10X_OFL_SCAN_REMOVE_AP_PROFILE,
-	WMI_10X_OFL_SCAN_PERIOD,
-
-	/* P2P specific commands */
-	WMI_10X_P2P_DEV_SET_DEVICE_INFO,
-	WMI_10X_P2P_DEV_SET_DISCOVERABILITY,
-	WMI_10X_P2P_GO_SET_BEACON_IE,
-	WMI_10X_P2P_GO_SET_PROBE_RESP_IE,
-
-	/* AP power save specific config */
-	WMI_10X_AP_PS_PEER_PARAM_CMDID,
-	WMI_10X_AP_PS_PEER_UAPSD_COEX_CMDID,
-
-	/* Rate-control specific commands */
-	WMI_10X_PEER_RATE_RETRY_SCHED_CMDID,
-
-	/* WLAN Profiling commands. */
-	WMI_10X_WLAN_PROFILE_TRIGGER_CMDID,
-	WMI_10X_WLAN_PROFILE_SET_HIST_INTVL_CMDID,
-	WMI_10X_WLAN_PROFILE_GET_PROFILE_DATA_CMDID,
-	WMI_10X_WLAN_PROFILE_ENABLE_PROFILE_ID_CMDID,
-	WMI_10X_WLAN_PROFILE_LIST_PROFILE_ID_CMDID,
-
-	/* Suspend resume command Ids */
-	WMI_10X_PDEV_SUSPEND_CMDID,
-	WMI_10X_PDEV_RESUME_CMDID,
-
-	/* Beacon filter commands */
-	WMI_10X_ADD_BCN_FILTER_CMDID,
-	WMI_10X_RMV_BCN_FILTER_CMDID,
-
-	/* WOW Specific WMI commands*/
-	WMI_10X_WOW_ADD_WAKE_PATTERN_CMDID,
-	WMI_10X_WOW_DEL_WAKE_PATTERN_CMDID,
-	WMI_10X_WOW_ENABLE_DISABLE_WAKE_EVENT_CMDID,
-	WMI_10X_WOW_ENABLE_CMDID,
-	WMI_10X_WOW_HOSTWAKEUP_FROM_SLEEP_CMDID,
-
-	/* RTT measurement related cmd */
-	WMI_10X_RTT_MEASREQ_CMDID,
-	WMI_10X_RTT_TSF_CMDID,
-
-	/* transmit beacon by value */
-	WMI_10X_PDEV_SEND_BCN_CMDID,
-
-	/* F/W stats */
-	WMI_10X_VDEV_SPECTRAL_SCAN_CONFIGURE_CMDID,
-	WMI_10X_VDEV_SPECTRAL_SCAN_ENABLE_CMDID,
-	WMI_10X_REQUEST_STATS_CMDID,
-
-	/* GPIO Configuration */
-	WMI_10X_GPIO_CONFIG_CMDID,
-	WMI_10X_GPIO_OUTPUT_CMDID,
-
-	WMI_10X_PDEV_UTF_CMDID = WMI_10X_END_CMDID - 1,
-};
-
-enum wmi_10x_event_id {
-	WMI_10X_SERVICE_READY_EVENTID = 0x8000,
-	WMI_10X_READY_EVENTID,
-	WMI_10X_START_EVENTID = 0x9000,
-	WMI_10X_END_EVENTID = 0x9FFF,
-
-	/* Scan specific events */
-	WMI_10X_SCAN_EVENTID = WMI_10X_START_EVENTID,
-	WMI_10X_ECHO_EVENTID,
-	WMI_10X_DEBUG_MESG_EVENTID,
-	WMI_10X_UPDATE_STATS_EVENTID,
-
-	/* Instantaneous RSSI event */
-	WMI_10X_INST_RSSI_STATS_EVENTID,
-
-	/* VDEV specific events */
-	WMI_10X_VDEV_START_RESP_EVENTID,
-	WMI_10X_VDEV_STANDBY_REQ_EVENTID,
-	WMI_10X_VDEV_RESUME_REQ_EVENTID,
-	WMI_10X_VDEV_STOPPED_EVENTID,
-
-	/* peer  specific events */
-	WMI_10X_PEER_STA_KICKOUT_EVENTID,
-
-	/* beacon/mgmt specific events */
-	WMI_10X_HOST_SWBA_EVENTID,
-	WMI_10X_TBTTOFFSET_UPDATE_EVENTID,
-	WMI_10X_MGMT_RX_EVENTID,
-
-	/* Channel stats event */
-	WMI_10X_CHAN_INFO_EVENTID,
-
-	/* PHY Error specific WMI event */
-	WMI_10X_PHYERR_EVENTID,
-
-	/* Roam event to trigger roaming on host */
-	WMI_10X_ROAM_EVENTID,
-
-	/* matching AP found from list of profiles */
-	WMI_10X_PROFILE_MATCH,
-
-	/* debug print message used for tracing FW code while debugging */
-	WMI_10X_DEBUG_PRINT_EVENTID,
-	/* VI spoecific event */
-	WMI_10X_PDEV_QVIT_EVENTID,
-	/* FW code profile data in response to profile request */
-	WMI_10X_WLAN_PROFILE_DATA_EVENTID,
-
-	/*RTT related event ID*/
-	WMI_10X_RTT_MEASUREMENT_REPORT_EVENTID,
-	WMI_10X_TSF_MEASUREMENT_REPORT_EVENTID,
-	WMI_10X_RTT_ERROR_REPORT_EVENTID,
-
-	WMI_10X_WOW_WAKEUP_HOST_EVENTID,
-	WMI_10X_DCS_INTERFERENCE_EVENTID,
-
-	/* TPC config for the current operating channel */
-	WMI_10X_PDEV_TPC_CONFIG_EVENTID,
-
-	WMI_10X_GPIO_INPUT_EVENTID,
-	WMI_10X_PDEV_UTF_EVENTID = WMI_10X_END_EVENTID - 1,
-};
-
 enum wmi_10_2_cmd_id {
 	WMI_10_2_START_CMDID = 0x9000,
 	WMI_10_2_END_CMDID = 0x9FFF,
@@ -2739,12 +2528,6 @@ struct wmi_init_cmd {
 	struct wmi_host_mem_chunks mem_chunks;
 } __packed;
 
-/* _10x stucture is from 10.X FW API */
-struct wmi_init_cmd_10x {
-	struct wmi_resource_config_10x resource_config;
-	struct wmi_host_mem_chunks mem_chunks;
-} __packed;
-
 struct wmi_init_cmd_10_2 {
 	struct wmi_resource_config_10_2 resource_config;
 	struct wmi_host_mem_chunks mem_chunks;
@@ -4241,14 +4024,6 @@ struct wmi_pdev_stats_extra {
 	__le32 mib_int_count;
 } __packed;
 
-struct wmi_10x_pdev_stats {
-	struct wmi_pdev_stats_base base;
-	struct wmi_pdev_stats_tx tx;
-	struct wmi_pdev_stats_rx rx;
-	struct wmi_pdev_stats_peer peer;
-	struct wmi_pdev_stats_extra extra;
-} __packed;
-
 struct wmi_pdev_stats_mem {
 	__le32 dram_free;
 	__le32 iram_free;
@@ -5863,23 +5638,6 @@ enum wmi_peer_flags {
 	WMI_PEER_PMF = 0x10000000,
 };
 
-enum wmi_10x_peer_flags {
-	WMI_10X_PEER_AUTH = 0x00000001,
-	WMI_10X_PEER_QOS = 0x00000002,
-	WMI_10X_PEER_NEED_PTK_4_WAY = 0x00000004,
-	WMI_10X_PEER_NEED_GTK_2_WAY = 0x00000010,
-	WMI_10X_PEER_APSD = 0x00000800,
-	WMI_10X_PEER_HT = 0x00001000,
-	WMI_10X_PEER_40MHZ = 0x00002000,
-	WMI_10X_PEER_STBC = 0x00008000,
-	WMI_10X_PEER_LDPC = 0x00010000,
-	WMI_10X_PEER_DYN_MIMOPS = 0x00020000,
-	WMI_10X_PEER_STATIC_MIMOPS = 0x00040000,
-	WMI_10X_PEER_SPATIAL_MUX = 0x00200000,
-	WMI_10X_PEER_VHT = 0x02000000,
-	WMI_10X_PEER_80MHZ = 0x04000000,
-};
-
 enum wmi_10_2_peer_flags {
 	WMI_10_2_PEER_AUTH = 0x00000001,
 	WMI_10_2_PEER_QOS = 0x00000002,
@@ -5949,10 +5707,6 @@ struct wmi_main_peer_assoc_complete_cmd {
 	__le32 peer_ht_info[2];
 } __packed;
 
-struct wmi_10_1_peer_assoc_complete_cmd {
-	struct wmi_common_peer_assoc_complete_cmd cmd;
-} __packed;
-
 #define WMI_PEER_ASSOC_INFO0_MAX_MCS_IDX_LSB 0
 #define WMI_PEER_ASSOC_INFO0_MAX_MCS_IDX_MASK 0x0f
 #define WMI_PEER_ASSOC_INFO0_MAX_NSS_LSB 4
-- 
2.8.3



From vthiagar at qti.qualcomm.com  Fri Jun  3 08:43:15 2016
From: vthiagar at qti.qualcomm.com (Vasanthakumar Thiagarajan)
Date: Fri, 3 Jun 2016 21:13:15 +0530
Subject: [PATCH 1/2] ath10k: Define an enum to enable cycle counter wraparound
 logic
Message-ID: <1464968596-19834-1-git-send-email-vthiagar@qti.qualcomm.com>

QCA988X hw implements a different cycle counter wraparound
behaviour when compared to QCA4019. To properly handle different
wraparound logic for these chipsets replace already available
bool hw_params member, has_shifted_cc_wraparound, with an
enum which could be extended to handle different wraparound
behaviour. This patch keeps the existing logic functionally
same and a prepares cycle counter wraparound handling to
extend for other chips.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c |  4 ++--
 drivers/net/wireless/ath/ath10k/core.h |  8 +++-----
 drivers/net/wireless/ath/ath10k/hw.c   |  4 +++-
 drivers/net/wireless/ath/ath10k/hw.h   | 11 +++++++++++
 4 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index cedf127..8f66653 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -55,7 +55,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.name = "qca988x hw2.0",
 		.patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
 		.uart_pin = 7,
-		.has_shifted_cc_wraparound = true,
+		.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
 		.otp_exe_param = 0,
 		.channel_counters_freq_hz = 88000,
 		.max_probe_resp_desc_thres = 0,
@@ -224,7 +224,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.name = "qca4019 hw1.0",
 		.patch_load_addr = QCA4019_HW_1_0_PATCH_LOAD_ADDR,
 		.uart_pin = 7,
-		.has_shifted_cc_wraparound = true,
+		.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
 		.otp_exe_param = 0x0010000,
 		.continuous_frag_desc = true,
 		.channel_counters_freq_hz = 125000,
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 4462c3f..b42b21f 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -710,12 +710,10 @@ struct ath10k {
 		int uart_pin;
 		u32 otp_exe_param;
 
-		/* This is true if given HW chip has a quirky Cycle Counter
-		 * wraparound which resets to 0x7fffffff instead of 0. All
-		 * other CC related counters (e.g. Rx Clear Count) are divided
-		 * by 2 so they never wraparound themselves.
+		/* Type of hw cycle counter wraparound logic, for more info
+		 * refer enum ath10k_hw_cc_wraparound_type.
 		 */
-		bool has_shifted_cc_wraparound;
+		enum ath10k_hw_cc_wraparound_type cc_wraparound_type;
 
 		/* Some of chip expects fragment descriptor to be continuous
 		 * memory for any TX operation. Set continuous_frag_desc flag
diff --git a/drivers/net/wireless/ath/ath10k/hw.c b/drivers/net/wireless/ath/ath10k/hw.c
index f544d48..31ec164 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -179,11 +179,13 @@ void ath10k_hw_fill_survey_time(struct ath10k *ar, struct survey_info *survey,
 				u32 cc, u32 rcc, u32 cc_prev, u32 rcc_prev)
 {
 	u32 cc_fix = 0;
+	enum ath10k_hw_cc_wraparound_type wraparound_type;
 
 	survey->filled |= SURVEY_INFO_TIME |
 			  SURVEY_INFO_TIME_BUSY;
 
-	if (ar->hw_params.has_shifted_cc_wraparound && cc < cc_prev) {
+	wraparound_type = ar->hw_params.cc_wraparound_type;
+	if (wraparound_type == ATH10K_HW_CC_WRAP_SHIFTED_ALL && cc < cc_prev) {
 		cc_fix = 0x7fffffff;
 		survey->filled &= ~SURVEY_INFO_TIME_BUSY;
 	}
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index f41c91c..64e45b2 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -331,6 +331,17 @@ enum ath10k_hw_4addr_pad {
 	ATH10K_HW_4ADDR_PAD_BEFORE,
 };
 
+enum ath10k_hw_cc_wraparound_type {
+	ATH10K_HW_CC_WRAP_DISABLED = 0,
+
+	/* This type is when the HW chip has a quirky Cycle Counter
+	 * wraparound which resets to 0x7fffffff instead of 0. All
+	 * other CC related counters (e.g. Rx Clear Count) are divided
+	 * by 2 so they never wraparound themselves.
+	 */
+	ATH10K_HW_CC_WRAP_SHIFTED_ALL = 1,
+};
+
 /* Target specific defines for MAIN firmware */
 #define TARGET_NUM_VDEVS			8
 #define TARGET_NUM_PEER_AST			2
-- 
1.9.1



From vthiagar at qti.qualcomm.com  Fri Jun  3 08:43:16 2016
From: vthiagar at qti.qualcomm.com (Vasanthakumar Thiagarajan)
Date: Fri, 3 Jun 2016 21:13:16 +0530
Subject: [PATCH 2/2] ath10k: Fix cycle counter wraparound handling for QCA4019
In-Reply-To: <1464968596-19834-1-git-send-email-vthiagar@qti.qualcomm.com>
References: <1464968596-19834-1-git-send-email-vthiagar@qti.qualcomm.com>
Message-ID: <1464968596-19834-2-git-send-email-vthiagar@qti.qualcomm.com>

In QCA4019, cycle counter wraparound is not tied to rx
clear counter. Each counter would wraparound individually
and after wraparound the respective counter will be reset
to 0x7fffffff while other counter still running unaffected.
Define a new wraparound type for this behaviour and handle
it separately so that rx clear counter wraparound is also
handled just like cycle counter. With this type of
wraparound we can accurately compute and report channel
active/busy time when any of the counter overflows.

Fixes: ee9ca147c59 ("ath10k: Fix survey reporting with QCA4019")
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c |  2 +-
 drivers/net/wireless/ath/ath10k/hw.c   | 24 ++++++++++++++++++++----
 drivers/net/wireless/ath/ath10k/hw.h   |  9 +++++++++
 3 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 8f66653..5ede9a4 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -224,7 +224,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.name = "qca4019 hw1.0",
 		.patch_load_addr = QCA4019_HW_1_0_PATCH_LOAD_ADDR,
 		.uart_pin = 7,
-		.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
+		.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
 		.otp_exe_param = 0x0010000,
 		.continuous_frag_desc = true,
 		.channel_counters_freq_hz = 125000,
diff --git a/drivers/net/wireless/ath/ath10k/hw.c b/drivers/net/wireless/ath/ath10k/hw.c
index 31ec164..bd86e7a 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -179,19 +179,35 @@ void ath10k_hw_fill_survey_time(struct ath10k *ar, struct survey_info *survey,
 				u32 cc, u32 rcc, u32 cc_prev, u32 rcc_prev)
 {
 	u32 cc_fix = 0;
+	u32 rcc_fix = 0;
 	enum ath10k_hw_cc_wraparound_type wraparound_type;
 
 	survey->filled |= SURVEY_INFO_TIME |
 			  SURVEY_INFO_TIME_BUSY;
 
 	wraparound_type = ar->hw_params.cc_wraparound_type;
-	if (wraparound_type == ATH10K_HW_CC_WRAP_SHIFTED_ALL && cc < cc_prev) {
-		cc_fix = 0x7fffffff;
-		survey->filled &= ~SURVEY_INFO_TIME_BUSY;
+
+	if (cc < cc_prev || rcc < rcc_prev) {
+		switch (wraparound_type) {
+		case ATH10K_HW_CC_WRAP_SHIFTED_ALL:
+			if (cc < cc_prev) {
+				cc_fix = 0x7fffffff;
+				survey->filled &= ~SURVEY_INFO_TIME_BUSY;
+			}
+			break;
+		case ATH10K_HW_CC_WRAP_SHIFTED_EACH:
+			if (cc < cc_prev)
+				cc_fix = 0x7fffffff;
+			else
+				rcc_fix = 0x7fffffff;
+			break;
+		case ATH10K_HW_CC_WRAP_DISABLED:
+			break;
+		}
 	}
 
 	cc -= cc_prev - cc_fix;
-	rcc -= rcc_prev;
+	rcc -= rcc_prev - rcc_fix;
 
 	survey->time = CCNT_TO_MSEC(ar, cc);
 	survey->time_busy = CCNT_TO_MSEC(ar, rcc);
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 64e45b2..7657c60 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -340,6 +340,15 @@ enum ath10k_hw_cc_wraparound_type {
 	 * by 2 so they never wraparound themselves.
 	 */
 	ATH10K_HW_CC_WRAP_SHIFTED_ALL = 1,
+
+	/* Each hw counter wrapsaround independently. When the
+	 * counter overflows the repestive counter is right shifted
+	 * by 1, i.e reset to 0x7fffffff, and other counters will be
+	 * running unaffected. In this type of wraparound, it should
+	 * be possible to report accurate Rx busy time unlike the
+	 * first type.
+	 */
+	ATH10K_HW_CC_WRAP_SHIFTED_EACH = 2,
 };
 
 /* Target specific defines for MAIN firmware */
-- 
1.9.1



From kvalo at qca.qualcomm.com  Fri Jun  3 08:52:03 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Fri, 3 Jun 2016 15:52:03 +0000
Subject: Bug 119151 - [regression] ath10k no longer authenitcates and
 freezes system
In-Reply-To: <57505179.8090509@candelatech.com> (Ben Greear's message of "Thu, 
 2 Jun 2016 08:32:09 -0700")
References: <8760trzoiw.fsf@kamboji.qca.qualcomm.com>
 <871t4fzn1x.fsf@kamboji.qca.qualcomm.com>	<57504F05.3040200@candelatech.com>
 <87k2i7y5m2.fsf@kamboji.qca.qualcomm.com>	<57505179.8090509@candelatech.com>
Message-ID: <871t4ew9r1.fsf@kamboji.qca.qualcomm.com>

Ben Greear <greearb at candelatech.com> writes:

> On 06/02/2016 08:26 AM, Valo, Kalle wrote:
>> Ben Greear <greearb at candelatech.com> writes:
>>
>>> I found a lot of problems with this code as well, and the 5 patches
>>> starting from the URL below fixed the issues for me.
>>>
>>> They are stuck as 'NA' in patchwork, but I don't know why.
>>>
>>> http://lists.infradead.org/pipermail/ath10k/2016-April/007218.html
>>
>> ath10k has a separate patchwork instance, did you look at the correct
>> one? I have quite a lot of patches from you in deferred state because of
>> the patch bomb, but I'm hoping to go through them soon.
>>
>> https://patchwork.kernel.org/project/ath10k/list/?state=10&delegate=25621&order=date
>
> Ok, they are deferred then.
>
> The series of 5 is likely quite useful and fixes some nasty bugs,
> and the first patch of the big bomb is also a trivial crash fix
> for a regression you added (as best as I can tell).
>
> The rest of the patch bomb is less critical, but making some progress on
> that would make me feel good about working on ath10k patches again.

If I get a big patchset like 25 patches it immediately goes to the
bottom of the queue. Organising them a bit better takes like 15 minutes
of your time and makes it a lot easier to review. For example, you could
have split the patches into three sets: important bug fixes, firmware
debugging and the rest. That helps everyone and saves time.

-- 
Kalle Valo

From greearb at candelatech.com  Fri Jun  3 08:48:37 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 3 Jun 2016 08:48:37 -0700
Subject: [PATCH 2/2] ath10k: remove 10.1 firmware support
In-Reply-To: <20160603153328.11947-2-rmanohar@qti.qualcomm.com>
References: <20160603153328.11947-1-rmanohar@qti.qualcomm.com>
 <20160603153328.11947-2-rmanohar@qti.qualcomm.com>
Message-ID: <5751A6D5.7080901@candelatech.com>

On 06/03/2016 08:33 AM, Rajkumar Manoharan wrote:
> Earlier qca9888 device was brought up using 10.1 firmware and then
> later all firmware fixes and new features are migrated to 10.2/10.2.x
> firmware branch. As all of 10.1 funtionalities are supported in 10.2
> based firmware, removing 10.1 firmware support for qca9888 device.

Oh please do not do this.  My 10.1 firmware works very nicely,
and out-performs 10.2 in my testing.  Lots of people use my firmware
when they need IBSS support or other features not found in
official firmware, so it is not just me that will have
problems if you remove this support.

Thanks,
Ben

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



From rmanohar at codeaurora.org  Fri Jun  3 08:55:00 2016
From: rmanohar at codeaurora.org (Rajkumar Manoharan)
Date: Fri, 03 Jun 2016 21:25:00 +0530
Subject: [PATCH 2/2] ath10k: remove 10.1 firmware support
In-Reply-To: <5751A6D5.7080901@candelatech.com>
References: <20160603153328.11947-1-rmanohar@qti.qualcomm.com>
 <20160603153328.11947-2-rmanohar@qti.qualcomm.com>
 <5751A6D5.7080901@candelatech.com>
Message-ID: <743182bcbd1efbdb576bcc51b0215300@codeaurora.org>

On 2016-06-03 21:18, Ben Greear wrote:
> On 06/03/2016 08:33 AM, Rajkumar Manoharan wrote:
>> Earlier qca9888 device was brought up using 10.1 firmware and then
>> later all firmware fixes and new features are migrated to 10.2/10.2.x
>> firmware branch. As all of 10.1 funtionalities are supported in 10.2
>> based firmware, removing 10.1 firmware support for qca9888 device.
> 
> Oh please do not do this.  My 10.1 firmware works very nicely,
> and out-performs 10.2 in my testing.  Lots of people use my firmware
> when they need IBSS support or other features not found in
> official firmware, so it is not just me that will have
> problems if you remove this support.
> 
Aah.. I thought CT firmware is 10.2 based. Since most of firmware bug 
fixes and enhancements are integrated into 10.2 based firmware, we 
thought of get rid of 10.1 firmware to reduce code size. Moreover 
existing 10.1 official firmware has known issues. Is it possible to 
upgrade CT firmware to 10.2 WMI/HTT interfaces?

-Rajkumar


From kvalo at qca.qualcomm.com  Fri Jun  3 09:02:28 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Fri, 3 Jun 2016 16:02:28 +0000
Subject: Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath
In-Reply-To: <f495d218d54a4c4c859849a85f38ab0c@aphydexm01b.ap.qualcomm.com>
 (Rajkumar Manoharan's message of "Thu, 2 Jun 2016 17:20:06 +0000")
References: <f495d218d54a4c4c859849a85f38ab0c@aphydexm01b.ap.qualcomm.com>
Message-ID: <87wpm6uup8.fsf@kamboji.qca.qualcomm.com>

(Fixing Felix' address to nbd at nbd.name)

"Manoharan, Rajkumar" <rmanohar at qti.qualcomm.com> writes:

> Found a regression in ath.git TOT that system hangs while probing qca99x0 device on x86_64 platform.
> It seems the system hangs while DMA mapping of bigger memory chunks. Below are the list of memory
> chucks requested by target for qca99x0 during service ready event. This issue is seen only on x86 platform.
> No issues are observed on ARM platform (AP148). After reverting below commit able to bring up device on x86.
>
> Jun  2 17:24:37 rmanohar-arch kernel: idx 0 pool_size 689816 num_units 529 unit_len 1304
> Jun  2 17:24:37 rmanohar-arch kernel: idx 1 pool_size 17152 num_units 67 unit_len 256
> Jun  2 17:24:37 rmanohar-arch kernel: idx 2 pool_size 68608 num_units 67 unit_len 1024
> Jun  2 17:24:37 rmanohar-arch kernel: idx 3 pool_size 274432 num_units 67 unit_len 4096
> Jun  2 17:24:37 rmanohar-arch kernel: idx 4 pool_size 107520 num_units 35 unit_len 3072
> Jun  2 17:24:37 rmanohar-arch kernel: idx 5 pool_size 6144 num_units 1 unit_len 6144
> Jun  2 17:24:37 rmanohar-arch kernel: idx 6 pool_size 865444 num_units 529 unit_len 1636

Did you enable kernel debugging features, like deplock, memory
poisoning, DMA-API debug etc? They might give more hints why it's
failing. We should get bottom of this.

Felix, in case you missed because of the old email address the commit
is:

commit b057886524be060021e3cfad0ba8458c850330cd
Author: Felix Fietkau <nbd at openwrt.org>
Date:   Mon Nov 30 19:32:01 2015 +0100

    ath10k: do not use coherent memory for allocated device memory chunks
    
    Coherent memory is more expensive to allocate (and constrained on some
    architectures where it has to be pre-allocated). It is also completely
    unnecessary, since the host has no reason to even access these allocated
    memory spaces
    
    Signed-off-by: Felix Fietkau <nbd at openwrt.org>
    Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>

-- 
Kalle Valo

From greearb at candelatech.com  Fri Jun  3 09:07:27 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 3 Jun 2016 09:07:27 -0700
Subject: [PATCH 2/2] ath10k: remove 10.1 firmware support
In-Reply-To: <743182bcbd1efbdb576bcc51b0215300@codeaurora.org>
References: <20160603153328.11947-1-rmanohar@qti.qualcomm.com>
 <20160603153328.11947-2-rmanohar@qti.qualcomm.com>
 <5751A6D5.7080901@candelatech.com>
 <743182bcbd1efbdb576bcc51b0215300@codeaurora.org>
Message-ID: <5751AB3F.2070604@candelatech.com>

On 06/03/2016 08:55 AM, Rajkumar Manoharan wrote:
> On 2016-06-03 21:18, Ben Greear wrote:
>> On 06/03/2016 08:33 AM, Rajkumar Manoharan wrote:
>>> Earlier qca9888 device was brought up using 10.1 firmware and then
>>> later all firmware fixes and new features are migrated to 10.2/10.2.x
>>> firmware branch. As all of 10.1 funtionalities are supported in 10.2
>>> based firmware, removing 10.1 firmware support for qca9888 device.
>>
>> Oh please do not do this.  My 10.1 firmware works very nicely,
>> and out-performs 10.2 in my testing.  Lots of people use my firmware
>> when they need IBSS support or other features not found in
>> official firmware, so it is not just me that will have
>> problems if you remove this support.
>>
> Aah.. I thought CT firmware is 10.2 based. Since most of firmware bug fixes and enhancements are integrated into 10.2 based firmware, we thought of get rid of
> 10.1 firmware to reduce code size. Moreover existing 10.1 official firmware has known issues. Is it possible to upgrade CT firmware to 10.2 WMI/HTT interfaces?

I have a 10.2 firmware too, but it is less stable, performs worse,
uses more RAM on the NIC (so I can do fewer virtual stations),
and I am not sure I can squeeze enough RAM out of it to port some
of the more interesting rate-ctrl fixes from 10.1 to 10.2.
I have recently started backporting a lot of 10.2.4 changes
into 10.1, which will aid any users on pre 4.0 kernels since they cannot
run 10.2.4 firmware w/out backporting.

I might could make my 10.1 work with a 10.2 driver API, but it would take quite a bit of
effort, way more than what removing 10.1 from the driver saves in my opinion.
The driver already separates firmware specific logic pretty well, so I don't think
it should be a huge maintenance effort to keep 10.1 support in the driver.

Maybe you could delete the 10.2 (not 10.2.4) firmware support and gain some space that way?  I
doubt anyone is using that productively....

Thanks,
Ben


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



From kvalo at qca.qualcomm.com  Fri Jun  3 09:09:55 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Fri, 3 Jun 2016 16:09:55 +0000
Subject: [PATCH 2/2] ath10k: remove 10.1 firmware support
In-Reply-To: <743182bcbd1efbdb576bcc51b0215300@codeaurora.org> (Rajkumar
 Manoharan's message of "Fri, 03 Jun 2016 21:25:00 +0530")
References: <20160603153328.11947-1-rmanohar@qti.qualcomm.com>
 <20160603153328.11947-2-rmanohar@qti.qualcomm.com>
 <5751A6D5.7080901@candelatech.com>
 <743182bcbd1efbdb576bcc51b0215300@codeaurora.org>
Message-ID: <87shwuuuct.fsf@kamboji.qca.qualcomm.com>

Rajkumar Manoharan <rmanohar at codeaurora.org> writes:

> On 2016-06-03 21:18, Ben Greear wrote:
>> On 06/03/2016 08:33 AM, Rajkumar Manoharan wrote:
>>> Earlier qca9888 device was brought up using 10.1 firmware and then
>>> later all firmware fixes and new features are migrated to 10.2/10.2.x
>>> firmware branch. As all of 10.1 funtionalities are supported in 10.2
>>> based firmware, removing 10.1 firmware support for qca9888 device.
>>
>> Oh please do not do this.  My 10.1 firmware works very nicely,
>> and out-performs 10.2 in my testing.  Lots of people use my firmware
>> when they need IBSS support or other features not found in
>> official firmware, so it is not just me that will have
>> problems if you remove this support.
>>
> Aah.. I thought CT firmware is 10.2 based. Since most of firmware bug
> fixes and enhancements are integrated into 10.2 based firmware, we
> thought of get rid of 10.1 firmware to reduce code size. Moreover
> existing 10.1 official firmware has known issues.

Yeah, we really want to reduce the amount firmware branches to support
in ath10k.

> Is it possible to upgrade CT firmware to 10.2 WMI/HTT interfaces?

That's a good idea. That shouldn't be too hard, right? I don't think HTT needs
any changes, but for WMI few commands and ids need to be changed.

-- 
Kalle Valo

From greearb at candelatech.com  Fri Jun  3 09:12:57 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 3 Jun 2016 09:12:57 -0700
Subject: Bug 119151 - [regression] ath10k no longer authenitcates and
 freezes system
In-Reply-To: <871t4ew9r1.fsf@kamboji.qca.qualcomm.com>
References: <8760trzoiw.fsf@kamboji.qca.qualcomm.com>
 <871t4fzn1x.fsf@kamboji.qca.qualcomm.com> <57504F05.3040200@candelatech.com>
 <87k2i7y5m2.fsf@kamboji.qca.qualcomm.com> <57505179.8090509@candelatech.com>
 <871t4ew9r1.fsf@kamboji.qca.qualcomm.com>
Message-ID: <5751AC89.6050607@candelatech.com>

On 06/03/2016 08:52 AM, Valo, Kalle wrote:
> Ben Greear <greearb at candelatech.com> writes:
>
>> On 06/02/2016 08:26 AM, Valo, Kalle wrote:
>>> Ben Greear <greearb at candelatech.com> writes:
>>>
>>>> I found a lot of problems with this code as well, and the 5 patches
>>>> starting from the URL below fixed the issues for me.
>>>>
>>>> They are stuck as 'NA' in patchwork, but I don't know why.
>>>>
>>>> http://lists.infradead.org/pipermail/ath10k/2016-April/007218.html
>>>
>>> ath10k has a separate patchwork instance, did you look at the correct
>>> one? I have quite a lot of patches from you in deferred state because of
>>> the patch bomb, but I'm hoping to go through them soon.
>>>
>>> https://patchwork.kernel.org/project/ath10k/list/?state=10&delegate=25621&order=date
>>
>> Ok, they are deferred then.
>>
>> The series of 5 is likely quite useful and fixes some nasty bugs,
>> and the first patch of the big bomb is also a trivial crash fix
>> for a regression you added (as best as I can tell).
>>
>> The rest of the patch bomb is less critical, but making some progress on
>> that would make me feel good about working on ath10k patches again.
>
> If I get a big patchset like 25 patches it immediately goes to the
> bottom of the queue. Organising them a bit better takes like 15 minutes
> of your time and makes it a lot easier to review. For example, you could
> have split the patches into three sets: important bug fixes, firmware
> debugging and the rest. That helps everyone and saves time.

The first 5 were posted a month earlier than the 25 patchset, and are
bug fixes.  Whatever reason you ignored them, it wasn't because
there were 25 patches from me on the list at the time.

The second big series has the first patch as bug-fix, and clearly noted
in the 0000 description.  Grab it, and save the rest for later.

I'll be happy to re-work the big patch-set, but there is a lot of churn in
ath10k, and waiting months before applying patches means they rot and makes
more work for everyone.  Let's get these 6 bug-fixes in, and then I'll rebase,
test, and post a smaller patch-set for consideration.

Thanks,
Ben

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



From greearb at candelatech.com  Fri Jun  3 09:20:20 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 3 Jun 2016 09:20:20 -0700
Subject: [PATCH 2/2] ath10k: remove 10.1 firmware support
In-Reply-To: <87shwuuuct.fsf@kamboji.qca.qualcomm.com>
References: <20160603153328.11947-1-rmanohar@qti.qualcomm.com>
 <20160603153328.11947-2-rmanohar@qti.qualcomm.com>
 <5751A6D5.7080901@candelatech.com>
 <743182bcbd1efbdb576bcc51b0215300@codeaurora.org>
 <87shwuuuct.fsf@kamboji.qca.qualcomm.com>
Message-ID: <5751AE44.8050607@candelatech.com>

On 06/03/2016 09:09 AM, Valo, Kalle wrote:
> Rajkumar Manoharan <rmanohar at codeaurora.org> writes:
>
>> On 2016-06-03 21:18, Ben Greear wrote:
>>> On 06/03/2016 08:33 AM, Rajkumar Manoharan wrote:
>>>> Earlier qca9888 device was brought up using 10.1 firmware and then
>>>> later all firmware fixes and new features are migrated to 10.2/10.2.x
>>>> firmware branch. As all of 10.1 funtionalities are supported in 10.2
>>>> based firmware, removing 10.1 firmware support for qca9888 device.
>>>
>>> Oh please do not do this.  My 10.1 firmware works very nicely,
>>> and out-performs 10.2 in my testing.  Lots of people use my firmware
>>> when they need IBSS support or other features not found in
>>> official firmware, so it is not just me that will have
>>> problems if you remove this support.
>>>
>> Aah.. I thought CT firmware is 10.2 based. Since most of firmware bug
>> fixes and enhancements are integrated into 10.2 based firmware, we
>> thought of get rid of 10.1 firmware to reduce code size. Moreover
>> existing 10.1 official firmware has known issues.
>
> Yeah, we really want to reduce the amount firmware branches to support
> in ath10k.
>
>> Is it possible to upgrade CT firmware to 10.2 WMI/HTT interfaces?
>
> That's a good idea. That shouldn't be too hard, right? I don't think HTT needs
> any changes, but for WMI few commands and ids need to be changed.

I was thinking the 10.2 mgt-over-htt API would be trouble-some to make work on
10.1 firmware.  I have my own way to do mgt-over-htt in 10.1, but API
is different and I would need a small driver patch upstream
to make that work.  I'm not sure what other changes would be needed, but
if it is just conditionally compiling some WMI defines, that should be
doable.

Thanks,
Ben

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



From rmanohar at codeaurora.org  Fri Jun  3 09:28:28 2016
From: rmanohar at codeaurora.org (Rajkumar Manoharan)
Date: Fri, 03 Jun 2016 21:58:28 +0530
Subject: [PATCH 2/2] ath10k: remove 10.1 firmware support
In-Reply-To: <5751AB3F.2070604@candelatech.com>
References: <20160603153328.11947-1-rmanohar@qti.qualcomm.com>
 <20160603153328.11947-2-rmanohar@qti.qualcomm.com>
 <5751A6D5.7080901@candelatech.com>
 <743182bcbd1efbdb576bcc51b0215300@codeaurora.org>
 <5751AB3F.2070604@candelatech.com>
Message-ID: <0ec837e1ff03d8a7df8bc06ebca7c635@codeaurora.org>

On 2016-06-03 21:37, Ben Greear wrote:
> On 06/03/2016 08:55 AM, Rajkumar Manoharan wrote:
>> On 2016-06-03 21:18, Ben Greear wrote:
>>> On 06/03/2016 08:33 AM, Rajkumar Manoharan wrote:
>>>> Earlier qca9888 device was brought up using 10.1 firmware and then
>>>> later all firmware fixes and new features are migrated to 
>>>> 10.2/10.2.x
>>>> firmware branch. As all of 10.1 funtionalities are supported in 10.2
>>>> based firmware, removing 10.1 firmware support for qca9888 device.
>>> 
>>> Oh please do not do this.  My 10.1 firmware works very nicely,
>>> and out-performs 10.2 in my testing.  Lots of people use my firmware
>>> when they need IBSS support or other features not found in
>>> official firmware, so it is not just me that will have
>>> problems if you remove this support.
>>> 
>> Aah.. I thought CT firmware is 10.2 based. Since most of firmware bug 
>> fixes and enhancements are integrated into 10.2 based firmware, we 
>> thought of get rid of
>> 10.1 firmware to reduce code size. Moreover existing 10.1 official 
>> firmware has known issues. Is it possible to upgrade CT firmware to 
>> 10.2 WMI/HTT interfaces?
> 
> I have a 10.2 firmware too, but it is less stable, performs worse,
> uses more RAM on the NIC (so I can do fewer virtual stations),
> and I am not sure I can squeeze enough RAM out of it to port some
> of the more interesting rate-ctrl fixes from 10.1 to 10.2.
> I have recently started backporting a lot of 10.2.4 changes
> into 10.1, which will aid any users on pre 4.0 kernels since they 
> cannot
> run 10.2.4 firmware w/out backporting.
> 
> I might could make my 10.1 work with a 10.2 driver API, but it would
> take quite a bit of
> effort, way more than what removing 10.1 from the driver saves in my 
> opinion.
> The driver already separates firmware specific logic pretty well, so I
> don't think
> it should be a huge maintenance effort to keep 10.1 support in the 
> driver.
> 
> Maybe you could delete the 10.2 (not 10.2.4) firmware support and gain
> some space that way?  I
> doubt anyone is using that productively....
> 
Nope. There are customers who are still using 10.2.2 firmware. My kind 
advice is that please try to optimize latest firmware. 10.2 is nothing 
but based on 10.1 trunk so there wont be much interface difference... 
Will drop this series as of now...

Kalle,

Please drop this series.. Sorry for the noise.

-Rajkumar



From kvalo at qca.qualcomm.com  Fri Jun  3 09:33:16 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Fri, 3 Jun 2016 16:33:16 +0000
Subject: [PATCH 2/2] ath10k: remove 10.1 firmware support
In-Reply-To: <5751AE44.8050607@candelatech.com> (Ben Greear's message of "Fri, 
 3 Jun 2016 09:20:20 -0700")
References: <20160603153328.11947-1-rmanohar@qti.qualcomm.com>
 <20160603153328.11947-2-rmanohar@qti.qualcomm.com>
 <5751A6D5.7080901@candelatech.com>
 <743182bcbd1efbdb576bcc51b0215300@codeaurora.org>
 <87shwuuuct.fsf@kamboji.qca.qualcomm.com>	<5751AE44.8050607@candelatech.com>
Message-ID: <87oa7iut9x.fsf@kamboji.qca.qualcomm.com>

Ben Greear <greearb at candelatech.com> writes:

>>> Is it possible to upgrade CT firmware to 10.2 WMI/HTT interfaces?
>>
>> That's a good idea. That shouldn't be too hard, right? I don't think HTT needs
>> any changes, but for WMI few commands and ids need to be changed.
>
> I was thinking the 10.2 mgt-over-htt API would be trouble-some to make work on
> 10.1 firmware.

Yeah, that would be harder. But I don't see Rajkumar removing support
for that (yet) or am I missing something?

-- 
Kalle Valo

From greearb at candelatech.com  Fri Jun  3 09:36:15 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 3 Jun 2016 09:36:15 -0700
Subject: [PATCH 2/2] ath10k: remove 10.1 firmware support
In-Reply-To: <0ec837e1ff03d8a7df8bc06ebca7c635@codeaurora.org>
References: <20160603153328.11947-1-rmanohar@qti.qualcomm.com>
 <20160603153328.11947-2-rmanohar@qti.qualcomm.com>
 <5751A6D5.7080901@candelatech.com>
 <743182bcbd1efbdb576bcc51b0215300@codeaurora.org>
 <5751AB3F.2070604@candelatech.com>
 <0ec837e1ff03d8a7df8bc06ebca7c635@codeaurora.org>
Message-ID: <5751B1FF.2070307@candelatech.com>

On 06/03/2016 09:28 AM, Rajkumar Manoharan wrote:
> On 2016-06-03 21:37, Ben Greear wrote:
>> On 06/03/2016 08:55 AM, Rajkumar Manoharan wrote:
>>> On 2016-06-03 21:18, Ben Greear wrote:
>>>> On 06/03/2016 08:33 AM, Rajkumar Manoharan wrote:
>>>>> Earlier qca9888 device was brought up using 10.1 firmware and then
>>>>> later all firmware fixes and new features are migrated to 10.2/10.2.x
>>>>> firmware branch. As all of 10.1 funtionalities are supported in 10.2
>>>>> based firmware, removing 10.1 firmware support for qca9888 device.
>>>>
>>>> Oh please do not do this.  My 10.1 firmware works very nicely,
>>>> and out-performs 10.2 in my testing.  Lots of people use my firmware
>>>> when they need IBSS support or other features not found in
>>>> official firmware, so it is not just me that will have
>>>> problems if you remove this support.
>>>>
>>> Aah.. I thought CT firmware is 10.2 based. Since most of firmware bug fixes and enhancements are integrated into 10.2 based firmware, we thought of get rid of
>>> 10.1 firmware to reduce code size. Moreover existing 10.1 official firmware has known issues. Is it possible to upgrade CT firmware to 10.2 WMI/HTT interfaces?
>>
>> I have a 10.2 firmware too, but it is less stable, performs worse,
>> uses more RAM on the NIC (so I can do fewer virtual stations),
>> and I am not sure I can squeeze enough RAM out of it to port some
>> of the more interesting rate-ctrl fixes from 10.1 to 10.2.
>> I have recently started backporting a lot of 10.2.4 changes
>> into 10.1, which will aid any users on pre 4.0 kernels since they cannot
>> run 10.2.4 firmware w/out backporting.
>>
>> I might could make my 10.1 work with a 10.2 driver API, but it would
>> take quite a bit of
>> effort, way more than what removing 10.1 from the driver saves in my opinion.
>> The driver already separates firmware specific logic pretty well, so I
>> don't think
>> it should be a huge maintenance effort to keep 10.1 support in the driver.
>>
>> Maybe you could delete the 10.2 (not 10.2.4) firmware support and gain
>> some space that way?  I
>> doubt anyone is using that productively....
>>
> Nope. There are customers who are still using 10.2.2 firmware. My kind advice is that please try to optimize latest firmware. 10.2 is nothing but based on 10.1
> trunk so there wont be much interface difference... Will drop this series as of now...

10.2 has a significant re-work of the rate-ctrl.  I think that is the main difference
that I see.

Maybe I can just copy the 10.1 rate-ctrl over 10.2 and get back the memory and performance
that I need.  But, I have a bunch of other stuff to do first.

Thanks,
Ben


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



From greearb at candelatech.com  Fri Jun  3 09:46:56 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 3 Jun 2016 09:46:56 -0700
Subject: [PATCH 2/2] ath10k: remove 10.1 firmware support
In-Reply-To: <87oa7iut9x.fsf@kamboji.qca.qualcomm.com>
References: <20160603153328.11947-1-rmanohar@qti.qualcomm.com>
 <20160603153328.11947-2-rmanohar@qti.qualcomm.com>
 <5751A6D5.7080901@candelatech.com>
 <743182bcbd1efbdb576bcc51b0215300@codeaurora.org>
 <87shwuuuct.fsf@kamboji.qca.qualcomm.com> <5751AE44.8050607@candelatech.com>
 <87oa7iut9x.fsf@kamboji.qca.qualcomm.com>
Message-ID: <5751B480.2060106@candelatech.com>

On 06/03/2016 09:33 AM, Valo, Kalle wrote:
> Ben Greear <greearb at candelatech.com> writes:
>
>>>> Is it possible to upgrade CT firmware to 10.2 WMI/HTT interfaces?
>>>
>>> That's a good idea. That shouldn't be too hard, right? I don't think HTT needs
>>> any changes, but for WMI few commands and ids need to be changed.
>>
>> I was thinking the 10.2 mgt-over-htt API would be trouble-some to make work on
>> 10.1 firmware.
>
> Yeah, that would be harder. But I don't see Rajkumar removing support
> for that (yet) or am I missing something?

What I mean is that to just make my 10.1 firmware act like 10.2 would require
my 10.1 to suddenly support 10.2's mgt-over-htt.  I think that will be difficult,
and there is plenty of risk that some subtle WMI change would cause hard-to-detect
bugs.

I have done an initial port of my 10.1 changes to 10.2, it is just that the
result is poor, and so I quit messing with 10.2 and re-focussed on 10.1
for the time being.

Another way to help with this problem in general is to quit adding so many
new firmware API.  It is a lot easier to make a new firmware backwards compat
than it is to make an old firmware forwards compat.  When you are designing your
WMI changes in new firmware, do it with care, and then you can reuse the vast bulk
of your driver.  I managed to add quite a few new features to my 10.1 in this
manner, and the driver patches (mostly keyed off of feature flags) are not that
invasive.

Thanks,
Ben

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



From kvalo at qca.qualcomm.com  Sat Jun  4 06:21:01 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Sat, 4 Jun 2016 13:21:01 +0000
Subject: [PATCH 1/2] ath10k: add QCA9887 chipset support
In-Reply-To: <1463755272-12912-1-git-send-email-sven.eckelmann@open-mesh.com>
 (Sven Eckelmann's message of "Fri, 20 May 2016 16:41:11 +0200")
References: <1568876.Six5hABE57@bentobox>
 <1463755272-12912-1-git-send-email-sven.eckelmann@open-mesh.com>
Message-ID: <87twh9t7ib.fsf@kamboji.qca.qualcomm.com>

Sven Eckelmann <sven.eckelmann at open-mesh.com> writes:

> Add the hardware name, revision, firmware names and update the pci_id
> table.
>
> QA9887 HW1.0 is supposed to be similar to QCA988X HW2.0 . Details about
> he firmware interface are currently unknown.
>
> Signed-off-by: Sven Eckelmann <sven.eckelmann at open-mesh.com>

I added the warning we talked about, diff below. Full patch in the
pending branch:

https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=ed730faad11df99f2aba3b8d78ac5587c3403e69

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index d34c32a075ac..3e8e7ed6faa1 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3005,6 +3005,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
 		pci_hard_reset = ath10k_pci_qca988x_chip_reset;
 		break;
 	case QCA9887_1_0_DEVICE_ID:
+		dev_warn(&pdev->dev, "QCA9887 support is still experimental, there are likely bugs. You have been warned.\n");
 		hw_rev = ATH10K_HW_QCA9887;
 		pci_ps = false;
 		pci_soft_reset = ath10k_pci_warm_reset;


-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Sat Jun  4 06:26:39 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Sat, 4 Jun 2016 13:26:39 +0000
Subject: [PATCH 2/2] ath10k: Add board data download from target
In-Reply-To: <1463755272-12912-2-git-send-email-sven.eckelmann@open-mesh.com>
 (Sven Eckelmann's message of "Fri, 20 May 2016 16:41:12 +0200")
References: <1568876.Six5hABE57@bentobox>
 <1463755272-12912-2-git-send-email-sven.eckelmann@open-mesh.com>
Message-ID: <87porxt78w.fsf@kamboji.qca.qualcomm.com>

Sven Eckelmann <sven.eckelmann at open-mesh.com> writes:

> The QCA9887 stores its calibration data (board.bin) inside the EEPROM of
> the target. This has to be downloaded manually to allow the device to
> initialize correctly.
>
> Signed-off-by: Sven Eckelmann <sven.eckelmann at open-mesh.com>

[...]

> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -18,6 +18,7 @@
>  #include <linux/module.h>
>  #include <linux/firmware.h>
>  #include <linux/of.h>
> +#include <asm/byteorder.h>
>  
>  #include "core.h"
>  #include "mac.h"
> @@ -550,6 +551,34 @@ out:
>  	return ret;
>  }
>  
> +static int ath10k_download_cal_eeprom(struct ath10k *ar)
> +{
> +	size_t data_len;
> +	void *data = NULL;
> +	int ret;
> +
> +	ret = ath10k_hif_fetch_target_board_data(ar, &data, &data_len);
> +	if (ret) {
> +		ath10k_warn(ar, "failed to read calibration data from EEPROM: %d\n",
> +			    ret);
> +		goto out_free;
> +	}

Looking at this again I noticed that we issue this warning even if
EEPROM is not supported, which I think is wrong. I fixed this in the
pending branch, the diff is below.

I also renamed target_board_data to cal_eeprom because, at least to my
understanding, the eeprom actually contains the real calibration data,
not the board data file.

Please review so that I didn't break anything.

https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=4f79bdf2db7bcfa9c7c093fd423af801b9797c63

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 10a1b620a68b..1e88251ca6d0 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -580,10 +580,11 @@ static int ath10k_download_cal_eeprom(struct ath10k *ar)
 	void *data = NULL;
 	int ret;
 
-	ret = ath10k_hif_fetch_target_board_data(ar, &data, &data_len);
+	ret = ath10k_hif_fetch_cal_eeprom(ar, &data, &data_len);
 	if (ret) {
-		ath10k_warn(ar, "failed to read calibration data from EEPROM: %d\n",
-			    ret);
+		if (ret != -EOPNOTSUPP)
+			ath10k_warn(ar, "failed to read calibration data from EEPROM: %d\n",
+				    ret);
 		goto out_free;
 	}
 
diff --git a/drivers/net/wireless/ath/ath10k/hif.h b/drivers/net/wireless/ath/ath10k/hif.h
index c18b8c81bde4..b2566b06e1e1 100644
--- a/drivers/net/wireless/ath/ath10k/hif.h
+++ b/drivers/net/wireless/ath/ath10k/hif.h
@@ -88,9 +88,9 @@ struct ath10k_hif_ops {
 	int (*suspend)(struct ath10k *ar);
 	int (*resume)(struct ath10k *ar);
 
-	/* fetch board data from target eeprom */
-	int (*fetch_target_board_data)(struct ath10k *ar, void **data,
-				       size_t *data_len);
+	/* fetch calibration data from target eeprom */
+	int (*fetch_cal_eeprom)(struct ath10k *ar, void **data,
+				size_t *data_len);
 };
 
 static inline int ath10k_hif_tx_sg(struct ath10k *ar, u8 pipe_id,
@@ -206,14 +206,14 @@ static inline void ath10k_hif_write32(struct ath10k *ar,
 	ar->hif.ops->write32(ar, address, data);
 }
 
-static inline int ath10k_hif_fetch_target_board_data(struct ath10k *ar,
-						     void **data,
-						     size_t *data_len)
+static inline int ath10k_hif_fetch_cal_eeprom(struct ath10k *ar,
+					      void **data,
+					      size_t *data_len)
 {
-	if (!ar->hif.ops->fetch_target_board_data)
+	if (!ar->hif.ops->fetch_cal_eeprom)
 		return -EOPNOTSUPP;
 
-	return ar->hif.ops->fetch_target_board_data(ar, data, data_len);
+	return ar->hif.ops->fetch_cal_eeprom(ar, data, data_len);
 }
 
 #endif /* _HIF_H_ */
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index fb53f8846efd..f06dd3941bac 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2678,8 +2678,8 @@ static int ath10k_pci_read_eeprom(struct ath10k *ar, u16 addr, u8 *out)
 	return 0;
 }
 
-static int ath10k_pci_fetch_target_board_data(struct ath10k *ar, void **data,
-					      size_t *data_len)
+static int ath10k_pci_hif_fetch_cal_eeprom(struct ath10k *ar, void **data,
+					   size_t *data_len)
 {
 	u8 *caldata = NULL;
 	size_t calsize, i;
@@ -2734,7 +2734,7 @@ static const struct ath10k_hif_ops ath10k_pci_hif_ops = {
 	.suspend		= ath10k_pci_hif_suspend,
 	.resume			= ath10k_pci_hif_resume,
 #endif
-	.fetch_target_board_data = ath10k_pci_fetch_target_board_data,
+	.fetch_cal_eeprom	= ath10k_pci_hif_fetch_cal_eeprom,
 };
 
 /*

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Sat Jun  4 07:53:54 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Sat, 4 Jun 2016 14:53:54 +0000
Subject: [PATCH 1/2] ath10k: Define an enum to enable cycle counter
 wraparound logic
References: <1464968596-19834-1-git-send-email-vthiagar@qti.qualcomm.com>
Message-ID: <8760tpt37i.fsf@kamboji.qca.qualcomm.com>

Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com> writes:

> QCA988X hw implements a different cycle counter wraparound
> behaviour when compared to QCA4019. To properly handle different
> wraparound logic for these chipsets replace already available
> bool hw_params member, has_shifted_cc_wraparound, with an
> enum which could be extended to handle different wraparound
> behaviour. This patch keeps the existing logic functionally
> same and a prepares cycle counter wraparound handling to
> extend for other chips.
>
> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com>

[...]

> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -55,7 +55,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
>  		.name = "qca988x hw2.0",
>  		.patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
>  		.uart_pin = 7,
> -		.has_shifted_cc_wraparound = true,
> +		.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
>  		.otp_exe_param = 0,
>  		.channel_counters_freq_hz = 88000,
>  		.max_probe_resp_desc_thres = 0,
> @@ -224,7 +224,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
>  		.name = "qca4019 hw1.0",
>  		.patch_load_addr = QCA4019_HW_1_0_PATCH_LOAD_ADDR,
>  		.uart_pin = 7,
> -		.has_shifted_cc_wraparound = true,
> +		.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
>  		.otp_exe_param = 0x0010000,
>  		.continuous_frag_desc = true,
>  		.channel_counters_freq_hz = 125000,

As the pending branch has the QCA9887 patch I added
ATH10K_HW_CC_WRAP_SHIFTED_ALL also for QCA9887. Please review my changes
in the pending branch:

https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=2fa32dbd9f26e8b2f323ca30ad116ea486840aba

-- 
Kalle Valo

From vthiagar at qti.qualcomm.com  Sat Jun  4 22:06:08 2016
From: vthiagar at qti.qualcomm.com (Thiagarajan, Vasanthakumar)
Date: Sun, 5 Jun 2016 05:06:08 +0000
Subject: [PATCH 1/2] ath10k: Define an enum to enable cycle counter
 wraparound logic
In-Reply-To: <8760tpt37i.fsf@kamboji.qca.qualcomm.com>
References: <1464968596-19834-1-git-send-email-vthiagar@qti.qualcomm.com>
 <8760tpt37i.fsf@kamboji.qca.qualcomm.com>
Message-ID: <5753B330.1070804@qti.qualcomm.com>

>> --- a/drivers/net/wireless/ath/ath10k/core.c
>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>> @@ -55,7 +55,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
>>   		.name = "qca988x hw2.0",
>>   		.patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
>>   		.uart_pin = 7,
>> -		.has_shifted_cc_wraparound = true,
>> +		.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
>>   		.otp_exe_param = 0,
>>   		.channel_counters_freq_hz = 88000,
>>   		.max_probe_resp_desc_thres = 0,
>> @@ -224,7 +224,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
>>   		.name = "qca4019 hw1.0",
>>   		.patch_load_addr = QCA4019_HW_1_0_PATCH_LOAD_ADDR,
>>   		.uart_pin = 7,
>> -		.has_shifted_cc_wraparound = true,
>> +		.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
>>   		.otp_exe_param = 0x0010000,
>>   		.continuous_frag_desc = true,
>>   		.channel_counters_freq_hz = 125000,
>
> As the pending branch has the QCA9887 patch I added
> ATH10K_HW_CC_WRAP_SHIFTED_ALL also for QCA9887. Please review my changes
> in the pending branch:
>
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=2fa32dbd9f26e8b2f323ca30ad116ea486840aba
>

Looks good, thanks.

Vasanth


From sven.eckelmann at open-mesh.com  Mon Jun  6 03:10:17 2016
From: sven.eckelmann at open-mesh.com (Sven Eckelmann)
Date: Mon, 06 Jun 2016 12:10:17 +0200
Subject: [PATCH 2/2] ath10k: Add board data download from target
In-Reply-To: <87porxt78w.fsf@kamboji.qca.qualcomm.com>
References: <1568876.Six5hABE57@bentobox>
 <1463755272-12912-2-git-send-email-sven.eckelmann@open-mesh.com>
 <87porxt78w.fsf@kamboji.qca.qualcomm.com>
Message-ID: <3343488.td5VS5T2AQ@bentobox>

On Saturday 04 June 2016 13:26:39 you wrote:
[...]
> Looking at this again I noticed that we issue this warning even if
> EEPROM is not supported, which I think is wrong. I fixed this in the
> pending branch, the diff is below.
> 
> I also renamed target_board_data to cal_eeprom because, at least to my
> understanding, the eeprom actually contains the real calibration data,
> not the board data file.
> 
> Please review so that I didn't break anything.

Thanks for the changes. Looks good to me.

Kind regards,
	Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160606/7b804904/attachment.sig>

From zach at netblazr.com  Mon Jun  6 10:12:46 2016
From: zach at netblazr.com (Zach Sherin)
Date: Mon, 6 Jun 2016 13:12:46 -0400
Subject: Any tips on where per-packet antenna selection could be pushed?
Message-ID: <CAOiRWuVxbGDoVtxahwRxyH9NaBB9LmaEBZ5bzgSPEf=Eu1g=ug@mail.gmail.com>

Hi all,

I'm working on a device with antenna selection, similar to the ideas
behind Ruckus or Google's Onhub router. I've been looking into a
solution for per-packet antenna selection (based on destination/next
hop). I was hoping this list might be able to suggest where I should
investigate adding that switching code. My switches are currently USB
RF switches, but I'm going to be using some serial protocol for the
final version (we don't have much to switch, and it should be a single
byte per packet).

The last suggestion I received was to emulate Netsed [1] by routing
all packets through a specific socket, running antenna selection, and
then pushing them to their final destinations.

I assumed that the best place to do antenna selection would be within
ath10k itself (my devices all run on ath10k) so that I could introduce
the minimum possible latency with antenna selection. Should I be
looking at a different part of the networking stack?

Does anyone have any suggestions, or perhaps an open-source project
out there already trying to do antenna selection?

Thanks,
Zach


[1] http://silicone.homelinux.org/projects/netsed/


From kvalo at qca.qualcomm.com  Mon Jun  6 10:24:43 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Mon, 6 Jun 2016 19:24:43 +0200
Subject: [v2,5/5] ath10k: Fix deadlock when peer cannot be created.
In-Reply-To: <1459545132-11295-5-git-send-email-greearb@candelatech.com>
Message-ID: <f7160429961449fc8729576118118606@euamsexm01a.eu.qualcomm.com>

Ben Greear <greearb at candelatech.com> wrote:
> From: Ben Greear <greearb at candelatech.com>
> 
> We must not attempt to send WMI packets while holding the data-lock,
> as it may deadlock:
> 
> BUG: sleeping function called from invalid context at drivers/net/wireless/ath/ath10k/wmi.c:1824
> in_atomic(): 1, irqs_disabled(): 0, pid: 2878, name: wpa_supplicant
> 
> =============================================
> [ INFO: possible recursive locking detected ]
> 4.4.6+ #21 Tainted: G        W  O
> ---------------------------------------------
> wpa_supplicant/2878 is trying to acquire lock:
>  (&(&ar->data_lock)->rlock){+.-...}, at: [<ffffffffa0721511>] ath10k_wmi_tx_beacons_iter+0x26/0x11a [ath10k_core]
> 
> but task is already holding lock:
>  (&(&ar->data_lock)->rlock){+.-...}, at: [<ffffffffa070251b>] ath10k_peer_create+0x122/0x1ae [ath10k_core]
> 
> other info that might help us debug this:
>  Possible unsafe locking scenario:
> 
>        CPU0
>        ----
>   lock(&(&ar->data_lock)->rlock);
>   lock(&(&ar->data_lock)->rlock);
> 
>  *** DEADLOCK ***
> 
>  May be due to missing lock nesting notation
> 
> 4 locks held by wpa_supplicant/2878:
>  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff816493ca>] rtnl_lock+0x12/0x14
>  #1:  (&ar->conf_mutex){+.+.+.}, at: [<ffffffffa0706932>] ath10k_add_interface+0x3b/0xbda [ath10k_core]
>  #2:  (&(&ar->data_lock)->rlock){+.-...}, at: [<ffffffffa070251b>] ath10k_peer_create+0x122/0x1ae [ath10k_core]
>  #3:  (rcu_read_lock){......}, at: [<ffffffffa062f304>] rcu_read_lock+0x0/0x66 [mac80211]
> 
> stack backtrace:
> CPU: 3 PID: 2878 Comm: wpa_supplicant Tainted: G        W  O    4.4.6+ #21
> Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.5 06/07/2013
>  0000000000000000 ffff8801fcadf8f0 ffffffff8137086d ffffffff82681720
>  ffffffff82681720 ffff8801fcadf9b0 ffffffff8112e3be ffff8801fcadf920
>  0000000100000000 ffffffff82681720 ffffffffa0721500 ffff8801fcb8d348
> Call Trace:
>  [<ffffffff8137086d>] dump_stack+0x81/0xb6
>  [<ffffffff8112e3be>] __lock_acquire+0xc5b/0xde7
>  [<ffffffffa0721500>] ? ath10k_wmi_tx_beacons_iter+0x15/0x11a [ath10k_core]
>  [<ffffffff8112d0d0>] ? mark_lock+0x24/0x201
>  [<ffffffff8112e908>] lock_acquire+0x132/0x1cb
>  [<ffffffff8112e908>] ? lock_acquire+0x132/0x1cb
>  [<ffffffffa0721511>] ? ath10k_wmi_tx_beacons_iter+0x26/0x11a [ath10k_core]
>  [<ffffffffa07214eb>] ? ath10k_wmi_cmd_send_nowait+0x1ce/0x1ce [ath10k_core]
>  [<ffffffff816f9e2b>] _raw_spin_lock_bh+0x31/0x40
>  [<ffffffffa0721511>] ? ath10k_wmi_tx_beacons_iter+0x26/0x11a [ath10k_core]
>  [<ffffffffa0721511>] ath10k_wmi_tx_beacons_iter+0x26/0x11a [ath10k_core]
>  [<ffffffffa07214eb>] ? ath10k_wmi_cmd_send_nowait+0x1ce/0x1ce [ath10k_core]
>  [<ffffffffa062eb18>] __iterate_interfaces+0x9d/0x13d [mac80211]
>  [<ffffffffa062f609>] ieee80211_iterate_active_interfaces_atomic+0x32/0x3e [mac80211]
>  [<ffffffffa07214eb>] ? ath10k_wmi_cmd_send_nowait+0x1ce/0x1ce [ath10k_core]
>  [<ffffffffa071fa9f>] ath10k_wmi_tx_beacons_nowait.isra.13+0x14/0x16 [ath10k_core]
>  [<ffffffffa0721676>] ath10k_wmi_cmd_send+0x71/0x242 [ath10k_core]
>  [<ffffffffa07023f6>] ath10k_wmi_peer_delete+0x3f/0x42 [ath10k_core]
>  [<ffffffffa0702557>] ath10k_peer_create+0x15e/0x1ae [ath10k_core]
>  [<ffffffffa0707004>] ath10k_add_interface+0x70d/0xbda [ath10k_core]
>  [<ffffffffa05fffcc>] drv_add_interface+0x123/0x1a5 [mac80211]
>  [<ffffffffa061554b>] ieee80211_do_open+0x351/0x667 [mac80211]
>  [<ffffffffa06158aa>] ieee80211_open+0x49/0x4c [mac80211]
>  [<ffffffff8163ecf9>] __dev_open+0x88/0xde
>  [<ffffffff8163ef6e>] __dev_change_flags+0xa4/0x13a
>  [<ffffffff8163f023>] dev_change_flags+0x1f/0x54
>  [<ffffffff816a5532>] devinet_ioctl+0x2b9/0x5c9
>  [<ffffffff816514dd>] ? copy_to_user+0x32/0x38
>  [<ffffffff816a6115>] inet_ioctl+0x81/0x9d
>  [<ffffffff816a6115>] ? inet_ioctl+0x81/0x9d
>  [<ffffffff81621cf8>] sock_do_ioctl+0x20/0x3d
>  [<ffffffff816223c4>] sock_ioctl+0x222/0x22e
>  [<ffffffff8121cf95>] do_vfs_ioctl+0x453/0x4d7
>  [<ffffffff81625603>] ? __sys_recvmsg+0x4c/0x5b
>  [<ffffffff81225af1>] ? __fget_light+0x48/0x6c
>  [<ffffffff8121d06b>] SyS_ioctl+0x52/0x74
>  [<ffffffff816fa736>] entry_SYSCALL_64_fastpath+0x16/0x7a
> 
> Signed-off-by: Ben Greear <greearb at candelatech.com>

Thanks, 1 patch applied to ath-current branch of ath.git:

fee48cf83745 ath10k: fix deadlock when peer cannot be created

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/8727841/



From zach at netblazr.com  Mon Jun  6 10:24:55 2016
From: zach at netblazr.com (Zach Sherin)
Date: Mon, 6 Jun 2016 13:24:55 -0400
Subject: Any tips on where per-packet antenna selection could be pushed?
In-Reply-To: <5755B0FF.9010900@candelatech.com>
References: <CAOiRWuVxbGDoVtxahwRxyH9NaBB9LmaEBZ5bzgSPEf=Eu1g=ug@mail.gmail.com>
 <5755B0FF.9010900@candelatech.com>
Message-ID: <CAOiRWuUFvZU1b4Pn8nDVs5O5sNK-g0PPbckriP=RmBnB5f-5Gw@mail.gmail.com>

I'm not sure I know exactly what you mean by per-peer. Do you mean
that the antenna switches only when we're delivering to a new
next-hop? I would absolutely be fine with that, by per-packet I do
actually mean selection based on destination/next hop so aggregating
deliveries for a single peer would be even better.

Also, I forgot to mention that this is intended for static mesh
networks, so I'm not worried about moment-to-moment changes in peer
location.

Thanks,
Zach

On Mon, Jun 6, 2016 at 1:21 PM, Ben Greear <greearb at candelatech.com> wrote:
> On 06/06/2016 10:12 AM, Zach Sherin wrote:
>>
>> Hi all,
>>
>> I'm working on a device with antenna selection, similar to the ideas
>> behind Ruckus or Google's Onhub router. I've been looking into a
>> solution for per-packet antenna selection (based on destination/next
>> hop). I was hoping this list might be able to suggest where I should
>> investigate adding that switching code. My switches are currently USB
>> RF switches, but I'm going to be using some serial protocol for the
>> final version (we don't have much to switch, and it should be a single
>> byte per packet).
>>
>> The last suggestion I received was to emulate Netsed [1] by routing
>> all packets through a specific socket, running antenna selection, and
>> then pushing them to their final destinations.
>>
>> I assumed that the best place to do antenna selection would be within
>> ath10k itself (my devices all run on ath10k) so that I could introduce
>> the minimum possible latency with antenna selection. Should I be
>> looking at a different part of the networking stack?
>>
>> Does anyone have any suggestions, or perhaps an open-source project
>> out there already trying to do antenna selection?
>
>
> Would per-peer antenna selection work?  That is probably more easily
> hacked into the firmware (I don't think stock firmware supports this
> feature, but I could be wrong.)
>
> Thanks,
> Ben
>
>>
>> Thanks,
>> Zach
>>
>>
>> [1] http://silicone.homelinux.org/projects/netsed/
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>


From greearb at candelatech.com  Mon Jun  6 10:21:03 2016
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 6 Jun 2016 10:21:03 -0700
Subject: Any tips on where per-packet antenna selection could be pushed?
In-Reply-To: <CAOiRWuVxbGDoVtxahwRxyH9NaBB9LmaEBZ5bzgSPEf=Eu1g=ug@mail.gmail.com>
References: <CAOiRWuVxbGDoVtxahwRxyH9NaBB9LmaEBZ5bzgSPEf=Eu1g=ug@mail.gmail.com>
Message-ID: <5755B0FF.9010900@candelatech.com>

On 06/06/2016 10:12 AM, Zach Sherin wrote:
> Hi all,
>
> I'm working on a device with antenna selection, similar to the ideas
> behind Ruckus or Google's Onhub router. I've been looking into a
> solution for per-packet antenna selection (based on destination/next
> hop). I was hoping this list might be able to suggest where I should
> investigate adding that switching code. My switches are currently USB
> RF switches, but I'm going to be using some serial protocol for the
> final version (we don't have much to switch, and it should be a single
> byte per packet).
>
> The last suggestion I received was to emulate Netsed [1] by routing
> all packets through a specific socket, running antenna selection, and
> then pushing them to their final destinations.
>
> I assumed that the best place to do antenna selection would be within
> ath10k itself (my devices all run on ath10k) so that I could introduce
> the minimum possible latency with antenna selection. Should I be
> looking at a different part of the networking stack?
>
> Does anyone have any suggestions, or perhaps an open-source project
> out there already trying to do antenna selection?

Would per-peer antenna selection work?  That is probably more easily
hacked into the firmware (I don't think stock firmware supports this
feature, but I could be wrong.)

Thanks,
Ben

>
> Thanks,
> Zach
>
>
> [1] http://silicone.homelinux.org/projects/netsed/
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>


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



From greearb at candelatech.com  Mon Jun  6 10:28:57 2016
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 6 Jun 2016 10:28:57 -0700
Subject: Any tips on where per-packet antenna selection could be pushed?
In-Reply-To: <CAOiRWuUFvZU1b4Pn8nDVs5O5sNK-g0PPbckriP=RmBnB5f-5Gw@mail.gmail.com>
References: <CAOiRWuVxbGDoVtxahwRxyH9NaBB9LmaEBZ5bzgSPEf=Eu1g=ug@mail.gmail.com>
 <5755B0FF.9010900@candelatech.com>
 <CAOiRWuUFvZU1b4Pn8nDVs5O5sNK-g0PPbckriP=RmBnB5f-5Gw@mail.gmail.com>
Message-ID: <5755B2D9.7080207@candelatech.com>

On 06/06/2016 10:24 AM, Zach Sherin wrote:
> I'm not sure I know exactly what you mean by per-peer. Do you mean
> that the antenna switches only when we're delivering to a new
> next-hop? I would absolutely be fine with that, by per-packet I do
> actually mean selection based on destination/next hop so aggregating
> deliveries for a single peer would be even better.
>
> Also, I forgot to mention that this is intended for static mesh
> networks, so I'm not worried about moment-to-moment changes in peer
> location.

Maybe some of the official QCA devs will have some ideas on how to do
this with stock firmware.

I am guessing you would have to have some API in the firmware that
could twiddle your antenna right before attempting to transmit a
frame?

Do you have physical output pins on your ath10k NIC to even do this?

Thanks,
Ben


>
> Thanks,
> Zach
>
> On Mon, Jun 6, 2016 at 1:21 PM, Ben Greear <greearb at candelatech.com> wrote:
>> On 06/06/2016 10:12 AM, Zach Sherin wrote:
>>>
>>> Hi all,
>>>
>>> I'm working on a device with antenna selection, similar to the ideas
>>> behind Ruckus or Google's Onhub router. I've been looking into a
>>> solution for per-packet antenna selection (based on destination/next
>>> hop). I was hoping this list might be able to suggest where I should
>>> investigate adding that switching code. My switches are currently USB
>>> RF switches, but I'm going to be using some serial protocol for the
>>> final version (we don't have much to switch, and it should be a single
>>> byte per packet).
>>>
>>> The last suggestion I received was to emulate Netsed [1] by routing
>>> all packets through a specific socket, running antenna selection, and
>>> then pushing them to their final destinations.
>>>
>>> I assumed that the best place to do antenna selection would be within
>>> ath10k itself (my devices all run on ath10k) so that I could introduce
>>> the minimum possible latency with antenna selection. Should I be
>>> looking at a different part of the networking stack?
>>>
>>> Does anyone have any suggestions, or perhaps an open-source project
>>> out there already trying to do antenna selection?
>>
>>
>> Would per-peer antenna selection work?  That is probably more easily
>> hacked into the firmware (I don't think stock firmware supports this
>> feature, but I could be wrong.)
>>
>> Thanks,
>> Ben
>>
>>>
>>> Thanks,
>>> Zach
>>>
>>>
>>> [1] http://silicone.homelinux.org/projects/netsed/
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>
>>
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>


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



From zach at netblazr.com  Mon Jun  6 10:59:09 2016
From: zach at netblazr.com (Zach Sherin)
Date: Mon, 6 Jun 2016 13:59:09 -0400
Subject: Any tips on where per-packet antenna selection could be pushed?
In-Reply-To: <5755B2D9.7080207@candelatech.com>
References: <CAOiRWuVxbGDoVtxahwRxyH9NaBB9LmaEBZ5bzgSPEf=Eu1g=ug@mail.gmail.com>
 <5755B0FF.9010900@candelatech.com>
 <CAOiRWuUFvZU1b4Pn8nDVs5O5sNK-g0PPbckriP=RmBnB5f-5Gw@mail.gmail.com>
 <5755B2D9.7080207@candelatech.com>
Message-ID: <CAOiRWuUjugeDtRTQUWBzoCq58L8XfW7aYQTHa=Mnf4smx6AR2g@mail.gmail.com>

I was aiming to run this off a serial interface on the general board,
not on the ath10k NIC. I have a consumer QCA9880 PCI board in an
Archer C7 router. It would be awesome if I could steal a GPIO or
something from the atheros chip to output, but I was assuming I
couldn't. The main reason I was looking at the ath10k driver was to
get as close to when the packets are transmitted as possible, to leave
as little room for error in the switching as possible.

However, it's  possible that I'm hoping for too much there. I'd be
interested to hear your thoughts on it. If I can't pull it off, I'll
move to an approach outside ath10k.

Thanks,
Zach
On Mon, Jun 6, 2016 at 1:28 PM, Ben Greear <greearb at candelatech.com> wrote:
> On 06/06/2016 10:24 AM, Zach Sherin wrote:
>>
>> I'm not sure I know exactly what you mean by per-peer. Do you mean
>> that the antenna switches only when we're delivering to a new
>> next-hop? I would absolutely be fine with that, by per-packet I do
>> actually mean selection based on destination/next hop so aggregating
>> deliveries for a single peer would be even better.
>>
>> Also, I forgot to mention that this is intended for static mesh
>> networks, so I'm not worried about moment-to-moment changes in peer
>> location.
>
>
> Maybe some of the official QCA devs will have some ideas on how to do
> this with stock firmware.
>
> I am guessing you would have to have some API in the firmware that
> could twiddle your antenna right before attempting to transmit a
> frame?
>
> Do you have physical output pins on your ath10k NIC to even do this?
>
> Thanks,
> Ben
>
>
>
>>
>> Thanks,
>> Zach
>>
>> On Mon, Jun 6, 2016 at 1:21 PM, Ben Greear <greearb at candelatech.com>
>> wrote:
>>>
>>> On 06/06/2016 10:12 AM, Zach Sherin wrote:
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> I'm working on a device with antenna selection, similar to the ideas
>>>> behind Ruckus or Google's Onhub router. I've been looking into a
>>>> solution for per-packet antenna selection (based on destination/next
>>>> hop). I was hoping this list might be able to suggest where I should
>>>> investigate adding that switching code. My switches are currently USB
>>>> RF switches, but I'm going to be using some serial protocol for the
>>>> final version (we don't have much to switch, and it should be a single
>>>> byte per packet).
>>>>
>>>> The last suggestion I received was to emulate Netsed [1] by routing
>>>> all packets through a specific socket, running antenna selection, and
>>>> then pushing them to their final destinations.
>>>>
>>>> I assumed that the best place to do antenna selection would be within
>>>> ath10k itself (my devices all run on ath10k) so that I could introduce
>>>> the minimum possible latency with antenna selection. Should I be
>>>> looking at a different part of the networking stack?
>>>>
>>>> Does anyone have any suggestions, or perhaps an open-source project
>>>> out there already trying to do antenna selection?
>>>
>>>
>>>
>>> Would per-peer antenna selection work?  That is probably more easily
>>> hacked into the firmware (I don't think stock firmware supports this
>>> feature, but I could be wrong.)
>>>
>>> Thanks,
>>> Ben
>>>
>>>>
>>>> Thanks,
>>>> Zach
>>>>
>>>>
>>>> [1] http://silicone.homelinux.org/projects/netsed/
>>>>
>>>> _______________________________________________
>>>> ath10k mailing list
>>>> ath10k at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>
>>>
>>>
>>> --
>>> Ben Greear <greearb at candelatech.com>
>>> Candela Technologies Inc  http://www.candelatech.com
>>>
>>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>


From greearb at candelatech.com  Mon Jun  6 11:02:34 2016
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 6 Jun 2016 11:02:34 -0700
Subject: Any tips on where per-packet antenna selection could be pushed?
In-Reply-To: <CAOiRWuUjugeDtRTQUWBzoCq58L8XfW7aYQTHa=Mnf4smx6AR2g@mail.gmail.com>
References: <CAOiRWuVxbGDoVtxahwRxyH9NaBB9LmaEBZ5bzgSPEf=Eu1g=ug@mail.gmail.com>
 <5755B0FF.9010900@candelatech.com>
 <CAOiRWuUFvZU1b4Pn8nDVs5O5sNK-g0PPbckriP=RmBnB5f-5Gw@mail.gmail.com>
 <5755B2D9.7080207@candelatech.com>
 <CAOiRWuUjugeDtRTQUWBzoCq58L8XfW7aYQTHa=Mnf4smx6AR2g@mail.gmail.com>
Message-ID: <5755BABA.1030006@candelatech.com>

On 06/06/2016 10:59 AM, Zach Sherin wrote:
> I was aiming to run this off a serial interface on the general board,
> not on the ath10k NIC. I have a consumer QCA9880 PCI board in an
> Archer C7 router. It would be awesome if I could steal a GPIO or
> something from the atheros chip to output, but I was assuming I
> couldn't. The main reason I was looking at the ath10k driver was to
> get as close to when the packets are transmitted as possible, to leave
> as little room for error in the switching as possible.
>
> However, it's  possible that I'm hoping for too much there. I'd be
> interested to hear your thoughts on it. If I can't pull it off, I'll
> move to an approach outside ath10k.

The driver just sends pkts to the firmware, it is the firmware that
knows when a pkt is to be transmitted, so I think you would have to have some
hooks low in the firmware tx logic to do what you want.  And you would need some
hardware output from the NIC.

I am guessing it would require quite a bit of changes to the firmware,
possibly very tricky/hacky ones, and hardware output on your NIC.

Thanks,
Ben

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



From zach at netblazr.com  Mon Jun  6 11:48:55 2016
From: zach at netblazr.com (Zach Sherin)
Date: Mon, 6 Jun 2016 14:48:55 -0400
Subject: Any tips on where per-packet antenna selection could be pushed?
In-Reply-To: <CAJ-VmomKzRAkJNQr2Sg=j57uPfptPiRs1Q026dPeuQv0jMx-Og@mail.gmail.com>
References: <CAOiRWuVxbGDoVtxahwRxyH9NaBB9LmaEBZ5bzgSPEf=Eu1g=ug@mail.gmail.com>
 <5755B0FF.9010900@candelatech.com>
 <CAOiRWuUFvZU1b4Pn8nDVs5O5sNK-g0PPbckriP=RmBnB5f-5Gw@mail.gmail.com>
 <5755B2D9.7080207@candelatech.com>
 <CAOiRWuUjugeDtRTQUWBzoCq58L8XfW7aYQTHa=Mnf4smx6AR2g@mail.gmail.com>
 <5755BABA.1030006@candelatech.com>
 <CAJ-VmomKzRAkJNQr2Sg=j57uPfptPiRs1Q026dPeuQv0jMx-Og@mail.gmail.com>
Message-ID: <CAOiRWuUL9RC61pdieiEh3ZtWFGLomHzPxqbbVE3Oe_3043Zv2g@mail.gmail.com>

Interesting. Could I ask if there's somewhere I should start digging?
If it's not obvious I'm a driver/kernel newbie, but I'm happy to
learn. Should I start by going through ath10k's documentation/code
until I find the relevant bits?

Thanks,
Zach


On Mon, Jun 6, 2016 at 2:42 PM, Adrian Chadd <adrian.chadd at gmail.com> wrote:
> I bet the ruckus mode shift stuff is in the ath10k hardware and is
> configurable per TX descriptor.
>
> a
>
> On Jun 6, 2016 11:03 AM, "Ben Greear" <greearb at candelatech.com> wrote:
>>
>> On 06/06/2016 10:59 AM, Zach Sherin wrote:
>>>
>>> I was aiming to run this off a serial interface on the general board,
>>> not on the ath10k NIC. I have a consumer QCA9880 PCI board in an
>>> Archer C7 router. It would be awesome if I could steal a GPIO or
>>> something from the atheros chip to output, but I was assuming I
>>> couldn't. The main reason I was looking at the ath10k driver was to
>>> get as close to when the packets are transmitted as possible, to leave
>>> as little room for error in the switching as possible.
>>>
>>> However, it's  possible that I'm hoping for too much there. I'd be
>>> interested to hear your thoughts on it. If I can't pull it off, I'll
>>> move to an approach outside ath10k.
>>
>>
>> The driver just sends pkts to the firmware, it is the firmware that
>> knows when a pkt is to be transmitted, so I think you would have to have
>> some
>> hooks low in the firmware tx logic to do what you want.  And you would
>> need some
>> hardware output from the NIC.
>>
>> I am guessing it would require quite a bit of changes to the firmware,
>> possibly very tricky/hacky ones, and hardware output on your NIC.
>>
>> Thanks,
>> Ben
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k


From greearb at candelatech.com  Mon Jun  6 11:57:51 2016
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 6 Jun 2016 11:57:51 -0700
Subject: Any tips on where per-packet antenna selection could be pushed?
In-Reply-To: <CAOiRWuUL9RC61pdieiEh3ZtWFGLomHzPxqbbVE3Oe_3043Zv2g@mail.gmail.com>
References: <CAOiRWuVxbGDoVtxahwRxyH9NaBB9LmaEBZ5bzgSPEf=Eu1g=ug@mail.gmail.com>
 <5755B0FF.9010900@candelatech.com>
 <CAOiRWuUFvZU1b4Pn8nDVs5O5sNK-g0PPbckriP=RmBnB5f-5Gw@mail.gmail.com>
 <5755B2D9.7080207@candelatech.com>
 <CAOiRWuUjugeDtRTQUWBzoCq58L8XfW7aYQTHa=Mnf4smx6AR2g@mail.gmail.com>
 <5755BABA.1030006@candelatech.com>
 <CAJ-VmomKzRAkJNQr2Sg=j57uPfptPiRs1Q026dPeuQv0jMx-Og@mail.gmail.com>
 <CAOiRWuUL9RC61pdieiEh3ZtWFGLomHzPxqbbVE3Oe_3043Zv2g@mail.gmail.com>
Message-ID: <5755C7AF.6020203@candelatech.com>

On 06/06/2016 11:48 AM, Zach Sherin wrote:
> Interesting. Could I ask if there's somewhere I should start digging?
> If it's not obvious I'm a driver/kernel newbie, but I'm happy to
> learn. Should I start by going through ath10k's documentation/code
> until I find the relevant bits?

Unfortunately, without firmware source, you have probably no chance
to do this.  And, you also probably have about no chance of getting
firmware source.

Thanks,
Ben

>
> Thanks,
> Zach
>
>
> On Mon, Jun 6, 2016 at 2:42 PM, Adrian Chadd <adrian.chadd at gmail.com> wrote:
>> I bet the ruckus mode shift stuff is in the ath10k hardware and is
>> configurable per TX descriptor.
>>
>> a
>>
>> On Jun 6, 2016 11:03 AM, "Ben Greear" <greearb at candelatech.com> wrote:
>>>
>>> On 06/06/2016 10:59 AM, Zach Sherin wrote:
>>>>
>>>> I was aiming to run this off a serial interface on the general board,
>>>> not on the ath10k NIC. I have a consumer QCA9880 PCI board in an
>>>> Archer C7 router. It would be awesome if I could steal a GPIO or
>>>> something from the atheros chip to output, but I was assuming I
>>>> couldn't. The main reason I was looking at the ath10k driver was to
>>>> get as close to when the packets are transmitted as possible, to leave
>>>> as little room for error in the switching as possible.
>>>>
>>>> However, it's  possible that I'm hoping for too much there. I'd be
>>>> interested to hear your thoughts on it. If I can't pull it off, I'll
>>>> move to an approach outside ath10k.
>>>
>>>
>>> The driver just sends pkts to the firmware, it is the firmware that
>>> knows when a pkt is to be transmitted, so I think you would have to have
>>> some
>>> hooks low in the firmware tx logic to do what you want.  And you would
>>> need some
>>> hardware output from the NIC.
>>>
>>> I am guessing it would require quite a bit of changes to the firmware,
>>> possibly very tricky/hacky ones, and hardware output on your NIC.
>>>
>>> Thanks,
>>> Ben
>>>
>>> --
>>> Ben Greear <greearb at candelatech.com>
>>> Candela Technologies Inc  http://www.candelatech.com
>>>
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>


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



From zach at netblazr.com  Mon Jun  6 12:22:01 2016
From: zach at netblazr.com (Zach Sherin)
Date: Mon, 6 Jun 2016 15:22:01 -0400
Subject: Any tips on where per-packet antenna selection could be pushed?
In-Reply-To: <5755C7AF.6020203@candelatech.com>
References: <CAOiRWuVxbGDoVtxahwRxyH9NaBB9LmaEBZ5bzgSPEf=Eu1g=ug@mail.gmail.com>
 <5755B0FF.9010900@candelatech.com>
 <CAOiRWuUFvZU1b4Pn8nDVs5O5sNK-g0PPbckriP=RmBnB5f-5Gw@mail.gmail.com>
 <5755B2D9.7080207@candelatech.com>
 <CAOiRWuUjugeDtRTQUWBzoCq58L8XfW7aYQTHa=Mnf4smx6AR2g@mail.gmail.com>
 <5755BABA.1030006@candelatech.com>
 <CAJ-VmomKzRAkJNQr2Sg=j57uPfptPiRs1Q026dPeuQv0jMx-Og@mail.gmail.com>
 <CAOiRWuUL9RC61pdieiEh3ZtWFGLomHzPxqbbVE3Oe_3043Zv2g@mail.gmail.com>
 <5755C7AF.6020203@candelatech.com>
Message-ID: <CAOiRWuX4mwQEmY0pNvAvufHrfte_94JzyMw41i1SDMNHj=KtCQ@mail.gmail.com>

That's what I thought. Thanks for confirming, and thanks again for
your time and help!

Have a good one,
Zach

On Mon, Jun 6, 2016 at 2:57 PM, Ben Greear <greearb at candelatech.com> wrote:
> On 06/06/2016 11:48 AM, Zach Sherin wrote:
>>
>> Interesting. Could I ask if there's somewhere I should start digging?
>> If it's not obvious I'm a driver/kernel newbie, but I'm happy to
>> learn. Should I start by going through ath10k's documentation/code
>> until I find the relevant bits?
>
>
> Unfortunately, without firmware source, you have probably no chance
> to do this.  And, you also probably have about no chance of getting
> firmware source.
>
> Thanks,
> Ben
>
>
>>
>> Thanks,
>> Zach
>>
>>
>> On Mon, Jun 6, 2016 at 2:42 PM, Adrian Chadd <adrian.chadd at gmail.com>
>> wrote:
>>>
>>> I bet the ruckus mode shift stuff is in the ath10k hardware and is
>>> configurable per TX descriptor.
>>>
>>> a
>>>
>>> On Jun 6, 2016 11:03 AM, "Ben Greear" <greearb at candelatech.com> wrote:
>>>>
>>>>
>>>> On 06/06/2016 10:59 AM, Zach Sherin wrote:
>>>>>
>>>>>
>>>>> I was aiming to run this off a serial interface on the general board,
>>>>> not on the ath10k NIC. I have a consumer QCA9880 PCI board in an
>>>>> Archer C7 router. It would be awesome if I could steal a GPIO or
>>>>> something from the atheros chip to output, but I was assuming I
>>>>> couldn't. The main reason I was looking at the ath10k driver was to
>>>>> get as close to when the packets are transmitted as possible, to leave
>>>>> as little room for error in the switching as possible.
>>>>>
>>>>> However, it's  possible that I'm hoping for too much there. I'd be
>>>>> interested to hear your thoughts on it. If I can't pull it off, I'll
>>>>> move to an approach outside ath10k.
>>>>
>>>>
>>>>
>>>> The driver just sends pkts to the firmware, it is the firmware that
>>>> knows when a pkt is to be transmitted, so I think you would have to have
>>>> some
>>>> hooks low in the firmware tx logic to do what you want.  And you would
>>>> need some
>>>> hardware output from the NIC.
>>>>
>>>> I am guessing it would require quite a bit of changes to the firmware,
>>>> possibly very tricky/hacky ones, and hardware output on your NIC.
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>> --
>>>> Ben Greear <greearb at candelatech.com>
>>>> Candela Technologies Inc  http://www.candelatech.com
>>>>
>>>>
>>>> _______________________________________________
>>>> ath10k mailing list
>>>> ath10k at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>


From greearb at candelatech.com  Mon Jun  6 14:25:52 2016
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 6 Jun 2016 14:25:52 -0700
Subject: Question on "ath10k: document ofdm/5ghz rate offset with a macro"
Message-ID: <5755EA60.7070504@candelatech.com>

While porting some patches forward, I notice the change below
that renamed the method to "ath10k_mac_sta_has_ofdm_only".  But,
that is not really what that is checking, since it just throws
away the CCK rates (and they might have been there).

Maybe it should just be "ath10k_mac_sta_has_ofdm()" ?

Thanks,
Ben



  ath10k: document ofdm/5ghz rate offset with a macro

     Don't use literal values for offsets. While at it
     rename a function so it is more clear what it
     checks for.

     This finally takes care of the last magic
     5GHz/OFDM offset.

     Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
     Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>

-------------------- drivers/net/wireless/ath/ath10k/mac.c --------------------
index e62b587..ec26d96 100644
@@ -61,8 +61,11 @@ static struct ieee80211_rate ath10k_rates[] = {
  	{ .bitrate = 540, .hw_value = ATH10K_HW_RATE_OFDM_54M },
  };

-#define ath10k_a_rates (ath10k_rates + 4)
-#define ath10k_a_rates_size (ARRAY_SIZE(ath10k_rates) - 4)
+#define ATH10K_MAC_FIRST_OFDM_RATE_IDX 4
+
+#define ath10k_a_rates (ath10k_rates + ATH10K_MAC_FIRST_OFDM_RATE_IDX)
+#define ath10k_a_rates_size (ARRAY_SIZE(ath10k_rates) - \
+			     ATH10K_MAC_FIRST_OFDM_RATE_IDX)
  #define ath10k_g_rates (ath10k_rates + 0)
  #define ath10k_g_rates_size (ARRAY_SIZE(ath10k_rates))

@@ -2038,10 +2041,10 @@ static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
  		   sta->addr, !!(arg->peer_flags & WMI_PEER_QOS));
  }

-static bool ath10k_mac_sta_has_11g_rates(struct ieee80211_sta *sta)
+static bool ath10k_mac_sta_has_ofdm_only(struct ieee80211_sta *sta)
  {
-	/* First 4 rates in ath10k_rates are CCK (11b) rates. */
-	return sta->supp_rates[IEEE80211_BAND_2GHZ] >> 4;
+	return sta->supp_rates[IEEE80211_BAND_2GHZ] >>
+	       ATH10K_MAC_FIRST_OFDM_RATE_IDX;
  }


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



From michal.kazior at tieto.com  Mon Jun  6 23:23:37 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 7 Jun 2016 08:23:37 +0200
Subject: Question on "ath10k: document ofdm/5ghz rate offset with a macro"
In-Reply-To: <5755EA60.7070504@candelatech.com>
References: <5755EA60.7070504@candelatech.com>
Message-ID: <CA+BoTQ=sGYcoHcBcPKqzqqFekbV9g23ZZ556N9+9kmtZKV=kEg@mail.gmail.com>

On 6 June 2016 at 23:25, Ben Greear <greearb at candelatech.com> wrote:
> While porting some patches forward, I notice the change below
> that renamed the method to "ath10k_mac_sta_has_ofdm_only".  But,
> that is not really what that is checking, since it just throws
> away the CCK rates (and they might have been there).
>
> Maybe it should just be "ath10k_mac_sta_has_ofdm()" ?

Yes, this seems like an unfortunate name pick on my side. The MODE_11G
phymode is for mixed b/g.


Micha?


From janusz.dziedzic at tieto.com  Mon Jun  6 23:24:17 2016
From: janusz.dziedzic at tieto.com (Janusz Dziedzic)
Date: Tue, 7 Jun 2016 08:24:17 +0200
Subject: Any tips on where per-packet antenna selection could be pushed?
In-Reply-To: <CAOiRWuX4mwQEmY0pNvAvufHrfte_94JzyMw41i1SDMNHj=KtCQ@mail.gmail.com>
References: <CAOiRWuVxbGDoVtxahwRxyH9NaBB9LmaEBZ5bzgSPEf=Eu1g=ug@mail.gmail.com>
 <5755B0FF.9010900@candelatech.com>
 <CAOiRWuUFvZU1b4Pn8nDVs5O5sNK-g0PPbckriP=RmBnB5f-5Gw@mail.gmail.com>
 <5755B2D9.7080207@candelatech.com>
 <CAOiRWuUjugeDtRTQUWBzoCq58L8XfW7aYQTHa=Mnf4smx6AR2g@mail.gmail.com>
 <5755BABA.1030006@candelatech.com>
 <CAJ-VmomKzRAkJNQr2Sg=j57uPfptPiRs1Q026dPeuQv0jMx-Og@mail.gmail.com>
 <CAOiRWuUL9RC61pdieiEh3ZtWFGLomHzPxqbbVE3Oe_3043Zv2g@mail.gmail.com>
 <5755C7AF.6020203@candelatech.com>
 <CAOiRWuX4mwQEmY0pNvAvufHrfte_94JzyMw41i1SDMNHj=KtCQ@mail.gmail.com>
Message-ID: <CALhHN=pkwmRJKq1_RQ+3dryu8XcgbhwR-9T288ugoSJAHKM5AA@mail.gmail.com>

On 6 June 2016 at 21:22, Zach Sherin <zach at netblazr.com> wrote:
> That's what I thought. Thanks for confirming, and thanks again for
> your time and help!
>
BTW, check google: ath10k smart antenna
Seems 10.2 support this.

BR
Janusz

> Have a good one,
> Zach
>
> On Mon, Jun 6, 2016 at 2:57 PM, Ben Greear <greearb at candelatech.com> wrote:
>> On 06/06/2016 11:48 AM, Zach Sherin wrote:
>>>
>>> Interesting. Could I ask if there's somewhere I should start digging?
>>> If it's not obvious I'm a driver/kernel newbie, but I'm happy to
>>> learn. Should I start by going through ath10k's documentation/code
>>> until I find the relevant bits?
>>
>>
>> Unfortunately, without firmware source, you have probably no chance
>> to do this.  And, you also probably have about no chance of getting
>> firmware source.
>>
>> Thanks,
>> Ben
>>
>>
>>>
>>> Thanks,
>>> Zach
>>>
>>>
>>> On Mon, Jun 6, 2016 at 2:42 PM, Adrian Chadd <adrian.chadd at gmail.com>
>>> wrote:
>>>>
>>>> I bet the ruckus mode shift stuff is in the ath10k hardware and is
>>>> configurable per TX descriptor.
>>>>
>>>> a
>>>>
>>>> On Jun 6, 2016 11:03 AM, "Ben Greear" <greearb at candelatech.com> wrote:
>>>>>
>>>>>
>>>>> On 06/06/2016 10:59 AM, Zach Sherin wrote:
>>>>>>
>>>>>>
>>>>>> I was aiming to run this off a serial interface on the general board,
>>>>>> not on the ath10k NIC. I have a consumer QCA9880 PCI board in an
>>>>>> Archer C7 router. It would be awesome if I could steal a GPIO or
>>>>>> something from the atheros chip to output, but I was assuming I
>>>>>> couldn't. The main reason I was looking at the ath10k driver was to
>>>>>> get as close to when the packets are transmitted as possible, to leave
>>>>>> as little room for error in the switching as possible.
>>>>>>
>>>>>> However, it's  possible that I'm hoping for too much there. I'd be
>>>>>> interested to hear your thoughts on it. If I can't pull it off, I'll
>>>>>> move to an approach outside ath10k.
>>>>>
>>>>>
>>>>>
>>>>> The driver just sends pkts to the firmware, it is the firmware that
>>>>> knows when a pkt is to be transmitted, so I think you would have to have
>>>>> some
>>>>> hooks low in the firmware tx logic to do what you want.  And you would
>>>>> need some
>>>>> hardware output from the NIC.
>>>>>
>>>>> I am guessing it would require quite a bit of changes to the firmware,
>>>>> possibly very tricky/hacky ones, and hardware output on your NIC.
>>>>>
>>>>> Thanks,
>>>>> Ben
>>>>>
>>>>> --
>>>>> Ben Greear <greearb at candelatech.com>
>>>>> Candela Technologies Inc  http://www.candelatech.com
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ath10k mailing list
>>>>> ath10k at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>
>>>
>>
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From adrian.chadd at gmail.com  Tue Jun  7 00:40:18 2016
From: adrian.chadd at gmail.com (Adrian Chadd)
Date: Tue, 7 Jun 2016 00:40:18 -0700
Subject: Any tips on where per-packet antenna selection could be pushed?
In-Reply-To: <CALhHN=pkwmRJKq1_RQ+3dryu8XcgbhwR-9T288ugoSJAHKM5AA@mail.gmail.com>
References: <CAOiRWuVxbGDoVtxahwRxyH9NaBB9LmaEBZ5bzgSPEf=Eu1g=ug@mail.gmail.com>
 <5755B0FF.9010900@candelatech.com>
 <CAOiRWuUFvZU1b4Pn8nDVs5O5sNK-g0PPbckriP=RmBnB5f-5Gw@mail.gmail.com>
 <5755B2D9.7080207@candelatech.com>
 <CAOiRWuUjugeDtRTQUWBzoCq58L8XfW7aYQTHa=Mnf4smx6AR2g@mail.gmail.com>
 <5755BABA.1030006@candelatech.com>
 <CAJ-VmomKzRAkJNQr2Sg=j57uPfptPiRs1Q026dPeuQv0jMx-Og@mail.gmail.com>
 <CAOiRWuUL9RC61pdieiEh3ZtWFGLomHzPxqbbVE3Oe_3043Zv2g@mail.gmail.com>
 <5755C7AF.6020203@candelatech.com>
 <CAOiRWuX4mwQEmY0pNvAvufHrfte_94JzyMw41i1SDMNHj=KtCQ@mail.gmail.com>
 <CALhHN=pkwmRJKq1_RQ+3dryu8XcgbhwR-9T288ugoSJAHKM5AA@mail.gmail.com>
Message-ID: <CAJ-VmontFzXCqOhyEENTeWFnyeb0r=1d9jdX8SVRc9WeuX5vag@mail.gmail.com>

On 6 June 2016 at 23:24, Janusz Dziedzic <janusz.dziedzic at tieto.com> wrote:
> On 6 June 2016 at 21:22, Zach Sherin <zach at netblazr.com> wrote:
>> That's what I thought. Thanks for confirming, and thanks again for
>> your time and help!
>>
> BTW, check google: ath10k smart antenna
> Seems 10.2 support this.


ooo cool. wonder how much of the useful bits it implements!



-adrian

>
> BR
> Janusz
>
>> Have a good one,
>> Zach
>>
>> On Mon, Jun 6, 2016 at 2:57 PM, Ben Greear <greearb at candelatech.com> wrote:
>>> On 06/06/2016 11:48 AM, Zach Sherin wrote:
>>>>
>>>> Interesting. Could I ask if there's somewhere I should start digging?
>>>> If it's not obvious I'm a driver/kernel newbie, but I'm happy to
>>>> learn. Should I start by going through ath10k's documentation/code
>>>> until I find the relevant bits?
>>>
>>>
>>> Unfortunately, without firmware source, you have probably no chance
>>> to do this.  And, you also probably have about no chance of getting
>>> firmware source.
>>>
>>> Thanks,
>>> Ben
>>>
>>>
>>>>
>>>> Thanks,
>>>> Zach
>>>>
>>>>
>>>> On Mon, Jun 6, 2016 at 2:42 PM, Adrian Chadd <adrian.chadd at gmail.com>
>>>> wrote:
>>>>>
>>>>> I bet the ruckus mode shift stuff is in the ath10k hardware and is
>>>>> configurable per TX descriptor.
>>>>>
>>>>> a
>>>>>
>>>>> On Jun 6, 2016 11:03 AM, "Ben Greear" <greearb at candelatech.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 06/06/2016 10:59 AM, Zach Sherin wrote:
>>>>>>>
>>>>>>>
>>>>>>> I was aiming to run this off a serial interface on the general board,
>>>>>>> not on the ath10k NIC. I have a consumer QCA9880 PCI board in an
>>>>>>> Archer C7 router. It would be awesome if I could steal a GPIO or
>>>>>>> something from the atheros chip to output, but I was assuming I
>>>>>>> couldn't. The main reason I was looking at the ath10k driver was to
>>>>>>> get as close to when the packets are transmitted as possible, to leave
>>>>>>> as little room for error in the switching as possible.
>>>>>>>
>>>>>>> However, it's  possible that I'm hoping for too much there. I'd be
>>>>>>> interested to hear your thoughts on it. If I can't pull it off, I'll
>>>>>>> move to an approach outside ath10k.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The driver just sends pkts to the firmware, it is the firmware that
>>>>>> knows when a pkt is to be transmitted, so I think you would have to have
>>>>>> some
>>>>>> hooks low in the firmware tx logic to do what you want.  And you would
>>>>>> need some
>>>>>> hardware output from the NIC.
>>>>>>
>>>>>> I am guessing it would require quite a bit of changes to the firmware,
>>>>>> possibly very tricky/hacky ones, and hardware output on your NIC.
>>>>>>
>>>>>> Thanks,
>>>>>> Ben
>>>>>>
>>>>>> --
>>>>>> Ben Greear <greearb at candelatech.com>
>>>>>> Candela Technologies Inc  http://www.candelatech.com
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> ath10k mailing list
>>>>>> ath10k at lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>
>>>>
>>>
>>>
>>> --
>>> Ben Greear <greearb at candelatech.com>
>>> Candela Technologies Inc  http://www.candelatech.com
>>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k


From michal.kazior at tieto.com  Tue Jun  7 00:53:48 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 7 Jun 2016 09:53:48 +0200
Subject: Any tips on where per-packet antenna selection could be pushed?
In-Reply-To: <CAJ-VmontFzXCqOhyEENTeWFnyeb0r=1d9jdX8SVRc9WeuX5vag@mail.gmail.com>
References: <CAOiRWuVxbGDoVtxahwRxyH9NaBB9LmaEBZ5bzgSPEf=Eu1g=ug@mail.gmail.com>
 <5755B0FF.9010900@candelatech.com>
 <CAOiRWuUFvZU1b4Pn8nDVs5O5sNK-g0PPbckriP=RmBnB5f-5Gw@mail.gmail.com>
 <5755B2D9.7080207@candelatech.com>
 <CAOiRWuUjugeDtRTQUWBzoCq58L8XfW7aYQTHa=Mnf4smx6AR2g@mail.gmail.com>
 <5755BABA.1030006@candelatech.com>
 <CAJ-VmomKzRAkJNQr2Sg=j57uPfptPiRs1Q026dPeuQv0jMx-Og@mail.gmail.com>
 <CAOiRWuUL9RC61pdieiEh3ZtWFGLomHzPxqbbVE3Oe_3043Zv2g@mail.gmail.com>
 <5755C7AF.6020203@candelatech.com>
 <CAOiRWuX4mwQEmY0pNvAvufHrfte_94JzyMw41i1SDMNHj=KtCQ@mail.gmail.com>
 <CALhHN=pkwmRJKq1_RQ+3dryu8XcgbhwR-9T288ugoSJAHKM5AA@mail.gmail.com>
 <CAJ-VmontFzXCqOhyEENTeWFnyeb0r=1d9jdX8SVRc9WeuX5vag@mail.gmail.com>
Message-ID: <CA+BoTQn_jR26JJrnGS_1Ays1yjAUKTFrLsWnofuHGZQv9NTHMg@mail.gmail.com>

On 7 June 2016 at 09:40, Adrian Chadd <adrian.chadd at gmail.com> wrote:
> On 6 June 2016 at 23:24, Janusz Dziedzic <janusz.dziedzic at tieto.com> wrote:
>> On 6 June 2016 at 21:22, Zach Sherin <zach at netblazr.com> wrote:
>>> That's what I thought. Thanks for confirming, and thanks again for
>>> your time and help!
>>>
>> BTW, check google: ath10k smart antenna
>> Seems 10.2 support this.
>
>
> ooo cool. wonder how much of the useful bits it implements!

Keep in mind smart antenna requires HW support (you can check this via
wmi_services in debugfs on ath10k - there's SW and HW bits are
advertised there). Not all qca988x chips support it - only some of the
revisions. I don't know if ones found in Archer C7 support it (maybe
some do?).

There's some code on codeaurora you can use as a reference:

 https://us.codeaurora.org/cgit/quic/qsdk/oss/system/feeds/wlan-open/tree/mac80211/patches/a00-0015-ath10k-smart-antenna-API-support.patch?h=coconut

 https://us.codeaurora.org/cgit/quic/qsdk/oss/system/feeds/wlan-open/tree/mac80211/patches/a00-0016-ath10k-smart-antenna-debugfs.patch?h=coconut

 https://us.codeaurora.org/cgit/quic/qsdk/oss/system/feeds/wlan-open/tree/mac80211/patches/a00-0021-ath10k-Smart-antenna-Algorithm.patch?h=coconut


Micha?


From kvalo at qca.qualcomm.com  Tue Jun  7 04:29:19 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 7 Jun 2016 13:29:19 +0200
Subject: [1/2] ath10k: add QCA9887 chipset support
In-Reply-To: <1463755272-12912-1-git-send-email-sven.eckelmann@open-mesh.com>
Message-ID: <d77ac566725940fa90cd014198ffb030@euamsexm01a.eu.qualcomm.com>

Sven Eckelmann <sven.eckelmann at open-mesh.com> wrote:
> Add the hardware name, revision, firmware names and update the pci_id
> table.
> 
> QA9887 HW1.0 is supposed to be similar to QCA988X HW2.0 . Details about
> he firmware interface are currently unknown.
> 
> Signed-off-by: Sven Eckelmann <sven.eckelmann at open-mesh.com>

Thanks, 2 patches applied to ath-next branch of ath.git:

6fd3dd716091 ath10k: add QCA9887 chipset support
6847f9673391 ath10k: add board data download from target

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9129717/



From kvalo at qca.qualcomm.com  Tue Jun  7 04:38:37 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 7 Jun 2016 13:38:37 +0200
Subject: [v2,01/21] ath10k: Fix crash related to printing features.
In-Reply-To: <1462986153-16318-2-git-send-email-greearb@candelatech.com>
Message-ID: <e2a4492749b54436ae1476c36adbcd20@euamsexm01a.eu.qualcomm.com>

Ben Greear <greearb at candelatech.com> wrote:
> From: Ben Greear <greearb at candelatech.com>
> 
> This looks like a regression from
> c4cdf753 (move fw_features to struct ath10k_fw_file)
> 
> Signed-off-by:  Ben Greear <greearb at candelatech.com>

Thanks, 1 patch applied to ath-current branch of ath.git:

8d0a0710ea0d ath10k: fix crash related to printing features

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9073471/



From greearb at candelatech.com  Tue Jun  7 05:57:32 2016
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 07 Jun 2016 05:57:32 -0700
Subject: Question on "ath10k: document ofdm/5ghz rate offset with a macro"
In-Reply-To: <CA+BoTQ=sGYcoHcBcPKqzqqFekbV9g23ZZ556N9+9kmtZKV=kEg@mail.gmail.com>
References: <5755EA60.7070504@candelatech.com>
 <CA+BoTQ=sGYcoHcBcPKqzqqFekbV9g23ZZ556N9+9kmtZKV=kEg@mail.gmail.com>
Message-ID: <5756C4BC.3040402@candelatech.com>



On 06/06/2016 11:23 PM, Michal Kazior wrote:
> On 6 June 2016 at 23:25, Ben Greear <greearb at candelatech.com> wrote:
>> While porting some patches forward, I notice the change below
>> that renamed the method to "ath10k_mac_sta_has_ofdm_only".  But,
>> that is not really what that is checking, since it just throws
>> away the CCK rates (and they might have been there).
>>
>> Maybe it should just be "ath10k_mac_sta_has_ofdm()" ?
>
> Yes, this seems like an unfortunate name pick on my side. The MODE_11G
> phymode is for mixed b/g.

I think the actual code behaviour is right.  I have some patches to
support G-only mode and such, and will change the name of your method
in those patches to be more clear.

Lots of other pending patches of mine before I will get to trying to push
that one upstream though.

Thanks,
Ben


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


From michal.kazior at tieto.com  Tue Jun  7 06:16:52 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 7 Jun 2016 15:16:52 +0200
Subject: Question on "ath10k: document ofdm/5ghz rate offset with a macro"
In-Reply-To: <5756C4BC.3040402@candelatech.com>
References: <5755EA60.7070504@candelatech.com>
 <CA+BoTQ=sGYcoHcBcPKqzqqFekbV9g23ZZ556N9+9kmtZKV=kEg@mail.gmail.com>
 <5756C4BC.3040402@candelatech.com>
Message-ID: <CA+BoTQmhwPyGP4OXw4=3LE+UvTm0DCxUFKBbXhKXc_N1NiS1xw@mail.gmail.com>

On 7 June 2016 at 14:57, Ben Greear <greearb at candelatech.com> wrote:
> On 06/06/2016 11:23 PM, Michal Kazior wrote:
>> On 6 June 2016 at 23:25, Ben Greear <greearb at candelatech.com> wrote:
>>>
>>> While porting some patches forward, I notice the change below
>>> that renamed the method to "ath10k_mac_sta_has_ofdm_only".  But,
>>> that is not really what that is checking, since it just throws
>>> away the CCK rates (and they might have been there).
>>>
>>> Maybe it should just be "ath10k_mac_sta_has_ofdm()" ?
>>
>> Yes, this seems like an unfortunate name pick on my side. The MODE_11G
>> phymode is for mixed b/g.
>
> I think the actual code behaviour is right.  I have some patches to
> support G-only mode and such, and will change the name of your method
> in those patches to be more clear.
>
> Lots of other pending patches of mine before I will get to trying to push
> that one upstream though.

Hmm.. I do recall 11G_ONLY phymode didn't play out well with 11B
coexistance in AP mode. I can't remember the details though..


Micha?


From greearb at candelatech.com  Tue Jun  7 06:19:18 2016
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 07 Jun 2016 06:19:18 -0700
Subject: Question on "ath10k: document ofdm/5ghz rate offset with a macro"
In-Reply-To: <CA+BoTQmhwPyGP4OXw4=3LE+UvTm0DCxUFKBbXhKXc_N1NiS1xw@mail.gmail.com>
References: <5755EA60.7070504@candelatech.com>
 <CA+BoTQ=sGYcoHcBcPKqzqqFekbV9g23ZZ556N9+9kmtZKV=kEg@mail.gmail.com>
 <5756C4BC.3040402@candelatech.com>
 <CA+BoTQmhwPyGP4OXw4=3LE+UvTm0DCxUFKBbXhKXc_N1NiS1xw@mail.gmail.com>
Message-ID: <5756C9D6.6030306@candelatech.com>



On 06/07/2016 06:16 AM, Michal Kazior wrote:
> On 7 June 2016 at 14:57, Ben Greear <greearb at candelatech.com> wrote:
>> On 06/06/2016 11:23 PM, Michal Kazior wrote:
>>> On 6 June 2016 at 23:25, Ben Greear <greearb at candelatech.com> wrote:
>>>>
>>>> While porting some patches forward, I notice the change below
>>>> that renamed the method to "ath10k_mac_sta_has_ofdm_only".  But,
>>>> that is not really what that is checking, since it just throws
>>>> away the CCK rates (and they might have been there).
>>>>
>>>> Maybe it should just be "ath10k_mac_sta_has_ofdm()" ?
>>>
>>> Yes, this seems like an unfortunate name pick on my side. The MODE_11G
>>> phymode is for mixed b/g.
>>
>> I think the actual code behaviour is right.  I have some patches to
>> support G-only mode and such, and will change the name of your method
>> in those patches to be more clear.
>>
>> Lots of other pending patches of mine before I will get to trying to push
>> that one upstream though.
>
> Hmm.. I do recall 11G_ONLY phymode didn't play out well with 11B
> coexistance in AP mode. I can't remember the details though..

If you remember a test case for this, let me know.

Thanks,
Ben


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


From mohammed at codeaurora.org  Tue Jun  7 07:50:02 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Tue, 7 Jun 2016 20:20:02 +0530
Subject: [PATCH 0/2] ath10k: Add support for QCA9887
In-Reply-To: <2262792.6VVL0Htyzj@bentobox>
References: <1568876.Six5hABE57@bentobox> <1505571.v1gM3hzMhG@bentobox>
 <87wpmf4qm5.fsf@kamboji.qca.qualcomm.com>
 <2262792.6VVL0Htyzj@bentobox>
Message-ID: <20160607145002.GB11250@atheros-ThinkPad-T61>

Hi Sven,

On Mon, May 30, 2016 at 01:12:27PM +0200, Sven Eckelmann wrote:
> On Friday 27 May 2016 12:44:52 Valo, Kalle wrote:
> [...]
> > > But maybe I should add that the results with the original AP147 firmware also
> > > wasn't better.
> > 
> > That doesn't sound good. Maybe a calibration issue?
> 
> Maybe but I don't have a different card to compare it to.
> 
> [...]
> > I pushed a new firmware image firmware-5.bin_10.2.3.31.7-2 with those
> > enabled:
> > 
> > https://github.com/kvalo/ath10k-firmware/tree/master/QCA9887
> 
> Thanks for the updated firmware file. I have done some basic tests and seems
> to work fine. Bindiff also looks fine
>
[shafi] it would be helpful if you can share your basic test results (if its
possible to share). Have you tried to bring up the card in 5ghz (or) 2ghz.
Or both of them were tried ?

regards
shafi




From adrian.chadd at gmail.com  Tue Jun  7 09:30:54 2016
From: adrian.chadd at gmail.com (Adrian Chadd)
Date: Tue, 7 Jun 2016 09:30:54 -0700
Subject: Any tips on where per-packet antenna selection could be pushed?
In-Reply-To: <CA+BoTQn_jR26JJrnGS_1Ays1yjAUKTFrLsWnofuHGZQv9NTHMg@mail.gmail.com>
References: <CAOiRWuVxbGDoVtxahwRxyH9NaBB9LmaEBZ5bzgSPEf=Eu1g=ug@mail.gmail.com>
 <5755B0FF.9010900@candelatech.com>
 <CAOiRWuUFvZU1b4Pn8nDVs5O5sNK-g0PPbckriP=RmBnB5f-5Gw@mail.gmail.com>
 <5755B2D9.7080207@candelatech.com>
 <CAOiRWuUjugeDtRTQUWBzoCq58L8XfW7aYQTHa=Mnf4smx6AR2g@mail.gmail.com>
 <5755BABA.1030006@candelatech.com>
 <CAJ-VmomKzRAkJNQr2Sg=j57uPfptPiRs1Q026dPeuQv0jMx-Og@mail.gmail.com>
 <CAOiRWuUL9RC61pdieiEh3ZtWFGLomHzPxqbbVE3Oe_3043Zv2g@mail.gmail.com>
 <5755C7AF.6020203@candelatech.com>
 <CAOiRWuX4mwQEmY0pNvAvufHrfte_94JzyMw41i1SDMNHj=KtCQ@mail.gmail.com>
 <CALhHN=pkwmRJKq1_RQ+3dryu8XcgbhwR-9T288ugoSJAHKM5AA@mail.gmail.com>
 <CAJ-VmontFzXCqOhyEENTeWFnyeb0r=1d9jdX8SVRc9WeuX5vag@mail.gmail.com>
 <CA+BoTQn_jR26JJrnGS_1Ays1yjAUKTFrLsWnofuHGZQv9NTHMg@mail.gmail.com>
Message-ID: <CAJ-VmomAkMBV7fWzWpmxUp5px+xiFCjBz3iWt6K7UXemuRFRiA@mail.gmail.com>

Do we know which hardware platforms use it? (Ie, which already have
some antennas with the right switching hardware?)



-adrian


From sven.eckelmann at open-mesh.com  Tue Jun  7 09:54:54 2016
From: sven.eckelmann at open-mesh.com (Sven Eckelmann)
Date: Tue, 07 Jun 2016 18:54:54 +0200
Subject: [PATCH 0/2] ath10k: Add support for QCA9887
In-Reply-To: <20160607145002.GB11250@atheros-ThinkPad-T61>
References: <1568876.Six5hABE57@bentobox> <2262792.6VVL0Htyzj@bentobox>
 <20160607145002.GB11250@atheros-ThinkPad-T61>
Message-ID: <2104766.hdzL6bzVNd@bentobox>

On Tuesday 07 June 2016 20:20:02 Mohammed Shafi Shajakhan wrote:
[...]
> [shafi] it would be helpful if you can share your basic test results (if its
> possible to share). Have you tried to bring up the card in 5ghz (or) 2ghz.
> Or both of them were tried ?

* 5GHz-only (I have no 2.4GHz capable card)
* card is able to scan
* card is able to create an AP
* data can be transferred via AP and client (bidirectional connection)
* performance was more like 15 Mibit/s for 1x1 HT20 11n devices instead of
  something like 35-40 Mibit/s

I cannot give you any more detailed, current performance test results because
they were done months ago and are most likely not relevant to describe the
current state. Please ask Kalle if you want to know why the old tests were
done many, many months ago.

Please ask Marek when you want to have tests done with the current
mac8011+ath10k.

Kind regards,
	Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160607/65e45090/attachment.sig>

From mohammed at codeaurora.org  Tue Jun  7 10:11:48 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Tue, 7 Jun 2016 22:41:48 +0530
Subject: [PATCH 0/2] ath10k: Add support for QCA9887
In-Reply-To: <2104766.hdzL6bzVNd@bentobox>
References: <1568876.Six5hABE57@bentobox> <2262792.6VVL0Htyzj@bentobox>
 <20160607145002.GB11250@atheros-ThinkPad-T61>
 <2104766.hdzL6bzVNd@bentobox>
Message-ID: <20160607171110.GA13293@atheros-ThinkPad-T61>

Hi Sven,

On Tue, Jun 07, 2016 at 06:54:54PM +0200, Sven Eckelmann wrote:
> On Tuesday 07 June 2016 20:20:02 Mohammed Shafi Shajakhan wrote:
> [...]
> > [shafi] it would be helpful if you can share your basic test results (if its
> > possible to share). Have you tried to bring up the card in 5ghz (or) 2ghz.
> > Or both of them were tried ?
> 
> * 5GHz-only (I have no 2.4GHz capable card)
> * card is able to scan
> * card is able to create an AP
> * data can be transferred via AP and client (bidirectional connection)
> * performance was more like 15 Mibit/s for 1x1 HT20 11n devices instead of
>   something like 35-40 Mibit/s

[shafi] sure thanks a lot, this is a good start, i will keep you posted
with my findings and results.

> 
> I cannot give you any more detailed, current performance test results because
> they were done months ago and are most likely not relevant to describe the
> current state. Please ask Kalle if you want to know why the old tests were
> done many, many months ago.

[shafi] sure, hopefully we can get this sorted out. Thank you for the patches
and support.

> 
> Please ask Marek when you want to have tests done with the current
> mac8011+ath10k.

[shafi] thanks

> 
> Kind regards,
> 	Sven




From gaurang at vt.edu  Wed Jun  8 02:01:30 2016
From: gaurang at vt.edu (Gaurang Ramesh Naik)
Date: Wed, 8 Jun 2016 05:01:30 -0400
Subject: Number of Transmission retries
Message-ID: <CAFc9h7synwZ1mt0PyRNN1Q6DOwtbL2im=PnxXhtrvZAFa2Yjcg@mail.gmail.com>

Hi,

I know there is an iw command to set the number of transmission
retries using "iw phy phyx set retry short 'y' long 'z'". When I used
this command though, I did not observe any change in the performance
of the link throughput. Does ath10k honor this command? Also, if it
does, is it implemented in the firmware, or open-source?

Thanks,
GN.


From michal.kazior at tieto.com  Wed Jun  8 02:14:54 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 8 Jun 2016 11:14:54 +0200
Subject: Number of Transmission retries
In-Reply-To: <CAFc9h7synwZ1mt0PyRNN1Q6DOwtbL2im=PnxXhtrvZAFa2Yjcg@mail.gmail.com>
References: <CAFc9h7synwZ1mt0PyRNN1Q6DOwtbL2im=PnxXhtrvZAFa2Yjcg@mail.gmail.com>
Message-ID: <CA+BoTQnF-WgxhBDm=t0QvHTSqsf1Y5mUTwKTu+Wso-hkM+3=xA@mail.gmail.com>

On 8 June 2016 at 11:01, Gaurang Ramesh Naik <gaurang at vt.edu> wrote:
> Hi,
>
> I know there is an iw command to set the number of transmission
> retries using "iw phy phyx set retry short 'y' long 'z'". When I used
> this command though, I did not observe any change in the performance
> of the link throughput. Does ath10k honor this command? Also, if it
> does, is it implemented in the firmware, or open-source?

ath10k does not honour it.

As far as I understand you want to alter number of retries with regard
to RTS/CTS being used or not. If so I'm not aware of any mechanism to
tell that to firmware (this is rate-control related and rate-control
is offloaded by firmware entirely).

To my knowledge what you can do is change number of software retries
for aggregated and non-aggregated traffic via NON_AGG_SW_RETRY_TH and
AGG_SW_RETRY_TH WMI's pdev parameters. Perhaps you'll find this
useful.


Micha?


From gaurang at vt.edu  Wed Jun  8 02:28:03 2016
From: gaurang at vt.edu (Gaurang Ramesh Naik)
Date: Wed, 8 Jun 2016 05:28:03 -0400
Subject: Number of Transmission retries
In-Reply-To: <CA+BoTQnF-WgxhBDm=t0QvHTSqsf1Y5mUTwKTu+Wso-hkM+3=xA@mail.gmail.com>
References: <CAFc9h7synwZ1mt0PyRNN1Q6DOwtbL2im=PnxXhtrvZAFa2Yjcg@mail.gmail.com>
 <CA+BoTQnF-WgxhBDm=t0QvHTSqsf1Y5mUTwKTu+Wso-hkM+3=xA@mail.gmail.com>
Message-ID: <CAFc9h7v=WH7+irh8=vTN4qQBXRfy4uj=PYs4iboE4piwufbPZQ@mail.gmail.com>

Hi Michal,

That does help. Thank you so much.

GN.

On Wed, Jun 8, 2016 at 5:14 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 8 June 2016 at 11:01, Gaurang Ramesh Naik <gaurang at vt.edu> wrote:
>> Hi,
>>
>> I know there is an iw command to set the number of transmission
>> retries using "iw phy phyx set retry short 'y' long 'z'". When I used
>> this command though, I did not observe any change in the performance
>> of the link throughput. Does ath10k honor this command? Also, if it
>> does, is it implemented in the firmware, or open-source?
>
> ath10k does not honour it.
>
> As far as I understand you want to alter number of retries with regard
> to RTS/CTS being used or not. If so I'm not aware of any mechanism to
> tell that to firmware (this is rate-control related and rate-control
> is offloaded by firmware entirely).
>
> To my knowledge what you can do is change number of software retries
> for aggregated and non-aggregated traffic via NON_AGG_SW_RETRY_TH and
> AGG_SW_RETRY_TH WMI's pdev parameters. Perhaps you'll find this
> useful.
>
>
> Micha?


From leroi.lists at gmail.com  Wed Jun  8 04:39:03 2016
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Wed, 8 Jun 2016 14:39:03 +0300
Subject: [RFC/RFT] ath10k: disable wake_tx_queue for older devices
In-Reply-To: <87inxrzqa5.fsf@kamboji.qca.qualcomm.com>
References: <1463489221-24989-1-git-send-email-michal.kazior@tieto.com>
 <87inxrzqa5.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CACiydbLvke0UxJbg2sn0q-=FwXpmX+FKUV7wwEMT=qUYekJrJA@mail.gmail.com>

On 2 June 2016 at 16:14, Valo, Kalle <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> Some setups suffer performance regressions with
>> current wake_tx_queue implementation.
>>
>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>> ---
>> Hi Roman,
>>
>> Can you give this patch a try and see if it helps
>> with your performance problems, please?
>
> Did anyone seeing the performance regression manage to test this? It
> would be good to get feedback, good or bad, before I push this to 4.7.
>
> Full patch here:
>
> https://patchwork.kernel.org/patch/9111981/

Sorry, didn't try yet, bad timing for me :(
Will try to test by the end of the week

Regards,
Roman


From mohammed at codeaurora.org  Wed Jun  8 05:43:08 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Wed, 8 Jun 2016 18:13:08 +0530
Subject: [PATCH 0/2] ath10k: Add support for QCA9887
In-Reply-To: <20160607171110.GA13293@atheros-ThinkPad-T61>
References: <1568876.Six5hABE57@bentobox> <2262792.6VVL0Htyzj@bentobox>
 <20160607145002.GB11250@atheros-ThinkPad-T61>
 <2104766.hdzL6bzVNd@bentobox>
 <20160607171110.GA13293@atheros-ThinkPad-T61>
Message-ID: <20160608124308.GB29340@atheros-ThinkPad-T61>

On Tue, Jun 07, 2016 at 10:41:48PM +0530, Mohammed Shafi Shajakhan wrote:
> Hi Sven,
> 
> On Tue, Jun 07, 2016 at 06:54:54PM +0200, Sven Eckelmann wrote:
> > On Tuesday 07 June 2016 20:20:02 Mohammed Shafi Shajakhan wrote:
> > [...]
> > > [shafi] it would be helpful if you can share your basic test results (if its
> > > possible to share). Have you tried to bring up the card in 5ghz (or) 2ghz.
> > > Or both of them were tried ?
> > 
> > * 5GHz-only (I have no 2.4GHz capable card)
> > * card is able to scan
> > * card is able to create an AP
> > * data can be transferred via AP and client (bidirectional connection)
> > * performance was more like 15 Mibit/s for 1x1 HT20 11n devices instead of
> >   something like 35-40 Mibit/s
> 
> [shafi] sure thanks a lot, this is a good start, i will keep you posted
> with my findings and results.

[shafi] request if you can disable TX-STBC for both HT and VHT, it helped
me though. Will keep you posted with more updates.

> 
> > 
> > I cannot give you any more detailed, current performance test results because
> > they were done months ago and are most likely not relevant to describe the
> > current state. Please ask Kalle if you want to know why the old tests were
> > done many, many months ago.
> 
> [shafi] sure, hopefully we can get this sorted out. Thank you for the patches
> and support.
> 
> > 
> > Please ask Marek when you want to have tests done with the current
> > mac8011+ath10k.
> 
> [shafi] thanks
> 
> > 
> > Kind regards,
> > 	Sven
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From michal.kazior at tieto.com  Wed Jun  8 06:53:44 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 8 Jun 2016 15:53:44 +0200
Subject: Any tips on where per-packet antenna selection could be pushed?
In-Reply-To: <CAJ-VmomAkMBV7fWzWpmxUp5px+xiFCjBz3iWt6K7UXemuRFRiA@mail.gmail.com>
References: <CAOiRWuVxbGDoVtxahwRxyH9NaBB9LmaEBZ5bzgSPEf=Eu1g=ug@mail.gmail.com>
 <5755B0FF.9010900@candelatech.com>
 <CAOiRWuUFvZU1b4Pn8nDVs5O5sNK-g0PPbckriP=RmBnB5f-5Gw@mail.gmail.com>
 <5755B2D9.7080207@candelatech.com>
 <CAOiRWuUjugeDtRTQUWBzoCq58L8XfW7aYQTHa=Mnf4smx6AR2g@mail.gmail.com>
 <5755BABA.1030006@candelatech.com>
 <CAJ-VmomKzRAkJNQr2Sg=j57uPfptPiRs1Q026dPeuQv0jMx-Og@mail.gmail.com>
 <CAOiRWuUL9RC61pdieiEh3ZtWFGLomHzPxqbbVE3Oe_3043Zv2g@mail.gmail.com>
 <5755C7AF.6020203@candelatech.com>
 <CAOiRWuX4mwQEmY0pNvAvufHrfte_94JzyMw41i1SDMNHj=KtCQ@mail.gmail.com>
 <CALhHN=pkwmRJKq1_RQ+3dryu8XcgbhwR-9T288ugoSJAHKM5AA@mail.gmail.com>
 <CAJ-VmontFzXCqOhyEENTeWFnyeb0r=1d9jdX8SVRc9WeuX5vag@mail.gmail.com>
 <CA+BoTQn_jR26JJrnGS_1Ays1yjAUKTFrLsWnofuHGZQv9NTHMg@mail.gmail.com>
 <CAJ-VmomAkMBV7fWzWpmxUp5px+xiFCjBz3iWt6K7UXemuRFRiA@mail.gmail.com>
Message-ID: <CA+BoTQ=DJ3R0Myz3BA3ajiqK51-hW80g_2wZMFVASDJycGTbuA@mail.gmail.com>

On 7 June 2016 at 18:30, Adrian Chadd <adrian.chadd at gmail.com> wrote:
> Do we know which hardware platforms use it? (Ie, which already have
> some antennas with the right switching hardware?)

Unfortunately I do not.


Micha?


From rmanohar at codeaurora.org  Wed Jun  8 08:52:55 2016
From: rmanohar at codeaurora.org (Rajkumar Manoharan)
Date: Wed, 08 Jun 2016 21:22:55 +0530
Subject: Bug 119151 - [regression] ath10k no longer authenitcates and
 freezes system
In-Reply-To: <CAHbf0-GT0y1pEs-ToxbPAf+aRo7TNAyV_Emies_rjL27R1fk2A@mail.gmail.com>
References: <8760trzoiw.fsf@kamboji.qca.qualcomm.com>
 <871t4fzn1x.fsf@kamboji.qca.qualcomm.com> <57504F05.3040200@candelatech.com>
 <1464887026467.72937@qti.qualcomm.com> <57506BA1.2090303@candelatech.com>
 <CAHbf0-GT0y1pEs-ToxbPAf+aRo7TNAyV_Emies_rjL27R1fk2A@mail.gmail.com>
Message-ID: <c36f442934605c492525af72fa04ada9@codeaurora.org>

On 2016-06-02 23:03, Mike Lothian wrote:
> I've just tried those two changes, the machine now locks up before X
> has even started
> 
Mike,

Sorry for the delay. Found root cause for dead lock. Can you please give 
a try with below change?

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 3b35c7ab5680..80e645302b54 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1905,7 +1905,6 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k 
*ar, struct sk_buff *skb)
                         return;
                 }
         }
-       ath10k_htt_rx_msdu_buff_replenish(htt);
  }


-Rajkumar


From andreas.kassler at kau.se  Wed Jun  8 08:53:23 2016
From: andreas.kassler at kau.se (Andreas Kassler)
Date: Wed, 8 Jun 2016 17:53:23 +0200
Subject: Channel Switch Time
Message-ID: <8817589a-13bf-5c59-a3f2-c5bdadf2906b@kau.se>

Hi,
we want to implement fast channel switching on ATH10K for IBSS mode. Any 
pointer on firmware modifications that allow to do that fast would be 
appreciated. Currently, we observe a latency of 2.5 sec under traffic. 
Also, 802.11h support for CSA would be nice to have in IBSS mode. How 
can we trigger this? I mean what interface do we have from outside to 
trigger a fast channel switch that then issues a 802.11h CSA so that all 
peers would also switch the channel, ideally in millisecond time?

Andreas
-- 
Andreas Kassler
==================================
Prof. Dr. Andreas J. Kassler
Computer Science Department - Telematics
Universitetsgatan 2
SE-65188 Karlstad
Sweden
Tel.: ++46 (0)54 700-2168
Fax: ++46 (0)54 700-1828
eMail: kassler at ieee.org
skype: andreaskassler
MSN: andreaskassler at hotmail.com
Web: www.cs.kau.se/~andreask



From mike at fireburn.co.uk  Wed Jun  8 10:41:30 2016
From: mike at fireburn.co.uk (Mike Lothian)
Date: Wed, 8 Jun 2016 18:41:30 +0100
Subject: Bug 119151 - [regression] ath10k no longer authenitcates and
 freezes system
In-Reply-To: <c36f442934605c492525af72fa04ada9@codeaurora.org>
References: <8760trzoiw.fsf@kamboji.qca.qualcomm.com>
 <871t4fzn1x.fsf@kamboji.qca.qualcomm.com>
 <57504F05.3040200@candelatech.com> <1464887026467.72937@qti.qualcomm.com>
 <57506BA1.2090303@candelatech.com>
 <CAHbf0-GT0y1pEs-ToxbPAf+aRo7TNAyV_Emies_rjL27R1fk2A@mail.gmail.com>
 <c36f442934605c492525af72fa04ada9@codeaurora.org>
Message-ID: <CAHbf0-EYKTo+ZyzVM5v8Ae1werwh6+enj_SEdZG6KbXB1TygXw@mail.gmail.com>

Hi

Yes that fixes things locally

Thanks

Mike

On 8 June 2016 at 16:52, Rajkumar Manoharan <rmanohar at codeaurora.org> wrote:
> On 2016-06-02 23:03, Mike Lothian wrote:
>>
>> I've just tried those two changes, the machine now locks up before X
>> has even started
>>
> Mike,
>
> Sorry for the delay. Found root cause for dead lock. Can you please give a
> try with below change?
>
> diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
> b/drivers/net/wireless/ath/ath10k/htt_rx.c
> index 3b35c7ab5680..80e645302b54 100644
> --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
> +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
> @@ -1905,7 +1905,6 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k
> *ar, struct sk_buff *skb)
>                         return;
>                 }
>         }
> -       ath10k_htt_rx_msdu_buff_replenish(htt);
>  }
>
>
> -Rajkumar


From gaurang at vt.edu  Wed Jun  8 20:10:34 2016
From: gaurang at vt.edu (Gaurang Ramesh Naik)
Date: Wed, 8 Jun 2016 23:10:34 -0400
Subject: Dynamic Bandwidth in hw rate control
Message-ID: <CAFc9h7uxTOUxONvW-gvgkFLUNR9OBn09kfetF9gqAtcNqN3SLg@mail.gmail.com>

Hi,

I needed a small clarification related to dynamic bandwidth setup. The
documentation in wmi.h says " When enabled HW rate control tries
different bandwidths when retransmitting frames."

Does this mean that each packet is first always tried over VHT80 and
if that fails it goes to HT40 and then to HT20? I tried this with one
AP-Sta operating in VHT80 and one AP operating in its first secondary
channel. When I check the rx rate info using "iw dev wlanx station
dump", the bandwidth seems to sometimes alternate between 20 and 80,
but sometimes it stays fixed at 20. Hence, I was wondering what really
happens.

Thanks,
Gaurang.


From mohammed at codeaurora.org  Wed Jun  8 22:06:58 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Thu, 9 Jun 2016 10:36:58 +0530
Subject: [PATCH 0/2] ath10k: Add support for QCA9887
In-Reply-To: <20160608124308.GB29340@atheros-ThinkPad-T61>
References: <1568876.Six5hABE57@bentobox> <2262792.6VVL0Htyzj@bentobox>
 <20160607145002.GB11250@atheros-ThinkPad-T61>
 <2104766.hdzL6bzVNd@bentobox>
 <20160607171110.GA13293@atheros-ThinkPad-T61>
 <20160608124308.GB29340@atheros-ThinkPad-T61>
Message-ID: <20160609050657.GA31330@atheros-ThinkPad-T61>

Hi Sven,

i have something like this as of now(generically
disabling TX-STBC for streams <= 1 just like ath9k
does

--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4194,6 +4194,9 @@ static struct ieee80211_sta_vht_cap ath10k_create_vht_cap(struct ath10k *ar)
 			mcs_map |= IEEE80211_VHT_MCS_NOT_SUPPORTED << (i * 2);
 	}
 
+	if (ar->cfg_tx_chainmask <= 1)
+		vht_cap.cap &= ~IEEE80211_VHT_CAP_TXSTBC;
+
 	vht_cap.vht_mcs.rx_mcs_map = cpu_to_le16(mcs_map);
 	vht_cap.vht_mcs.tx_mcs_map = cpu_to_le16(mcs_map);
 
@@ -4231,7 +4234,7 @@ static struct ieee80211_sta_ht_cap ath10k_get_ht_cap(struct ath10k *ar)
 		ht_cap.cap |= smps;
 	}
 
-	if (ar->ht_cap_info & WMI_HT_CAP_TX_STBC)
+	if (ar->ht_cap_info & WMI_HT_CAP_TX_STBC && (ar->cfg_tx_chainmask > 1))
 		ht_cap.cap |= IEEE80211_HT_CAP_TX_STBC;
 
 	if (ar->ht_cap_info & WMI_HT_CAP_RX_STBC) {
-- 

regards,
shafi

On Wed, Jun 08, 2016 at 06:13:08PM +0530, Mohammed Shafi Shajakhan wrote:
> On Tue, Jun 07, 2016 at 10:41:48PM +0530, Mohammed Shafi Shajakhan wrote:
> > Hi Sven,
> > 
> > On Tue, Jun 07, 2016 at 06:54:54PM +0200, Sven Eckelmann wrote:
> > > On Tuesday 07 June 2016 20:20:02 Mohammed Shafi Shajakhan wrote:
> > > [...]
> > > > [shafi] it would be helpful if you can share your basic test results (if its
> > > > possible to share). Have you tried to bring up the card in 5ghz (or) 2ghz.
> > > > Or both of them were tried ?
> > > 
> > > * 5GHz-only (I have no 2.4GHz capable card)
> > > * card is able to scan
> > > * card is able to create an AP
> > > * data can be transferred via AP and client (bidirectional connection)
> > > * performance was more like 15 Mibit/s for 1x1 HT20 11n devices instead of
> > >   something like 35-40 Mibit/s
> > 
> > [shafi] sure thanks a lot, this is a good start, i will keep you posted
> > with my findings and results.
> 
> [shafi] request if you can disable TX-STBC for both HT and VHT, it helped
> me though. Will keep you posted with more updates.
> 
> > 
> > > 
> > > I cannot give you any more detailed, current performance test results because
> > > they were done months ago and are most likely not relevant to describe the
> > > current state. Please ask Kalle if you want to know why the old tests were
> > > done many, many months ago.
> > 
> > [shafi] sure, hopefully we can get this sorted out. Thank you for the patches
> > and support.
> > 
> > > 
> > > Please ask Marek when you want to have tests done with the current
> > > mac8011+ath10k.
> > 
> > [shafi] thanks
> > 
> > > 
> > > Kind regards,
> > > 	Sven
> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From greearb at candelatech.com  Wed Jun  8 22:23:55 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 08 Jun 2016 22:23:55 -0700
Subject: Dynamic Bandwidth in hw rate control
In-Reply-To: <CAFc9h7uxTOUxONvW-gvgkFLUNR9OBn09kfetF9gqAtcNqN3SLg@mail.gmail.com>
References: <CAFc9h7uxTOUxONvW-gvgkFLUNR9OBn09kfetF9gqAtcNqN3SLg@mail.gmail.com>
Message-ID: <5758FD6B.40409@candelatech.com>



On 06/08/2016 08:10 PM, Gaurang Ramesh Naik wrote:
> Hi,
>
> I needed a small clarification related to dynamic bandwidth setup. The
> documentation in wmi.h says " When enabled HW rate control tries
> different bandwidths when retransmitting frames."
>
> Does this mean that each packet is first always tried over VHT80 and
> if that fails it goes to HT40 and then to HT20? I tried this with one
> AP-Sta operating in VHT80 and one AP operating in its first secondary
> channel. When I check the rx rate info using "iw dev wlanx station
> dump", the bandwidth seems to sometimes alternate between 20 and 80,
> but sometimes it stays fixed at 20. Hence, I was wondering what really
> happens.

For one thing, if the hardware detects interference on secondary channels,
then it may decide to transmit a 20Mhz encoding.

The rate-ctrl algs in the firmware differ from release to release, but
the general goal is to transmit with the fastest encoding rate.

Thanks,
Ben

>
> Thanks,
> Gaurang.
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>

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


From rmanohar at qti.qualcomm.com  Wed Jun  8 23:03:55 2016
From: rmanohar at qti.qualcomm.com (Rajkumar Manoharan)
Date: Thu, 9 Jun 2016 11:33:55 +0530
Subject: [PATCH] ath10k: fix deadlock while processing rx_in_ord_ind
Message-ID: <20160609060355.16219-1-rmanohar@qti.qualcomm.com>

commit 5c86d97bcc1d ("ath10k: combine txrx and replenish task")
introduced deadlock while processing rx in order indication message
for qca6174 based devices. While merging replenish and txrx tasklets,
replenish task should be called out of htt rx ring locking since it
is also try to acquire the same lock.

Unfortunately this issue is not exposed by other solutions (qca988x,
qca99x0 & qca4019), as rx_in_ord_ind message is specific to qca6174
based devices. This patch fixes

=============================================
[ INFO: possible recursive locking detected ]
4.7.0-rc2-wt-ath+ #1353 Tainted: G            E
---------------------------------------------
swapper/3/0 is trying to acquire lock:
 (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d7ef19>]
ath10k_htt_rx_msdu_buff_replenish+0x29/0x90 [ath10k_core]

but task is already holding lock:
 (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d82cab>]
ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&(&htt->rx_ring.lock)->rlock);
  lock(&(&htt->rx_ring.lock)->rlock);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

1 lock held by swapper/3/0:
 #0:  (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d82cab>]
ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=119151
Fixes: 5c86d97bcc1d ("ath10k: combine txrx and replenish task")
Reported-by: Mike Lothian <mike at fireburn.co.uk>
Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 3b35c7ab5680..80e645302b54 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1905,7 +1905,6 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 			return;
 		}
 	}
-	ath10k_htt_rx_msdu_buff_replenish(htt);
 }
 
 static void ath10k_htt_rx_tx_fetch_resp_id_confirm(struct ath10k *ar,
-- 
2.8.3



From yamada.masahiro at socionext.com  Mon Jun  6 05:20:56 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon,  6 Jun 2016 21:20:56 +0900
Subject: [PATCH] tree-wide: replace config_enabled() with IS_ENABLED()
Message-ID: <1465215656-20569-1-git-send-email-yamada.masahiro@socionext.com>

The use of config_enabled() against config options is ambiguous.
In practical terms, config_enabled() is equivalent to IS_BUILTIN(),
but the author might have used it for the meaning of IS_ENABLED().
Using IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc. makes the
intention clearer.

This commit replaces config_enabled() with IS_ENABLED() where
possible.  This commit is only touching bool config options.

I noticed two cases where config_enabled() is used against a tristate
option:

 - config_enabled(CONFIG_HWMON)
  [ drivers/net/wireless/ath/ath10k/thermal.c ]

 - config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)
  [ drivers/gpu/drm/gma500/opregion.c ]

I did not touch them because they should be converted to IS_BUILTIN()
in order to keep the logic, but I was not sure it was the authors'
intention.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/mips/include/asm/mips-cm.h                  |  2 +-
 arch/mips/include/asm/pgtable.h                  | 16 +++++------
 arch/mips/include/asm/seccomp.h                  |  4 +--
 arch/mips/include/asm/signal.h                   |  4 +--
 arch/mips/include/asm/syscall.h                  |  2 +-
 arch/mips/include/asm/uaccess.h                  |  2 +-
 arch/mips/jz4740/setup.c                         |  2 +-
 arch/mips/kernel/cpu-bugs64.c                    |  6 ++---
 arch/mips/kernel/elf.c                           |  4 +--
 arch/mips/kernel/mips-cm.c                       |  2 +-
 arch/mips/kernel/mips-r2-to-r6-emul.c            | 34 ++++++++++++------------
 arch/mips/kernel/pm-cps.c                        |  4 +--
 arch/mips/kernel/signal.c                        | 10 +++----
 arch/mips/kernel/smp-cps.c                       |  4 +--
 arch/mips/kernel/unaligned.c                     | 10 +++----
 arch/mips/math-emu/cp1emu.c                      |  6 ++---
 arch/mips/mm/tlbex.c                             | 10 +++----
 arch/mips/mti-malta/malta-dtshim.c               |  4 +--
 arch/mips/mti-malta/malta-memory.c               |  2 +-
 arch/mips/mti-malta/malta-setup.c                |  2 +-
 arch/mips/net/bpf_jit.c                          |  4 +--
 arch/x86/include/asm/elf.h                       |  4 +--
 arch/x86/include/asm/fpu/internal.h              | 16 +++++------
 arch/x86/include/asm/mmu_context.h               |  2 +-
 arch/x86/kernel/apic/apic.c                      |  2 +-
 arch/x86/kernel/apic/vector.c                    |  2 +-
 arch/x86/kernel/fpu/signal.c                     | 12 ++++-----
 arch/x86/kernel/signal.c                         | 14 +++++-----
 drivers/firmware/broadcom/bcm47xx_sprom.c        |  2 +-
 drivers/irqchip/irq-mips-gic.c                   |  2 +-
 drivers/mtd/bcm47xxpart.c                        |  2 +-
 drivers/net/wireless/ath/ath10k/debug.c          | 12 ++++-----
 drivers/net/wireless/ath/ath10k/mac.c            | 10 +++----
 drivers/net/wireless/ath/ath10k/wmi.c            |  2 +-
 drivers/net/wireless/ath/ath6kl/cfg80211.c       |  2 +-
 drivers/net/wireless/ath/ath9k/common-spectral.c |  6 ++---
 drivers/net/wireless/ath/ath9k/init.c            |  2 +-
 drivers/net/wireless/ath/ath9k/main.c            | 12 ++++-----
 drivers/net/wireless/ath/ath9k/recv.c            |  2 +-
 drivers/net/wireless/ath/dfs_pattern_detector.c  |  2 +-
 drivers/net/wireless/ath/regd.c                  |  4 +--
 drivers/pci/ecam.c                               |  2 +-
 drivers/tty/serial/ar933x_uart.c                 |  4 +--
 include/linux/fence.h                            |  2 +-
 include/linux/ww_mutex.h                         |  4 +--
 kernel/ptrace.c                                  |  4 +--
 kernel/seccomp.c                                 |  6 ++---
 net/wireless/chan.c                              |  2 +-
 48 files changed, 135 insertions(+), 135 deletions(-)

diff --git a/arch/mips/include/asm/mips-cm.h b/arch/mips/include/asm/mips-cm.h
index 9411a4c..58e7874 100644
--- a/arch/mips/include/asm/mips-cm.h
+++ b/arch/mips/include/asm/mips-cm.h
@@ -462,7 +462,7 @@ static inline unsigned int mips_cm_max_vp_width(void)
 	if (mips_cm_revision() >= CM_REV_CM3)
 		return read_gcr_sys_config2() & CM_GCR_SYS_CONFIG2_MAXVPW_MSK;
 
-	if (config_enabled(CONFIG_SMP))
+	if (IS_ENABLED(CONFIG_SMP))
 		return smp_num_siblings;
 
 	return 1;
diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
index a6b611f..ec5c730 100644
--- a/arch/mips/include/asm/pgtable.h
+++ b/arch/mips/include/asm/pgtable.h
@@ -159,7 +159,7 @@ static inline void set_pte(pte_t *ptep, pte_t pte)
 		 * it better already be global)
 		 */
 		if (pte_none(*buddy)) {
-			if (!config_enabled(CONFIG_XPA))
+			if (!IS_ENABLED(CONFIG_XPA))
 				buddy->pte_low |= _PAGE_GLOBAL;
 			buddy->pte_high |= _PAGE_GLOBAL;
 		}
@@ -172,7 +172,7 @@ static inline void pte_clear(struct mm_struct *mm, unsigned long addr, pte_t *pt
 
 	htw_stop();
 	/* Preserve global status for the pair */
-	if (config_enabled(CONFIG_XPA)) {
+	if (IS_ENABLED(CONFIG_XPA)) {
 		if (ptep_buddy(ptep)->pte_high & _PAGE_GLOBAL)
 			null.pte_high = _PAGE_GLOBAL;
 	} else {
@@ -319,7 +319,7 @@ static inline int pte_young(pte_t pte)	{ return pte.pte_low & _PAGE_ACCESSED; }
 static inline pte_t pte_wrprotect(pte_t pte)
 {
 	pte.pte_low  &= ~_PAGE_WRITE;
-	if (!config_enabled(CONFIG_XPA))
+	if (!IS_ENABLED(CONFIG_XPA))
 		pte.pte_low &= ~_PAGE_SILENT_WRITE;
 	pte.pte_high &= ~_PAGE_SILENT_WRITE;
 	return pte;
@@ -328,7 +328,7 @@ static inline pte_t pte_wrprotect(pte_t pte)
 static inline pte_t pte_mkclean(pte_t pte)
 {
 	pte.pte_low  &= ~_PAGE_MODIFIED;
-	if (!config_enabled(CONFIG_XPA))
+	if (!IS_ENABLED(CONFIG_XPA))
 		pte.pte_low &= ~_PAGE_SILENT_WRITE;
 	pte.pte_high &= ~_PAGE_SILENT_WRITE;
 	return pte;
@@ -337,7 +337,7 @@ static inline pte_t pte_mkclean(pte_t pte)
 static inline pte_t pte_mkold(pte_t pte)
 {
 	pte.pte_low  &= ~_PAGE_ACCESSED;
-	if (!config_enabled(CONFIG_XPA))
+	if (!IS_ENABLED(CONFIG_XPA))
 		pte.pte_low &= ~_PAGE_SILENT_READ;
 	pte.pte_high &= ~_PAGE_SILENT_READ;
 	return pte;
@@ -347,7 +347,7 @@ static inline pte_t pte_mkwrite(pte_t pte)
 {
 	pte.pte_low |= _PAGE_WRITE;
 	if (pte.pte_low & _PAGE_MODIFIED) {
-		if (!config_enabled(CONFIG_XPA))
+		if (!IS_ENABLED(CONFIG_XPA))
 			pte.pte_low |= _PAGE_SILENT_WRITE;
 		pte.pte_high |= _PAGE_SILENT_WRITE;
 	}
@@ -358,7 +358,7 @@ static inline pte_t pte_mkdirty(pte_t pte)
 {
 	pte.pte_low |= _PAGE_MODIFIED;
 	if (pte.pte_low & _PAGE_WRITE) {
-		if (!config_enabled(CONFIG_XPA))
+		if (!IS_ENABLED(CONFIG_XPA))
 			pte.pte_low |= _PAGE_SILENT_WRITE;
 		pte.pte_high |= _PAGE_SILENT_WRITE;
 	}
@@ -369,7 +369,7 @@ static inline pte_t pte_mkyoung(pte_t pte)
 {
 	pte.pte_low |= _PAGE_ACCESSED;
 	if (!(pte.pte_low & _PAGE_NO_READ)) {
-		if (!config_enabled(CONFIG_XPA))
+		if (!IS_ENABLED(CONFIG_XPA))
 			pte.pte_low |= _PAGE_SILENT_READ;
 		pte.pte_high |= _PAGE_SILENT_READ;
 	}
diff --git a/arch/mips/include/asm/seccomp.h b/arch/mips/include/asm/seccomp.h
index 684fb3a..d886d6f 100644
--- a/arch/mips/include/asm/seccomp.h
+++ b/arch/mips/include/asm/seccomp.h
@@ -16,10 +16,10 @@ static inline const int *get_compat_mode1_syscalls(void)
 		0, /* null terminated */
 	};
 
-	if (config_enabled(CONFIG_MIPS32_O32) && test_thread_flag(TIF_32BIT_REGS))
+	if (IS_ENABLED(CONFIG_MIPS32_O32) && test_thread_flag(TIF_32BIT_REGS))
 		return syscalls_O32;
 
-	if (config_enabled(CONFIG_MIPS32_N32))
+	if (IS_ENABLED(CONFIG_MIPS32_N32))
 		return syscalls_N32;
 
 	BUG();
diff --git a/arch/mips/include/asm/signal.h b/arch/mips/include/asm/signal.h
index 2292373..82eae15 100644
--- a/arch/mips/include/asm/signal.h
+++ b/arch/mips/include/asm/signal.h
@@ -19,8 +19,8 @@ extern struct mips_abi mips_abi_32;
 		((ka)->sa.sa_flags & SA_SIGINFO))
 #else
 #define sig_uses_siginfo(ka, abi)                               \
-	(config_enabled(CONFIG_64BIT) ? 1 :                     \
-		(config_enabled(CONFIG_TRAD_SIGNALS) ?          \
+	(IS_ENABLED(CONFIG_64BIT) ? 1 :                     \
+		(IS_ENABLED(CONFIG_TRAD_SIGNALS) ?          \
 			((ka)->sa.sa_flags & SA_SIGINFO) : 1) )
 #endif
 
diff --git a/arch/mips/include/asm/syscall.h b/arch/mips/include/asm/syscall.h
index 47bc45a..d878825 100644
--- a/arch/mips/include/asm/syscall.h
+++ b/arch/mips/include/asm/syscall.h
@@ -99,7 +99,7 @@ static inline void syscall_get_arguments(struct task_struct *task,
 {
 	int ret;
 	/* O32 ABI syscall() - Either 64-bit with O32 or 32-bit */
-	if ((config_enabled(CONFIG_32BIT) ||
+	if ((IS_ENABLED(CONFIG_32BIT) ||
 	    test_tsk_thread_flag(task, TIF_32BIT_REGS)) &&
 	    (regs->regs[2] == __NR_syscall))
 		i++;
diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h
index 7f109d4..11b965f 100644
--- a/arch/mips/include/asm/uaccess.h
+++ b/arch/mips/include/asm/uaccess.h
@@ -88,7 +88,7 @@ extern u64 __ua_limit;
  */
 static inline bool eva_kernel_access(void)
 {
-	if (!config_enabled(CONFIG_EVA))
+	if (!IS_ENABLED(CONFIG_EVA))
 		return false;
 
 	return segment_eq(get_fs(), get_ds());
diff --git a/arch/mips/jz4740/setup.c b/arch/mips/jz4740/setup.c
index 510fc0d..e53f90b 100644
--- a/arch/mips/jz4740/setup.c
+++ b/arch/mips/jz4740/setup.c
@@ -83,7 +83,7 @@ arch_initcall(populate_machine);
 
 const char *get_system_type(void)
 {
-	if (config_enabled(CONFIG_MACH_JZ4780))
+	if (IS_ENABLED(CONFIG_MACH_JZ4780))
 		return "JZ4780";
 
 	return "JZ4740";
diff --git a/arch/mips/kernel/cpu-bugs64.c b/arch/mips/kernel/cpu-bugs64.c
index 6392dbe..a378e44 100644
--- a/arch/mips/kernel/cpu-bugs64.c
+++ b/arch/mips/kernel/cpu-bugs64.c
@@ -244,7 +244,7 @@ static inline void check_daddi(void)
 	panic(bug64hit, !DADDI_WAR ? daddiwar : nowar);
 }
 
-int daddiu_bug	= config_enabled(CONFIG_CPU_MIPSR6) ? 0 : -1;
+int daddiu_bug	= IS_ENABLED(CONFIG_CPU_MIPSR6) ? 0 : -1;
 
 static inline void check_daddiu(void)
 {
@@ -314,7 +314,7 @@ static inline void check_daddiu(void)
 
 void __init check_bugs64_early(void)
 {
-	if (!config_enabled(CONFIG_CPU_MIPSR6)) {
+	if (!IS_ENABLED(CONFIG_CPU_MIPSR6)) {
 		check_mult_sh();
 		check_daddiu();
 	}
@@ -322,6 +322,6 @@ void __init check_bugs64_early(void)
 
 void __init check_bugs64(void)
 {
-	if (!config_enabled(CONFIG_CPU_MIPSR6))
+	if (!IS_ENABLED(CONFIG_CPU_MIPSR6))
 		check_daddi();
 }
diff --git a/arch/mips/kernel/elf.c b/arch/mips/kernel/elf.c
index 891f5ee..e6eb7f1 100644
--- a/arch/mips/kernel/elf.c
+++ b/arch/mips/kernel/elf.c
@@ -179,7 +179,7 @@ int arch_check_elf(void *_ehdr, bool has_interpreter, void *_interp_ehdr,
 			return -ELIBBAD;
 	}
 
-	if (!config_enabled(CONFIG_MIPS_O32_FP64_SUPPORT))
+	if (!IS_ENABLED(CONFIG_MIPS_O32_FP64_SUPPORT))
 		return 0;
 
 	fp_abi = state->fp_abi;
@@ -285,7 +285,7 @@ void mips_set_personality_fp(struct arch_elf_state *state)
 	 * not be worried about N32/N64 binaries.
 	 */
 
-	if (!config_enabled(CONFIG_MIPS_O32_FP64_SUPPORT))
+	if (!IS_ENABLED(CONFIG_MIPS_O32_FP64_SUPPORT))
 		return;
 
 	switch (state->overall_fp_mode) {
diff --git a/arch/mips/kernel/mips-cm.c b/arch/mips/kernel/mips-cm.c
index 760217b..659e6d3 100644
--- a/arch/mips/kernel/mips-cm.c
+++ b/arch/mips/kernel/mips-cm.c
@@ -251,7 +251,7 @@ int mips_cm_probe(void)
 	mips_cm_probe_l2sync();
 
 	/* determine register width for this CM */
-	mips_cm_is64 = config_enabled(CONFIG_64BIT) && (mips_cm_revision() >= CM_REV_CM3);
+	mips_cm_is64 = IS_ENABLED(CONFIG_64BIT) && (mips_cm_revision() >= CM_REV_CM3);
 
 	for_each_possible_cpu(cpu)
 		spin_lock_init(&per_cpu(cm_core_lock, cpu));
diff --git a/arch/mips/kernel/mips-r2-to-r6-emul.c b/arch/mips/kernel/mips-r2-to-r6-emul.c
index 7ff2a55..43fbadc 100644
--- a/arch/mips/kernel/mips-r2-to-r6-emul.c
+++ b/arch/mips/kernel/mips-r2-to-r6-emul.c
@@ -84,7 +84,7 @@ static inline int mipsr6_emul(struct pt_regs *regs, u32 ir)
 				(s32)MIPSInst_SIMM(ir);
 		return 0;
 	case daddiu_op:
-		if (config_enabled(CONFIG_32BIT))
+		if (IS_ENABLED(CONFIG_32BIT))
 			break;
 
 		if (MIPSInst_RT(ir))
@@ -143,7 +143,7 @@ static inline int mipsr6_emul(struct pt_regs *regs, u32 ir)
 					      (u32)regs->regs[MIPSInst_RT(ir)]);
 			return 0;
 		case dsll_op:
-			if (config_enabled(CONFIG_32BIT) || MIPSInst_RS(ir))
+			if (IS_ENABLED(CONFIG_32BIT) || MIPSInst_RS(ir))
 				break;
 
 			if (MIPSInst_RD(ir))
@@ -152,7 +152,7 @@ static inline int mipsr6_emul(struct pt_regs *regs, u32 ir)
 						MIPSInst_FD(ir));
 			return 0;
 		case dsrl_op:
-			if (config_enabled(CONFIG_32BIT) || MIPSInst_RS(ir))
+			if (IS_ENABLED(CONFIG_32BIT) || MIPSInst_RS(ir))
 				break;
 
 			if (MIPSInst_RD(ir))
@@ -161,7 +161,7 @@ static inline int mipsr6_emul(struct pt_regs *regs, u32 ir)
 						MIPSInst_FD(ir));
 			return 0;
 		case daddu_op:
-			if (config_enabled(CONFIG_32BIT) || MIPSInst_FD(ir))
+			if (IS_ENABLED(CONFIG_32BIT) || MIPSInst_FD(ir))
 				break;
 
 			if (MIPSInst_RD(ir))
@@ -170,7 +170,7 @@ static inline int mipsr6_emul(struct pt_regs *regs, u32 ir)
 					(u64)regs->regs[MIPSInst_RT(ir)];
 			return 0;
 		case dsubu_op:
-			if (config_enabled(CONFIG_32BIT) || MIPSInst_FD(ir))
+			if (IS_ENABLED(CONFIG_32BIT) || MIPSInst_FD(ir))
 				break;
 
 			if (MIPSInst_RD(ir))
@@ -498,7 +498,7 @@ static int dmult_func(struct pt_regs *regs, u32 ir)
 	s64 res;
 	s64 rt, rs;
 
-	if (config_enabled(CONFIG_32BIT))
+	if (IS_ENABLED(CONFIG_32BIT))
 		return SIGILL;
 
 	rt = regs->regs[MIPSInst_RT(ir)];
@@ -530,7 +530,7 @@ static int dmultu_func(struct pt_regs *regs, u32 ir)
 	u64 res;
 	u64 rt, rs;
 
-	if (config_enabled(CONFIG_32BIT))
+	if (IS_ENABLED(CONFIG_32BIT))
 		return SIGILL;
 
 	rt = regs->regs[MIPSInst_RT(ir)];
@@ -561,7 +561,7 @@ static int ddiv_func(struct pt_regs *regs, u32 ir)
 {
 	s64 rt, rs;
 
-	if (config_enabled(CONFIG_32BIT))
+	if (IS_ENABLED(CONFIG_32BIT))
 		return SIGILL;
 
 	rt = regs->regs[MIPSInst_RT(ir)];
@@ -586,7 +586,7 @@ static int ddivu_func(struct pt_regs *regs, u32 ir)
 {
 	u64 rt, rs;
 
-	if (config_enabled(CONFIG_32BIT))
+	if (IS_ENABLED(CONFIG_32BIT))
 		return SIGILL;
 
 	rt = regs->regs[MIPSInst_RT(ir)];
@@ -825,7 +825,7 @@ static int dclz_func(struct pt_regs *regs, u32 ir)
 	u64 res;
 	u64 rs;
 
-	if (config_enabled(CONFIG_32BIT))
+	if (IS_ENABLED(CONFIG_32BIT))
 		return SIGILL;
 
 	if (!MIPSInst_RD(ir))
@@ -852,7 +852,7 @@ static int dclo_func(struct pt_regs *regs, u32 ir)
 	u64 res;
 	u64 rs;
 
-	if (config_enabled(CONFIG_32BIT))
+	if (IS_ENABLED(CONFIG_32BIT))
 		return SIGILL;
 
 	if (!MIPSInst_RD(ir))
@@ -1484,7 +1484,7 @@ fpu_emul:
 		break;
 
 	case ldl_op:
-		if (config_enabled(CONFIG_32BIT)) {
+		if (IS_ENABLED(CONFIG_32BIT)) {
 		    err = SIGILL;
 		    break;
 		}
@@ -1603,7 +1603,7 @@ fpu_emul:
 		break;
 
 	case ldr_op:
-		if (config_enabled(CONFIG_32BIT)) {
+		if (IS_ENABLED(CONFIG_32BIT)) {
 		    err = SIGILL;
 		    break;
 		}
@@ -1722,7 +1722,7 @@ fpu_emul:
 		break;
 
 	case sdl_op:
-		if (config_enabled(CONFIG_32BIT)) {
+		if (IS_ENABLED(CONFIG_32BIT)) {
 		    err = SIGILL;
 		    break;
 		}
@@ -1840,7 +1840,7 @@ fpu_emul:
 		break;
 
 	case sdr_op:
-		if (config_enabled(CONFIG_32BIT)) {
+		if (IS_ENABLED(CONFIG_32BIT)) {
 		    err = SIGILL;
 		    break;
 		}
@@ -2072,7 +2072,7 @@ fpu_emul:
 		break;
 
 	case lld_op:
-		if (config_enabled(CONFIG_32BIT)) {
+		if (IS_ENABLED(CONFIG_32BIT)) {
 		    err = SIGILL;
 		    break;
 		}
@@ -2133,7 +2133,7 @@ fpu_emul:
 		break;
 
 	case scd_op:
-		if (config_enabled(CONFIG_32BIT)) {
+		if (IS_ENABLED(CONFIG_32BIT)) {
 		    err = SIGILL;
 		    break;
 		}
diff --git a/arch/mips/kernel/pm-cps.c b/arch/mips/kernel/pm-cps.c
index adda3ff..5b31a94 100644
--- a/arch/mips/kernel/pm-cps.c
+++ b/arch/mips/kernel/pm-cps.c
@@ -148,7 +148,7 @@ int cps_pm_enter_state(enum cps_pm_state state)
 	}
 
 	/* Setup the VPE to run mips_cps_pm_restore when started again */
-	if (config_enabled(CONFIG_CPU_PM) && state == CPS_PM_POWER_GATED) {
+	if (IS_ENABLED(CONFIG_CPU_PM) && state == CPS_PM_POWER_GATED) {
 		/* Power gating relies upon CPS SMP */
 		if (!mips_cps_smp_in_use())
 			return -EINVAL;
@@ -387,7 +387,7 @@ static void * __init cps_gen_entry_code(unsigned cpu, enum cps_pm_state state)
 	memset(labels, 0, sizeof(labels));
 	memset(relocs, 0, sizeof(relocs));
 
-	if (config_enabled(CONFIG_CPU_PM) && state == CPS_PM_POWER_GATED) {
+	if (IS_ENABLED(CONFIG_CPU_PM) && state == CPS_PM_POWER_GATED) {
 		/* Power gating relies upon CPS SMP */
 		if (!mips_cps_smp_in_use())
 			goto out_err;
diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c
index ae42314..1975cd2 100644
--- a/arch/mips/kernel/signal.c
+++ b/arch/mips/kernel/signal.c
@@ -165,7 +165,7 @@ static int save_msa_extcontext(void __user *buf)
 		 * should already have been done when handling scalar FP
 		 * context.
 		 */
-		BUG_ON(config_enabled(CONFIG_EVA));
+		BUG_ON(IS_ENABLED(CONFIG_EVA));
 
 		err = __put_user(read_msa_csr(), &msa->csr);
 		err |= _save_msa_all_upper(&msa->wr);
@@ -195,7 +195,7 @@ static int restore_msa_extcontext(void __user *buf, unsigned int size)
 	unsigned int csr;
 	int i, err;
 
-	if (!config_enabled(CONFIG_CPU_HAS_MSA))
+	if (!IS_ENABLED(CONFIG_CPU_HAS_MSA))
 		return SIGSYS;
 
 	if (size != sizeof(*msa))
@@ -215,7 +215,7 @@ static int restore_msa_extcontext(void __user *buf, unsigned int size)
 		 * scalar FP context, so FPU & MSA should have already been
 		 * disabled whilst handling scalar FP context.
 		 */
-		BUG_ON(config_enabled(CONFIG_EVA));
+		BUG_ON(IS_ENABLED(CONFIG_EVA));
 
 		write_msa_csr(csr);
 		err |= _restore_msa_all_upper(&msa->wr);
@@ -315,7 +315,7 @@ int protected_save_fp_context(void __user *sc)
 	 * EVA does not have userland equivalents of ldc1 or sdc1, so
 	 * save to the kernel FP context & copy that to userland below.
 	 */
-	if (config_enabled(CONFIG_EVA))
+	if (IS_ENABLED(CONFIG_EVA))
 		lose_fpu(1);
 
 	while (1) {
@@ -378,7 +378,7 @@ int protected_restore_fp_context(void __user *sc)
 	 * disable the FPU here such that the code below simply copies to
 	 * the kernel FP context.
 	 */
-	if (config_enabled(CONFIG_EVA))
+	if (IS_ENABLED(CONFIG_EVA))
 		lose_fpu(0);
 
 	while (1) {
diff --git a/arch/mips/kernel/smp-cps.c b/arch/mips/kernel/smp-cps.c
index 4ed36f2..05b3201 100644
--- a/arch/mips/kernel/smp-cps.c
+++ b/arch/mips/kernel/smp-cps.c
@@ -46,8 +46,8 @@ static unsigned core_vpe_count(unsigned core)
 	if (threads_disabled)
 		return 1;
 
-	if ((!config_enabled(CONFIG_MIPS_MT_SMP) || !cpu_has_mipsmt)
-		&& (!config_enabled(CONFIG_CPU_MIPSR6) || !cpu_has_vp))
+	if ((!IS_ENABLED(CONFIG_MIPS_MT_SMP) || !cpu_has_mipsmt)
+		&& (!IS_ENABLED(CONFIG_CPU_MIPSR6) || !cpu_has_vp))
 		return 1;
 
 	mips_cm_lock_other(core, 0);
diff --git a/arch/mips/kernel/unaligned.c b/arch/mips/kernel/unaligned.c
index 28b3af7..f1c308d 100644
--- a/arch/mips/kernel/unaligned.c
+++ b/arch/mips/kernel/unaligned.c
@@ -1025,7 +1025,7 @@ static void emulate_load_store_insn(struct pt_regs *regs,
 		if (!access_ok(VERIFY_READ, addr, 2))
 			goto sigbus;
 
-		if (config_enabled(CONFIG_EVA)) {
+		if (IS_ENABLED(CONFIG_EVA)) {
 			if (segment_eq(get_fs(), get_ds()))
 				LoadHW(addr, value, res);
 			else
@@ -1044,7 +1044,7 @@ static void emulate_load_store_insn(struct pt_regs *regs,
 		if (!access_ok(VERIFY_READ, addr, 4))
 			goto sigbus;
 
-		if (config_enabled(CONFIG_EVA)) {
+		if (IS_ENABLED(CONFIG_EVA)) {
 			if (segment_eq(get_fs(), get_ds()))
 				LoadW(addr, value, res);
 			else
@@ -1063,7 +1063,7 @@ static void emulate_load_store_insn(struct pt_regs *regs,
 		if (!access_ok(VERIFY_READ, addr, 2))
 			goto sigbus;
 
-		if (config_enabled(CONFIG_EVA)) {
+		if (IS_ENABLED(CONFIG_EVA)) {
 			if (segment_eq(get_fs(), get_ds()))
 				LoadHWU(addr, value, res);
 			else
@@ -1131,7 +1131,7 @@ static void emulate_load_store_insn(struct pt_regs *regs,
 		compute_return_epc(regs);
 		value = regs->regs[insn.i_format.rt];
 
-		if (config_enabled(CONFIG_EVA)) {
+		if (IS_ENABLED(CONFIG_EVA)) {
 			if (segment_eq(get_fs(), get_ds()))
 				StoreHW(addr, value, res);
 			else
@@ -1151,7 +1151,7 @@ static void emulate_load_store_insn(struct pt_regs *regs,
 		compute_return_epc(regs);
 		value = regs->regs[insn.i_format.rt];
 
-		if (config_enabled(CONFIG_EVA)) {
+		if (IS_ENABLED(CONFIG_EVA)) {
 			if (segment_eq(get_fs(), get_ds()))
 				StoreW(addr, value, res);
 			else
diff --git a/arch/mips/math-emu/cp1emu.c b/arch/mips/math-emu/cp1emu.c
index d96e912..5dd3c59 100644
--- a/arch/mips/math-emu/cp1emu.c
+++ b/arch/mips/math-emu/cp1emu.c
@@ -784,10 +784,10 @@ static int isBranchInstr(struct pt_regs *regs, struct mm_decoded_insn dec_insn,
  */
 static inline int cop1_64bit(struct pt_regs *xcp)
 {
-	if (config_enabled(CONFIG_64BIT) && !config_enabled(CONFIG_MIPS32_O32))
+	if (IS_ENABLED(CONFIG_64BIT) && !IS_ENABLED(CONFIG_MIPS32_O32))
 		return 1;
-	else if (config_enabled(CONFIG_32BIT) &&
-		 !config_enabled(CONFIG_MIPS_O32_FP64_SUPPORT))
+	else if (IS_ENABLED(CONFIG_32BIT) &&
+		 !IS_ENABLED(CONFIG_MIPS_O32_FP64_SUPPORT))
 		return 0;
 
 	return !test_thread_flag(TIF_32BIT_FPREGS);
diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
index 4004b65..ff49b29 100644
--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -1025,7 +1025,7 @@ static void build_update_entries(u32 **p, unsigned int tmp, unsigned int ptep)
 	pte_off_odd += offsetof(pte_t, pte_high);
 #endif
 
-	if (config_enabled(CONFIG_XPA)) {
+	if (IS_ENABLED(CONFIG_XPA)) {
 		uasm_i_lw(p, tmp, pte_off_even, ptep); /* even pte */
 		UASM_i_ROTR(p, tmp, tmp, ilog2(_PAGE_GLOBAL));
 		UASM_i_MTC0(p, tmp, C0_ENTRYLO0);
@@ -1643,7 +1643,7 @@ iPTE_SW(u32 **p, struct uasm_reloc **r, unsigned int pte, unsigned int ptr,
 	unsigned int hwmode = mode & (_PAGE_VALID | _PAGE_DIRTY);
 	unsigned int swmode = mode & ~hwmode;
 
-	if (config_enabled(CONFIG_XPA) && !cpu_has_64bits) {
+	if (IS_ENABLED(CONFIG_XPA) && !cpu_has_64bits) {
 		uasm_i_lui(p, scratch, swmode >> 16);
 		uasm_i_or(p, pte, pte, scratch);
 		BUG_ON(swmode & 0xffff);
@@ -2432,7 +2432,7 @@ static void config_htw_params(void)
 		pwsize |= ilog2(PTRS_PER_PMD) << MIPS_PWSIZE_MDW_SHIFT;
 
 	/* Set pointer size to size of directory pointers */
-	if (config_enabled(CONFIG_64BIT))
+	if (IS_ENABLED(CONFIG_64BIT))
 		pwsize |= MIPS_PWSIZE_PS_MASK;
 	/* PTEs may be multiple pointers long (e.g. with XPA) */
 	pwsize |= ((PTE_T_LOG2 - PGD_T_LOG2) << MIPS_PWSIZE_PTEW_SHIFT)
@@ -2448,7 +2448,7 @@ static void config_htw_params(void)
 	 * the pwctl fields.
 	 */
 	config = 1 << MIPS_PWCTL_PWEN_SHIFT;
-	if (config_enabled(CONFIG_64BIT))
+	if (IS_ENABLED(CONFIG_64BIT))
 		config |= MIPS_PWCTL_XU_MASK;
 	write_c0_pwctl(config);
 	pr_info("Hardware Page Table Walker enabled\n");
@@ -2522,7 +2522,7 @@ void build_tlb_refill_handler(void)
 	 */
 	static int run_once = 0;
 
-	if (config_enabled(CONFIG_XPA) && !cpu_has_rixi)
+	if (IS_ENABLED(CONFIG_XPA) && !cpu_has_rixi)
 		panic("Kernels supporting XPA currently require CPUs with RIXI");
 
 	output_pgtable_bits_defines();
diff --git a/arch/mips/mti-malta/malta-dtshim.c b/arch/mips/mti-malta/malta-dtshim.c
index f7133ef..151f488 100644
--- a/arch/mips/mti-malta/malta-dtshim.c
+++ b/arch/mips/mti-malta/malta-dtshim.c
@@ -31,7 +31,7 @@ static unsigned __init gen_fdt_mem_array(__be32 *mem_array, unsigned long size)
 
 	entries = 1;
 	mem_array[0] = cpu_to_be32(PHYS_OFFSET);
-	if (config_enabled(CONFIG_EVA)) {
+	if (IS_ENABLED(CONFIG_EVA)) {
 		/*
 		 * The current Malta EVA configuration is "special" in that it
 		 * always makes use of addresses in the upper half of the 32 bit
@@ -82,7 +82,7 @@ static void __init append_memory(void *fdt, int root_off)
 		physical_memsize = 32 << 20;
 	}
 
-	if (config_enabled(CONFIG_CPU_BIG_ENDIAN)) {
+	if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN)) {
 		/*
 		 * SOC-it swaps, or perhaps doesn't swap, when DMA'ing
 		 * the last word of physical memory.
diff --git a/arch/mips/mti-malta/malta-memory.c b/arch/mips/mti-malta/malta-memory.c
index d5f8dae..a475567 100644
--- a/arch/mips/mti-malta/malta-memory.c
+++ b/arch/mips/mti-malta/malta-memory.c
@@ -32,7 +32,7 @@ static void free_init_pages_eva_malta(void *begin, void *end)
 
 void __init fw_meminit(void)
 {
-	bool eva = config_enabled(CONFIG_EVA);
+	bool eva = IS_ENABLED(CONFIG_EVA);
 
 	free_init_pages_eva = eva ? free_init_pages_eva_malta : NULL;
 }
diff --git a/arch/mips/mti-malta/malta-setup.c b/arch/mips/mti-malta/malta-setup.c
index 33d5ff5..ec5b216 100644
--- a/arch/mips/mti-malta/malta-setup.c
+++ b/arch/mips/mti-malta/malta-setup.c
@@ -261,7 +261,7 @@ void __init plat_mem_setup(void)
 	fdt = malta_dt_shim(fdt);
 	__dt_setup_arch(fdt);
 
-	if (config_enabled(CONFIG_EVA))
+	if (IS_ENABLED(CONFIG_EVA))
 		/* EVA has already been configured in mach-malta/kernel-init.h */
 		pr_info("Enhanced Virtual Addressing (EVA) activated\n");
 
diff --git a/arch/mips/net/bpf_jit.c b/arch/mips/net/bpf_jit.c
index 1a8c960..d1b7bd0 100644
--- a/arch/mips/net/bpf_jit.c
+++ b/arch/mips/net/bpf_jit.c
@@ -426,7 +426,7 @@ static inline void emit_load_ptr(unsigned int dst, unsigned int src,
 static inline void emit_load_func(unsigned int reg, ptr imm,
 				  struct jit_ctx *ctx)
 {
-	if (config_enabled(CONFIG_64BIT)) {
+	if (IS_ENABLED(CONFIG_64BIT)) {
 		/* At this point imm is always 64-bit */
 		emit_load_imm(r_tmp, (u64)imm >> 32, ctx);
 		emit_dsll(r_tmp_imm, r_tmp, 16, ctx); /* left shift by 16 */
@@ -516,7 +516,7 @@ static inline void emit_jr(unsigned int reg, struct jit_ctx *ctx)
 static inline u16 align_sp(unsigned int num)
 {
 	/* Double word alignment for 32-bit, quadword for 64-bit */
-	unsigned int align = config_enabled(CONFIG_64BIT) ? 16 : 8;
+	unsigned int align = IS_ENABLED(CONFIG_64BIT) ? 16 : 8;
 	num = (num + (align - 1)) & -align;
 	return num;
 }
diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index fea7724..e7f155c 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -344,8 +344,8 @@ extern int compat_arch_setup_additional_pages(struct linux_binprm *bprm,
  */
 static inline int mmap_is_ia32(void)
 {
-	return config_enabled(CONFIG_X86_32) ||
-	       (config_enabled(CONFIG_COMPAT) &&
+	return IS_ENABLED(CONFIG_X86_32) ||
+	       (IS_ENABLED(CONFIG_COMPAT) &&
 		test_thread_flag(TIF_ADDR32));
 }
 
diff --git a/arch/x86/include/asm/fpu/internal.h b/arch/x86/include/asm/fpu/internal.h
index 31ac8e6..a9ef2b6 100644
--- a/arch/x86/include/asm/fpu/internal.h
+++ b/arch/x86/include/asm/fpu/internal.h
@@ -136,9 +136,9 @@ static inline int copy_fregs_to_user(struct fregs_state __user *fx)
 
 static inline int copy_fxregs_to_user(struct fxregs_state __user *fx)
 {
-	if (config_enabled(CONFIG_X86_32))
+	if (IS_ENABLED(CONFIG_X86_32))
 		return user_insn(fxsave %[fx], [fx] "=m" (*fx), "m" (*fx));
-	else if (config_enabled(CONFIG_AS_FXSAVEQ))
+	else if (IS_ENABLED(CONFIG_AS_FXSAVEQ))
 		return user_insn(fxsaveq %[fx], [fx] "=m" (*fx), "m" (*fx));
 
 	/* See comment in copy_fxregs_to_kernel() below. */
@@ -149,10 +149,10 @@ static inline void copy_kernel_to_fxregs(struct fxregs_state *fx)
 {
 	int err;
 
-	if (config_enabled(CONFIG_X86_32)) {
+	if (IS_ENABLED(CONFIG_X86_32)) {
 		err = check_insn(fxrstor %[fx], "=m" (*fx), [fx] "m" (*fx));
 	} else {
-		if (config_enabled(CONFIG_AS_FXSAVEQ)) {
+		if (IS_ENABLED(CONFIG_AS_FXSAVEQ)) {
 			err = check_insn(fxrstorq %[fx], "=m" (*fx), [fx] "m" (*fx));
 		} else {
 			/* See comment in copy_fxregs_to_kernel() below. */
@@ -165,9 +165,9 @@ static inline void copy_kernel_to_fxregs(struct fxregs_state *fx)
 
 static inline int copy_user_to_fxregs(struct fxregs_state __user *fx)
 {
-	if (config_enabled(CONFIG_X86_32))
+	if (IS_ENABLED(CONFIG_X86_32))
 		return user_insn(fxrstor %[fx], "=m" (*fx), [fx] "m" (*fx));
-	else if (config_enabled(CONFIG_AS_FXSAVEQ))
+	else if (IS_ENABLED(CONFIG_AS_FXSAVEQ))
 		return user_insn(fxrstorq %[fx], "=m" (*fx), [fx] "m" (*fx));
 
 	/* See comment in copy_fxregs_to_kernel() below. */
@@ -189,9 +189,9 @@ static inline int copy_user_to_fregs(struct fregs_state __user *fx)
 
 static inline void copy_fxregs_to_kernel(struct fpu *fpu)
 {
-	if (config_enabled(CONFIG_X86_32))
+	if (IS_ENABLED(CONFIG_X86_32))
 		asm volatile( "fxsave %[fx]" : [fx] "=m" (fpu->state.fxsave));
-	else if (config_enabled(CONFIG_AS_FXSAVEQ))
+	else if (IS_ENABLED(CONFIG_AS_FXSAVEQ))
 		asm volatile("fxsaveq %[fx]" : [fx] "=m" (fpu->state.fxsave));
 	else {
 		/* Using "rex64; fxsave %0" is broken because, if the memory
diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
index 39634819..d8abfcf 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -155,7 +155,7 @@ static inline void arch_exit_mmap(struct mm_struct *mm)
 #ifdef CONFIG_X86_64
 static inline bool is_64bit_mm(struct mm_struct *mm)
 {
-	return	!config_enabled(CONFIG_IA32_EMULATION) ||
+	return	!IS_ENABLED(CONFIG_IA32_EMULATION) ||
 		!(mm->context.ia32_compat == TIF_IA32);
 }
 #else
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 60078a6..529e165 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -145,7 +145,7 @@ static int force_enable_local_apic __initdata;
  */
 static int __init parse_lapic(char *arg)
 {
-	if (config_enabled(CONFIG_X86_32) && !arg)
+	if (IS_ENABLED(CONFIG_X86_32) && !arg)
 		force_enable_local_apic = 1;
 	else if (arg && !strncmp(arg, "notscdeadline", 13))
 		setup_clear_cpu_cap(X86_FEATURE_TSC_DEADLINE_TIMER);
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index a5e400a..6066d94 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -523,7 +523,7 @@ static int apic_set_affinity(struct irq_data *irq_data,
 	struct apic_chip_data *data = irq_data->chip_data;
 	int err, irq = irq_data->irq;
 
-	if (!config_enabled(CONFIG_SMP))
+	if (!IS_ENABLED(CONFIG_SMP))
 		return -EPERM;
 
 	if (!cpumask_intersects(dest, cpu_online_mask))
diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
index 31c6a60..466b801 100644
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@ -156,8 +156,8 @@ int copy_fpstate_to_sigframe(void __user *buf, void __user *buf_fx, int size)
 	struct task_struct *tsk = current;
 	int ia32_fxstate = (buf != buf_fx);
 
-	ia32_fxstate &= (config_enabled(CONFIG_X86_32) ||
-			 config_enabled(CONFIG_IA32_EMULATION));
+	ia32_fxstate &= (IS_ENABLED(CONFIG_X86_32) ||
+			 IS_ENABLED(CONFIG_IA32_EMULATION));
 
 	if (!access_ok(VERIFY_WRITE, buf, size))
 		return -EACCES;
@@ -254,8 +254,8 @@ static int __fpu__restore_sig(void __user *buf, void __user *buf_fx, int size)
 	u64 xfeatures = 0;
 	int fx_only = 0;
 
-	ia32_fxstate &= (config_enabled(CONFIG_X86_32) ||
-			 config_enabled(CONFIG_IA32_EMULATION));
+	ia32_fxstate &= (IS_ENABLED(CONFIG_X86_32) ||
+			 IS_ENABLED(CONFIG_IA32_EMULATION));
 
 	if (!buf) {
 		fpu__clear(fpu);
@@ -392,8 +392,8 @@ void fpu__init_prepare_fx_sw_frame(void)
 	fx_sw_reserved.xfeatures = xfeatures_mask;
 	fx_sw_reserved.xstate_size = xstate_size;
 
-	if (config_enabled(CONFIG_IA32_EMULATION) ||
-	    config_enabled(CONFIG_X86_32)) {
+	if (IS_ENABLED(CONFIG_IA32_EMULATION) ||
+	    IS_ENABLED(CONFIG_X86_32)) {
 		int fsave_header_size = sizeof(struct fregs_state);
 
 		fx_sw_reserved_ia32 = fx_sw_reserved;
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index 22cc2f9..99f285b 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -146,7 +146,7 @@ static int restore_sigcontext(struct pt_regs *regs,
 		buf = (void __user *)buf_val;
 	} get_user_catch(err);
 
-	err |= fpu__restore_sig(buf, config_enabled(CONFIG_X86_32));
+	err |= fpu__restore_sig(buf, IS_ENABLED(CONFIG_X86_32));
 
 	force_iret();
 
@@ -245,14 +245,14 @@ get_sigframe(struct k_sigaction *ka, struct pt_regs *regs, size_t frame_size,
 	struct fpu *fpu = &current->thread.fpu;
 
 	/* redzone */
-	if (config_enabled(CONFIG_X86_64))
+	if (IS_ENABLED(CONFIG_X86_64))
 		sp -= 128;
 
 	/* This is the X/Open sanctioned signal stack switching.  */
 	if (ka->sa.sa_flags & SA_ONSTACK) {
 		if (sas_ss_flags(sp) == 0)
 			sp = current->sas_ss_sp + current->sas_ss_size;
-	} else if (config_enabled(CONFIG_X86_32) &&
+	} else if (IS_ENABLED(CONFIG_X86_32) &&
 		   !onsigstack &&
 		   (regs->ss & 0xffff) != __USER_DS &&
 		   !(ka->sa.sa_flags & SA_RESTORER) &&
@@ -262,7 +262,7 @@ get_sigframe(struct k_sigaction *ka, struct pt_regs *regs, size_t frame_size,
 	}
 
 	if (fpu->fpstate_active) {
-		sp = fpu__alloc_mathframe(sp, config_enabled(CONFIG_X86_32),
+		sp = fpu__alloc_mathframe(sp, IS_ENABLED(CONFIG_X86_32),
 					  &buf_fx, &math_size);
 		*fpstate = (void __user *)sp;
 	}
@@ -662,18 +662,18 @@ badframe:
 
 static inline int is_ia32_compat_frame(void)
 {
-	return config_enabled(CONFIG_IA32_EMULATION) &&
+	return IS_ENABLED(CONFIG_IA32_EMULATION) &&
 	       test_thread_flag(TIF_IA32);
 }
 
 static inline int is_ia32_frame(void)
 {
-	return config_enabled(CONFIG_X86_32) || is_ia32_compat_frame();
+	return IS_ENABLED(CONFIG_X86_32) || is_ia32_compat_frame();
 }
 
 static inline int is_x32_frame(void)
 {
-	return config_enabled(CONFIG_X86_X32_ABI) && test_thread_flag(TIF_X32);
+	return IS_ENABLED(CONFIG_X86_X32_ABI) && test_thread_flag(TIF_X32);
 }
 
 static int
diff --git a/drivers/firmware/broadcom/bcm47xx_sprom.c b/drivers/firmware/broadcom/bcm47xx_sprom.c
index b6eb875..62aa3cf 100644
--- a/drivers/firmware/broadcom/bcm47xx_sprom.c
+++ b/drivers/firmware/broadcom/bcm47xx_sprom.c
@@ -669,7 +669,7 @@ static int bcm47xx_get_sprom_bcma(struct bcma_bus *bus, struct ssb_sprom *out)
 	case BCMA_HOSTTYPE_PCI:
 		memset(out, 0, sizeof(struct ssb_sprom));
 		/* On BCM47XX all PCI buses share the same domain */
-		if (config_enabled(CONFIG_BCM47XX))
+		if (IS_ENABLED(CONFIG_BCM47XX))
 			snprintf(buf, sizeof(buf), "pci/%u/%u/",
 				 bus->host_pci->bus->number + 1,
 				 PCI_SLOT(bus->host_pci->devfn));
diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
index 3b5e10a..986f766 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -359,7 +359,7 @@ static void gic_handle_shared_int(bool chained)
 		pending_reg += gic_reg_step;
 		intrmask_reg += gic_reg_step;
 
-		if (!config_enabled(CONFIG_64BIT) || mips_cm_is64)
+		if (!IS_ENABLED(CONFIG_64BIT) || mips_cm_is64)
 			continue;
 
 		pending[i] |= (u64)gic_read(pending_reg) << 32;
diff --git a/drivers/mtd/bcm47xxpart.c b/drivers/mtd/bcm47xxpart.c
index 845dd27..3779475 100644
--- a/drivers/mtd/bcm47xxpart.c
+++ b/drivers/mtd/bcm47xxpart.c
@@ -122,7 +122,7 @@ static int bcm47xxpart_parse(struct mtd_info *master,
 	for (offset = 0; offset <= master->size - blocksize;
 	     offset += blocksize) {
 		/* Nothing more in higher memory on BCM47XX (MIPS) */
-		if (config_enabled(CONFIG_BCM47XX) && offset >= 0x2000000)
+		if (IS_ENABLED(CONFIG_BCM47XX) && offset >= 0x2000000)
 			break;
 
 		if (curr_part >= BCM47XXPART_MAX_PARTS) {
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index e251155..0a8a421 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -139,11 +139,11 @@ void ath10k_debug_print_hwfw_info(struct ath10k *ar)
 		    ar->id.subsystem_vendor, ar->id.subsystem_device);
 
 	ath10k_info(ar, "kconfig debug %d debugfs %d tracing %d dfs %d testmode %d\n",
-		    config_enabled(CONFIG_ATH10K_DEBUG),
-		    config_enabled(CONFIG_ATH10K_DEBUGFS),
-		    config_enabled(CONFIG_ATH10K_TRACING),
-		    config_enabled(CONFIG_ATH10K_DFS_CERTIFIED),
-		    config_enabled(CONFIG_NL80211_TESTMODE));
+		    IS_ENABLED(CONFIG_ATH10K_DEBUG),
+		    IS_ENABLED(CONFIG_ATH10K_DEBUGFS),
+		    IS_ENABLED(CONFIG_ATH10K_TRACING),
+		    IS_ENABLED(CONFIG_ATH10K_DFS_CERTIFIED),
+		    IS_ENABLED(CONFIG_NL80211_TESTMODE));
 
 	firmware = ar->normal_mode_fw.fw_file.firmware;
 	if (firmware)
@@ -2397,7 +2397,7 @@ int ath10k_debug_register(struct ath10k *ar)
 	debugfs_create_file("nf_cal_period", S_IRUSR | S_IWUSR,
 			    ar->debug.debugfs_phy, ar, &fops_nf_cal_period);
 
-	if (config_enabled(CONFIG_ATH10K_DFS_CERTIFIED)) {
+	if (IS_ENABLED(CONFIG_ATH10K_DFS_CERTIFIED)) {
 		debugfs_create_file("dfs_simulate_radar", S_IWUSR,
 				    ar->debug.debugfs_phy, ar,
 				    &fops_simulate_radar);
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 6dd1d26..181159d 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2993,7 +2993,7 @@ static void ath10k_regd_update(struct ath10k *ar)
 
 	regpair = ar->ath_common.regulatory.regpair;
 
-	if (config_enabled(CONFIG_ATH10K_DFS_CERTIFIED) && ar->dfs_detector) {
+	if (IS_ENABLED(CONFIG_ATH10K_DFS_CERTIFIED) && ar->dfs_detector) {
 		nl_dfs_reg = ar->dfs_detector->region;
 		wmi_dfs_reg = ath10k_mac_get_dfs_region(nl_dfs_reg);
 	} else {
@@ -3022,7 +3022,7 @@ static void ath10k_reg_notifier(struct wiphy *wiphy,
 
 	ath_reg_notifier_apply(wiphy, request, &ar->ath_common.regulatory);
 
-	if (config_enabled(CONFIG_ATH10K_DFS_CERTIFIED) && ar->dfs_detector) {
+	if (IS_ENABLED(CONFIG_ATH10K_DFS_CERTIFIED) && ar->dfs_detector) {
 		ath10k_dbg(ar, ATH10K_DBG_REGULATORY, "dfs region 0x%x\n",
 			   request->dfs_region);
 		result = ar->dfs_detector->set_dfs_domain(ar->dfs_detector,
@@ -7860,7 +7860,7 @@ int ath10k_mac_register(struct ath10k *ar)
 	if (!test_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags))
 		ar->hw->netdev_features = NETIF_F_HW_CSUM;
 
-	if (config_enabled(CONFIG_ATH10K_DFS_CERTIFIED)) {
+	if (IS_ENABLED(CONFIG_ATH10K_DFS_CERTIFIED)) {
 		/* Init ath dfs pattern detector */
 		ar->ath_common.debug_mask = ATH_DBG_DFS;
 		ar->dfs_detector = dfs_pattern_detector_init(&ar->ath_common,
@@ -7899,7 +7899,7 @@ err_unregister:
 	ieee80211_unregister_hw(ar->hw);
 
 err_dfs_detector_exit:
-	if (config_enabled(CONFIG_ATH10K_DFS_CERTIFIED) && ar->dfs_detector)
+	if (IS_ENABLED(CONFIG_ATH10K_DFS_CERTIFIED) && ar->dfs_detector)
 		ar->dfs_detector->exit(ar->dfs_detector);
 
 err_free:
@@ -7914,7 +7914,7 @@ void ath10k_mac_unregister(struct ath10k *ar)
 {
 	ieee80211_unregister_hw(ar->hw);
 
-	if (config_enabled(CONFIG_ATH10K_DFS_CERTIFIED) && ar->dfs_detector)
+	if (IS_ENABLED(CONFIG_ATH10K_DFS_CERTIFIED) && ar->dfs_detector)
 		ar->dfs_detector->exit(ar->dfs_detector);
 
 	kfree(ar->mac.sbands[NL80211_BAND_2GHZ].channels);
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 2c30032..2978044 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3671,7 +3671,7 @@ void ath10k_wmi_event_dfs(struct ath10k *ar,
 		   phyerr->tsf_timestamp, tsf, buf_len);
 
 	/* Skip event if DFS disabled */
-	if (!config_enabled(CONFIG_ATH10K_DFS_CERTIFIED))
+	if (!IS_ENABLED(CONFIG_ATH10K_DFS_CERTIFIED))
 		return;
 
 	ATH10K_DFS_STAT_INC(ar, pulses_total);
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 4e11ba0..f6b5390 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -3870,7 +3870,7 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
 					  BIT(NL80211_IFTYPE_P2P_CLIENT);
 	}
 
-	if (config_enabled(CONFIG_ATH6KL_REGDOMAIN) &&
+	if (IS_ENABLED(CONFIG_ATH6KL_REGDOMAIN) &&
 	    test_bit(ATH6KL_FW_CAPABILITY_REGDOMAIN, ar->fw_capabilities)) {
 		wiphy->reg_notifier = ath6kl_cfg80211_reg_notify;
 		ar->wiphy->features |= NL80211_FEATURE_CELL_BASE_REG_HINTS;
diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.c b/drivers/net/wireless/ath/ath9k/common-spectral.c
index a876271..e2512d5 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.c
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.c
@@ -731,7 +731,7 @@ void ath9k_cmn_spectral_scan_trigger(struct ath_common *common,
 	struct ath_hw *ah = spec_priv->ah;
 	u32 rxfilter;
 
-	if (config_enabled(CONFIG_ATH9K_TX99))
+	if (IS_ENABLED(CONFIG_ATH9K_TX99))
 		return;
 
 	if (!ath9k_hw_ops(ah)->spectral_scan_trigger) {
@@ -806,7 +806,7 @@ static ssize_t write_file_spec_scan_ctl(struct file *file,
 	char buf[32];
 	ssize_t len;
 
-	if (config_enabled(CONFIG_ATH9K_TX99))
+	if (IS_ENABLED(CONFIG_ATH9K_TX99))
 		return -EOPNOTSUPP;
 
 	len = min(count, sizeof(buf) - 1);
@@ -1072,7 +1072,7 @@ static struct rchan_callbacks rfs_spec_scan_cb = {
 
 void ath9k_cmn_spectral_deinit_debug(struct ath_spec_scan_priv *spec_priv)
 {
-	if (config_enabled(CONFIG_ATH9K_DEBUGFS)) {
+	if (IS_ENABLED(CONFIG_ATH9K_DEBUGFS)) {
 		relay_close(spec_priv->rfs_chan_spec_scan);
 		spec_priv->rfs_chan_spec_scan = NULL;
 	}
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 2ee8624..486d526 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -839,7 +839,7 @@ static void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
 			       NL80211_FEATURE_AP_MODE_CHAN_WIDTH_CHANGE |
 			       NL80211_FEATURE_P2P_GO_CTWIN;
 
-	if (!config_enabled(CONFIG_ATH9K_TX99)) {
+	if (!IS_ENABLED(CONFIG_ATH9K_TX99)) {
 		hw->wiphy->interface_modes =
 			BIT(NL80211_IFTYPE_P2P_GO) |
 			BIT(NL80211_IFTYPE_P2P_CLIENT) |
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 8b63988..fccef70 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1239,7 +1239,7 @@ static int ath9k_add_interface(struct ieee80211_hw *hw,
 
 	mutex_lock(&sc->mutex);
 
-	if (config_enabled(CONFIG_ATH9K_TX99)) {
+	if (IS_ENABLED(CONFIG_ATH9K_TX99)) {
 		if (sc->cur_chan->nvifs >= 1) {
 			mutex_unlock(&sc->mutex);
 			return -EOPNOTSUPP;
@@ -1289,7 +1289,7 @@ static int ath9k_change_interface(struct ieee80211_hw *hw,
 
 	mutex_lock(&sc->mutex);
 
-	if (config_enabled(CONFIG_ATH9K_TX99)) {
+	if (IS_ENABLED(CONFIG_ATH9K_TX99)) {
 		mutex_unlock(&sc->mutex);
 		return -EOPNOTSUPP;
 	}
@@ -1349,7 +1349,7 @@ static void ath9k_enable_ps(struct ath_softc *sc)
 	struct ath_hw *ah = sc->sc_ah;
 	struct ath_common *common = ath9k_hw_common(ah);
 
-	if (config_enabled(CONFIG_ATH9K_TX99))
+	if (IS_ENABLED(CONFIG_ATH9K_TX99))
 		return;
 
 	sc->ps_enabled = true;
@@ -1368,7 +1368,7 @@ static void ath9k_disable_ps(struct ath_softc *sc)
 	struct ath_hw *ah = sc->sc_ah;
 	struct ath_common *common = ath9k_hw_common(ah);
 
-	if (config_enabled(CONFIG_ATH9K_TX99))
+	if (IS_ENABLED(CONFIG_ATH9K_TX99))
 		return;
 
 	sc->ps_enabled = false;
@@ -1926,7 +1926,7 @@ static int ath9k_get_survey(struct ieee80211_hw *hw, int idx,
 	struct ieee80211_channel *chan;
 	int pos;
 
-	if (config_enabled(CONFIG_ATH9K_TX99))
+	if (IS_ENABLED(CONFIG_ATH9K_TX99))
 		return -EOPNOTSUPP;
 
 	spin_lock_bh(&common->cc_lock);
@@ -1976,7 +1976,7 @@ static void ath9k_set_coverage_class(struct ieee80211_hw *hw,
 	struct ath_softc *sc = hw->priv;
 	struct ath_hw *ah = sc->sc_ah;
 
-	if (config_enabled(CONFIG_ATH9K_TX99))
+	if (IS_ENABLED(CONFIG_ATH9K_TX99))
 		return;
 
 	mutex_lock(&sc->mutex);
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 32160fc..6697342 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -377,7 +377,7 @@ u32 ath_calcrxfilter(struct ath_softc *sc)
 	struct ath_common *common = ath9k_hw_common(sc->sc_ah);
 	u32 rfilt;
 
-	if (config_enabled(CONFIG_ATH9K_TX99))
+	if (IS_ENABLED(CONFIG_ATH9K_TX99))
 		return 0;
 
 	rfilt = ATH9K_RX_FILTER_UCAST | ATH9K_RX_FILTER_BCAST
diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c b/drivers/net/wireless/ath/dfs_pattern_detector.c
index 2303ef9..2f8136d 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
@@ -352,7 +352,7 @@ dfs_pattern_detector_init(struct ath_common *common,
 {
 	struct dfs_pattern_detector *dpd;
 
-	if (!config_enabled(CONFIG_CFG80211_CERTIFICATION_ONUS))
+	if (!IS_ENABLED(CONFIG_CFG80211_CERTIFICATION_ONUS))
 		return NULL;
 
 	dpd = kmalloc(sizeof(*dpd), GFP_KERNEL);
diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index 7e15ed9..f850603 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -116,7 +116,7 @@ static const struct ieee80211_regdomain ath_world_regdom_67_68_6A_6C = {
 
 static bool dynamic_country_user_possible(struct ath_regulatory *reg)
 {
-	if (config_enabled(CONFIG_ATH_REG_DYNAMIC_USER_CERT_TESTING))
+	if (IS_ENABLED(CONFIG_ATH_REG_DYNAMIC_USER_CERT_TESTING))
 		return true;
 
 	switch (reg->country_code) {
@@ -188,7 +188,7 @@ static bool dynamic_country_user_possible(struct ath_regulatory *reg)
 
 static bool ath_reg_dyn_country_user_allow(struct ath_regulatory *reg)
 {
-	if (!config_enabled(CONFIG_ATH_REG_DYNAMIC_USER_REG_HINTS))
+	if (!IS_ENABLED(CONFIG_ATH_REG_DYNAMIC_USER_REG_HINTS))
 		return false;
 	if (!dynamic_country_user_possible(reg))
 		return false;
diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
index f9832ad..8bd3a08 100644
--- a/drivers/pci/ecam.c
+++ b/drivers/pci/ecam.c
@@ -28,7 +28,7 @@
  * since we have enough virtual address range available.  On 32-bit, we
  * ioremap the config space for each bus individually.
  */
-static const bool per_bus_mapping = !config_enabled(CONFIG_64BIT);
+static const bool per_bus_mapping = !IS_ENABLED(CONFIG_64BIT);
 
 /*
  * Create a PCI config space window
diff --git a/drivers/tty/serial/ar933x_uart.c b/drivers/tty/serial/ar933x_uart.c
index 1519d2c..73137f4 100644
--- a/drivers/tty/serial/ar933x_uart.c
+++ b/drivers/tty/serial/ar933x_uart.c
@@ -54,7 +54,7 @@ struct ar933x_uart_port {
 
 static inline bool ar933x_uart_console_enabled(void)
 {
-	return config_enabled(CONFIG_SERIAL_AR933X_CONSOLE);
+	return IS_ENABLED(CONFIG_SERIAL_AR933X_CONSOLE);
 }
 
 static inline unsigned int ar933x_uart_read(struct ar933x_uart_port *up,
@@ -636,7 +636,7 @@ static int ar933x_uart_probe(struct platform_device *pdev)
 	int ret;
 
 	np = pdev->dev.of_node;
-	if (config_enabled(CONFIG_OF) && np) {
+	if (IS_ENABLED(CONFIG_OF) && np) {
 		id = of_alias_get_id(np, "serial");
 		if (id < 0) {
 			dev_err(&pdev->dev, "unable to get alias id, err=%d\n",
diff --git a/include/linux/fence.h b/include/linux/fence.h
index 2056e9f..c00346d 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -359,7 +359,7 @@ unsigned fence_context_alloc(unsigned num);
 #define FENCE_TRACE(f, fmt, args...) \
 	do {								\
 		struct fence *__ff = (f);				\
-		if (config_enabled(CONFIG_FENCE_TRACE))			\
+		if (IS_ENABLED(CONFIG_FENCE_TRACE))			\
 			pr_info("f %u#%u: " fmt,			\
 				__ff->context, __ff->seqno, ##args);	\
 	} while (0)
diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h
index 760399a..2bb5deb 100644
--- a/include/linux/ww_mutex.h
+++ b/include/linux/ww_mutex.h
@@ -173,14 +173,14 @@ static inline void ww_acquire_fini(struct ww_acquire_ctx *ctx)
 	mutex_release(&ctx->dep_map, 0, _THIS_IP_);
 
 	DEBUG_LOCKS_WARN_ON(ctx->acquired);
-	if (!config_enabled(CONFIG_PROVE_LOCKING))
+	if (!IS_ENABLED(CONFIG_PROVE_LOCKING))
 		/*
 		 * lockdep will normally handle this,
 		 * but fail without anyway
 		 */
 		ctx->done_acquire = 1;
 
-	if (!config_enabled(CONFIG_DEBUG_LOCK_ALLOC))
+	if (!IS_ENABLED(CONFIG_DEBUG_LOCK_ALLOC))
 		/* ensure ww_acquire_fini will still fail if called twice */
 		ctx->acquired = ~0U;
 #endif
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index d49bfa1..1d3b766 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -585,8 +585,8 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data)
 		return -EINVAL;
 
 	if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
-		if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
-		    !config_enabled(CONFIG_SECCOMP))
+		if (!IS_ENABLED(CONFIG_CHECKPOINT_RESTORE) ||
+		    !IS_ENABLED(CONFIG_SECCOMP))
 			return -EINVAL;
 
 		if (!capable(CAP_SYS_ADMIN))
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 7002796..eaf2458 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -347,7 +347,7 @@ static struct seccomp_filter *seccomp_prepare_filter(struct sock_fprog *fprog)
 {
 	struct seccomp_filter *sfilter;
 	int ret;
-	const bool save_orig = config_enabled(CONFIG_CHECKPOINT_RESTORE);
+	const bool save_orig = IS_ENABLED(CONFIG_CHECKPOINT_RESTORE);
 
 	if (fprog->len == 0 || fprog->len > BPF_MAXINSNS)
 		return ERR_PTR(-EINVAL);
@@ -542,7 +542,7 @@ void secure_computing_strict(int this_syscall)
 {
 	int mode = current->seccomp.mode;
 
-	if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
+	if (IS_ENABLED(CONFIG_CHECKPOINT_RESTORE) &&
 	    unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
 		return;
 
@@ -647,7 +647,7 @@ u32 seccomp_phase1(struct seccomp_data *sd)
 	int this_syscall = sd ? sd->nr :
 		syscall_get_nr(current, task_pt_regs(current));
 
-	if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
+	if (IS_ENABLED(CONFIG_CHECKPOINT_RESTORE) &&
 	    unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
 		return SECCOMP_PHASE1_OK;
 
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index da49c0b..b0e11b6 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -715,7 +715,7 @@ static bool cfg80211_ir_permissive_chan(struct wiphy *wiphy,
 
 	ASSERT_RTNL();
 
-	if (!config_enabled(CONFIG_CFG80211_REG_RELAX_NO_IR) ||
+	if (!IS_ENABLED(CONFIG_CFG80211_REG_RELAX_NO_IR) ||
 	    !(wiphy->regulatory_flags & REGULATORY_ENABLE_RELAX_NO_IR))
 		return false;
 
-- 
1.9.1



From keescook at chromium.org  Mon Jun  6 08:53:29 2016
From: keescook at chromium.org (Kees Cook)
Date: Mon, 6 Jun 2016 08:53:29 -0700
Subject: [PATCH] tree-wide: replace config_enabled() with IS_ENABLED()
In-Reply-To: <1465215656-20569-1-git-send-email-yamada.masahiro@socionext.com>
References: <1465215656-20569-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <CAGXu5j+z-QOG+x6ie+BYVTmopCSZrLzzH3A2zLE1nQi+Q+WyKg@mail.gmail.com>

On Mon, Jun 6, 2016 at 5:20 AM, Masahiro Yamada
<yamada.masahiro at socionext.com> wrote:
> The use of config_enabled() against config options is ambiguous.
> In practical terms, config_enabled() is equivalent to IS_BUILTIN(),
> but the author might have used it for the meaning of IS_ENABLED().
> Using IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc. makes the
> intention clearer.
>
> This commit replaces config_enabled() with IS_ENABLED() where
> possible.  This commit is only touching bool config options.
>
> I noticed two cases where config_enabled() is used against a tristate
> option:
>
>  - config_enabled(CONFIG_HWMON)
>   [ drivers/net/wireless/ath/ath10k/thermal.c ]
>
>  - config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)
>   [ drivers/gpu/drm/gma500/opregion.c ]
>
> I did not touch them because they should be converted to IS_BUILTIN()
> in order to keep the logic, but I was not sure it was the authors'
> intention.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>

Sounds good to me! :)

Acked-by: Kees Cook <keescook at chromium.org>

-- 
Kees Cook
Chrome OS & Brillo Security


From akpm at linux-foundation.org  Tue Jun  7 15:29:30 2016
From: akpm at linux-foundation.org (Andrew Morton)
Date: Tue, 7 Jun 2016 15:29:30 -0700
Subject: [PATCH] tree-wide: replace config_enabled() with IS_ENABLED()
In-Reply-To: <1465215656-20569-1-git-send-email-yamada.masahiro@socionext.com>
References: <1465215656-20569-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <20160607152930.71273719bdaea322814213d0@linux-foundation.org>

On Mon,  6 Jun 2016 21:20:56 +0900 Masahiro Yamada <yamada.masahiro at socionext.com> wrote:

> The use of config_enabled() against config options is ambiguous.
> In practical terms, config_enabled() is equivalent to IS_BUILTIN(),
> but the author might have used it for the meaning of IS_ENABLED().
> Using IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc. makes the
> intention clearer.
> 
> This commit replaces config_enabled() with IS_ENABLED() where
> possible.  This commit is only touching bool config options.
> 
> I noticed two cases where config_enabled() is used against a tristate
> option:
> 
>  - config_enabled(CONFIG_HWMON)
>   [ drivers/net/wireless/ath/ath10k/thermal.c ]
> 
>  - config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)
>   [ drivers/gpu/drm/gma500/opregion.c ]
> 
> I did not touch them because they should be converted to IS_BUILTIN()
> in order to keep the logic, but I was not sure it was the authors'
> intention.

Well, we do want to be able to remove config_enabled() altogether if
we're going to do this.  So please later send along a patch which makes
a best-effort fix of the unclear usages and let's zap the thing.

If those fixes weren't quite correct then there will be a build error
(drivers/net/wireless/ath/ath10k/thermal.c) or no change in behaviour
(drivers/gpu/drm/gma500/opregion.c).



From mohammed at qti.qualcomm.com  Thu Jun  9 06:28:47 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Thu, 9 Jun 2016 18:58:47 +0530
Subject: [PATCH v2] ath10k: Fix crash during card removal
Message-ID: <1465478927-21401-1-git-send-email-mohammed@qca.qualcomm.com>

From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Usually when the firmware crashes we check for the value
'FW_IND_EVENT_PENDING' in 'FW_INDICATOR_ADDRESS' and proceed with
disabling the irq and dumping firmware 'crash dump'. Now
when the PCI card is unplugged from the device the PCI controller
seems to generate a spurious interrupt after some time which
was as treated a firmware crash and resulting in the below race
condition (and eventually crashing the system)

	ath10k_core_unregister -> ath10k_core_free_board_files

	...... device unplug spurious interrupt .........

	ath10k_pci_taklet -> ath10k_pci_fw_crashed_dump  ...etc

Clearly even after the firmware board files related data structure
is freed up we are getting a spurious interrupt from PCI with 0xfffffff
in the 'FW_INDICATOR_ADDRESS' resulting in scheduling of the pci tasklet
and doing a crash dump, printing f/w board related info resulting in the
below crash. Fix this by detecting this spurious interrupt in ath10k PCI
irq handler itself and return IRQ_NONE. Thanks to Michal Kazior for
helping us conclude the most appropriate fix.

Call trace:

 EIP is at ath10k_debug_print_board_info+0x39/0xb0
[ath10k_core]
EAX: 00000000 EBX: d4de15a0 ECX: 00000000 EDX: 00000064
ESI: f615ddd0 EDI: f8530000 EBP: f615de3c ESP: f615ddbc
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 80050033 CR2: 00000004 CR3: 01c0a000 CR4: 000006f0
Stack:
 f615ddd0 00000064 f8b4ecdd 00000000 00000000 00412f4e
00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Call Trace:
  [<f8b1f517>] ath10k_print_driver_info+0x17/0x30
[ath10k_core]
[<f875463a>] ath10k_pci_fw_crashed_dump+0x7a/0xe0
[ath10k_pci]
[<f87549d0>] ath10k_pci_tasklet+0x70/0x90 [ath10k_pci]
[<c106151e>] tasklet_action+0x9e/0xb0

Cc: Michal Kazior <michal.kazior at tieto.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/pci.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 8133d7b..ce6269f 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2198,6 +2198,14 @@ static void ath10k_pci_fw_crashed_clear(struct ath10k *ar)
 	ath10k_pci_write32(ar, FW_INDICATOR_ADDRESS, val);
 }
 
+static bool ath10k_pci_has_device_gone(struct ath10k *ar)
+{
+	u32 val;
+
+	val = ath10k_pci_read32(ar, FW_INDICATOR_ADDRESS);
+	return (val == 0xffffffff);
+}
+
 /* this function effectively clears target memory controller assert line */
 static void ath10k_pci_warm_reset_si0(struct ath10k *ar)
 {
@@ -2591,6 +2599,9 @@ static irqreturn_t ath10k_pci_interrupt_handler(int irq, void *arg)
 	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
 	int ret;
 
+	if (ath10k_pci_has_device_gone(ar))
+		return IRQ_NONE;
+
 	ret = ath10k_pci_force_wake(ar);
 	if (ret) {
 		ath10k_warn(ar, "failed to wake device up on irq: %d\n", ret);
-- 
1.7.9.5



From mohammed at qti.qualcomm.com  Thu Jun  9 06:29:51 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Thu, 9 Jun 2016 18:59:51 +0530
Subject: [PATCH] ath10k: Remove unneccessary WARN_ON_ONCE in rx during ACS
Message-ID: <1465478991-21449-1-git-send-email-mohammed@qca.qualcomm.com>

From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

The below warning message seems to hit occasionally with the following
combination (IPQ4019 + ACS scan) where we receive packets as a self peer
when hostapd does ACS when we bring up AP mode . ath10k has the below
fall back mechanism to fetch current operating channel in rx (it will
check for the next channel tracking variable if the current one is NULL)

	[scan channel] --> [rx channel] --> [peer channel] -->
	[vdev channel] -->  [any vdev channel] --> [target oper channel]

'scan channel' and 'target operating channel' are directly fetched from
firmware events. All the others should be updated by mac80211.

During ACS scan we wouldn't have a valid channel context
assigned from mac80211 ('ar->rx_channel'), and also relying on
('ar->scan_channel') is not helpful (it becomes NULL when it goes to
BSS channel and also when the scan event is completed). In short we
cannot always rely on these two channel tracking variables.

'Target Operating Channel' (ar->tgt_oper_chan) seems to keep track of
the current operating even while we are doing ACS scan and etc. Hence
remove this un-necessary warning message and continue with
target_operating channel. At the worst case scenario when the target
operating channel is invalid (NULL) we already have an ath10k warning
message to notify we really don't have a proper channel configured in
rx to update the rx status("no channel configured; ignoring frame(s)!")

    WARNING: CPU: 0 PID: 0 at ath/ath10k/htt_rx.c:803
    [<c0318838>] (warn_slowpath_null) from [<bf4a0104>]
    (ath10k_htt_rx_h_channel+0xe0/0x1b8 [ath10k_core])
    [<bf4a0104>] (ath10k_htt_rx_h_channel [ath10k_core]) from
    [<bf4a025c>] (ath10k_htt_rx_h_ppdu+0x80/0x288 [ath10k_core])
    [<bf4a025c>] (ath10k_htt_rx_h_ppdu [ath10k_core]) from
    [<bf4a1a9c>] (ath10k_htt_txrx_compl_task+0x724/0x9d4 [ath10k_core])
    [<bf4a1a9c>] (ath10k_htt_txrx_compl_task [ath10k_core])

Fixes:3b0499e9ce42 ("ath10k: reduce warning messages during rx without proper channel context")
Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
---

[updated commit log - Michal Kazior]

 drivers/net/wireless/ath/ath10k/htt_rx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 7bf1909..aa44c09 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -748,7 +748,7 @@ ath10k_htt_rx_h_peer_channel(struct ath10k *ar, struct htt_rx_desc *rxd)
 	if (WARN_ON_ONCE(!arvif))
 		return NULL;
 
-	if (WARN_ON_ONCE(ath10k_mac_vif_chan(arvif->vif, &def)))
+	if (ath10k_mac_vif_chan(arvif->vif, &def))
 		return NULL;
 
 	return def.chan;
-- 
1.7.9.5



From greearb at candelatech.com  Thu Jun  9 06:52:11 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 09 Jun 2016 06:52:11 -0700
Subject: Looking for CUS239 AR9980 chipset NICs.
Message-ID: <5759748B.5050105@candelatech.com>

If anyone has any of the AR9980 CUS239 Compex NICS they don't need, I'd be happy to buy them.
They are EOL (never really had a life, really), and it will take me some time to migrate to
the newer 9984 chipset nics.

Thanks,
Ben

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


From greearb at candelatech.com  Thu Jun  9 16:45:51 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 9 Jun 2016 16:45:51 -0700
Subject: Any reason to allow MGT TID to be paused by power-save?
Message-ID: <5759FFAF.4040609@candelatech.com>

I'm trying to track down a tricky problem with a Mac book and power save
with my ath10k firmware.

At least part of the issue is that when the Mac sleeps, it goes into power-save
state as far as AP is concerned, and then it simply turns itself off.  When it wakes
up a short time later, it then tries to scan and re-associate.  But, if hostapd
hasn't timed out the station (due to longer idle timer), then STA still is treated
as being in power-save in the firmware.  It appears that this causes mgt-frames (probe responses)
not be sent back out of the firmware, so Mac gives up fairly quickly.

I fixed at least some of this by forcing a power-save wake on
receipt of probe requests and auth requests, but some issues remain
for one reason or another.

One thing that came to mind:  Is it *ever* a good idea to pause a mgt-tid due to
power-save?  A second non-pausable TID also exists in the firmware...maybe all
mgt frames should use that?  But if so, then why have a mgt tid at all?

Thanks,
Ben

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



From michal.kazior at tieto.com  Fri Jun 10 00:49:50 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 10 Jun 2016 09:49:50 +0200
Subject: Any reason to allow MGT TID to be paused by power-save?
In-Reply-To: <5759FFAF.4040609@candelatech.com>
References: <5759FFAF.4040609@candelatech.com>
Message-ID: <CA+BoTQkSE5c=v08r=XsHgX27+pLMPSt2daP3Rh6tEw6fdtj6wg@mail.gmail.com>

On 10 June 2016 at 01:45, Ben Greear <greearb at candelatech.com> wrote:
> I'm trying to track down a tricky problem with a Mac book and power save
> with my ath10k firmware.
>
> At least part of the issue is that when the Mac sleeps, it goes into
> power-save
> state as far as AP is concerned, and then it simply turns itself off.  When
> it wakes
> up a short time later, it then tries to scan and re-associate.  But, if
> hostapd
> hasn't timed out the station (due to longer idle timer), then STA still is
> treated
> as being in power-save in the firmware.  It appears that this causes
> mgt-frames (probe responses)
> not be sent back out of the firmware, so Mac gives up fairly quickly.
>
> I fixed at least some of this by forcing a power-save wake on
> receipt of probe requests and auth requests, but some issues remain
> for one reason or another.
>
> One thing that came to mind:  Is it *ever* a good idea to pause a mgt-tid
> due to
> power-save?

The spec defines some mgmt frames as bufferable (IEEE 802.11-2012
8.2.4.1.7). See ieee80211_is_bufferable_mmpdu() in
include/linux/ieee80211.h.

Action, deauth and disassoc are bufferable. It makes sense anyway.

E.g. On DFS channel you may opt for CSA action frame (instead of CSA
IE in beacons) in which case you do want to buffer frames to clients
that are asleep to give them a chance to notice it, wake up and get
it.


Micha?


From kvalo at codeaurora.org  Fri Jun 10 05:22:42 2016
From: kvalo at codeaurora.org (Kalle Valo)
Date: Fri, 10 Jun 2016 15:22:42 +0300
Subject: ath10k/QCA9980 - Issues introduced in wireless testing 2016-05
In-Reply-To: <d836933e-ddbb-d10c-0715-6bce4396fd41@nbd.name> (Felix Fietkau's
 message of "Fri, 10 Jun 2016 10:55:36 +0200")
References: <ff65514a-47a3-2f32-658c-a2177401aa9a@bk.ru>
 <CA+BoTQmJ+JruxZ9WsG8Dnz=cwNY+e3Dy=g74-brS+0OE_5iu0Q@mail.gmail.com>
 <d836933e-ddbb-d10c-0715-6bce4396fd41@nbd.name>
Message-ID: <877fdxfd2l.fsf@kamboji.qca.qualcomm.com>

Felix Fietkau <nbd at nbd.name> writes:

> On 2016-06-10 10:50, Michal Kazior wrote:
>> On 9 June 2016 at 09:46, A. Benz <ash.benz at bk.ru> wrote:
>>> Dear All,
>>>
>>> I am using LEDE on my IPQ806x (QCA9980) system (Archer C2600).
>>> With compat-wireless-2016-05-12, I observed traces attached below.
>>> The router is unstable and eventually reboots by itself (randomly).
>>>
>>> Upon reverting to compat-wireless-2016-01, the issue disappears. Nothing
>>> else is changed (software-wise or hardware).
>>> This was confirmed with other users.
>>>
>>> A new compile with the fixes below:
>>> https://git.lede-project.org/?p=lede/nbd/staging.git;a=commit;h=858e26f3c0fc11231f25497cbb2ddca1e5f101e0
>>>
>>> Did not solve the problem.
>>>
>>> Please let me know if I need to provide any further information.
>>>
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 558 at
>>> compat-wireless-2016-05-12/net/mac80211/rx.c:4068
>>> ieee80211_rx_napi+0x8c/0x8a4 [mac80211]()
>> 
>> Can you post what is at rx.c line 4068 (and +/- 3 lines), please?
> It's early in ieee80211_rx_napi:
>
>     sband = local->hw.wiphy->bands[status->band];
>     if (WARN_ON(!sband))
>         goto drop;
>
> I could not easily find a scenario under which status->band would not be
> set properly by the driver, so my guess is there is some nasty memory
> corruption going on.
>
> FWIW, I've received several reports like this from different people on
> different devices. They're also confirming that reverting to the
> snapshot from January makes things stable again.

Adding ath10k list to the loop.

-- 
Kalle Valo


From me at bobcopeland.com  Fri Jun 10 05:52:44 2016
From: me at bobcopeland.com (Bob Copeland)
Date: Fri, 10 Jun 2016 08:52:44 -0400
Subject: [PATCH] ath10k: fix potential null dereference bugs
Message-ID: <1465563164-783-1-git-send-email-me@bobcopeland.com>

Smatch warns about a number of cases in ath10k where a pointer is
null-checked after it has already been dereferenced, in code involving
ath10k private virtual interface pointers.

Fix these by making the dereference happen later.

Addresses the following smatch warnings:

drivers/net/wireless/ath/ath10k/mac.c:3651 ath10k_mac_txq_init() warn: variable dereferenced before check 'txq' (see line 3649)
drivers/net/wireless/ath/ath10k/mac.c:3664 ath10k_mac_txq_unref() warn: variable dereferenced before check 'txq' (see line 3659)
drivers/net/wireless/ath/ath10k/htt_tx.c:70 __ath10k_htt_tx_txq_recalc() warn: variable dereferenced before check 'txq->sta' (see line 52)
drivers/net/wireless/ath/ath10k/htt_tx.c:740 ath10k_htt_tx_get_vdev_id() warn: variable dereferenced before check 'cb->vif' (see line 736)
drivers/net/wireless/ath/ath10k/txrx.c:86 ath10k_txrx_tx_unref() warn: variable dereferenced before check 'txq' (see line 84)
drivers/net/wireless/ath/ath10k/wmi.c:1837 ath10k_wmi_op_gen_mgmt_tx() warn: variable dereferenced before check 'cb->vif' (see line 1825)

Signed-off-by: Bob Copeland <me at bobcopeland.com>
---
Although I glanced at a few cases, by and large I didn't check
whether the if() tests were correct but assumed they were.

Also, I only compile-tested this.

 drivers/net/wireless/ath/ath10k/htt_tx.c | 15 +++++++++------
 drivers/net/wireless/ath/ath10k/mac.c    |  6 ++++--
 drivers/net/wireless/ath/ath10k/txrx.c   |  5 +++--
 drivers/net/wireless/ath/ath10k/wmi.c    |  8 +++++---
 4 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 6269c61..dfcc43d 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -49,7 +49,7 @@ static void __ath10k_htt_tx_txq_recalc(struct ieee80211_hw *hw,
 				       struct ieee80211_txq *txq)
 {
 	struct ath10k *ar = hw->priv;
-	struct ath10k_sta *arsta = (void *)txq->sta->drv_priv;
+	struct ath10k_sta *arsta;
 	struct ath10k_vif *arvif = (void *)txq->vif->drv_priv;
 	unsigned long frame_cnt;
 	unsigned long byte_cnt;
@@ -67,10 +67,12 @@ static void __ath10k_htt_tx_txq_recalc(struct ieee80211_hw *hw,
 	if (ar->htt.tx_q_state.mode != HTT_TX_MODE_SWITCH_PUSH_PULL)
 		return;
 
-	if (txq->sta)
+	if (txq->sta) {
+		arsta = (void *)txq->sta->drv_priv;
 		peer_id = arsta->peer_id;
-	else
+	} else {
 		peer_id = arvif->peer_id;
+	}
 
 	tid = txq->tid;
 	bit = BIT(peer_id % 32);
@@ -733,13 +735,14 @@ static u8 ath10k_htt_tx_get_vdev_id(struct ath10k *ar, struct sk_buff *skb)
 {
 	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 	struct ath10k_skb_cb *cb = ATH10K_SKB_CB(skb);
-	struct ath10k_vif *arvif = (void *)cb->vif->drv_priv;
+	struct ath10k_vif *arvif;
 
 	if (info->flags & IEEE80211_TX_CTL_TX_OFFCHAN)
 		return ar->scan.vdev_id;
-	else if (cb->vif)
+	else if (cb->vif) {
+		arvif = (void *)cb->vif->drv_priv;
 		return arvif->vdev_id;
-	else if (ar->monitor_started)
+	} else if (ar->monitor_started)
 		return ar->monitor_vdev_id;
 	else
 		return 0;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 6dd1d26..4eee4b9 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3646,17 +3646,18 @@ void ath10k_mgmt_over_wmi_tx_work(struct work_struct *work)
 
 static void ath10k_mac_txq_init(struct ieee80211_txq *txq)
 {
-	struct ath10k_txq *artxq = (void *)txq->drv_priv;
+	struct ath10k_txq *artxq;
 
 	if (!txq)
 		return;
 
+	artxq = (void *)txq->drv_priv;
 	INIT_LIST_HEAD(&artxq->list);
 }
 
 static void ath10k_mac_txq_unref(struct ath10k *ar, struct ieee80211_txq *txq)
 {
-	struct ath10k_txq *artxq = (void *)txq->drv_priv;
+	struct ath10k_txq *artxq;
 	struct ath10k_skb_cb *cb;
 	struct sk_buff *msdu;
 	int msdu_id;
@@ -3664,6 +3665,7 @@ static void ath10k_mac_txq_unref(struct ath10k *ar, struct ieee80211_txq *txq)
 	if (!txq)
 		return;
 
+	artxq = (void *)txq->drv_priv;
 	spin_lock_bh(&ar->txqs_lock);
 	if (!list_empty(&artxq->list))
 		list_del_init(&artxq->list);
diff --git a/drivers/net/wireless/ath/ath10k/txrx.c b/drivers/net/wireless/ath/ath10k/txrx.c
index 576e7c4..9f17863 100644
--- a/drivers/net/wireless/ath/ath10k/txrx.c
+++ b/drivers/net/wireless/ath/ath10k/txrx.c
@@ -81,10 +81,11 @@ int ath10k_txrx_tx_unref(struct ath10k_htt *htt,
 
 	skb_cb = ATH10K_SKB_CB(msdu);
 	txq = skb_cb->txq;
-	artxq = (void *)txq->drv_priv;
 
-	if (txq)
+	if (txq) {
+		artxq = (void *)txq->drv_priv;
 		artxq->num_fw_queued--;
+	}
 
 	ath10k_htt_tx_free_msdu_id(htt, tx_done->msdu_id);
 	ath10k_htt_tx_dec_pending(htt);
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 2c30032..60f78a6 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1822,7 +1822,7 @@ static struct sk_buff *
 ath10k_wmi_op_gen_mgmt_tx(struct ath10k *ar, struct sk_buff *msdu)
 {
 	struct ath10k_skb_cb *cb = ATH10K_SKB_CB(msdu);
-	struct ath10k_vif *arvif = (void *)cb->vif->drv_priv;
+	struct ath10k_vif *arvif;
 	struct wmi_mgmt_tx_cmd *cmd;
 	struct ieee80211_hdr *hdr;
 	struct sk_buff *skb;
@@ -1834,10 +1834,12 @@ ath10k_wmi_op_gen_mgmt_tx(struct ath10k *ar, struct sk_buff *msdu)
 	hdr = (struct ieee80211_hdr *)msdu->data;
 	fc = le16_to_cpu(hdr->frame_control);
 
-	if (cb->vif)
+	if (cb->vif) {
+		arvif = (void *)cb->vif->drv_priv;
 		vdev_id = arvif->vdev_id;
-	else
+	} else {
 		vdev_id = 0;
+	}
 
 	if (WARN_ON_ONCE(!ieee80211_is_mgmt(hdr->frame_control)))
 		return ERR_PTR(-EINVAL);
-- 
2.1.4



From nbd at nbd.name  Fri Jun 10 05:57:27 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Fri, 10 Jun 2016 14:57:27 +0200
Subject: ath10k/QCA9980 - Issues introduced in wireless testing 2016-05
In-Reply-To: <575AB829.10101@candelatech.com>
References: <ff65514a-47a3-2f32-658c-a2177401aa9a@bk.ru>
 <CA+BoTQmJ+JruxZ9WsG8Dnz=cwNY+e3Dy=g74-brS+0OE_5iu0Q@mail.gmail.com>
 <d836933e-ddbb-d10c-0715-6bce4396fd41@nbd.name>
 <877fdxfd2l.fsf@kamboji.qca.qualcomm.com> <575AB829.10101@candelatech.com>
Message-ID: <f80db123-9b8a-289d-aed8-12531db13424@nbd.name>

On 2016-06-10 14:52, Ben Greear wrote:
> This looks a lot like the problems I was having.
> 
> Two of these 5 patches recently made it upstream (but may not be in LEDE yet),
> but the other patches also were related to memory corruption.
> 
> See my patches posted on 4/1/16:
> 
> https://patchwork.kernel.org/project/ath10k/list/
> 
> I don't know where the 5/5 patch ended up.
I had already asked affected users to test with those patches (I have a
commit that adds them in my staging tree), but it did not resolve the issue.

- Felix


From greearb at candelatech.com  Fri Jun 10 05:52:57 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 10 Jun 2016 05:52:57 -0700
Subject: ath10k/QCA9980 - Issues introduced in wireless testing 2016-05
In-Reply-To: <877fdxfd2l.fsf@kamboji.qca.qualcomm.com>
References: <ff65514a-47a3-2f32-658c-a2177401aa9a@bk.ru>
 <CA+BoTQmJ+JruxZ9WsG8Dnz=cwNY+e3Dy=g74-brS+0OE_5iu0Q@mail.gmail.com>
 <d836933e-ddbb-d10c-0715-6bce4396fd41@nbd.name>
 <877fdxfd2l.fsf@kamboji.qca.qualcomm.com>
Message-ID: <575AB829.10101@candelatech.com>



On 06/10/2016 05:22 AM, Kalle Valo wrote:
> Felix Fietkau <nbd at nbd.name> writes:
>
>> On 2016-06-10 10:50, Michal Kazior wrote:
>>> On 9 June 2016 at 09:46, A. Benz <ash.benz at bk.ru> wrote:
>>>> Dear All,
>>>>
>>>> I am using LEDE on my IPQ806x (QCA9980) system (Archer C2600).
>>>> With compat-wireless-2016-05-12, I observed traces attached below.
>>>> The router is unstable and eventually reboots by itself (randomly).
>>>>
>>>> Upon reverting to compat-wireless-2016-01, the issue disappears. Nothing
>>>> else is changed (software-wise or hardware).
>>>> This was confirmed with other users.
>>>>
>>>> A new compile with the fixes below:
>>>> https://git.lede-project.org/?p=lede/nbd/staging.git;a=commit;h=858e26f3c0fc11231f25497cbb2ddca1e5f101e0
>>>>
>>>> Did not solve the problem.
>>>>
>>>> Please let me know if I need to provide any further information.
>>>>
>>>> ------------[ cut here ]------------
>>>> WARNING: CPU: 0 PID: 558 at
>>>> compat-wireless-2016-05-12/net/mac80211/rx.c:4068
>>>> ieee80211_rx_napi+0x8c/0x8a4 [mac80211]()
>>>
>>> Can you post what is at rx.c line 4068 (and +/- 3 lines), please?
>> It's early in ieee80211_rx_napi:
>>
>>      sband = local->hw.wiphy->bands[status->band];
>>      if (WARN_ON(!sband))
>>          goto drop;
>>
>> I could not easily find a scenario under which status->band would not be
>> set properly by the driver, so my guess is there is some nasty memory
>> corruption going on.
>>
>> FWIW, I've received several reports like this from different people on
>> different devices. They're also confirming that reverting to the
>> snapshot from January makes things stable again.
>
> Adding ath10k list to the loop.

This looks a lot like the problems I was having.

Two of these 5 patches recently made it upstream (but may not be in LEDE yet),
but the other patches also were related to memory corruption.

See my patches posted on 4/1/16:

https://patchwork.kernel.org/project/ath10k/list/

I don't know where the 5/5 patch ended up.

Thanks,
Ben

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


From greearb at candelatech.com  Fri Jun 10 06:16:18 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 10 Jun 2016 06:16:18 -0700
Subject: ath10k/QCA9980 - Issues introduced in wireless testing 2016-05
In-Reply-To: <f80db123-9b8a-289d-aed8-12531db13424@nbd.name>
References: <ff65514a-47a3-2f32-658c-a2177401aa9a@bk.ru>
 <CA+BoTQmJ+JruxZ9WsG8Dnz=cwNY+e3Dy=g74-brS+0OE_5iu0Q@mail.gmail.com>
 <d836933e-ddbb-d10c-0715-6bce4396fd41@nbd.name>
 <877fdxfd2l.fsf@kamboji.qca.qualcomm.com> <575AB829.10101@candelatech.com>
 <f80db123-9b8a-289d-aed8-12531db13424@nbd.name>
Message-ID: <575ABDA2.9020609@candelatech.com>



On 06/10/2016 05:57 AM, Felix Fietkau wrote:
> On 2016-06-10 14:52, Ben Greear wrote:
>> This looks a lot like the problems I was having.
>>
>> Two of these 5 patches recently made it upstream (but may not be in LEDE yet),
>> but the other patches also were related to memory corruption.
>>
>> See my patches posted on 4/1/16:
>>
>> https://patchwork.kernel.org/project/ath10k/list/
>>
>> I don't know where the 5/5 patch ended up.
> I had already asked affected users to test with those patches (I have a
> commit that adds them in my staging tree), but it did not resolve the issue.

Ok, must be something else then.

If you can run on x86 under KASAN it may provide some clues..that is how I eventually
made progress on the issues I was seeing.  My rebase onto 3.7 has been slow and painful,
but I should be ready to start testing that sometime soon, maybe I can reproduce something
there.

Thanks,
Ben

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


From clinton.webster at powerofloveexperience.com  Sun Jun 12 10:24:23 2016
From: clinton.webster at powerofloveexperience.com (FedEx 2Day A.M.)
Date: Sun, 12 Jun 2016 12:24:23 -0500
Subject: Problems with item delivery, n.00000872749
Message-ID: <47b5ee06d5c390ba4a4b26a3584cd761@powerofloveexperience.com>

Dear Customer,

Your parcel has arrived at June 11. Courier was unable to deliver the parcel to you.
Please, open email attachment to print shipment label.

Yours trully,
Clinton Webster,
Sr. Operation Agent.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Delivery_Notification_00000872749.zip
Type: application/zip
Size: 9182 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160612/bb42a39e/attachment.zip>

From michal.kazior at tieto.com  Sun Jun 12 22:39:56 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 13 Jun 2016 07:39:56 +0200
Subject: [PATCH] ath10k: fix potential null dereference bugs
In-Reply-To: <1465563164-783-1-git-send-email-me@bobcopeland.com>
References: <1465563164-783-1-git-send-email-me@bobcopeland.com>
Message-ID: <CA+BoTQkg+uea_YzUgrVBPhA8uRxNpd29Kd1y1tvt0a-JyOSLQw@mail.gmail.com>

On 10 June 2016 at 14:52, Bob Copeland <me at bobcopeland.com> wrote:
> Smatch warns about a number of cases in ath10k where a pointer is
> null-checked after it has already been dereferenced, in code involving
> ath10k private virtual interface pointers.
>
> Fix these by making the dereference happen later.
>
> Addresses the following smatch warnings:
>
> drivers/net/wireless/ath/ath10k/mac.c:3651 ath10k_mac_txq_init() warn: variable dereferenced before check 'txq' (see line 3649)
> drivers/net/wireless/ath/ath10k/mac.c:3664 ath10k_mac_txq_unref() warn: variable dereferenced before check 'txq' (see line 3659)
> drivers/net/wireless/ath/ath10k/htt_tx.c:70 __ath10k_htt_tx_txq_recalc() warn: variable dereferenced before check 'txq->sta' (see line 52)
> drivers/net/wireless/ath/ath10k/htt_tx.c:740 ath10k_htt_tx_get_vdev_id() warn: variable dereferenced before check 'cb->vif' (see line 736)
> drivers/net/wireless/ath/ath10k/txrx.c:86 ath10k_txrx_tx_unref() warn: variable dereferenced before check 'txq' (see line 84)
> drivers/net/wireless/ath/ath10k/wmi.c:1837 ath10k_wmi_op_gen_mgmt_tx() warn: variable dereferenced before check 'cb->vif' (see line 1825)

FWIW all of these are false positives. I think this was already
pointed out some time ago. The drv_priv stuff is merely an offset (see
how ieee80211_vif and ieee80211_sta are defined) and the according
structure is always checked beforehand.


Micha?


From johannes at sipsolutions.net  Mon Jun 13 02:08:59 2016
From: johannes at sipsolutions.net (Johannes Berg)
Date: Mon, 13 Jun 2016 11:08:59 +0200
Subject: [PATCH] ath10k: fix potential null dereference bugs
In-Reply-To: <CA+BoTQkg+uea_YzUgrVBPhA8uRxNpd29Kd1y1tvt0a-JyOSLQw@mail.gmail.com>
 (sfid-20160613_074004_402825_22006851)
References: <1465563164-783-1-git-send-email-me@bobcopeland.com>
 <CA+BoTQkg+uea_YzUgrVBPhA8uRxNpd29Kd1y1tvt0a-JyOSLQw@mail.gmail.com>
 (sfid-20160613_074004_402825_22006851)
Message-ID: <1465808939.2434.1.camel@sipsolutions.net>

On Mon, 2016-06-13 at 07:39 +0200, Michal Kazior wrote:
>?
> FWIW all of these are false positives. I think this was already
> pointed out some time ago. The drv_priv stuff is merely an offset
> (see how ieee80211_vif and ieee80211_sta are defined) and the
> according structure is always checked beforehand.
> 

IIRC, doing something like that can (sometimes?) still get you into
undefined behaviour territory, so the compiler could potentially
"optimize" away the later NULL check.

Or am I confusing something? Seems entirely possible :)

johannes


From me at bobcopeland.com  Mon Jun 13 06:05:07 2016
From: me at bobcopeland.com (Bob Copeland)
Date: Mon, 13 Jun 2016 09:05:07 -0400
Subject: [PATCH] ath10k: fix potential null dereference bugs
In-Reply-To: <1465808939.2434.1.camel@sipsolutions.net>
References: <1465563164-783-1-git-send-email-me@bobcopeland.com>
 <CA+BoTQkg+uea_YzUgrVBPhA8uRxNpd29Kd1y1tvt0a-JyOSLQw@mail.gmail.com>
 <1465808939.2434.1.camel@sipsolutions.net>
Message-ID: <20160613130507.GA11074@localhost>

On Mon, Jun 13, 2016 at 11:08:59AM +0200, Johannes Berg wrote:
> On Mon, 2016-06-13 at 07:39 +0200, Michal Kazior wrote:
> >?
> > FWIW all of these are false positives. I think this was already
> > pointed out some time ago. The drv_priv stuff is merely an offset
> > (see how ieee80211_vif and ieee80211_sta are defined) and the
> > according structure is always checked beforehand.

OK, fair enough, sorry for the noise.  I'm daily running sparse / smatch
on wireless-testing; although these had been around for a while they
showed up as new "errors" because of some line number changes, but I'll
squelch them going forward.

> IIRC, doing something like that can (sometimes?) still get you into
> undefined behaviour territory, so the compiler could potentially
> "optimize" away the later NULL check.

So I did just go and check the generated code for each of these cases
and gcc didn't elide the subsequent if-test, at least on x86-64 and my
compiler / build config.  Given http://lwn.net/Articles/342330, it seems
possible, though.

-- 
Bob Copeland %% http://bobcopeland.com/


From johannes at sipsolutions.net  Mon Jun 13 06:18:00 2016
From: johannes at sipsolutions.net (Johannes Berg)
Date: Mon, 13 Jun 2016 15:18:00 +0200
Subject: [PATCH] ath10k: fix potential null dereference bugs
In-Reply-To: <20160613130507.GA11074@localhost>
 (sfid-20160613_150522_731750_3B82E728)
References: <1465563164-783-1-git-send-email-me@bobcopeland.com>
 <CA+BoTQkg+uea_YzUgrVBPhA8uRxNpd29Kd1y1tvt0a-JyOSLQw@mail.gmail.com>
 <1465808939.2434.1.camel@sipsolutions.net>
 <20160613130507.GA11074@localhost> (sfid-20160613_150522_731750_3B82E728)
Message-ID: <1465823880.10050.3.camel@sipsolutions.net>

On Mon, 2016-06-13 at 09:05 -0400, Bob Copeland wrote:
>?
> So I did just go and check the generated code for each of these cases
> and gcc didn't elide the subsequent if-test, at least on x86-64 and
> my compiler / build config.??Given http://lwn.net/Articles/342330, it
> seems possible, though.

It's not clear that's the same situation, since tun->sk is very likely
to have been an actual pointer, not an embedded thing like drv_priv.

However, with all this, I think I'd simply not take any chances - the
patch isn't exactly invasive and in some cases (for example the first
hunk of the patch) will even improve the code to the point where the
compiler could warn about uninitialized usage of the pointer when the
code gets modified to use it in case of !txq->sta.

I'd take it, but I guess it's Kalle's decision :)

johannes


From gaurang at vt.edu  Mon Jun 13 21:37:17 2016
From: gaurang at vt.edu (Gaurang Ramesh Naik)
Date: Tue, 14 Jun 2016 00:37:17 -0400
Subject: Problem with spectral scan in VHT80 mode
Message-ID: <CAFc9h7vk6e-BntP+GMv8s2jaNSOkA=37rChTjss2-7mgupAv7Q@mail.gmail.com>

Hello,

I was trying the ath10k's spectral scan. I used the following commands
given on the link
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/spectral

echo 8 > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_count
echo manual > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
echo trigger > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
cat /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan0 >> /tmp/fft.dump

I am using OpenWrt Bleeding edge. In the HT20 and HT40 mode, I
correctly get 8 samples. However, in the VHT80 mode, the /tmp/fft.dump
file generated is empty.

In the open issues on the above link, it said that the HT40 and HT20
modes ignore the count parameter. That isn't the case for me. I seem
to get correct # of samples (I view the dump file using
https://github.com/simonwunderlich/FFT_eval). However, in the VHT80
mode, there seems to be no output. Am I doing something wrong here?

Thanks,
Gaurang.


From gaurang at vt.edu  Mon Jun 13 22:08:29 2016
From: gaurang at vt.edu (Gaurang Ramesh Naik)
Date: Tue, 14 Jun 2016 01:08:29 -0400
Subject: Problem with spectral scan in VHT80 mode
In-Reply-To: <CAFc9h7vk6e-BntP+GMv8s2jaNSOkA=37rChTjss2-7mgupAv7Q@mail.gmail.com>
References: <CAFc9h7vk6e-BntP+GMv8s2jaNSOkA=37rChTjss2-7mgupAv7Q@mail.gmail.com>
Message-ID: <CAFc9h7uABMUJ349bgNJLcZDNL5hyp96CrYoc8PD9VDLv_-8rqw@mail.gmail.com>

Apologies for my previous e-mail. I had read the whole page once, but
somehow I missed the point about 64 bins for VHT80. It's working now.

On Tue, Jun 14, 2016 at 12:37 AM, Gaurang Ramesh Naik <gaurang at vt.edu> wrote:
> Hello,
>
> I was trying the ath10k's spectral scan. I used the following commands
> given on the link
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/spectral
>
> echo 8 > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_count
> echo manual > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
> echo trigger > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
> cat /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan0 >> /tmp/fft.dump
>
> I am using OpenWrt Bleeding edge. In the HT20 and HT40 mode, I
> correctly get 8 samples. However, in the VHT80 mode, the /tmp/fft.dump
> file generated is empty.
>
> In the open issues on the above link, it said that the HT40 and HT20
> modes ignore the count parameter. That isn't the case for me. I seem
> to get correct # of samples (I view the dump file using
> https://github.com/simonwunderlich/FFT_eval). However, in the VHT80
> mode, there seems to be no output. Am I doing something wrong here?
>
> Thanks,
> Gaurang.


From mohammed at codeaurora.org  Mon Jun 13 22:30:11 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Tue, 14 Jun 2016 11:00:11 +0530
Subject: Problem with spectral scan in VHT80 mode
In-Reply-To: <CAFc9h7uABMUJ349bgNJLcZDNL5hyp96CrYoc8PD9VDLv_-8rqw@mail.gmail.com>
References: <CAFc9h7vk6e-BntP+GMv8s2jaNSOkA=37rChTjss2-7mgupAv7Q@mail.gmail.com>
 <CAFc9h7uABMUJ349bgNJLcZDNL5hyp96CrYoc8PD9VDLv_-8rqw@mail.gmail.com>
Message-ID: <20160614053011.GB2800@atheros-ThinkPad-T61>

Hi Gaurang,

On Tue, Jun 14, 2016 at 01:08:29AM -0400, Gaurang Ramesh Naik wrote:
> Apologies for my previous e-mail. I had read the whole page once, but
> somehow I missed the point about 64 bins for VHT80. It's working now.

[shafi] may i know the chipset you are testing, also if its feasible
you can share the graph plots of the spectral scan .

> 
> On Tue, Jun 14, 2016 at 12:37 AM, Gaurang Ramesh Naik <gaurang at vt.edu> wrote:
> > Hello,
> >
> > I was trying the ath10k's spectral scan. I used the following commands
> > given on the link
> > https://wireless.wiki.kernel.org/en/users/drivers/ath10k/spectral
> >
> > echo 8 > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_count
> > echo manual > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
> > echo trigger > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
> > cat /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan0 >> /tmp/fft.dump
> >
> > I am using OpenWrt Bleeding edge. In the HT20 and HT40 mode, I
> > correctly get 8 samples. However, in the VHT80 mode, the /tmp/fft.dump
> > file generated is empty.
> >
> > In the open issues on the above link, it said that the HT40 and HT20
> > modes ignore the count parameter. That isn't the case for me. I seem
> > to get correct # of samples (I view the dump file using
> > https://github.com/simonwunderlich/FFT_eval). However, in the VHT80
> > mode, there seems to be no output. Am I doing something wrong here?
> >

regards,
shafi


From mohammed at qti.qualcomm.com  Mon Jun 13 22:33:54 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Tue, 14 Jun 2016 11:03:54 +0530
Subject: [PATCH] ath10k: Fix a typo in spectral code commments
Message-ID: <1465882434-594-1-git-send-email-mohammed@qca.qualcomm.com>

From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Found this obvious typo while going through the spectral
code design in ath10k

Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/spectral.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/spectral.c b/drivers/net/wireless/ath/ath10k/spectral.c
index 4671cfb..4510906 100644
--- a/drivers/net/wireless/ath/ath10k/spectral.c
+++ b/drivers/net/wireless/ath/ath10k/spectral.c
@@ -101,7 +101,7 @@ int ath10k_spectral_process_fft(struct ath10k *ar,
 		break;
 	case 80:
 		/* TODO: As experiments with an analogue sender and various
-		 * configuaritions (fft-sizes of 64/128/256 and 20/40/80 Mhz)
+		 * configurations (fft-sizes of 64/128/256 and 20/40/80 Mhz)
 		 * show, the particular configuration of 80 MHz/64 bins does
 		 * not match with the other smaples at all. Until the reason
 		 * for that is found, don't report these samples.
-- 
1.7.9.5



From rmanohar at qti.qualcomm.com  Mon Jun 13 23:17:28 2016
From: rmanohar at qti.qualcomm.com (Rajkumar Manoharan)
Date: Tue, 14 Jun 2016 11:47:28 +0530
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
Message-ID: <20160614061728.570-1-rmanohar@qti.qualcomm.com>

commit b057886524be ("ath10k: do not use coherent memory for allocated
device memory chunks") replaced coherent memory allocation for memory
chunks to fix low memory platforms. Unfortunately this is causing system
freeze on x86 platform while bringing up qca99x0 device. The system
hangs while DMA mapping bigger memory chunks (689816/865444 bytes). Fix
this by limiting maximum memory chunk size to 256 KiB per request.

Cc: Felix Fietkau <nbd at nbd.name>
Fixes: b057886524be ("ath10k: do not use coherent memory for allocated device memory chunks")
Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.c | 6 ++++++
 drivers/net/wireless/ath/ath10k/wmi.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 6279ab4a760e..7c15f65fe5ed 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -4411,6 +4411,12 @@ static int ath10k_wmi_alloc_chunk(struct ath10k *ar, u32 req_id,
 		if (!pool_size)
 			return -EINVAL;
 
+		if (pool_size > WMI_MAX_MEM_CHUNK_SIZE) {
+			num_units = WMI_MAX_MEM_CHUNK_SIZE /
+					round_up(unit_len, 4);
+			pool_size = num_units * round_up(unit_len, 4);
+		}
+
 		vaddr = kzalloc(pool_size, GFP_KERNEL | __GFP_NOWARN);
 		if (!vaddr)
 			num_units /= 2;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 90f594e89f94..dea1f235a54d 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6184,6 +6184,7 @@ struct wmi_roam_ev {
 #define ATH10K_DEFAULT_ATIM 0
 
 #define WMI_MAX_MEM_REQS 16
+#define WMI_MAX_MEM_CHUNK_SIZE (256 * 1024) /* 256 KB */
 
 struct wmi_scan_ev_arg {
 	__le32 event_type; /* %WMI_SCAN_EVENT_ */
-- 
2.8.3



From rmanohar at codeaurora.org  Mon Jun 13 23:21:48 2016
From: rmanohar at codeaurora.org (Rajkumar Manoharan)
Date: Tue, 14 Jun 2016 11:51:48 +0530
Subject: Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath
In-Reply-To: <57507269.1060108@candelatech.com>
References: <f495d218d54a4c4c859849a85f38ab0c@aphydexm01b.ap.qualcomm.com>
 <57506C7A.7070109@candelatech.com>
 <c3facd0acc1c2f49f4a4638bf0c2a591@codeaurora.org>
 <57507269.1060108@candelatech.com>
Message-ID: <ac15f3e10cedc20199051bab88b36eba@codeaurora.org>

On 2016-06-02 23:22, Ben Greear wrote:
> On 06/02/2016 10:46 AM, Rajkumar Manoharan wrote:
>> On 2016-06-02 22:57, Ben Greear wrote:
>>> On 06/02/2016 10:20 AM, Manoharan, Rajkumar wrote:
>>>> Found a regression in ath.git TOT that system hangs while probing 
>>>> qca99x0 device on x86_64 platform.
>>>> It seems the system hangs while DMA mapping of bigger memory chunks. 
>>>> Below are the list of memory
>>>> chucks requested by target for qca99x0 during service ready event. 
>>>> This issue is seen only on x86 platform.
>>>> No issues are observed on ARM platform (AP148). After reverting 
>>>> below commit able to bring up device on x86.
>>>> 
>>>> Jun  2 17:24:37 rmanohar-arch kernel: idx 0 pool_size 689816 
>>>> num_units 529 unit_len 1304
>>>> Jun  2 17:24:37 rmanohar-arch kernel: idx 1 pool_size 17152 
>>>> num_units 67 unit_len 256
>>>> Jun  2 17:24:37 rmanohar-arch kernel: idx 2 pool_size 68608 
>>>> num_units 67 unit_len 1024
>>>> Jun  2 17:24:37 rmanohar-arch kernel: idx 3 pool_size 274432 
>>>> num_units 67 unit_len 4096
>>>> Jun  2 17:24:37 rmanohar-arch kernel: idx 4 pool_size 107520 
>>>> num_units 35 unit_len 3072
>>>> Jun  2 17:24:37 rmanohar-arch kernel: idx 5 pool_size 6144 num_units 
>>>> 1 unit_len 6144
>>>> Jun  2 17:24:37 rmanohar-arch kernel: idx 6 pool_size 865444 
>>>> num_units 529 unit_len 1636
>>> 
>>> We have seen similar.  But, if we enable VT-d in our BIOS, then it
>>> works, at least in
>>> our scenarios.  I have not tried putting more than one 99x0 NIC in a
>>> system to date, so possibly
>>> more than one would cause more issues, and I guess systems without 
>>> VT-d might
>>> fail too...
>>> 
>> Yeah.. But the code should work even on non-VT-d systems. ins't it?
> 
> It would be great if it did.
> 
>>>> commit b057886524be060021e3cfad0ba8458c850330cd
>>>> Author: Felix Fietkau <nbd at openwrt.org>
>>>> Date:   Mon Nov 30 19:32:01 2015 +0100
>>>> 
>>>>      ath10k: do not use coherent memory for allocated device memory 
>>>> chunks
>>>> 
>>>>      Coherent memory is more expensive to allocate (and constrained 
>>>> on some
>>>>      architectures where it has to be pre-allocated). It is also 
>>>> completely
>>>>      unnecessary, since the host has no reason to even access these 
>>>> allocated
>>>>      memory spaces
>>>> 
>>>>      Signed-off-by: Felix Fietkau <nbd at openwrt.org>
>>>>      Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>
>>>> 
>>>> 
>> Ben,
>> 
>> Can you help to confirm this issue by disabling VT-d and bring up 
>> qca99x0? If it freezes, try reverting the patch.
> 
> At the time, I bisected to this commit as well, but I decided to just
> live with it
> since it seemed it fixed some other bug and we had a work-around.  My
> understanding
> is that without the patch above, some ARM systems failed to work.
> 
Ben,

I posted a fix for the freeze issue 
(https://patchwork.kernel.org/patch/9175029/). Can you please give a try 
with VT-d disabled?

-Rajkumar



From mohammed at qti.qualcomm.com  Tue Jun 14 00:54:25 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Tue, 14 Jun 2016 13:24:25 +0530
Subject: [PATCH v4 1/2] ath10k: Add support for ath10k_sta_statistics support
Message-ID: <1465890866-2390-1-git-send-email-mohammed@qca.qualcomm.com>

From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Enable support for 'drv_sta_statistics' callback.
Export rx_duration support if available to cfg80211/nl80211

This can also act as a placeholder for any new per STA stats support

Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
---

[v4] rebased over 'pending' branch
[v3] removed conditions for ath10k state checks based on Michal's suggestion

Both the dependent changes are merged now in master tree

1. cfg80211/nl80211: Add support for NL80211_STA_INFO_RX_DURATION
2. iw: Add support for NL80211_STA_INFO_RX_DURATION netlink
 attribute
---
 drivers/net/wireless/ath/ath10k/debug.h       |  3 +++
 drivers/net/wireless/ath/ath10k/debugfs_sta.c | 14 ++++++++++++++
 drivers/net/wireless/ath/ath10k/mac.c         |  1 +
 3 files changed, 18 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index dc549c4..c458fa9 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -156,6 +156,9 @@ void ath10k_sta_add_debugfs(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
 			    struct ieee80211_sta *sta, struct dentry *dir);
 void ath10k_sta_update_rx_duration(struct ath10k *ar,
 				   struct ath10k_fw_stats *stats);
+void ath10k_sta_statistics(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
+			   struct ieee80211_sta *sta,
+			   struct station_info *sinfo);
 #else
 static inline
 void ath10k_sta_update_rx_duration(struct ath10k *ar,
diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
index 0da8a57..60e5da0 100644
--- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
+++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
@@ -65,6 +65,20 @@ void ath10k_sta_update_rx_duration(struct ath10k *ar,
 		ath10k_sta_update_stats_rx_duration(ar, stats);
 }
 
+void ath10k_sta_statistics(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
+			   struct ieee80211_sta *sta,
+			   struct station_info *sinfo)
+{
+	struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
+	struct ath10k *ar = arsta->arvif->ar;
+
+	if (!ath10k_peer_stats_enabled(ar))
+		return;
+
+	sinfo->rx_duration = arsta->rx_duration;
+	sinfo->filled |= 1ULL << NL80211_STA_INFO_RX_DURATION;
+}
+
 static ssize_t ath10k_dbg_sta_read_aggr_mode(struct file *file,
 					     char __user *user_buf,
 					     size_t count, loff_t *ppos)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 3a170b1..1fe33c36 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7402,6 +7402,7 @@ static const struct ieee80211_ops ath10k_ops = {
 #endif
 #ifdef CONFIG_MAC80211_DEBUGFS
 	.sta_add_debugfs		= ath10k_sta_add_debugfs,
+	.sta_statistics			= ath10k_sta_statistics,
 #endif
 };
 
-- 
1.9.1



From mohammed at qti.qualcomm.com  Tue Jun 14 00:54:26 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Tue, 14 Jun 2016 13:24:26 +0530
Subject: [PATCH v4 2/2] ath10k: Remove debugfs support for Per STA total rx
 duration
In-Reply-To: <1465890866-2390-1-git-send-email-mohammed@qca.qualcomm.com>
References: <1465890866-2390-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <1465890866-2390-2-git-send-email-mohammed@qca.qualcomm.com>

From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

cfg80211/nl80211 interface changes for per STA total rx-duration and
very basic 'ath10k_sta_statistics'  mac80211 callback is implemented
to extend support for per station statistics from the driver.

Also provision in 'iw dev wlan#N station dump' to parse rx-duration
is supported. So its safer to remove the debugfs entry for per STA
rx-duration

Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
---
[v4 rebased over pending branch]

 drivers/net/wireless/ath/ath10k/debugfs_sta.c | 24 ------------------------
 1 file changed, 24 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
index 60e5da0..9955fea 100644
--- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
+++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
@@ -293,28 +293,6 @@ static const struct file_operations fops_delba = {
 	.llseek = default_llseek,
 };
 
-static ssize_t ath10k_dbg_sta_read_rx_duration(struct file *file,
-					       char __user *user_buf,
-					       size_t count, loff_t *ppos)
-{
-	struct ieee80211_sta *sta = file->private_data;
-	struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
-	char buf[100];
-	int len = 0;
-
-	len = scnprintf(buf, sizeof(buf),
-			"%llu usecs\n", arsta->rx_duration);
-
-	return simple_read_from_buffer(user_buf, count, ppos, buf, len);
-}
-
-static const struct file_operations fops_rx_duration = {
-	.read = ath10k_dbg_sta_read_rx_duration,
-	.open = simple_open,
-	.owner = THIS_MODULE,
-	.llseek = default_llseek,
-};
-
 void ath10k_sta_add_debugfs(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
 			    struct ieee80211_sta *sta, struct dentry *dir)
 {
@@ -323,6 +301,4 @@ void ath10k_sta_add_debugfs(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
 	debugfs_create_file("addba", S_IWUSR, dir, sta, &fops_addba);
 	debugfs_create_file("addba_resp", S_IWUSR, dir, sta, &fops_addba_resp);
 	debugfs_create_file("delba", S_IWUSR, dir, sta, &fops_delba);
-	debugfs_create_file("rx_duration", S_IRUGO, dir, sta,
-			    &fops_rx_duration);
 }
-- 
1.9.1



From kvalo at qca.qualcomm.com  Tue Jun 14 04:53:53 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Tue, 14 Jun 2016 11:53:53 +0000
Subject: [PATCH] ath10k: Fix some of the macro definitions of HTT_RX_IND
 message
In-Reply-To: <1464870025-4557-1-git-send-email-vthiagar@qti.qualcomm.com>
 (Vasanthakumar Thiagarajan's message of "Thu, 2 Jun 2016 17:50:25	+0530")
References: <1464870025-4557-1-git-send-email-vthiagar@qti.qualcomm.com>
Message-ID: <87wpls2dgv.fsf@kamboji.qca.qualcomm.com>

Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com> writes:

> Only five bits are defined to pass tid information in HTT_RX_IND
> message, so the mask which can be used to extract tid should be 0x1f
> instead of the current 0x3f. Also, macros which can be used to extract
> flush_valid and release_valid bits have to be left shifted one bit less
> because these information follow the tid right after. This patch does
> not really fix anything functionally because these macros are not used
> currently.
>
> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com>

Applied to ath.git, thanks.

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Tue Jun 14 04:56:44 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 14 Jun 2016 13:56:44 +0200
Subject: [v3,1/2] ath10k: remove duplicate and unused rx rate flags
In-Reply-To: <1464877482-14620-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <8c7494314722406d9af8328fdc51b1ba@euamsexm01a.eu.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> All these flags are not used and their use is completely
> covered by 'ath10k_hw_rate_ofdm', 'ath10k_hw_rate_cck',
> and RX_PPDU_START_RATE_FLAG
> 
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Thanks, 2 patches applied to ath-next branch of ath.git:

9cd24451859a ath10k: remove duplicate and unused rx rate flags
5269c65900d9 ath10k: fix CCK h/w rates for QCA99X0 and newer chipsets

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9150143/



From kvalo at qca.qualcomm.com  Tue Jun 14 04:59:27 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 14 Jun 2016 13:59:27 +0200
Subject: [1/2] ath10k: Define an enum to enable cycle counter wraparound
 logic
In-Reply-To: <1464968596-19834-1-git-send-email-vthiagar@qti.qualcomm.com>
Message-ID: <751c58687e0842228c179608fd4018ce@euamsexm01a.eu.qualcomm.com>

Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com> wrote:
> QCA988X hw implements a different cycle counter wraparound
> behaviour when compared to QCA4019. To properly handle different
> wraparound logic for these chipsets replace already available
> bool hw_params member, has_shifted_cc_wraparound, with an
> enum which could be extended to handle different wraparound
> behaviour. This patch keeps the existing logic functionally
> same and a prepares cycle counter wraparound handling to
> extend for other chips.
> 
> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com>

Thanks, 2 patches applied to ath-next branch of ath.git:

26c197600b43 ath10k: define an enum to enable cycle counter wraparound logic
8e100354a985 ath10k: fix cycle counter wraparound handling for QCA4019

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9153403/



From kvalo at qca.qualcomm.com  Tue Jun 14 05:06:35 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 14 Jun 2016 14:06:35 +0200
Subject: ath10k: fix deadlock while processing rx_in_ord_ind
In-Reply-To: <20160609060355.16219-1-rmanohar@qti.qualcomm.com>
Message-ID: <acc80c66985d43dfbc9d5a6a17fcc85e@euamsexm01a.eu.qualcomm.com>

Rajkumar Manoharan <rmanohar at qti.qualcomm.com> wrote:
> commit 5c86d97bcc1d ("ath10k: combine txrx and replenish task")
> introduced deadlock while processing rx in order indication message
> for qca6174 based devices. While merging replenish and txrx tasklets,
> replenish task should be called out of htt rx ring locking since it
> is also try to acquire the same lock.
> 
> Unfortunately this issue is not exposed by other solutions (qca988x,
> qca99x0 & qca4019), as rx_in_ord_ind message is specific to qca6174
> based devices. This patch fixes
> 
> =============================================
> [ INFO: possible recursive locking detected ]
> 4.7.0-rc2-wt-ath+ #1353 Tainted: G            E
> ---------------------------------------------
> swapper/3/0 is trying to acquire lock:
>  (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d7ef19>]
> ath10k_htt_rx_msdu_buff_replenish+0x29/0x90 [ath10k_core]
> 
> but task is already holding lock:
>  (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d82cab>]
> ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]
> 
> other info that might help us debug this:
>  Possible unsafe locking scenario:
> 
>        CPU0
>        ----
>   lock(&(&htt->rx_ring.lock)->rlock);
>   lock(&(&htt->rx_ring.lock)->rlock);
> 
>  *** DEADLOCK ***
> 
>  May be due to missing lock nesting notation
> 
> 1 lock held by swapper/3/0:
>  #0:  (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d82cab>]
> ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=119151
> Fixes: 5c86d97bcc1d ("ath10k: combine txrx and replenish task")
> Reported-by: Mike Lothian <mike at fireburn.co.uk>
> Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>

Thanks, 1 patch applied to ath-current branch of ath.git:

e50525bef593 ath10k: fix deadlock while processing rx_in_ord_ind

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9166323/



From kvalo at qca.qualcomm.com  Tue Jun 14 06:51:24 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Tue, 14 Jun 2016 13:51:24 +0000
Subject: [PATCH] ath10k: fix potential null dereference bugs
In-Reply-To: <1465823880.10050.3.camel@sipsolutions.net> (Johannes Berg's
 message of "Mon, 13 Jun 2016 15:18:00 +0200")
References: <1465563164-783-1-git-send-email-me@bobcopeland.com>
 <CA+BoTQkg+uea_YzUgrVBPhA8uRxNpd29Kd1y1tvt0a-JyOSLQw@mail.gmail.com>
 <1465808939.2434.1.camel@sipsolutions.net>	<20160613130507.GA11074@localhost>
 <1465823880.10050.3.camel@sipsolutions.net>
Message-ID: <87shwf3mlh.fsf@kamboji.qca.qualcomm.com>

Johannes Berg <johannes at sipsolutions.net> writes:

> On Mon, 2016-06-13 at 09:05 -0400, Bob Copeland wrote:
>>?
>> So I did just go and check the generated code for each of these cases
>> and gcc didn't elide the subsequent if-test, at least on x86-64 and
>> my compiler / build config.??Given http://lwn.net/Articles/342330, it
>> seems possible, though.
>
> It's not clear that's the same situation, since tun->sk is very likely
> to have been an actual pointer, not an embedded thing like drv_priv.
>
> However, with all this, I think I'd simply not take any chances - the
> patch isn't exactly invasive and in some cases (for example the first
> hunk of the patch) will even improve the code to the point where the
> compiler could warn about uninitialized usage of the pointer when the
> code gets modified to use it in case of !txq->sta.
>
> I'd take it, but I guess it's Kalle's decision :)

Yeah, I'm leaning towards Johannes. These are not really invasive.

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Tue Jun 14 06:53:12 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Tue, 14 Jun 2016 13:53:12 +0000
Subject: [PATCH] ath10k: fix potential null dereference bugs
In-Reply-To: <1465563164-783-1-git-send-email-me@bobcopeland.com> (Bob
 Copeland's message of "Fri, 10 Jun 2016 08:52:44 -0400")
References: <1465563164-783-1-git-send-email-me@bobcopeland.com>
Message-ID: <87oa733mig.fsf@kamboji.qca.qualcomm.com>

Bob Copeland <me at bobcopeland.com> writes:

> Smatch warns about a number of cases in ath10k where a pointer is
> null-checked after it has already been dereferenced, in code involving
> ath10k private virtual interface pointers.
>
> Fix these by making the dereference happen later.
>
> Addresses the following smatch warnings:
>
> drivers/net/wireless/ath/ath10k/mac.c:3651 ath10k_mac_txq_init() warn: variable dereferenced before check 'txq' (see line 3649)
> drivers/net/wireless/ath/ath10k/mac.c:3664 ath10k_mac_txq_unref() warn: variable dereferenced before check 'txq' (see line 3659)
> drivers/net/wireless/ath/ath10k/htt_tx.c:70 __ath10k_htt_tx_txq_recalc() warn: variable dereferenced before check 'txq->sta' (see line 52)
> drivers/net/wireless/ath/ath10k/htt_tx.c:740 ath10k_htt_tx_get_vdev_id() warn: variable dereferenced before check 'cb->vif' (see line 736)
> drivers/net/wireless/ath/ath10k/txrx.c:86 ath10k_txrx_tx_unref() warn: variable dereferenced before check 'txq' (see line 84)
> drivers/net/wireless/ath/ath10k/wmi.c:1837 ath10k_wmi_op_gen_mgmt_tx() warn: variable dereferenced before check 'cb->vif' (see line 1825)
>
> Signed-off-by: Bob Copeland <me at bobcopeland.com>

There was a new checkpatch warning:

drivers/net/wireless/ath/ath10k/htt_tx.c:740: braces {} should be used on all arms of this statement

I "fixed" it like this, which is folded to the patch in pending branch
(pushed soon):

diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index dfcc43d80808..ae5b33fe5ba8 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -737,15 +737,16 @@ static u8 ath10k_htt_tx_get_vdev_id(struct ath10k *ar, struct sk_buff *skb)
 	struct ath10k_skb_cb *cb = ATH10K_SKB_CB(skb);
 	struct ath10k_vif *arvif;
 
-	if (info->flags & IEEE80211_TX_CTL_TX_OFFCHAN)
+	if (info->flags & IEEE80211_TX_CTL_TX_OFFCHAN) {
 		return ar->scan.vdev_id;
-	else if (cb->vif) {
+	} else if (cb->vif) {
 		arvif = (void *)cb->vif->drv_priv;
 		return arvif->vdev_id;
-	} else if (ar->monitor_started)
+	} else if (ar->monitor_started) {
 		return ar->monitor_vdev_id;
-	else
+	} else {
 		return 0;
+	}
 }
 
 static u8 ath10k_htt_tx_get_tid(struct sk_buff *skb, bool is_eth)

From kvalo at qca.qualcomm.com  Tue Jun 14 06:58:25 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Tue, 14 Jun 2016 13:58:25 +0000
Subject: [PATCH v4 1/2] ath10k: Add support for ath10k_sta_statistics
 support
In-Reply-To: <1465890866-2390-1-git-send-email-mohammed@qca.qualcomm.com>
 (Mohammed Shafi Shajakhan's message of "Tue, 14 Jun 2016 13:24:25	+0530")
References: <1465890866-2390-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <87k2hr3m9r.fsf@kamboji.qca.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> writes:

> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
>
> Enable support for 'drv_sta_statistics' callback.
> Export rx_duration support if available to cfg80211/nl80211
>
> This can also act as a placeholder for any new per STA stats support
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> ---
>
> [v4] rebased over 'pending' branch
> [v3] removed conditions for ath10k state checks based on Michal's suggestion
>
> Both the dependent changes are merged now in master tree
>
> 1. cfg80211/nl80211: Add support for NL80211_STA_INFO_RX_DURATION
> 2. iw: Add support for NL80211_STA_INFO_RX_DURATION netlink
>  attribute

But these are not in ath-next branch yet, so I can't take these until I
have updated ath-next.

Also please ping instead of resending patches. These are already waiting
in patchwork:

https://patchwork.kernel.org/patch/8993601/
https://patchwork.kernel.org/patch/8993621/

-- 
Kalle Valo

From me at bobcopeland.com  Tue Jun 14 07:16:06 2016
From: me at bobcopeland.com (Bob Copeland)
Date: Tue, 14 Jun 2016 10:16:06 -0400
Subject: [PATCH] ath10k: fix potential null dereference bugs
In-Reply-To: <87shwf3mlh.fsf@kamboji.qca.qualcomm.com>
References: <1465563164-783-1-git-send-email-me@bobcopeland.com>
 <CA+BoTQkg+uea_YzUgrVBPhA8uRxNpd29Kd1y1tvt0a-JyOSLQw@mail.gmail.com>
 <1465808939.2434.1.camel@sipsolutions.net>
 <20160613130507.GA11074@localhost>
 <1465823880.10050.3.camel@sipsolutions.net>
 <87shwf3mlh.fsf@kamboji.qca.qualcomm.com>
Message-ID: <20160614141606.GA713@localhost>

On Tue, Jun 14, 2016 at 01:51:24PM +0000, Kalle Valo wrote:
> > It's not clear that's the same situation, since tun->sk is very likely
> > to have been an actual pointer, not an embedded thing like drv_priv.

Just to follow up on that thread, I did research it a bit yesterday and
came to the conclusion that it is UB even when the target is in the same
struct.  However, in a not very scientific survey, I didn't see either clang
or gcc remove the test in a simplified test case (with -O3 and without
-fno-delete-null-pointer-checks).  If drv_priv were an actual pointer, gcc
did remove it but clang did not.  So, there's that.

> > However, with all this, I think I'd simply not take any chances - the
> > patch isn't exactly invasive and in some cases (for example the first
> > hunk of the patch) will even improve the code to the point where the
> > compiler could warn about uninitialized usage of the pointer when the
> > code gets modified to use it in case of !txq->sta.
> >
> > I'd take it, but I guess it's Kalle's decision :)
> 
> Yeah, I'm leaning towards Johannes. These are not really invasive.

Thanks, and sorry about the checkpatch -- I did run checkpatch on it but
for some reason my version only complained about some of them.

-- 
Bob Copeland %% http://bobcopeland.com/


From kvalo at qca.qualcomm.com  Tue Jun 14 07:39:52 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Tue, 14 Jun 2016 14:39:52 +0000
Subject: [PATCH] ath10k: fix potential null dereference bugs
In-Reply-To: <20160614141606.GA713@localhost> (Bob Copeland's message of "Tue, 
 14 Jun 2016 10:16:06 -0400")
References: <1465563164-783-1-git-send-email-me@bobcopeland.com>
 <CA+BoTQkg+uea_YzUgrVBPhA8uRxNpd29Kd1y1tvt0a-JyOSLQw@mail.gmail.com>
 <1465808939.2434.1.camel@sipsolutions.net>	<20160613130507.GA11074@localhost>
 <1465823880.10050.3.camel@sipsolutions.net>
 <87shwf3mlh.fsf@kamboji.qca.qualcomm.com>	<20160614141606.GA713@localhost>
Message-ID: <87d1njzvew.fsf@kamboji.qca.qualcomm.com>

Bob Copeland <me at bobcopeland.com> writes:

>> > However, with all this, I think I'd simply not take any chances - the
>> > patch isn't exactly invasive and in some cases (for example the first
>> > hunk of the patch) will even improve the code to the point where the
>> > compiler could warn about uninitialized usage of the pointer when the
>> > code gets modified to use it in case of !txq->sta.
>> >
>> > I'd take it, but I guess it's Kalle's decision :)
>> 
>> Yeah, I'm leaning towards Johannes. These are not really invasive.
>
> Thanks, and sorry about the checkpatch -- I did run checkpatch on it but
> for some reason my version only complained about some of them.

I actually have a custom script which enables (and disables) various
checkpatch checks, most likely that's why you didn't see it.

https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-check

-- 
Kalle Valo

From mohammed at codeaurora.org  Tue Jun 14 08:21:31 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Tue, 14 Jun 2016 20:51:31 +0530
Subject: [PATCH v4 1/2] ath10k: Add support for ath10k_sta_statistics
 support
In-Reply-To: <87k2hr3m9r.fsf@kamboji.qca.qualcomm.com>
References: <1465890866-2390-1-git-send-email-mohammed@qca.qualcomm.com>
 <87k2hr3m9r.fsf@kamboji.qca.qualcomm.com>
Message-ID: <20160614152131.GA3941@atheros-ThinkPad-T61>

Hi Kalle,

On Tue, Jun 14, 2016 at 01:58:25PM +0000, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> writes:
> 
> > From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> >
> > Enable support for 'drv_sta_statistics' callback.
> > Export rx_duration support if available to cfg80211/nl80211
> >
> > This can also act as a placeholder for any new per STA stats support
> >
> > Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> > ---
> >
> > [v4] rebased over 'pending' branch
> > [v3] removed conditions for ath10k state checks based on Michal's suggestion
> >
> > Both the dependent changes are merged now in master tree
> >
> > 1. cfg80211/nl80211: Add support for NL80211_STA_INFO_RX_DURATION
> > 2. iw: Add support for NL80211_STA_INFO_RX_DURATION netlink
> >  attribute
> 
> But these are not in ath-next branch yet, so I can't take these until I
> have updated ath-next.

[shafi] oops ! sorry i thought they are finally in

> 
> Also please ping instead of resending patches. These are already waiting
> in patchwork:
> 
> https://patchwork.kernel.org/patch/8993601/
> https://patchwork.kernel.org/patch/8993621/
>

[shafi] oh ok thanks, sorry i thought this required a rebased over pending
branch next time i will do this

a) ping you first
b) if required send a rebased version

regards,
shafi


From greearb at candelatech.com  Tue Jun 14 06:44:28 2016
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 14 Jun 2016 06:44:28 -0700
Subject: Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath
In-Reply-To: <ac15f3e10cedc20199051bab88b36eba@codeaurora.org>
References: <f495d218d54a4c4c859849a85f38ab0c@aphydexm01b.ap.qualcomm.com>
 <57506C7A.7070109@candelatech.com>
 <c3facd0acc1c2f49f4a4638bf0c2a591@codeaurora.org>
 <57507269.1060108@candelatech.com>
 <ac15f3e10cedc20199051bab88b36eba@codeaurora.org>
Message-ID: <57600A3C.9000104@candelatech.com>



On 06/13/2016 11:21 PM, Rajkumar Manoharan wrote:
> On 2016-06-02 23:22, Ben Greear wrote:

>> At the time, I bisected to this commit as well, but I decided to just
>> live with it
>> since it seemed it fixed some other bug and we had a work-around.  My
>> understanding
>> is that without the patch above, some ARM systems failed to work.
>>
> Ben,
>
> I posted a fix for the freeze issue (https://patchwork.kernel.org/patch/9175029/). Can you please give a try with VT-d disabled?
>
> -Rajkumar

Yes, but it might be a bit.  I just ported my patches to 4.7, and will add yours
there.  We are mainly focussed on getting a stable 4.4+ out the door currently though.

Were you able to test on the ARM platform that originally had the problem that
Felix's patch was supposed to fix?

Thanks,
Ben

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


From gaurang at vt.edu  Tue Jun 14 09:33:38 2016
From: gaurang at vt.edu (Gaurang Ramesh Naik)
Date: Tue, 14 Jun 2016 12:33:38 -0400
Subject: Problem with spectral scan in VHT80 mode
In-Reply-To: <20160614053011.GB2800@atheros-ThinkPad-T61>
References: <CAFc9h7vk6e-BntP+GMv8s2jaNSOkA=37rChTjss2-7mgupAv7Q@mail.gmail.com>
 <CAFc9h7uABMUJ349bgNJLcZDNL5hyp96CrYoc8PD9VDLv_-8rqw@mail.gmail.com>
 <20160614053011.GB2800@atheros-ThinkPad-T61>
Message-ID: <CAFc9h7u4yTesQR3D++D3sKZ9Lv9tek_=JMtwzs=1jTNnXjVvBw@mail.gmail.com>

Hi Shafi,

I am using QCA9882 (I'm using RB911G-5HPacD). This is what I observed
http://postimg.org/image/vha3pmvhz/

I have one AP-Client running iperf over HT40 and I'm using another AP
for the scan.

Thanks,
Gaurang.

On Tue, Jun 14, 2016 at 1:30 AM, Mohammed Shafi Shajakhan
<mohammed at codeaurora.org> wrote:
> Hi Gaurang,
>
> On Tue, Jun 14, 2016 at 01:08:29AM -0400, Gaurang Ramesh Naik wrote:
>> Apologies for my previous e-mail. I had read the whole page once, but
>> somehow I missed the point about 64 bins for VHT80. It's working now.
>
> [shafi] may i know the chipset you are testing, also if its feasible
> you can share the graph plots of the spectral scan .
>
>>
>> On Tue, Jun 14, 2016 at 12:37 AM, Gaurang Ramesh Naik <gaurang at vt.edu> wrote:
>> > Hello,
>> >
>> > I was trying the ath10k's spectral scan. I used the following commands
>> > given on the link
>> > https://wireless.wiki.kernel.org/en/users/drivers/ath10k/spectral
>> >
>> > echo 8 > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_count
>> > echo manual > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
>> > echo trigger > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
>> > cat /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan0 >> /tmp/fft.dump
>> >
>> > I am using OpenWrt Bleeding edge. In the HT20 and HT40 mode, I
>> > correctly get 8 samples. However, in the VHT80 mode, the /tmp/fft.dump
>> > file generated is empty.
>> >
>> > In the open issues on the above link, it said that the HT40 and HT20
>> > modes ignore the count parameter. That isn't the case for me. I seem
>> > to get correct # of samples (I view the dump file using
>> > https://github.com/simonwunderlich/FFT_eval). However, in the VHT80
>> > mode, there seems to be no output. Am I doing something wrong here?
>> >
>
> regards,
> shafi


From arnagara at qti.qualcomm.com  Tue Jun 14 10:38:31 2016
From: arnagara at qti.qualcomm.com (Ashok Raj Nagarajan)
Date: Tue, 14 Jun 2016 23:08:31 +0530
Subject: [PATCH] ath10k: add support for controlling tx power to a station
Message-ID: <1465925914-6404-1-git-send-email-arnagara@qti.qualcomm.com>

This patch will add the support to control the transmit power for traffic
to a station associated with the AP. Userspace provide the transmit power
value in mBm units and the allowed range is from 0 to 70. Underlying FW
will enforce that the maximum tx power will be based on the regulatory
requirements. If the user given transmit power is greater than the allowed
tx power in the given channel, then the FW will use the maximum tx power
in the same channel.

When 0 is sent to the FW as tx power, it will revert to the automatic tx
power for the station.

Signed-off-by: Ashok Raj Nagarajan <arnagara at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/debug.h |  3 +++
 drivers/net/wireless/ath/ath10k/mac.c   | 29 +++++++++++++++++++++++++++++
 drivers/net/wireless/ath/ath10k/wmi.h   |  1 +
 3 files changed, 33 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 75c89e3..340950b 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -59,6 +59,9 @@ enum ath10k_dbg_aggr_mode {
 /* FIXME: How to calculate the buffer size sanely? */
 #define ATH10K_FW_STATS_BUF_SIZE (1024 * 1024)
 
+#define ATH10K_TX_POWER_MAX_VAL 70
+#define ATH10K_TX_POWER_MIN_VAL 0
+
 extern unsigned int ath10k_debug_mask;
 
 __printf(2, 3) void ath10k_info(struct ath10k *ar, const char *fmt, ...);
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d4b7a16..79aaf6c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5824,6 +5824,34 @@ static int ath10k_mac_tdls_vifs_count(struct ieee80211_hw *hw)
 	return num_tdls_vifs;
 }
 
+static int ath10k_sta_set_txpwr(struct ieee80211_hw *hw,
+				struct ieee80211_vif *vif,
+				struct ieee80211_sta *sta)
+{
+	struct ath10k *ar = hw->priv;
+	struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+	int ret = 0;
+	u8 txpwr;
+
+	txpwr = sta->txpwr;
+	if (txpwr > ATH10K_TX_POWER_MAX_VAL || txpwr < ATH10K_TX_POWER_MIN_VAL)
+		return -EINVAL;
+
+	mutex_lock(&ar->conf_mutex);
+
+	ret = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
+					WMI_PEER_USE_FIXED_PWR, txpwr);
+	if (ret) {
+		ath10k_warn(ar, "failed to set tx power for station ret: %d\n",
+			    ret);
+		goto out;
+	}
+
+out:
+	mutex_unlock(&ar->conf_mutex);
+	return ret;
+}
+
 static int ath10k_sta_state(struct ieee80211_hw *hw,
 			    struct ieee80211_vif *vif,
 			    struct ieee80211_sta *sta,
@@ -7368,6 +7396,7 @@ static const struct ieee80211_ops ath10k_ops = {
 	.set_key			= ath10k_set_key,
 	.set_default_unicast_key        = ath10k_set_default_unicast_key,
 	.sta_state			= ath10k_sta_state,
+	.sta_set_txpwr			= ath10k_sta_set_txpwr,
 	.conf_tx			= ath10k_conf_tx,
 	.remain_on_channel		= ath10k_remain_on_channel,
 	.cancel_remain_on_channel	= ath10k_cancel_remain_on_channel,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 90f594e..f4d4e6e 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -5761,6 +5761,7 @@ enum wmi_peer_param {
 	WMI_PEER_CHAN_WIDTH = 0x4,
 	WMI_PEER_NSS        = 0x5,
 	WMI_PEER_USE_4ADDR  = 0x6,
+	WMI_PEER_USE_FIXED_PWR = 0x8,
 	WMI_PEER_DUMMY_VAR  = 0xff, /* dummy parameter for STA PS workaround */
 };
 
-- 
1.9.1



From arnagara at qti.qualcomm.com  Tue Jun 14 10:44:16 2016
From: arnagara at qti.qualcomm.com (Ashok Raj Nagarajan)
Date: Tue, 14 Jun 2016 23:14:16 +0530
Subject: [PATCH 1/2] cfg80211: Add support to set tx power for a station
 associated
Message-ID: <1465926256-6463-1-git-send-email-arnagara@qti.qualcomm.com>

This patch adds support to set transmit power setting type and transmit
power level attributes to NL80211_CMD_SET_STATION in order to facilitate
adjusting the transmit power level of a station associated to the AP.

The added attributes allow selection of automatic and limited transmit
power level, with the level defined in mBm format.

Signed-off-by: Ashok Raj Nagarajan <arnagara at qti.qualcomm.com>
---
 include/net/cfg80211.h       |  5 ++++
 include/uapi/linux/nl80211.h | 12 ++++++++++
 net/wireless/nl80211.c       | 54 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 71 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 6392167..4bf761d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -797,6 +797,10 @@ enum station_parameters_apply_mask {
  * @opmode_notif: operating mode field from Operating Mode Notification
  * @opmode_notif_used: information if operating mode field is used
  * @support_p2p_ps: information if station supports P2P PS mechanism
+ * @txpwr: tx power (in mBm) to be used for sending data traffic. If tx power
+ *	is not provided, the default per-interface tx power setting will be
+ *	overriding. Driver should be picking up the lowest tx power, either tx
+ *	power per-interface or per-station.
  */
 struct station_parameters {
 	const u8 *supported_rates;
@@ -823,6 +827,7 @@ struct station_parameters {
 	u8 opmode_notif;
 	bool opmode_notif_used;
 	int support_p2p_ps;
+	unsigned int txpwr;
 };
 
 /**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index e23d786..fe28006 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1819,6 +1819,15 @@ enum nl80211_commands {
  *
  * @NL80211_ATTR_PAD: attribute used for padding for 64-bit alignment
  *
+ * @NL80211_ATTR_STA_TX_POWER_SETTING: Transmit power setting type (u32) for
+ *	station associated with the AP. See &enum nl80211_tx_power_setting for
+ *	possible values.
+ * @NL80211_ATTR_STA_TX_POWER: Transmit power level (u32) in mBm units. This
+ *	allows to set Tx power for a station. If this attribute is not included,
+ *	the default per-interface tx power setting will be overriding. Driver
+ *	should be picking up the lowest tx power, either tx power per-interface
+ *	or per-station.
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2201,6 +2210,9 @@ enum nl80211_attrs {
 
 	NL80211_ATTR_PAD,
 
+	NL80211_ATTR_STA_TX_POWER_SETTING,
+	NL80211_ATTR_STA_TX_POWER,
+
 	/* add attributes here, update the policy in nl80211.c */
 
 	__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d759901..0ef7377 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -257,6 +257,8 @@ static const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
 	[NL80211_ATTR_STA_SUPPORTED_RATES] = { .type = NLA_BINARY,
 					       .len = NL80211_MAX_SUPP_RATES },
 	[NL80211_ATTR_STA_PLINK_ACTION] = { .type = NLA_U8 },
+	[NL80211_ATTR_STA_TX_POWER_SETTING] = { .type = NLA_U32 },
+	[NL80211_ATTR_STA_TX_POWER] = { .type = NLA_U32 },
 	[NL80211_ATTR_STA_VLAN] = { .type = NLA_U32 },
 	[NL80211_ATTR_MNTR_FLAGS] = { /* NLA_NESTED can't be empty */ },
 	[NL80211_ATTR_MESH_ID] = { .type = NLA_BINARY,
@@ -4380,6 +4382,32 @@ static int nl80211_set_station(struct sk_buff *skb, struct genl_info *info)
 		params.local_pm = pm;
 	}
 
+	if (info->attrs[NL80211_ATTR_STA_TX_POWER_SETTING]) {
+		enum nl80211_tx_power_setting type;
+		int idx;
+
+		if (!rdev->ops->set_tx_power)
+			return -EOPNOTSUPP;
+
+		idx = NL80211_ATTR_STA_TX_POWER_SETTING;
+		type = nla_get_u32(info->attrs[idx]);
+
+		if (!info->attrs[NL80211_ATTR_STA_TX_POWER] &&
+		    (type != NL80211_TX_POWER_AUTOMATIC))
+			return -EINVAL;
+
+		if (type != NL80211_TX_POWER_AUTOMATIC) {
+			if (type == NL80211_TX_POWER_LIMITED) {
+				idx = NL80211_ATTR_STA_TX_POWER;
+				params.txpwr = nla_get_u32(info->attrs[idx]);
+			} else {
+				return -EINVAL;
+			}
+		} else {
+			params.txpwr = 0;
+		}
+	}
+
 	/* Include parameters for TDLS peer (will check later) */
 	err = nl80211_set_station_tdls(info, &params);
 	if (err)
@@ -4507,6 +4535,32 @@ static int nl80211_new_station(struct sk_buff *skb, struct genl_info *info)
 			return -EINVAL;
 	}
 
+	if (info->attrs[NL80211_ATTR_STA_TX_POWER_SETTING]) {
+		enum nl80211_tx_power_setting type;
+		int idx;
+
+		if (!rdev->ops->set_tx_power)
+			return -EOPNOTSUPP;
+
+		idx = NL80211_ATTR_STA_TX_POWER_SETTING;
+		type = nla_get_u32(info->attrs[idx]);
+
+		if (!info->attrs[NL80211_ATTR_STA_TX_POWER] &&
+		    (type != NL80211_TX_POWER_AUTOMATIC))
+			return -EINVAL;
+
+		if (type != NL80211_TX_POWER_AUTOMATIC) {
+			if (type == NL80211_TX_POWER_LIMITED) {
+				idx = NL80211_ATTR_STA_TX_POWER;
+				params.txpwr = nla_get_u32(info->attrs[idx]);
+			} else {
+				return -EINVAL;
+			}
+		} else {
+			params.txpwr = 0;
+		}
+	}
+
 	err = nl80211_parse_sta_channel_info(info, &params);
 	if (err)
 		return err;
-- 
1.9.1



From arnagara at qti.qualcomm.com  Tue Jun 14 10:44:37 2016
From: arnagara at qti.qualcomm.com (Ashok Raj Nagarajan)
Date: Tue, 14 Jun 2016 23:14:37 +0530
Subject: [PATCH 2/2] mac80211: store tx power value from user to station
Message-ID: <1465926277-6509-1-git-send-email-arnagara@qti.qualcomm.com>

This patch introduce a new driver callback drv_sta_set_txpwr. This API will
copy the transmit power value passed from user space and call the driver
callback to set the tx power for the station.

Signed-off-by: Ashok Raj Nagarajan <arnagara at qti.qualcomm.com>
---
 include/net/mac80211.h    |  6 ++++++
 net/mac80211/cfg.c        |  7 +++++++
 net/mac80211/driver-ops.c | 21 +++++++++++++++++++++
 net/mac80211/driver-ops.h |  5 +++++
 net/mac80211/trace.h      | 27 +++++++++++++++++++++++++++
 5 files changed, 66 insertions(+)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index be30b05..70c02d7 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1755,6 +1755,8 @@ struct ieee80211_sta_rates {
  *	This is defined by the spec (IEEE 802.11-2012 section 8.3.2.2 NOTE 2).
  * @support_p2p_ps: indicates whether the STA supports P2P PS mechanism or not.
  * @max_rc_amsdu_len: Maximum A-MSDU size in bytes recommended by rate control.
+ * @txpwr: indicates the tx power, in dBm, to be used when sending data frames
+ *	to the STA. Value of 0 means, automatic (default) tx power.
  * @txq: per-TID data TX queues (if driver uses the TXQ abstraction)
  */
 struct ieee80211_sta {
@@ -1777,6 +1779,7 @@ struct ieee80211_sta {
 	u16 max_amsdu_len;
 	bool support_p2p_ps;
 	u16 max_rc_amsdu_len;
+	u8 txpwr;
 
 	struct ieee80211_txq *txq[IEEE80211_NUM_TIDS];
 
@@ -3484,6 +3487,9 @@ struct ieee80211_ops {
 #endif
 	void (*sta_notify)(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
 			enum sta_notify_cmd, struct ieee80211_sta *sta);
+	int (*sta_set_txpwr)(struct ieee80211_hw *hw,
+			     struct ieee80211_vif *vif,
+			     struct ieee80211_sta *sta);
 	int (*sta_state)(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
 			 struct ieee80211_sta *sta,
 			 enum ieee80211_sta_state old_state,
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 0c12e40..d439854 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1181,6 +1181,13 @@ static int sta_apply_parameters(struct ieee80211_local *local,
 	if (params->listen_interval >= 0)
 		sta->listen_interval = params->listen_interval;
 
+	if (params->txpwr >= 0) {
+		sta->sta.txpwr = MBM_TO_DBM(params->txpwr);
+		ret = drv_sta_set_txpwr(local, sdata, sta);
+		if (ret)
+			return ret;
+	}
+
 	if (params->supported_rates) {
 		ieee80211_parse_bitrates(&sdata->vif.bss_conf.chandef,
 					 sband, params->supported_rates,
diff --git a/net/mac80211/driver-ops.c b/net/mac80211/driver-ops.c
index c258f10..638480c 100644
--- a/net/mac80211/driver-ops.c
+++ b/net/mac80211/driver-ops.c
@@ -138,6 +138,27 @@ int drv_sta_state(struct ieee80211_local *local,
 	return ret;
 }
 
+__must_check
+int drv_sta_set_txpwr(struct ieee80211_local *local,
+		      struct ieee80211_sub_if_data *sdata,
+		      struct sta_info *sta)
+{
+	int ret = -EOPNOTSUPP;
+
+	might_sleep();
+
+	sdata = get_bss_sdata(sdata);
+	if (!check_sdata_in_driver(sdata))
+		return -EIO;
+
+	trace_drv_sta_set_txpwr(local, sdata, &sta->sta);
+	if (local->ops->sta_set_txpwr)
+		ret = local->ops->sta_set_txpwr(&local->hw, &sdata->vif,
+						&sta->sta);
+	trace_drv_return_int(local, ret);
+	return ret;
+}
+
 void drv_sta_rc_update(struct ieee80211_local *local,
 		       struct ieee80211_sub_if_data *sdata,
 		       struct ieee80211_sta *sta, u32 changed)
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 184473c..59b2f28 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -539,6 +539,11 @@ int drv_sta_state(struct ieee80211_local *local,
 		  enum ieee80211_sta_state old_state,
 		  enum ieee80211_sta_state new_state);
 
+__must_check
+int drv_sta_set_txpwr(struct ieee80211_local *local,
+		      struct ieee80211_sub_if_data *sdata,
+		      struct sta_info *sta);
+
 void drv_sta_rc_update(struct ieee80211_local *local,
 		       struct ieee80211_sub_if_data *sdata,
 		       struct ieee80211_sta *sta, u32 changed);
diff --git a/net/mac80211/trace.h b/net/mac80211/trace.h
index 77e4c53..78c37e9 100644
--- a/net/mac80211/trace.h
+++ b/net/mac80211/trace.h
@@ -823,6 +823,33 @@ TRACE_EVENT(drv_sta_state,
 	)
 );
 
+TRACE_EVENT(drv_sta_set_txpwr,
+	TP_PROTO(struct ieee80211_local *local,
+		 struct ieee80211_sub_if_data *sdata,
+		 struct ieee80211_sta *sta),
+
+	TP_ARGS(local, sdata, sta),
+
+	TP_STRUCT__entry(
+		LOCAL_ENTRY
+		VIF_ENTRY
+		STA_ENTRY
+		__field(u8, txpwr)
+	),
+
+	TP_fast_assign(
+		LOCAL_ASSIGN;
+		VIF_ASSIGN;
+		STA_ASSIGN;
+		__entry->txpwr = sta->txpwr;
+	),
+
+	TP_printk(
+		LOCAL_PR_FMT  VIF_PR_FMT  STA_PR_FMT " txpwr: %d",
+		LOCAL_PR_ARG, VIF_PR_ARG, STA_PR_ARG, __entry->txpwr
+	)
+);
+
 TRACE_EVENT(drv_sta_rc_update,
 	TP_PROTO(struct ieee80211_local *local,
 		 struct ieee80211_sub_if_data *sdata,
-- 
1.9.1



From arnagara at qti.qualcomm.com  Tue Jun 14 10:46:00 2016
From: arnagara at qti.qualcomm.com (Ashok Raj Nagarajan)
Date: Tue, 14 Jun 2016 23:16:00 +0530
Subject: [PATCH] iw: Add support for controlling tx power for per station
Message-ID: <1465926360-6561-1-git-send-email-arnagara@qti.qualcomm.com>

This patch allows userspace to set transmit power, in mBm units, to a
station associated to the AP.

To set a limit tx power of 2000 mBm:
iw wlan0 station set <mac-addr> txpwr limit 2000

To revert the user defined tx power for a station:
iw wlan0 station set <mac-addr> txpwr auto

Signed-off-by: Ashok Raj Nagarajan <arnagara at qti.qualcomm.com>
---
 station.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/station.c b/station.c
index f3e3da8..8364593 100644
--- a/station.c
+++ b/station.c
@@ -569,6 +569,7 @@ COMMAND(station, del, "<MAC address> [subtype <subtype>] [reason-code <code>]",
 static const struct cmd *station_set_plink;
 static const struct cmd *station_set_vlan;
 static const struct cmd *station_set_mesh_power_mode;
+static const struct cmd *station_set_txpwr;
 
 static const struct cmd *select_station_cmd(int argc, char **argv)
 {
@@ -580,6 +581,8 @@ static const struct cmd *select_station_cmd(int argc, char **argv)
 		return station_set_vlan;
 	if (strcmp(argv[1], "mesh_power_mode") == 0)
 		return station_set_mesh_power_mode;
+	if (strcmp(argv[1], "txpwr") == 0)
+		return station_set_txpwr;
 	return NULL;
 }
 
@@ -731,6 +734,72 @@ COMMAND_ALIAS(station, set, "<MAC address> mesh_power_mode "
 	"Set link-specific mesh power mode for this station",
 	select_station_cmd, station_set_mesh_power_mode);
 
+static int handle_station_set_txpwr(struct nl80211_state *state,
+				    struct nl_msg *msg,
+				    int argc, char **argv,
+				    enum id_input id)
+{
+	enum nl80211_tx_power_setting type;
+	unsigned char mac_addr[ETH_ALEN];
+	unsigned int sta_txpwr = 0;
+	char *err = NULL;
+
+	if (argc != 3 && argc != 4)
+		return 1;
+
+	if (mac_addr_a2n(mac_addr, argv[0])) {
+		fprintf(stderr, "invalid mac address\n");
+		return 2;
+	}
+
+	NLA_PUT(msg, NL80211_ATTR_MAC, ETH_ALEN, mac_addr);
+	argc--;
+	argv++;
+
+	if (strcmp("txpwr", argv[0]) != 0)
+		return 1;
+	argc--;
+	argv++;
+
+	if (!strcmp(argv[0], "auto"))
+		type = NL80211_TX_POWER_AUTOMATIC;
+	else if (!strcmp(argv[0], "limit"))
+		type = NL80211_TX_POWER_LIMITED;
+	else {
+		printf("Invalid parameter: %s\n", argv[0]);
+		return 2;
+	}
+
+	NLA_PUT_U32(msg, NL80211_ATTR_STA_TX_POWER_SETTING, type);
+
+	if (type != NL80211_TX_POWER_AUTOMATIC) {
+		if (argc != 2) {
+			printf("Missing TX power level argument.\n");
+			return 2;
+		}
+
+		argc--;
+		argv++;
+
+		sta_txpwr = strtoul(argv[0], &err, 0);
+		NLA_PUT_U32(msg, NL80211_ATTR_STA_TX_POWER, sta_txpwr);
+	}
+
+	argc--;
+	argv++;
+
+	if (argc)
+		return 1;
+
+	return 0;
+ nla_put_failure:
+	return -ENOBUFS;
+}
+COMMAND_ALIAS(station, set, "<MAC address> txpwr <auto|limit> [<tx power mBm>]",
+	NL80211_CMD_SET_STATION, 0, CIB_NETDEV, handle_station_set_txpwr,
+	"Set Tx power for this station.",
+	select_station_cmd, station_set_txpwr);
+
 static int handle_station_dump(struct nl80211_state *state,
 			       struct nl_msg *msg,
 			       int argc, char **argv,
-- 
1.9.1



From lkp at intel.com  Tue Jun 14 11:29:54 2016
From: lkp at intel.com (kbuild test robot)
Date: Wed, 15 Jun 2016 02:29:54 +0800
Subject: [PATCH] ath10k: add support for controlling tx power to a station
In-Reply-To: <1465925914-6404-1-git-send-email-arnagara@qti.qualcomm.com>
Message-ID: <201606150220.30TL93eZ%fengguang.wu@intel.com>

Hi,

[auto build test ERROR on ath6kl/ath-next]
[also build test ERROR on v4.7-rc3 next-20160614]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Ashok-Raj-Nagarajan/ath10k-add-support-for-controlling-tx-power-to-a-station/20160615-014225
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_sta_set_txpwr':
>> drivers/net/wireless/ath/ath10k/mac.c:5836:13: error: 'struct ieee80211_sta' has no member named 'txpwr'
     txpwr = sta->txpwr;
                ^~
   drivers/net/wireless/ath/ath10k/mac.c: At top level:
>> drivers/net/wireless/ath/ath10k/mac.c:7399:2: error: unknown field 'sta_set_txpwr' specified in initializer
     .sta_set_txpwr   = ath10k_sta_set_txpwr,
     ^
>> drivers/net/wireless/ath/ath10k/mac.c:7399:21: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .sta_set_txpwr   = ath10k_sta_set_txpwr,
                        ^~~~~~~~~~~~~~~~~~~~
   drivers/net/wireless/ath/ath10k/mac.c:7399:21: note: (near initialization for 'ath10k_ops.sta_pre_rcu_remove')
   cc1: some warnings being treated as errors

vim +5836 drivers/net/wireless/ath/ath10k/mac.c

  5830	{
  5831		struct ath10k *ar = hw->priv;
  5832		struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
  5833		int ret = 0;
  5834		u8 txpwr;
  5835	
> 5836		txpwr = sta->txpwr;
  5837		if (txpwr > ATH10K_TX_POWER_MAX_VAL || txpwr < ATH10K_TX_POWER_MIN_VAL)
  5838			return -EINVAL;
  5839	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 54116 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160615/fd6c2c3e/attachment-0001.obj>

From lkp at intel.com  Tue Jun 14 11:48:32 2016
From: lkp at intel.com (kbuild test robot)
Date: Wed, 15 Jun 2016 02:48:32 +0800
Subject: [PATCH 2/2] mac80211: store tx power value from user to station
In-Reply-To: <1465926277-6509-1-git-send-email-arnagara@qti.qualcomm.com>
Message-ID: <201606150209.vv1R4ZUm%fengguang.wu@intel.com>

Hi,

[auto build test WARNING on mac80211/master]
[also build test WARNING on v4.7-rc3]
[cannot apply to mac80211-next/master next-20160614]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Ashok-Raj-Nagarajan/cfg80211-Add-support-to-set-tx-power-for-a-station-associated/20160615-014826
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git master
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'
>> include/net/mac80211.h:3640: warning: No description found for parameter 'sta_set_txpwr'

vim +/sta_set_txpwr +3640 include/net/mac80211.h

a7a6bdd0 Arik Nemtsov  2014-11-09  3624  
a7a6bdd0 Arik Nemtsov  2014-11-09  3625  	int (*tdls_channel_switch)(struct ieee80211_hw *hw,
a7a6bdd0 Arik Nemtsov  2014-11-09  3626  				   struct ieee80211_vif *vif,
a7a6bdd0 Arik Nemtsov  2014-11-09  3627  				   struct ieee80211_sta *sta, u8 oper_class,
a7a6bdd0 Arik Nemtsov  2014-11-09  3628  				   struct cfg80211_chan_def *chandef,
8a4d32f3 Arik Nemtsov  2014-11-09  3629  				   struct sk_buff *tmpl_skb, u32 ch_sw_tm_ie);
a7a6bdd0 Arik Nemtsov  2014-11-09  3630  	void (*tdls_cancel_channel_switch)(struct ieee80211_hw *hw,
a7a6bdd0 Arik Nemtsov  2014-11-09  3631  					   struct ieee80211_vif *vif,
a7a6bdd0 Arik Nemtsov  2014-11-09  3632  					   struct ieee80211_sta *sta);
8a4d32f3 Arik Nemtsov  2014-11-09  3633  	void (*tdls_recv_channel_switch)(struct ieee80211_hw *hw,
8a4d32f3 Arik Nemtsov  2014-11-09  3634  					 struct ieee80211_vif *vif,
8a4d32f3 Arik Nemtsov  2014-11-09  3635  					 struct ieee80211_tdls_ch_sw_params *params);
ba8c3d6f Felix Fietkau 2015-03-27  3636  
ba8c3d6f Felix Fietkau 2015-03-27  3637  	void (*wake_tx_queue)(struct ieee80211_hw *hw,
ba8c3d6f Felix Fietkau 2015-03-27  3638  			      struct ieee80211_txq *txq);
f59374eb Sara Sharon   2016-03-02  3639  	void (*sync_rx_queues)(struct ieee80211_hw *hw);
f0706e82 Jiri Benc     2007-05-05 @3640  };
f0706e82 Jiri Benc     2007-05-05  3641  
75a5f0cc Johannes Berg 2007-09-18  3642  /**
ad28757e Ben Greear    2014-10-22  3643   * ieee80211_alloc_hw_nm - Allocate a new hardware device
ad28757e Ben Greear    2014-10-22  3644   *
ad28757e Ben Greear    2014-10-22  3645   * This must be called once for each hardware device. The returned pointer
ad28757e Ben Greear    2014-10-22  3646   * must be used to refer to this device when calling other functions.
ad28757e Ben Greear    2014-10-22  3647   * mac80211 allocates a private data area for the driver pointed to by
ad28757e Ben Greear    2014-10-22  3648   * @priv in &struct ieee80211_hw, the size of this area is given as

:::::: The code at line 3640 was first introduced by commit
:::::: f0706e828e96d0fa4e80c0d25aa98523f6d589a0 [MAC80211]: Add mac80211 wireless stack.

:::::: TO: Jiri Benc <jbenc at suse.cz>
:::::: CC: David S. Miller <davem at davemloft.net>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 6343 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160615/5d95670d/attachment.obj>

From lkp at intel.com  Tue Jun 14 11:48:38 2016
From: lkp at intel.com (kbuild test robot)
Date: Wed, 15 Jun 2016 02:48:38 +0800
Subject: [PATCH] ath10k: add support for controlling tx power to a station
In-Reply-To: <1465925914-6404-1-git-send-email-arnagara@qti.qualcomm.com>
Message-ID: <201606150222.ywY7xycR%fengguang.wu@intel.com>

Hi,

[auto build test WARNING on ath6kl/ath-next]
[also build test WARNING on v4.7-rc3 next-20160614]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Ashok-Raj-Nagarajan/ath10k-add-support-for-controlling-tx-power-to-a-station/20160615-014225
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: m68k-allyesconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=m68k 

All warnings (new ones prefixed by >>):

   drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_sta_set_txpwr':
   drivers/net/wireless/ath/ath10k/mac.c:5836:13: error: 'struct ieee80211_sta' has no member named 'txpwr'
     txpwr = sta->txpwr;
                ^
   drivers/net/wireless/ath/ath10k/mac.c: At top level:
   drivers/net/wireless/ath/ath10k/mac.c:7399:2: error: unknown field 'sta_set_txpwr' specified in initializer
     .sta_set_txpwr   = ath10k_sta_set_txpwr,
     ^
>> drivers/net/wireless/ath/ath10k/mac.c:7399:2: warning: initialization from incompatible pointer type
   drivers/net/wireless/ath/ath10k/mac.c:7399:2: warning: (near initialization for 'ath10k_ops.sta_pre_rcu_remove')

vim +7399 drivers/net/wireless/ath/ath10k/mac.c

  7383	
  7384	static const struct ieee80211_ops ath10k_ops = {
  7385		.tx				= ath10k_mac_op_tx,
  7386		.wake_tx_queue			= ath10k_mac_op_wake_tx_queue,
  7387		.start				= ath10k_start,
  7388		.stop				= ath10k_stop,
  7389		.config				= ath10k_config,
  7390		.add_interface			= ath10k_add_interface,
  7391		.remove_interface		= ath10k_remove_interface,
  7392		.configure_filter		= ath10k_configure_filter,
  7393		.bss_info_changed		= ath10k_bss_info_changed,
  7394		.hw_scan			= ath10k_hw_scan,
  7395		.cancel_hw_scan			= ath10k_cancel_hw_scan,
  7396		.set_key			= ath10k_set_key,
  7397		.set_default_unicast_key        = ath10k_set_default_unicast_key,
  7398		.sta_state			= ath10k_sta_state,
> 7399		.sta_set_txpwr			= ath10k_sta_set_txpwr,
  7400		.conf_tx			= ath10k_conf_tx,
  7401		.remain_on_channel		= ath10k_remain_on_channel,
  7402		.cancel_remain_on_channel	= ath10k_cancel_remain_on_channel,
  7403		.set_rts_threshold		= ath10k_set_rts_threshold,
  7404		.set_frag_threshold		= ath10k_mac_op_set_frag_threshold,
  7405		.flush				= ath10k_flush,
  7406		.tx_last_beacon			= ath10k_tx_last_beacon,
  7407		.set_antenna			= ath10k_set_antenna,

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 36318 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160615/c69cab28/attachment-0001.obj>

From rmanohar at codeaurora.org  Tue Jun 14 19:55:34 2016
From: rmanohar at codeaurora.org (Rajkumar Manoharan)
Date: Wed, 15 Jun 2016 08:25:34 +0530
Subject: Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath
In-Reply-To: <57600A3C.9000104@candelatech.com>
References: <f495d218d54a4c4c859849a85f38ab0c@aphydexm01b.ap.qualcomm.com>
 <57506C7A.7070109@candelatech.com>
 <c3facd0acc1c2f49f4a4638bf0c2a591@codeaurora.org>
 <57507269.1060108@candelatech.com>
 <ac15f3e10cedc20199051bab88b36eba@codeaurora.org>
 <57600A3C.9000104@candelatech.com>
Message-ID: <f91f033b77e415fc14f94d5890115e09@codeaurora.org>

On 2016-06-14 19:14, Ben Greear wrote:
> On 06/13/2016 11:21 PM, Rajkumar Manoharan wrote:
>> On 2016-06-02 23:22, Ben Greear wrote:
> 
>>> At the time, I bisected to this commit as well, but I decided to just
>>> live with it
>>> since it seemed it fixed some other bug and we had a work-around.  My
>>> understanding
>>> is that without the patch above, some ARM systems failed to work.
>>> 
>> Ben,
>> 
>> I posted a fix for the freeze issue 
>> (https://patchwork.kernel.org/patch/9175029/). Can you please give a 
>> try with VT-d disabled?
>> 
>> -Rajkumar
> 
> Yes, but it might be a bit.  I just ported my patches to 4.7, and will 
> add yours
> there.  We are mainly focussed on getting a stable 4.4+ out the door
> currently though.
> 
Thanks..

> Were you able to test on the ARM platform that originally had the 
> problem that
> Felix's patch was supposed to fix?
> 
I tested this patch on ARM platform. Unfortunately I did not observe 
original dma_alloc_coherent failures. Felix replaced dma_alloc_coherent 
by kmalloc + dma_map_single. I retained the logic as it is. Thee change 
is that host memory chuck size for target is limited by 256 KiB.

-Rajkumar


From mohammed at codeaurora.org  Tue Jun 14 23:16:53 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Wed, 15 Jun 2016 11:46:53 +0530
Subject: Problem with spectral scan in VHT80 mode
In-Reply-To: <CAFc9h7u4yTesQR3D++D3sKZ9Lv9tek_=JMtwzs=1jTNnXjVvBw@mail.gmail.com>
References: <CAFc9h7vk6e-BntP+GMv8s2jaNSOkA=37rChTjss2-7mgupAv7Q@mail.gmail.com>
 <CAFc9h7uABMUJ349bgNJLcZDNL5hyp96CrYoc8PD9VDLv_-8rqw@mail.gmail.com>
 <20160614053011.GB2800@atheros-ThinkPad-T61>
 <CAFc9h7u4yTesQR3D++D3sKZ9Lv9tek_=JMtwzs=1jTNnXjVvBw@mail.gmail.com>
Message-ID: <20160615061653.GA4593@atheros-ThinkPad-T61>

Hi Gaurang,

thanks a lot will check the spectral scan results.

regards,
shafi

On Tue, Jun 14, 2016 at 12:33:38PM -0400, Gaurang Ramesh Naik wrote:
> Hi Shafi,
> 
> I am using QCA9882 (I'm using RB911G-5HPacD). This is what I observed
> http://postimg.org/image/vha3pmvhz/
> 
> I have one AP-Client running iperf over HT40 and I'm using another AP
> for the scan.
> 
> Thanks,
> Gaurang.
> 
> On Tue, Jun 14, 2016 at 1:30 AM, Mohammed Shafi Shajakhan
> <mohammed at codeaurora.org> wrote:
> > Hi Gaurang,
> >
> > On Tue, Jun 14, 2016 at 01:08:29AM -0400, Gaurang Ramesh Naik wrote:
> >> Apologies for my previous e-mail. I had read the whole page once, but
> >> somehow I missed the point about 64 bins for VHT80. It's working now.
> >
> > [shafi] may i know the chipset you are testing, also if its feasible
> > you can share the graph plots of the spectral scan .
> >
> >>
> >> On Tue, Jun 14, 2016 at 12:37 AM, Gaurang Ramesh Naik <gaurang at vt.edu> wrote:
> >> > Hello,
> >> >
> >> > I was trying the ath10k's spectral scan. I used the following commands
> >> > given on the link
> >> > https://wireless.wiki.kernel.org/en/users/drivers/ath10k/spectral
> >> >
> >> > echo 8 > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_count
> >> > echo manual > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
> >> > echo trigger > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
> >> > cat /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan0 >> /tmp/fft.dump
> >> >
> >> > I am using OpenWrt Bleeding edge. In the HT20 and HT40 mode, I
> >> > correctly get 8 samples. However, in the VHT80 mode, the /tmp/fft.dump
> >> > file generated is empty.
> >> >
> >> > In the open issues on the above link, it said that the HT40 and HT20
> >> > modes ignore the count parameter. That isn't the case for me. I seem
> >> > to get correct # of samples (I view the dump file using
> >> > https://github.com/simonwunderlich/FFT_eval). However, in the VHT80
> >> > mode, there seems to be no output. Am I doing something wrong here?
> >> >
> >
> > regards,
> > shafi
> 
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From kvalo at qca.qualcomm.com  Thu Jun 16 04:07:09 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 16 Jun 2016 11:07:09 +0000
Subject: [PATCH v4 1/2] ath10k: Add support for ath10k_sta_statistics
 support
In-Reply-To: <20160614152131.GA3941@atheros-ThinkPad-T61> (Mohammed Shafi
 Shajakhan's message of "Tue, 14 Jun 2016 20:51:31 +0530")
References: <1465890866-2390-1-git-send-email-mohammed@qca.qualcomm.com>
 <87k2hr3m9r.fsf@kamboji.qca.qualcomm.com>
 <20160614152131.GA3941@atheros-ThinkPad-T61>
Message-ID: <874m8tqtnp.fsf@qca.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at codeaurora.org> writes:

>> Also please ping instead of resending patches. These are already waiting
>> in patchwork:
>> 
>> https://patchwork.kernel.org/patch/8993601/
>> https://patchwork.kernel.org/patch/8993621/
>
> [shafi] oh ok thanks, sorry i thought this required a rebased over pending
> branch next time i will do this
>
> a) ping you first
> b) if required send a rebased version

Thanks, this way I have less patches to worry about :)

-- 
Kalle Valo

From mohammed at qti.qualcomm.com  Thu Jun 16 05:54:44 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Thu, 16 Jun 2016 18:24:44 +0530
Subject: [PATCH] ath10k: Enable beacon loss detection support for 10.4
Message-ID: <1466081684-8074-1-git-send-email-mohammed@qca.qualcomm.com>

From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Enable beacon loss detection support for 10.4 by handling
roam event. With this change QCA99X0 station is able to
detect beacon loss when the AP is powered off

Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 6279ab4..4dd35f1 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5257,6 +5257,9 @@ static void ath10k_wmi_10_4_op_rx(struct ath10k *ar, struct sk_buff *skb)
 	case WMI_10_4_PEER_STA_KICKOUT_EVENTID:
 		ath10k_wmi_event_peer_sta_kickout(ar, skb);
 		break;
+	case WMI_10_4_ROAM_EVENTID:
+		ath10k_wmi_event_roam(ar, skb);
+		break;
 	case WMI_10_4_HOST_SWBA_EVENTID:
 		ath10k_wmi_event_host_swba(ar, skb);
 		break;
@@ -7903,6 +7906,7 @@ static const struct wmi_ops wmi_10_4_ops = {
 	.pull_phyerr = ath10k_wmi_10_4_op_pull_phyerr_ev,
 	.pull_svc_rdy = ath10k_wmi_main_op_pull_svc_rdy_ev,
 	.pull_rdy = ath10k_wmi_op_pull_rdy_ev,
+	.pull_roam_ev = ath10k_wmi_op_pull_roam_ev,
 	.get_txbf_conf_scheme = ath10k_wmi_10_4_txbf_conf_scheme,
 
 	.gen_pdev_suspend = ath10k_wmi_op_gen_pdev_suspend,
-- 
1.9.1



From mohammed at qti.qualcomm.com  Thu Jun 16 05:55:13 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Thu, 16 Jun 2016 18:25:13 +0530
Subject: [PATCH] ath10k: Disable TX_STBC for tx chainmask of 1
Message-ID: <1466081713-8122-1-git-send-email-mohammed@qca.qualcomm.com>

From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Disable TX_STBC for both HT and VHT if the devices tx chainmask is '1'
TX_STBC is required only for devices with tx_chainmask > 1. This fixes
a ping failure for QCA9887 (1x1) in HT/VHT mode

Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 1fe33c36..5e40922 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4224,6 +4224,9 @@ static struct ieee80211_sta_vht_cap ath10k_create_vht_cap(struct ath10k *ar)
 			mcs_map |= IEEE80211_VHT_MCS_NOT_SUPPORTED << (i * 2);
 	}
 
+	if (ar->cfg_tx_chainmask <= 1)
+		vht_cap.cap &= ~IEEE80211_VHT_CAP_TXSTBC;
+
 	vht_cap.vht_mcs.rx_mcs_map = cpu_to_le16(mcs_map);
 	vht_cap.vht_mcs.tx_mcs_map = cpu_to_le16(mcs_map);
 
@@ -4261,7 +4264,7 @@ static struct ieee80211_sta_ht_cap ath10k_get_ht_cap(struct ath10k *ar)
 		ht_cap.cap |= smps;
 	}
 
-	if (ar->ht_cap_info & WMI_HT_CAP_TX_STBC)
+	if (ar->ht_cap_info & WMI_HT_CAP_TX_STBC && (ar->cfg_tx_chainmask > 1))
 		ht_cap.cap |= IEEE80211_HT_CAP_TX_STBC;
 
 	if (ar->ht_cap_info & WMI_HT_CAP_RX_STBC) {
-- 
1.9.1



From kvalo at qca.qualcomm.com  Thu Jun 16 06:57:43 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 16 Jun 2016 13:57:43 +0000
Subject: [PATCH] ath10k:  Fix mgmt tx status for 10.4.3 firmware.
In-Reply-To: <1456782654-24723-1-git-send-email-greearb@candelatech.com>
 (greearb@candelatech.com's message of "Mon, 29 Feb 2016 13:50:54	-0800")
References: <1456782654-24723-1-git-send-email-greearb@candelatech.com>
Message-ID: <87shwdw815.fsf@kamboji.qca.qualcomm.com>

greearb at candelatech.com writes:

> From: Ben Greear <greearb at candelatech.com>
>
> When testing a 10.4.3 firmware in station mode, I notice that
> when the AP is powered down, the ath10k does not notice AP is gone
> because mgt frames get tx status of 3, which is not handled.
>
> It appears that status 3 means something similar to failed-retry.
>
> Treating it thus lets the station disconnect properly.
>
> Tested against a non-stock 10.4.3 firmware, but likely upstream
> firmware acts similarly in this case.
>
> Signed-off-by: Ben Greear <greearb at candelatech.com>
> ---
>
> This patch is against a heavily patched tree based on 4.4, hopefully
> it can be applied to upstream code w/out too much trouble.
>
> Someone should verify this on stock 10.4-ish firmware before applying.

Has anyone tested this with stock driver and stock firmware?

Full patch here:

https://patchwork.kernel.org/patch/8460831/

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Thu Jun 16 07:08:13 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 16 Jun 2016 14:08:13 +0000
Subject: [PATCH] ath10k: add support for controlling tx power to a station
In-Reply-To: <201606150220.30TL93eZ%fengguang.wu@intel.com> (kbuild test
 robot's message of "Wed, 15 Jun 2016 02:29:54 +0800")
References: <201606150220.30TL93eZ%fengguang.wu@intel.com>
Message-ID: <87fusdw7jn.fsf@kamboji.qca.qualcomm.com>

kbuild test robot <lkp at intel.com> writes:

> [auto build test ERROR on ath6kl/ath-next]
> [also build test ERROR on v4.7-rc3 next-20160614]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url:    https://github.com/0day-ci/linux/commits/Ashok-Raj-Nagarajan/ath10k-add-support-for-controlling-tx-power-to-a-station/20160615-014225
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
> config: x86_64-allmodconfig (attached as .config)
> compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
> reproduce:
>         # save the attached .config to linux build tree
>         make ARCH=x86_64 
>
> All errors (new ones prefixed by >>):
>
>    drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_sta_set_txpwr':
>>> drivers/net/wireless/ath/ath10k/mac.c:5836:13: error: 'struct ieee80211_sta' has no member named 'txpwr'
>      txpwr = sta->txpwr;
>                 ^~
>    drivers/net/wireless/ath/ath10k/mac.c: At top level:
>>> drivers/net/wireless/ath/ath10k/mac.c:7399:2: error: unknown field 'sta_set_txpwr' specified in initializer
>      .sta_set_txpwr   = ath10k_sta_set_txpwr,
>      ^
>>> drivers/net/wireless/ath/ath10k/mac.c:7399:21: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .sta_set_txpwr   = ath10k_sta_set_txpwr,
>                         ^~~~~~~~~~~~~~~~~~~~
>    drivers/net/wireless/ath/ath10k/mac.c:7399:21: note: (near initialization for 'ath10k_ops.sta_pre_rcu_remove')
>    cc1: some warnings being treated as errors

These errors are expected as this depends on a mac80211 patch which is
not yet applied.

-- 
Kalle Valo

From me at bobcopeland.com  Thu Jun 16 08:59:59 2016
From: me at bobcopeland.com (Bob Copeland)
Date: Thu, 16 Jun 2016 11:59:59 -0400
Subject: [PATCH] ath10k: Fix a typo in spectral code commments
In-Reply-To: <1465882434-594-1-git-send-email-mohammed@qca.qualcomm.com>
References: <1465882434-594-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <20160616155958.GA24359@localhost>

On Tue, Jun 14, 2016 at 11:03:54AM +0530, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> Found this obvious typo while going through the spectral
> code design in ath10k

>  		/* TODO: As experiments with an analogue sender and various
> -		 * configuaritions (fft-sizes of 64/128/256 and 20/40/80 Mhz)
> +		 * configurations (fft-sizes of 64/128/256 and 20/40/80 Mhz)
>  		 * show, the particular configuration of 80 MHz/64 bins does
>  		 * not match with the other smaples at all. Until the reason
>  		 * for that is found, don't report these samples.

Also "smaples" :)

-- 
Bob Copeland %% http://bobcopeland.com/


From mohammed at codeaurora.org  Thu Jun 16 09:04:31 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Thu, 16 Jun 2016 21:34:31 +0530
Subject: [PATCH] ath10k: Fix a typo in spectral code commments
In-Reply-To: <20160616155958.GA24359@localhost>
References: <1465882434-594-1-git-send-email-mohammed@qca.qualcomm.com>
 <20160616155958.GA24359@localhost>
Message-ID: <20160616160430.GA10584@atheros-ThinkPad-T61>

On Thu, Jun 16, 2016 at 11:59:59AM -0400, Bob Copeland wrote:
> On Tue, Jun 14, 2016 at 11:03:54AM +0530, Mohammed Shafi Shajakhan wrote:
> > From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> > 
> > Found this obvious typo while going through the spectral
> > code design in ath10k
> 
> >  		/* TODO: As experiments with an analogue sender and various
> > -		 * configuaritions (fft-sizes of 64/128/256 and 20/40/80 Mhz)
> > +		 * configurations (fft-sizes of 64/128/256 and 20/40/80 Mhz)
> >  		 * show, the particular configuration of 80 MHz/64 bins does
> >  		 * not match with the other smaples at all. Until the reason
> >  		 * for that is found, don't report these samples.
> 
> Also "smaples" :)

[shafi]  goodness me will that as well !

> 
> -- 
> Bob Copeland %% http://bobcopeland.com/


From mohammed at qti.qualcomm.com  Thu Jun 16 09:06:52 2016
From: mohammed at qti.qualcomm.com (Shajakhan, Mohammed Shafi (Mohammed Shafi))
Date: Thu, 16 Jun 2016 16:06:52 +0000
Subject: [PATCH] ath10k: Fix a typo in spectral code commments
In-Reply-To: <575FC1E5.90108@vitracom.de>
References: <1465882434-594-1-git-send-email-mohammed@qca.qualcomm.com>
 <575FC1E5.90108@vitracom.de>
Message-ID: <eb4c30ff7ff54ea2b63a950acecdd51a@aphydexm01b.ap.qualcomm.com>

+ linux wireless, ath10k

Thanks, initially I could not get what you meant :(

-----Original Message-----
From: Arthur Jagiella [mailto:jagiella at vitracom.de] 
Sent: Tuesday, June 14, 2016 2:06 PM
To: Shajakhan, Mohammed Shafi (Mohammed Shafi) <mohammed at qti.qualcomm.com>
Subject: Re: [PATCH] ath10k: Fix a typo in spectral code commments

smaples?



Am 14.06.2016 um 07:33 schrieb Mohammed Shafi Shajakhan:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
>
> Found this obvious typo while going through the spectral code design 
> in ath10k
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> ---
>   drivers/net/wireless/ath/ath10k/spectral.c |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/spectral.c 
> b/drivers/net/wireless/ath/ath10k/spectral.c
> index 4671cfb..4510906 100644
> --- a/drivers/net/wireless/ath/ath10k/spectral.c
> +++ b/drivers/net/wireless/ath/ath10k/spectral.c
> @@ -101,7 +101,7 @@ int ath10k_spectral_process_fft(struct ath10k *ar,
>   		break;
>   	case 80:
>   		/* TODO: As experiments with an analogue sender and various
> -		 * configuaritions (fft-sizes of 64/128/256 and 20/40/80 Mhz)
> +		 * configurations (fft-sizes of 64/128/256 and 20/40/80 Mhz)
>   		 * show, the particular configuration of 80 MHz/64 bins does
>   		 * not match with the other smaples at all. Until the reason
>   		 * for that is found, don't report these samples.

--
Arthur Jagiella
Praktikant
Forschung und Entwicklung
Vitracom AG

Erbprinzenstr. 4-12, A
D-76133 Karlsruhe

Email: jagiella at vitracom.de
Internet: www.vitracom.de



------------------------------------------------
HRB Mannheim 111263
UST-ID: DE 247872702
Vorstand: Axel Stephan,
           Ralph Majer
Aufsichtsrat: Paul A. Stodden (Vors.)
               Christian Eckart, Sacha Grau
------------------------------------------------



From mohammed at qti.qualcomm.com  Thu Jun 16 09:13:48 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Thu, 16 Jun 2016 21:43:48 +0530
Subject: [PATCH v2] ath10k: Fix some typo in spectral code commments
Message-ID: <1466093628-10653-1-git-send-email-mohammed@qca.qualcomm.com>

From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Found this obvious typo while going through the spectral
code design in ath10k

Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/spectral.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/spectral.c b/drivers/net/wireless/ath/ath10k/spectral.c
index 4671cfb..7d9b0da 100644
--- a/drivers/net/wireless/ath/ath10k/spectral.c
+++ b/drivers/net/wireless/ath/ath10k/spectral.c
@@ -101,9 +101,9 @@ int ath10k_spectral_process_fft(struct ath10k *ar,
 		break;
 	case 80:
 		/* TODO: As experiments with an analogue sender and various
-		 * configuaritions (fft-sizes of 64/128/256 and 20/40/80 Mhz)
+		 * configurations (fft-sizes of 64/128/256 and 20/40/80 Mhz)
 		 * show, the particular configuration of 80 MHz/64 bins does
-		 * not match with the other smaples at all. Until the reason
+		 * not match with the other samples at all. Until the reason
 		 * for that is found, don't report these samples.
 		 */
 		if (bin_len == 64)
-- 
1.9.1



From gaurang at vt.edu  Thu Jun 16 12:57:57 2016
From: gaurang at vt.edu (Gaurang Ramesh Naik)
Date: Thu, 16 Jun 2016 15:57:57 -0400
Subject: Dynamic Bandwidth in hw rate control
In-Reply-To: <5758FD6B.40409@candelatech.com>
References: <CAFc9h7uxTOUxONvW-gvgkFLUNR9OBn09kfetF9gqAtcNqN3SLg@mail.gmail.com>
 <5758FD6B.40409@candelatech.com>
Message-ID: <CAFc9h7s69rVpMNUx553zsHfLf2uLcqx0jhKqma-+SxA6EkybMA@mail.gmail.com>

Hi Ben,

Thanks for your reply.

I wanted to know if the dynamic bandwidth option implemented in ath10k
is the same as that mentioned in the standard, or does it deviate? I
tried to look for any documentation on ath10k dynamic bandwidth, but
could not find any.

If I am not wrong, on the secondary channel, the sender senses the
channel for PIFS interval of time immediately preceding the start of
the TXOP (9.19.2.8 in the standard). In the static mode, if the
secondary channel is sensed busy, the sender waits until all channels
become idle; but in the dynamic mode, the sender sends on the primary
and (adjacent) secondary channel that are not busy.

However, the documentation for dynamic bandwidth in ath10k/mac.c seems
to suggest that the transmission retries are carried over narrower
bandwidth in dynamic mode. Does this mean the same as what is given in
the standard? Or is the dynamic mode implemented differently? Any help
is appreciated.

Thanks,
Gaurang.

On Thu, Jun 9, 2016 at 1:23 AM, Ben Greear <greearb at candelatech.com> wrote:
>
>
> On 06/08/2016 08:10 PM, Gaurang Ramesh Naik wrote:
>>
>> Hi,
>>
>> I needed a small clarification related to dynamic bandwidth setup. The
>> documentation in wmi.h says " When enabled HW rate control tries
>> different bandwidths when retransmitting frames."
>>
>> Does this mean that each packet is first always tried over VHT80 and
>> if that fails it goes to HT40 and then to HT20? I tried this with one
>> AP-Sta operating in VHT80 and one AP operating in its first secondary
>> channel. When I check the rx rate info using "iw dev wlanx station
>> dump", the bandwidth seems to sometimes alternate between 20 and 80,
>> but sometimes it stays fixed at 20. Hence, I was wondering what really
>> happens.
>
>
> For one thing, if the hardware detects interference on secondary channels,
> then it may decide to transmit a 20Mhz encoding.
>
> The rate-ctrl algs in the firmware differ from release to release, but
> the general goal is to transmit with the fastest encoding rate.
>
> Thanks,
> Ben
>
>>
>> Thanks,
>> Gaurang.
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com


From dave.taht at gmail.com  Thu Jun 16 13:06:31 2016
From: dave.taht at gmail.com (Dave Taht)
Date: Thu, 16 Jun 2016 13:06:31 -0700
Subject: Dynamic Bandwidth in hw rate control
In-Reply-To: <CAFc9h7s69rVpMNUx553zsHfLf2uLcqx0jhKqma-+SxA6EkybMA@mail.gmail.com>
References: <CAFc9h7uxTOUxONvW-gvgkFLUNR9OBn09kfetF9gqAtcNqN3SLg@mail.gmail.com>
 <5758FD6B.40409@candelatech.com>
 <CAFc9h7s69rVpMNUx553zsHfLf2uLcqx0jhKqma-+SxA6EkybMA@mail.gmail.com>
Message-ID: <CAA93jw51DHMCsP1gn4NKvZ87t53LtNhqkX=SoJ_Jd8FUYBNP5A@mail.gmail.com>

On Thu, Jun 16, 2016 at 12:57 PM, Gaurang Ramesh Naik <gaurang at vt.edu> wrote:
> Hi Ben,
>
> Thanks for your reply.
>
> I wanted to know if the dynamic bandwidth option implemented in ath10k
> is the same as that mentioned in the standard, or does it deviate? I
> tried to look for any documentation on ath10k dynamic bandwidth, but
> could not find any.

So far as I know "rate control" is one of the major handwaves in the
standard and differs from vendor to vendor and 802.11 standard to
another.

The pieces of how 802.11ac should fall back to narrower channels,  I
think you've correctly identified below (as for width)...

but actually choosing a MCS rate, number of retries, formatting an
aggregate... and other factors, are... different.

I've tried to point at the first and best paper that shows how
minstrel works here:

http://blog.cerowrt.org/post/minstrel/

(and minstrel's known problems) but that's not what ath10k uses.

I would *welcome* full documentation (or code!) on how ath10k choses
its rates. Or any other wifi chipset's blob, frankly.

> If I am not wrong, on the secondary channel, the sender senses the
> channel for PIFS interval of time immediately preceding the start of
> the TXOP (9.19.2.8 in the standard). In the static mode, if the
> secondary channel is sensed busy, the sender waits until all channels
> become idle; but in the dynamic mode, the sender sends on the primary
> and (adjacent) secondary channel that are not busy.
>
> However, the documentation for dynamic bandwidth in ath10k/mac.c seems
> to suggest that the transmission retries are carried over narrower
> bandwidth in dynamic mode. Does this mean the same as what is given in
> the standard? Or is the dynamic mode implemented differently? Any help
> is appreciated.
>
> Thanks,
> Gaurang.
>
> On Thu, Jun 9, 2016 at 1:23 AM, Ben Greear <greearb at candelatech.com> wrote:
>>
>>
>> On 06/08/2016 08:10 PM, Gaurang Ramesh Naik wrote:
>>>
>>> Hi,
>>>
>>> I needed a small clarification related to dynamic bandwidth setup. The
>>> documentation in wmi.h says " When enabled HW rate control tries
>>> different bandwidths when retransmitting frames."
>>>
>>> Does this mean that each packet is first always tried over VHT80 and
>>> if that fails it goes to HT40 and then to HT20? I tried this with one
>>> AP-Sta operating in VHT80 and one AP operating in its first secondary
>>> channel. When I check the rx rate info using "iw dev wlanx station
>>> dump", the bandwidth seems to sometimes alternate between 20 and 80,
>>> but sometimes it stays fixed at 20. Hence, I was wondering what really
>>> happens.
>>
>>
>> For one thing, if the hardware detects interference on secondary channels,
>> then it may decide to transmit a 20Mhz encoding.
>>
>> The rate-ctrl algs in the firmware differ from release to release, but
>> the general goal is to transmit with the fastest encoding rate.
>>
>> Thanks,
>> Ben
>>
>>>
>>> Thanks,
>>> Gaurang.
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k



-- 
Dave T?ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org


From greearb at candelatech.com  Thu Jun 16 13:54:38 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 16 Jun 2016 13:54:38 -0700
Subject: Dynamic Bandwidth in hw rate control
In-Reply-To: <CAFc9h7s69rVpMNUx553zsHfLf2uLcqx0jhKqma-+SxA6EkybMA@mail.gmail.com>
References: <CAFc9h7uxTOUxONvW-gvgkFLUNR9OBn09kfetF9gqAtcNqN3SLg@mail.gmail.com>
 <5758FD6B.40409@candelatech.com>
 <CAFc9h7s69rVpMNUx553zsHfLf2uLcqx0jhKqma-+SxA6EkybMA@mail.gmail.com>
Message-ID: <5763120E.4040902@candelatech.com>

On 06/16/2016 12:57 PM, Gaurang Ramesh Naik wrote:
> Hi Ben,
>
> Thanks for your reply.
>
> I wanted to know if the dynamic bandwidth option implemented in ath10k
> is the same as that mentioned in the standard, or does it deviate? I
> tried to look for any documentation on ath10k dynamic bandwidth, but
> could not find any.
>
> If I am not wrong, on the secondary channel, the sender senses the
> channel for PIFS interval of time immediately preceding the start of
> the TXOP (9.19.2.8 in the standard). In the static mode, if the
> secondary channel is sensed busy, the sender waits until all channels
> become idle; but in the dynamic mode, the sender sends on the primary
> and (adjacent) secondary channel that are not busy.
>
> However, the documentation for dynamic bandwidth in ath10k/mac.c seems
> to suggest that the transmission retries are carried over narrower
> bandwidth in dynamic mode. Does this mean the same as what is given in
> the standard? Or is the dynamic mode implemented differently? Any help
> is appreciated.

I don't know exactly how this works.  At least the sensing and stuff is probably
baked into the hardware.  What I notice is that the firmware passes a series
of rates to the hardware to use for each packet, and it includes different
bandwidth rates.

If you used my firmware and my kernel, you can see the (successful) transmit
rate for each frame.  Perhaps you could discover some info about how it works
in that manner if you could reliably add noise on an adjacent channel.

Upstream firmware can see tx rates using pktlog I think, but I have
never tried that.

Thanks,
Ben

>
> Thanks,
> Gaurang.
>
> On Thu, Jun 9, 2016 at 1:23 AM, Ben Greear <greearb at candelatech.com> wrote:
>>
>>
>> On 06/08/2016 08:10 PM, Gaurang Ramesh Naik wrote:
>>>
>>> Hi,
>>>
>>> I needed a small clarification related to dynamic bandwidth setup. The
>>> documentation in wmi.h says " When enabled HW rate control tries
>>> different bandwidths when retransmitting frames."
>>>
>>> Does this mean that each packet is first always tried over VHT80 and
>>> if that fails it goes to HT40 and then to HT20? I tried this with one
>>> AP-Sta operating in VHT80 and one AP operating in its first secondary
>>> channel. When I check the rx rate info using "iw dev wlanx station
>>> dump", the bandwidth seems to sometimes alternate between 20 and 80,
>>> but sometimes it stays fixed at 20. Hence, I was wondering what really
>>> happens.
>>
>>
>> For one thing, if the hardware detects interference on secondary channels,
>> then it may decide to transmit a 20Mhz encoding.
>>
>> The rate-ctrl algs in the firmware differ from release to release, but
>> the general goal is to transmit with the fastest encoding rate.
>>
>> Thanks,
>> Ben
>>
>>>
>>> Thanks,
>>> Gaurang.
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>


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



From gaurang at vt.edu  Thu Jun 16 15:44:17 2016
From: gaurang at vt.edu (Gaurang Ramesh Naik)
Date: Thu, 16 Jun 2016 18:44:17 -0400
Subject: Dynamic Bandwidth in hw rate control
In-Reply-To: <5763120E.4040902@candelatech.com>
References: <CAFc9h7uxTOUxONvW-gvgkFLUNR9OBn09kfetF9gqAtcNqN3SLg@mail.gmail.com>
 <5758FD6B.40409@candelatech.com>
 <CAFc9h7s69rVpMNUx553zsHfLf2uLcqx0jhKqma-+SxA6EkybMA@mail.gmail.com>
 <5763120E.4040902@candelatech.com>
Message-ID: <CAFc9h7uBnGK_paWPCzb_R=kFmcGKenSY6-Ab1c--pfhKn9cAWw@mail.gmail.com>

Thanks Ben and Dave for your replies. So what I understand is that
dynamic bandwidth management is a part of the rate control algorithm
(which is implemented in firmware) and hence I have not much control
over how that works.

I am assuming your firmware is the one that can be downloaded from
http://www.candelatech.com/ath10k.php Is your kernel a modified one
too? When you say I can see the tx rate for each frame, is it through
some logs? I could try to get some info by using that. Thanks again.

Slightly unrelated, but is there a way I can play around with PIFS
value? I could not locate it in the ath10k source, so I am assuming it
is implemented in the firmware. I am trying to study some fairness
issues when legacy devices operate in the secondary channels.

On Thu, Jun 16, 2016 at 4:54 PM, Ben Greear <greearb at candelatech.com> wrote:
> On 06/16/2016 12:57 PM, Gaurang Ramesh Naik wrote:
>>
>> Hi Ben,
>>
>> Thanks for your reply.
>>
>> I wanted to know if the dynamic bandwidth option implemented in ath10k
>> is the same as that mentioned in the standard, or does it deviate? I
>> tried to look for any documentation on ath10k dynamic bandwidth, but
>> could not find any.
>>
>> If I am not wrong, on the secondary channel, the sender senses the
>> channel for PIFS interval of time immediately preceding the start of
>> the TXOP (9.19.2.8 in the standard). In the static mode, if the
>> secondary channel is sensed busy, the sender waits until all channels
>> become idle; but in the dynamic mode, the sender sends on the primary
>> and (adjacent) secondary channel that are not busy.
>>
>> However, the documentation for dynamic bandwidth in ath10k/mac.c seems
>> to suggest that the transmission retries are carried over narrower
>> bandwidth in dynamic mode. Does this mean the same as what is given in
>> the standard? Or is the dynamic mode implemented differently? Any help
>> is appreciated.
>
>
> I don't know exactly how this works.  At least the sensing and stuff is
> probably
> baked into the hardware.  What I notice is that the firmware passes a series
> of rates to the hardware to use for each packet, and it includes different
> bandwidth rates.
>
> If you used my firmware and my kernel, you can see the (successful) transmit
> rate for each frame.  Perhaps you could discover some info about how it
> works
> in that manner if you could reliably add noise on an adjacent channel.
>
> Upstream firmware can see tx rates using pktlog I think, but I have
> never tried that.
>
> Thanks,
> Ben
>
>
>>
>> Thanks,
>> Gaurang.
>>
>> On Thu, Jun 9, 2016 at 1:23 AM, Ben Greear <greearb at candelatech.com>
>> wrote:
>>>
>>>
>>>
>>> On 06/08/2016 08:10 PM, Gaurang Ramesh Naik wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I needed a small clarification related to dynamic bandwidth setup. The
>>>> documentation in wmi.h says " When enabled HW rate control tries
>>>> different bandwidths when retransmitting frames."
>>>>
>>>> Does this mean that each packet is first always tried over VHT80 and
>>>> if that fails it goes to HT40 and then to HT20? I tried this with one
>>>> AP-Sta operating in VHT80 and one AP operating in its first secondary
>>>> channel. When I check the rx rate info using "iw dev wlanx station
>>>> dump", the bandwidth seems to sometimes alternate between 20 and 80,
>>>> but sometimes it stays fixed at 20. Hence, I was wondering what really
>>>> happens.
>>>
>>>
>>>
>>> For one thing, if the hardware detects interference on secondary
>>> channels,
>>> then it may decide to transmit a 20Mhz encoding.
>>>
>>> The rate-ctrl algs in the firmware differ from release to release, but
>>> the general goal is to transmit with the fastest encoding rate.
>>>
>>> Thanks,
>>> Ben
>>>
>>>>
>>>> Thanks,
>>>> Gaurang.
>>>>
>>>> _______________________________________________
>>>> ath10k mailing list
>>>> ath10k at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>
>>>
>>> --
>>> Ben Greear <greearb at candelatech.com>
>>> Candela Technologies Inc  http://www.candelatech.com
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>


From greearb at candelatech.com  Thu Jun 16 17:01:55 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 16 Jun 2016 17:01:55 -0700
Subject: Unicast packets stop being transmitted to a particular station,
 under load, when WPA2 is enabled
In-Reply-To: <877g57bl9a.fsf@kamboji.qca.qualcomm.com>
References: <CAHqTa-3YUpt3jByNxiEkPGV52CoRDS-R4W33ywKVLa-Ye9d2bQ@mail.gmail.com>
 <53703B61.3050305@candelatech.com>
 <CAHqTa-3Rj-=4A3BoQoD0fb7P=jDd53KvGjxW_BnkoF_+hdWW5g@mail.gmail.com>
 <877g57bl9a.fsf@kamboji.qca.qualcomm.com>
Message-ID: <57633DF3.3070009@candelatech.com>

On 05/27/2014 02:53 AM, Kalle Valo wrote:
> Hi Avery,
>
> Avery Pennarun <apenwarr at gmail.com> writes:
>
>> On Sun, May 11, 2014 at 11:09 PM, Ben Greear <greearb at candelatech.com> wrote:
>>> Can you reproduce with any other type of station
>>> device?
>>
>> I'll try.  It's a little tricky since it seems to involve running
>> Chrome, etc, rather than my usual command-line tests for which I have
>> a wider variety of clients.
>
> did you have a chance to check with other clients? It would be good to
> know if this is macbook specific interoparibility problem or something
> else.
>

So, to resurrect an ancient thread....

I have a user (who wants to buy and sell lots and lots of QCA chipset NICS!)
of my 10.1 firmware hitting this problem.  They have a way to reproduce
it readily, though for one reason or another, I cannot reproduce it locally using what
should be an identical setup.

Their problem cannot be reproduced in a stock 10.2 firmware (firmware-3.bin, I think) on a newer kernel,
while that newer kernel does hit the problem with my 10.1 firmware.  So, it is
definitely something in the firmware.  Their system cannot use 10.2 firmware
at the moment because it is based on an older kernel.

So, I am curious if someone would like to give me a hint as to what was the actual
firmware fix for this issue.  I don't need code snippets since that stuff is
private...but just a method name and/or file or something and I should be able
to track it down and backport just that fix.  I've tried comparing obvious code
spots in 10.1 and 10.2 firmware, but nothing obvious jumps out.

Thanks,
Ben

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



From greearb at candelatech.com  Thu Jun 16 17:11:33 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 16 Jun 2016 17:11:33 -0700
Subject: Dynamic Bandwidth in hw rate control
In-Reply-To: <CAFc9h7uBnGK_paWPCzb_R=kFmcGKenSY6-Ab1c--pfhKn9cAWw@mail.gmail.com>
References: <CAFc9h7uxTOUxONvW-gvgkFLUNR9OBn09kfetF9gqAtcNqN3SLg@mail.gmail.com>
 <5758FD6B.40409@candelatech.com>
 <CAFc9h7s69rVpMNUx553zsHfLf2uLcqx0jhKqma-+SxA6EkybMA@mail.gmail.com>
 <5763120E.4040902@candelatech.com>
 <CAFc9h7uBnGK_paWPCzb_R=kFmcGKenSY6-Ab1c--pfhKn9cAWw@mail.gmail.com>
Message-ID: <57634035.20101@candelatech.com>

On 06/16/2016 03:44 PM, Gaurang Ramesh Naik wrote:
> Thanks Ben and Dave for your replies. So what I understand is that
> dynamic bandwidth management is a part of the rate control algorithm
> (which is implemented in firmware) and hence I have not much control
> over how that works.

With stock firmware you have very little control, though newer stock
firmware has some tweaks to rate-ctrl that the driver does not yet
support.

With my firmware and driver, you can at least disable any particular rate.
So, you could disable all 40Mhz rates, for instance.  I'm not sure how
useful that would be...

> I am assuming your firmware is the one that can be downloaded from
> http://www.candelatech.com/ath10k.php Is your kernel a modified one
> too? When you say I can see the tx rate for each frame, is it through
> some logs? I could try to get some info by using that. Thanks again.

Please read that page, it has links to kernel source.

tx-rate will be reported up the stack in a normal manner (ie, somewhat like
ath9k does it).  You could instrument the kernel to save a histogram of
tx-rates or something similar, perhaps.  'iw dev wlan0 station dump' and
similar will now show expected tx rate, but that is an average or maybe
the last tx rate reported, so it does not give a detailed view of
what is happening.

You can also sniff the air and see the rates in that manner (on any
firmware, including stock).

> Slightly unrelated, but is there a way I can play around with PIFS
> value? I could not locate it in the ath10k source, so I am assuming it
> is implemented in the firmware. I am trying to study some fairness
> issues when legacy devices operate in the secondary channels.

I don't have time to dig into this right now, but if you don't
see anything in the driver related to this, then probably it requires
firmware changes.

Thanks,
Ben


>
> On Thu, Jun 16, 2016 at 4:54 PM, Ben Greear <greearb at candelatech.com> wrote:
>> On 06/16/2016 12:57 PM, Gaurang Ramesh Naik wrote:
>>>
>>> Hi Ben,
>>>
>>> Thanks for your reply.
>>>
>>> I wanted to know if the dynamic bandwidth option implemented in ath10k
>>> is the same as that mentioned in the standard, or does it deviate? I
>>> tried to look for any documentation on ath10k dynamic bandwidth, but
>>> could not find any.
>>>
>>> If I am not wrong, on the secondary channel, the sender senses the
>>> channel for PIFS interval of time immediately preceding the start of
>>> the TXOP (9.19.2.8 in the standard). In the static mode, if the
>>> secondary channel is sensed busy, the sender waits until all channels
>>> become idle; but in the dynamic mode, the sender sends on the primary
>>> and (adjacent) secondary channel that are not busy.
>>>
>>> However, the documentation for dynamic bandwidth in ath10k/mac.c seems
>>> to suggest that the transmission retries are carried over narrower
>>> bandwidth in dynamic mode. Does this mean the same as what is given in
>>> the standard? Or is the dynamic mode implemented differently? Any help
>>> is appreciated.
>>
>>
>> I don't know exactly how this works.  At least the sensing and stuff is
>> probably
>> baked into the hardware.  What I notice is that the firmware passes a series
>> of rates to the hardware to use for each packet, and it includes different
>> bandwidth rates.
>>
>> If you used my firmware and my kernel, you can see the (successful) transmit
>> rate for each frame.  Perhaps you could discover some info about how it
>> works
>> in that manner if you could reliably add noise on an adjacent channel.
>>
>> Upstream firmware can see tx rates using pktlog I think, but I have
>> never tried that.
>>
>> Thanks,
>> Ben
>>
>>
>>>
>>> Thanks,
>>> Gaurang.
>>>
>>> On Thu, Jun 9, 2016 at 1:23 AM, Ben Greear <greearb at candelatech.com>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On 06/08/2016 08:10 PM, Gaurang Ramesh Naik wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I needed a small clarification related to dynamic bandwidth setup. The
>>>>> documentation in wmi.h says " When enabled HW rate control tries
>>>>> different bandwidths when retransmitting frames."
>>>>>
>>>>> Does this mean that each packet is first always tried over VHT80 and
>>>>> if that fails it goes to HT40 and then to HT20? I tried this with one
>>>>> AP-Sta operating in VHT80 and one AP operating in its first secondary
>>>>> channel. When I check the rx rate info using "iw dev wlanx station
>>>>> dump", the bandwidth seems to sometimes alternate between 20 and 80,
>>>>> but sometimes it stays fixed at 20. Hence, I was wondering what really
>>>>> happens.
>>>>
>>>>
>>>>
>>>> For one thing, if the hardware detects interference on secondary
>>>> channels,
>>>> then it may decide to transmit a 20Mhz encoding.
>>>>
>>>> The rate-ctrl algs in the firmware differ from release to release, but
>>>> the general goal is to transmit with the fastest encoding rate.
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>>>
>>>>> Thanks,
>>>>> Gaurang.
>>>>>
>>>>> _______________________________________________
>>>>> ath10k mailing list
>>>>> ath10k at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>
>>>>
>>>> --
>>>> Ben Greear <greearb at candelatech.com>
>>>> Candela Technologies Inc  http://www.candelatech.com
>>>
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>
>>
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>


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



From greearb at candelatech.com  Mon Jun 20 13:49:42 2016
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 20 Jun 2016 13:49:42 -0700
Subject: [PATCH v2 01/21] ath10k: Fix crash related to printing features.
In-Reply-To: <1462986153-16318-2-git-send-email-greearb@candelatech.com>
References: <1462986153-16318-1-git-send-email-greearb@candelatech.com>
 <1462986153-16318-2-git-send-email-greearb@candelatech.com>
Message-ID: <576856E6.2030003@candelatech.com>

On 05/11/2016 10:02 AM, greearb at candelatech.com wrote:
> From: Ben Greear <greearb at candelatech.com>
>
> This looks like a regression from
> c4cdf753 (move fw_features to struct ath10k_fw_file)

Just FYI, this patch does not appear to be in 4.7-rc4 as of today, and so kernel crashes on
startup when loading ath10k, at least when DBG_BOOT logging is enabled....

Thanks,
Ben

>
> Signed-off-by:  Ben Greear <greearb at candelatech.com>
> ---
>   drivers/net/wireless/ath/ath10k/core.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> index e94cb87..b7318b8 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -1078,7 +1078,7 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, const char *name,
>   			}
>
>   			ath10k_dbg_dump(ar, ATH10K_DBG_BOOT, "features", "",
> -					ar->running_fw->fw_file.fw_features,
> +					fw_file->fw_features,
>   					sizeof(fw_file->fw_features));
>   			break;
>   		case ATH10K_FW_IE_FW_IMAGE:
>


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



From greearb at candelatech.com  Mon Jun 20 14:52:07 2016
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 20 Jun 2016 14:52:07 -0700
Subject: Stand-alone ath10k-ct driver.
Message-ID: <57686587.9050607@candelatech.com>

Hello!

I have made an attempt to provide a stand-alone ath10k driver that should compile
and work against stock 4.7 kernels.  This should provide better support for CT ath10k
firmware without having to apply large numbers of patches.  My 4.7 kernel has only been very lightly tested
to date, and the stand-alone driver is only compile tested.  I will update the
ath-ct repo often as testing progresses on 4.7.

If there are brave souls that want to try it out, I'd appreciate any feedback.

https://github.com/greearb/ath-ct

See the README.txt for some details.  This will require at least some familiarity
with building kernels since I do not have any nice automation to compile against
the current running kernel yet, for instance.

Thanks,
Ben

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



From kvalo at qca.qualcomm.com  Mon Jun 20 14:53:30 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Mon, 20 Jun 2016 21:53:30 +0000
Subject: WARNING at include/net/fq_impl.h:22 fq_flow_dequeue+0xed/0x140
 [mac80211]
Message-ID: <878txzo7c6.fsf@kamboji.qca.qualcomm.com>

Hi,

I updated to latest wireless-testing (wt-2016-06-20) and noticed that my
syslog has thousands of warnings like this:

[  237.335805] ------------[ cut here ]------------
[  237.335852] WARNING: CPU: 3 PID: 1921 at include/net/fq_impl.h:22 fq_flow_dequeue+0xed/0x140 [mac80211]
[  237.335855] Modules linked in: ath10k_pci(E-) ath10k_core(E) ath(E) mac80211(E) cfg80211(E) arc4 snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core coretemp snd_hwdep snd_pcm joydev input_leds serio_raw snd_seq_midi btusb btintel snd_r
[  237.335913] CPU: 3 PID: 1921 Comm: rmmod Tainted: G        W   E   4.7.0-rc4-wt-ath+ #1377
[  237.335916] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD Ver. F.04 01/27/2010
[  237.335918]  00200286 00200286 eff85dac c14151e2 f901574e 00000000 eff85de0 c1081075
[  237.335928]  c1ab91f0 00000003 00000781 f901574e 00000016 f8fbabad f8fbabad 00000016
[  237.335938]  eb24ff60 00000000 ef3886c0 eff85df4 c10810ba 00000009 00000000 00000000
[  237.335948] Call Trace:
[  237.335953]  [<c14151e2>] dump_stack+0x76/0xb4
[  237.335957]  [<c1081075>] __warn+0xe5/0x100
[  237.336002]  [<f8fbabad>] ? fq_flow_dequeue+0xed/0x140 [mac80211]
[  237.336046]  [<f8fbabad>] ? fq_flow_dequeue+0xed/0x140 [mac80211]
[  237.336053]  [<c10810ba>] warn_slowpath_null+0x2a/0x30
[  237.336095]  [<f8fbabad>] fq_flow_dequeue+0xed/0x140 [mac80211]
[  237.336137]  [<f8fbc67a>] fq_flow_reset.constprop.56+0x2a/0x90 [mac80211]
[  237.336180]  [<f8fbc79a>] fq_reset.constprop.59+0x2a/0x50 [mac80211]
[  237.336222]  [<f8fc04e8>] ieee80211_txq_teardown_flows+0x38/0x40 [mac80211]
[  237.336258]  [<f8f7c1a4>] ieee80211_unregister_hw+0xe4/0x120 [mac80211]
[  237.336275]  [<f933f536>] ath10k_mac_unregister+0x16/0x50 [ath10k_core]
[  237.336292]  [<f934592d>] ath10k_core_unregister+0x3d/0x90 [ath10k_core]
[  237.336301]  [<f85f8836>] ath10k_pci_remove+0x36/0xa0 [ath10k_pci]
[  237.336307]  [<c1470388>] pci_device_remove+0x38/0xb0
[  237.336314]  [<c1572e8b>] __device_release_driver+0x7b/0x110
[  237.336321]  [<c1573117>] driver_detach+0x97/0xa0
[  237.336327]  [<c1571f7f>] bus_remove_driver+0x4f/0xc0
[  237.336333]  [<c1573d0a>] driver_unregister+0x2a/0x60
[  237.336339]  [<c146f3a8>] pci_unregister_driver+0x18/0x70
[  237.336347]  [<f85f9c8e>] ath10k_pci_exit+0xd/0x37f [ath10k_pci]
[  237.336354]  [<c1122fd8>] SyS_delete_module+0xf8/0x170
[  237.336361]  [<c11e66c9>] ? __might_fault+0x49/0xa0
[  237.336367]  [<c11e6713>] ? __might_fault+0x93/0xa0
[  237.336373]  [<c1003886>] do_fast_syscall_32+0xa6/0x1d0
[  237.336379]  [<c1871dbc>] sysenter_past_esp+0x45/0x74
[  237.336384] ---[ end trace 6fc65ff0beec502c ]---
[  237.336388] ------------[ cut here ]------------
[  237.336431] WARNING: CPU: 3 PID: 1921 at include/net/fq_impl.h:22 fq_flow_dequeue+0xed/0x140 [mac80211]
[  237.336435] Modules linked in: ath10k_pci(E-) ath10k_core(E) ath(E) mac80211(E) cfg80211(E) arc4 snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core coretemp snd_hwdep snd_pcm joydev input_leds serio_raw snd_seq_midi btusb btintel snd_r
[  237.336537] CPU: 3 PID: 1921 Comm: rmmod Tainted: G        W   E   4.7.0-rc4-wt-ath+ #1377
[  237.336542] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD Ver. F.04 01/27/2010
[  237.336546]  00200286 00200286 eff85dac c14151e2 f901574e 00000000 eff85de0 c1081075
[  237.336563]  c1ab91f0 00000003 00000781 f901574e 00000016 f8fbabad f8fbabad 00000016
[  237.336573]  eb24ffb0 00000000 ef3886c0 eff85df4 c10810ba 00000009 00000000 00000000
[  237.336581] Call Trace:
[  237.336586]  [<c14151e2>] dump_stack+0x76/0xb4
[  237.336590]  [<c1081075>] __warn+0xe5/0x100
[  237.336634]  [<f8fbabad>] ? fq_flow_dequeue+0xed/0x140 [mac80211]
[  237.336678]  [<f8fbabad>] ? fq_flow_dequeue+0xed/0x140 [mac80211]
[  237.336682]  [<c10810ba>] warn_slowpath_null+0x2a/0x30
[  237.336726]  [<f8fbabad>] fq_flow_dequeue+0xed/0x140 [mac80211]
[  237.336770]  [<f8fbc67a>] fq_flow_reset.constprop.56+0x2a/0x90 [mac80211]
[  237.336814]  [<f8fbc79a>] fq_reset.constprop.59+0x2a/0x50 [mac80211]
[  237.336857]  [<f8fc04e8>] ieee80211_txq_teardown_flows+0x38/0x40 [mac80211]
[  237.336895]  [<f8f7c1a4>] ieee80211_unregister_hw+0xe4/0x120 [mac80211]
[  237.336912]  [<f933f536>] ath10k_mac_unregister+0x16/0x50 [ath10k_core]
[  237.336928]  [<f934592d>] ath10k_core_unregister+0x3d/0x90 [ath10k_core]
[  237.336934]  [<f85f8836>] ath10k_pci_remove+0x36/0xa0 [ath10k_pci]
[  237.336939]  [<c1470388>] pci_device_remove+0x38/0xb0
[  237.336944]  [<c1572e8b>] __device_release_driver+0x7b/0x110
[  237.336948]  [<c1573117>] driver_detach+0x97/0xa0
[  237.336952]  [<c1571f7f>] bus_remove_driver+0x4f/0xc0
[  237.336957]  [<c1573d0a>] driver_unregister+0x2a/0x60
[  237.336960]  [<c146f3a8>] pci_unregister_driver+0x18/0x70
[  237.336966]  [<f85f9c8e>] ath10k_pci_exit+0xd/0x37f [ath10k_pci]
[  237.336970]  [<c1122fd8>] SyS_delete_module+0xf8/0x170
[  237.336974]  [<c11e66c9>] ? __might_fault+0x49/0xa0
[  237.336980]  [<c11e6713>] ? __might_fault+0x93/0xa0
[  237.336986]  [<c1003886>] do_fast_syscall_32+0xa6/0x1d0
[  237.336992]  [<c1871dbc>] sysenter_past_esp+0x45/0x74
[  237.336997] ---[ end trace 6fc65ff0beec502d ]---

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Mon Jun 20 14:56:38 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Mon, 20 Jun 2016 21:56:38 +0000
Subject: [PATCH v2 01/21] ath10k: Fix crash related to printing features.
In-Reply-To: <576856E6.2030003@candelatech.com> (Ben Greear's message of "Mon, 
 20 Jun 2016 13:49:42 -0700")
References: <1462986153-16318-1-git-send-email-greearb@candelatech.com>
 <1462986153-16318-2-git-send-email-greearb@candelatech.com>
 <576856E6.2030003@candelatech.com>
Message-ID: <874m8no76y.fsf@kamboji.qca.qualcomm.com>

Ben Greear <greearb at candelatech.com> writes:

> On 05/11/2016 10:02 AM, greearb at candelatech.com wrote:
>> From: Ben Greear <greearb at candelatech.com>
>>
>> This looks like a regression from
>> c4cdf753 (move fw_features to struct ath10k_fw_file)
>
> Just FYI, this patch does not appear to be in 4.7-rc4 as of today, and
> so kernel crashes on startup when loading ath10k, at least when
> DBG_BOOT logging is enabled....

The fix is wireless-drivers.git now, I'm planning to send a pull request
to Dave tomorrow.

-- 
Kalle Valo

From greearb at candelatech.com  Mon Jun 20 16:06:52 2016
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 20 Jun 2016 16:06:52 -0700
Subject: Bug with: ath10k: enable parsing per station rx duration for 10.4?
Message-ID: <5768770C.5050305@candelatech.com>

I'm working on bringing up my hacked up version of 4.7 ath10k and 10.4 firmware, and I think
I may have found a regression.

My 10.4.3-ish firmware source has a bunch of:

if (stats_id == WMI_REQUEST_PEER_STAT)
logic in it.  In other words, it is not using that id as a bitfield.

Now, I can fix the firmware, but I am guessing that at least some stock
10.4 firmware has this same issue, and of course any older firmware
that does not have this change will still be broken.

So, do you want to back out this patch below, at least the part where it sends
in 0x9 as the stats_id?

Or, is all available upstream 10.4 firmware OK with this and I should just fix mine?

Or possibly, this is all my fault and I somehow screwed up when rebasing....

Thanks,
Ben


Author: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>  2016-03-16 05:43:34
Committer: Kalle Valo <kvalo at qca.qualcomm.com>  2016-04-04 07:02:47
Parent: 47771902a9beb23859805721f1d98d03dee5da7c (ath10k: introduce Extended Resource Config support for 10.4)
Child:  59465fe46ef1c2caf2c1beca828c4f29d28b98ca (ath10k: speedup htt rx descriptor processing for tx completion)
Branches: master, master.stgit, remotes/origin/master, remotes/origin/master.stgit
Follows: v4.5-rc5
Precedes: v4.7-rc1

     ath10k: enable parsing per station rx duration for 10.4

     Rx duration support for per station is part of extended peer
     stats, enable provision to parse the same and provide backward
     compatibility based on the 'stats_id' event

     Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
     Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>

....

@@ -1615,7 +1615,8 @@ static int ath10k_core_init_firmware_features(struct ath10k *ar)
  		ar->num_active_peers = TARGET_10_4_ACTIVE_PEERS;
  		ar->max_num_vdevs = TARGET_10_4_NUM_VDEVS;
  		ar->num_tids = TARGET_10_4_TGT_NUM_TIDS;
-		ar->fw_stats_req_mask = WMI_STAT_PEER;
+		ar->fw_stats_req_mask = WMI_10_4_STAT_PEER |
+					WMI_10_4_STAT_PEER_EXTD;
  		ar->max_spatial_stream = ar->hw_params.max_spatial_stream;

  		if (test_bit(ATH10K_FW_FEATURE_PEER_FLOW_CONTROL,


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



From s.gottschall at dd-wrt.com  Mon Jun 20 16:11:35 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Tue, 21 Jun 2016 01:11:35 +0200
Subject: Stand-alone ath10k-ct driver.
In-Reply-To: <57686587.9050607@candelatech.com>
References: <57686587.9050607@candelatech.com>
Message-ID: <1c702fd0-677c-82e3-ddbe-ab4335a4a1a6@dd-wrt.com>

Am 20.06.2016 um 23:52 schrieb Ben Greear:
> Hello!
>
> I have made an attempt to provide a stand-alone ath10k driver that 
> should compile
> and work against stock 4.7 kernels.  This should provide better 
> support for CT ath10k
> firmware without having to apply large numbers of patches.  My 4.7 
> kernel has only been very lightly tested
> to date, and the stand-alone driver is only compile tested.  I will 
> update the
> ath-ct repo often as testing progresses on 4.7.
>
> If there are brave souls that want to try it out, I'd appreciate any 
> feedback.
>
> https://github.com/greearb/ath-ct
>
> See the README.txt for some details.  This will require at least some 
> familiarity
> with building kernels since I do not have any nice automation to 
> compile against
> the current running kernel yet, for instance.
>
why dont you use compat-wireless / backports as base?
so you can use your driver in any kernel version
> Thanks,
> Ben
>


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From greearb at candelatech.com  Mon Jun 20 16:19:33 2016
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 20 Jun 2016 16:19:33 -0700
Subject: Stand-alone ath10k-ct driver.
In-Reply-To: <1c702fd0-677c-82e3-ddbe-ab4335a4a1a6@dd-wrt.com>
References: <57686587.9050607@candelatech.com>
 <1c702fd0-677c-82e3-ddbe-ab4335a4a1a6@dd-wrt.com>
Message-ID: <57687A05.3080400@candelatech.com>

On 06/20/2016 04:11 PM, Sebastian Gottschall wrote:
> Am 20.06.2016 um 23:52 schrieb Ben Greear:
>> Hello!
>>
>> I have made an attempt to provide a stand-alone ath10k driver that should compile
>> and work against stock 4.7 kernels.  This should provide better support for CT ath10k
>> firmware without having to apply large numbers of patches.  My 4.7 kernel has only been very lightly tested
>> to date, and the stand-alone driver is only compile tested.  I will update the
>> ath-ct repo often as testing progresses on 4.7.
>>
>> If there are brave souls that want to try it out, I'd appreciate any feedback.
>>
>> https://github.com/greearb/ath-ct
>>
>> See the README.txt for some details.  This will require at least some familiarity
>> with building kernels since I do not have any nice automation to compile against
>> the current running kernel yet, for instance.
>>
> why dont you use compat-wireless / backports as base?
> so you can use your driver in any kernel version

Just no time to deal with backports, and if I have just a stand-alone driver,
then it is easier for folks to use it in whatever kernel they already happen
to be using.  Hopefully some project that is already using a 4.7-ish backport
can compile my driver against that and have it just work, for instance.

Since I'm finding so many regressions when I rebase, and rebasing makes it almost
impossible to bisect between kernels, then maybe it would just be better if
I maintained a parallel drivers/net/wireless/ath/ath10k-ct/, and just applied
patches from ../ath10k/ manually on top of my own stuff.  At least that way
I could bisect regressions....

Thanks,
Ben

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



From mohammed at codeaurora.org  Mon Jun 20 22:18:30 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Tue, 21 Jun 2016 10:48:30 +0530
Subject: Bug with: ath10k: enable parsing per station rx duration for 10.4?
In-Reply-To: <5768770C.5050305@candelatech.com>
References: <5768770C.5050305@candelatech.com>
Message-ID: <20160621051829.GA20604@atheros-ThinkPad-T61>

Hi Ben,

thanks for reporting ...

On Mon, Jun 20, 2016 at 04:06:52PM -0700, Ben Greear wrote:
> I'm working on bringing up my hacked up version of 4.7 ath10k and 10.4 firmware, and I think
> I may have found a regression.

[shafi] let me know what is the issue.. some steps to recreate the issue.
> 
> My 10.4.3-ish firmware source has a bunch of:
> 
> if (stats_id == WMI_REQUEST_PEER_STAT)
> logic in it.  In other words, it is not using that id as a bitfield.

[shafi] will check this.

> 
> Now, I can fix the firmware, but I am guessing that at least some stock
> 10.4 firmware has this same issue, and of course any older firmware
> that does not have this change will still be broken.
> 
> So, do you want to back out this patch below, at least the part where it sends
> in 0x9 as the stats_id?

[shafi] request if you can check this please, there was some misunderstanding
in the design when this feature got enabled in 10.4, we fixed it in
https://patchwork.kernel.org/patch/9149357/

> 
> Or, is all available upstream 10.4 firmware OK with this and I should just fix mine?
> 
> Or possibly, this is all my fault and I somehow screwed up when rebasing....

[shafi] i will check this and get back to you by end of day.

regards,
shafi
> 
> 
> Author: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>  2016-03-16 05:43:34
> Committer: Kalle Valo <kvalo at qca.qualcomm.com>  2016-04-04 07:02:47
> Parent: 47771902a9beb23859805721f1d98d03dee5da7c (ath10k: introduce Extended Resource Config support for 10.4)
> Child:  59465fe46ef1c2caf2c1beca828c4f29d28b98ca (ath10k: speedup htt rx descriptor processing for tx completion)
> Branches: master, master.stgit, remotes/origin/master, remotes/origin/master.stgit
> Follows: v4.5-rc5
> Precedes: v4.7-rc1
> 
>     ath10k: enable parsing per station rx duration for 10.4
> 
>     Rx duration support for per station is part of extended peer
>     stats, enable provision to parse the same and provide backward
>     compatibility based on the 'stats_id' event
> 
>     Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
>     Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>
> 
> ....
> 
> @@ -1615,7 +1615,8 @@ static int ath10k_core_init_firmware_features(struct ath10k *ar)
>  		ar->num_active_peers = TARGET_10_4_ACTIVE_PEERS;
>  		ar->max_num_vdevs = TARGET_10_4_NUM_VDEVS;
>  		ar->num_tids = TARGET_10_4_TGT_NUM_TIDS;
> -		ar->fw_stats_req_mask = WMI_STAT_PEER;
> +		ar->fw_stats_req_mask = WMI_10_4_STAT_PEER |
> +					WMI_10_4_STAT_PEER_EXTD;
>  		ar->max_spatial_stream = ar->hw_params.max_spatial_stream;
> 
>  		if (test_bit(ATH10K_FW_FEATURE_PEER_FLOW_CONTROL,
> 
> 
> -- 
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
> 
> 
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From akolli at qti.qualcomm.com  Mon Jun 20 22:48:07 2016
From: akolli at qti.qualcomm.com (akolli at qti.qualcomm.com)
Date: Tue, 21 Jun 2016 11:18:07 +0530
Subject: [PATCH 1/2] ath10k: remove unused member in ath10k_hw_regs
Message-ID: <1466488088-20961-1-git-send-email-akolli@qti.qualcomm.com>

From: Anilkumar Kolli <akolli at qti.qualcomm.com>

rtc_state_cold_reset_mask is unused in ath10k_hw_regs.
instead fixed delays are used.

Signed-off-by: Anilkumar Kolli <akolli at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/hw.c |    3 ---
 drivers/net/wireless/ath/ath10k/hw.h |    2 --
 2 files changed, 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/hw.c b/drivers/net/wireless/ath/ath10k/hw.c
index f544d48518c3..433e064c7718 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -19,7 +19,6 @@
 #include "hw.h"
 
 const struct ath10k_hw_regs qca988x_regs = {
-	.rtc_state_cold_reset_mask	= 0x00000400,
 	.rtc_soc_base_address		= 0x00004000,
 	.rtc_wmac_base_address		= 0x00005000,
 	.soc_core_base_address		= 0x00009000,
@@ -46,7 +45,6 @@ const struct ath10k_hw_regs qca988x_regs = {
 };
 
 const struct ath10k_hw_regs qca6174_regs = {
-	.rtc_state_cold_reset_mask		= 0x00002000,
 	.rtc_soc_base_address			= 0x00000800,
 	.rtc_wmac_base_address			= 0x00001000,
 	.soc_core_base_address			= 0x0003a000,
@@ -73,7 +71,6 @@ const struct ath10k_hw_regs qca6174_regs = {
 };
 
 const struct ath10k_hw_regs qca99x0_regs = {
-	.rtc_state_cold_reset_mask		= 0x00000400,
 	.rtc_soc_base_address			= 0x00080000,
 	.rtc_wmac_base_address			= 0x00000000,
 	.soc_core_base_address			= 0x00082000,
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index f41c91ccb56a..549f99bdfb86 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -208,7 +208,6 @@ enum ath10k_hw_rev {
 };
 
 struct ath10k_hw_regs {
-	u32 rtc_state_cold_reset_mask;
 	u32 rtc_soc_base_address;
 	u32 rtc_wmac_base_address;
 	u32 soc_core_base_address;
@@ -495,7 +494,6 @@ enum ath10k_hw_4addr_pad {
 /* as of IP3.7.1 */
 #define RTC_STATE_V_ON				ar->hw_values->rtc_state_val_on
 
-#define RTC_STATE_COLD_RESET_MASK		ar->regs->rtc_state_cold_reset_mask
 #define RTC_STATE_V_LSB				0
 #define RTC_STATE_V_MASK			0x00000007
 #define RTC_STATE_ADDRESS			0x0000
-- 
1.7.9.5



From akolli at qti.qualcomm.com  Mon Jun 20 22:48:08 2016
From: akolli at qti.qualcomm.com (akolli at qti.qualcomm.com)
Date: Tue, 21 Jun 2016 11:18:08 +0530
Subject: [PATCH 2/2] ath10k: Enable support for QCA9888
In-Reply-To: <1466488088-20961-1-git-send-email-akolli@qti.qualcomm.com>
References: <1466488088-20961-1-git-send-email-akolli@qti.qualcomm.com>
Message-ID: <1466488088-20961-2-git-send-email-akolli@qti.qualcomm.com>

From: Anilkumar Kolli <akolli at qti.qualcomm.com>

QCA9888 shares the same configuration with QCA99X0
with NSS=2.

Signed-off-by: Anilkumar Kolli <akolli at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c |   26 ++++++++++++++++++++++++++
 drivers/net/wireless/ath/ath10k/hw.c   |    9 +++++++++
 drivers/net/wireless/ath/ath10k/hw.h   |   12 ++++++++++++
 drivers/net/wireless/ath/ath10k/pci.c  |   13 +++++++++++++
 4 files changed, 60 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index a003980d8972..8a080ab5b07e 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -185,6 +185,28 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		},
 	},
 	{
+		.id = QCA9888_HW_2_0_DEV_VERSION,
+		.dev_id = QCA9888_2_0_DEVICE_ID,
+		.name = "qca9888 hw2.0",
+		.patch_load_addr = QCA9888_HW_2_0_PATCH_LOAD_ADDR,
+		.uart_pin = 7,
+		.otp_exe_param = 0x00000700,
+		.continuous_frag_desc = true,
+		.channel_counters_freq_hz = 150000,
+		.max_probe_resp_desc_thres = 24,
+		.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
+		.tx_chain_mask = 3,
+		.rx_chain_mask = 3,
+		.max_spatial_stream = 2,
+		.cal_data_len = 12064,
+		.fw = {
+			.dir = QCA9888_HW_2_0_FW_DIR,
+			.board = QCA9888_HW_2_0_BOARD_DATA_FILE,
+			.board_size = QCA99X0_BOARD_DATA_SZ,
+			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+		},
+	},
+	{
 		.id = QCA9377_HW_1_0_DEV_VERSION,
 		.dev_id = QCA9377_1_0_DEVICE_ID,
 		.name = "qca9377 hw1.0",
@@ -2097,6 +2119,10 @@ struct ath10k *ath10k_core_create(size_t priv_size, struct device *dev,
 		ar->regs = &qca99x0_regs;
 		ar->hw_values = &qca99x0_values;
 		break;
+	case ATH10K_HW_QCA9888:
+		ar->regs = &qca99x0_regs;
+		ar->hw_values = &qca9888_values;
+		break;
 	case ATH10K_HW_QCA4019:
 		ar->regs = &qca4019_regs;
 		ar->hw_values = &qca4019_values;
diff --git a/drivers/net/wireless/ath/ath10k/hw.c b/drivers/net/wireless/ath/ath10k/hw.c
index 433e064c7718..c2c0122a140b 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -165,6 +165,15 @@ const struct ath10k_hw_values qca99x0_values = {
 	.ce_desc_meta_data_lsb		= 4,
 };
 
+const struct ath10k_hw_values qca9888_values = {
+	.rtc_state_val_on		= 3,
+	.ce_count			= 12,
+	.msi_assign_ce_max		= 12,
+	.num_target_ce_config_wlan	= 10,
+	.ce_desc_meta_data_mask		= 0xFFF0,
+	.ce_desc_meta_data_lsb		= 4,
+};
+
 const struct ath10k_hw_values qca4019_values = {
 	.ce_count                       = 12,
 	.num_target_ce_config_wlan      = 10,
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 549f99bdfb86..d537555b28e7 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -26,6 +26,7 @@
 #define QCA6164_2_1_DEVICE_ID   (0x0041)
 #define QCA6174_2_1_DEVICE_ID   (0x003e)
 #define QCA99X0_2_0_DEVICE_ID   (0x0040)
+#define QCA9888_2_0_DEVICE_ID	(0x0056)
 #define QCA9984_1_0_DEVICE_ID	(0x0046)
 #define QCA9377_1_0_DEVICE_ID   (0x0042)
 
@@ -100,6 +101,14 @@ enum qca9377_chip_id_rev {
 #define QCA9984_HW_1_0_BOARD_DATA_FILE "board.bin"
 #define QCA9984_HW_1_0_PATCH_LOAD_ADDR	0x1234
 
+/* QCA9888 2.0 defines */
+#define QCA9888_HW_2_0_DEV_VERSION	0x1000000
+#define QCA9888_HW_DEV_TYPE		0xc
+#define QCA9888_HW_2_0_CHIP_ID_REV	0x0
+#define QCA9888_HW_2_0_FW_DIR		ATH10K_FW_DIR "/QCA9888/hw2.0"
+#define QCA9888_HW_2_0_BOARD_DATA_FILE "board.bin"
+#define QCA9888_HW_2_0_PATCH_LOAD_ADDR	0x1234
+
 /* QCA9377 1.0 definitions */
 #define QCA9377_HW_1_0_FW_DIR          ATH10K_FW_DIR "/QCA9377/hw1.0"
 #define QCA9377_HW_1_0_BOARD_DATA_FILE "board.bin"
@@ -202,6 +211,7 @@ enum ath10k_hw_rev {
 	ATH10K_HW_QCA988X,
 	ATH10K_HW_QCA6174,
 	ATH10K_HW_QCA99X0,
+	ATH10K_HW_QCA9888,
 	ATH10K_HW_QCA9984,
 	ATH10K_HW_QCA9377,
 	ATH10K_HW_QCA4019,
@@ -250,6 +260,7 @@ struct ath10k_hw_values {
 extern const struct ath10k_hw_values qca988x_values;
 extern const struct ath10k_hw_values qca6174_values;
 extern const struct ath10k_hw_values qca99x0_values;
+extern const struct ath10k_hw_values qca9888_values;
 extern const struct ath10k_hw_values qca4019_values;
 
 void ath10k_hw_fill_survey_time(struct ath10k *ar, struct survey_info *survey,
@@ -258,6 +269,7 @@ void ath10k_hw_fill_survey_time(struct ath10k *ar, struct survey_info *survey,
 #define QCA_REV_988X(ar) ((ar)->hw_rev == ATH10K_HW_QCA988X)
 #define QCA_REV_6174(ar) ((ar)->hw_rev == ATH10K_HW_QCA6174)
 #define QCA_REV_99X0(ar) ((ar)->hw_rev == ATH10K_HW_QCA99X0)
+#define QCA_REV_9888(ar) ((ar)->hw_rev == ATH10K_HW_QCA9888)
 #define QCA_REV_9984(ar) ((ar)->hw_rev == ATH10K_HW_QCA9984)
 #define QCA_REV_9377(ar) ((ar)->hw_rev == ATH10K_HW_QCA9377)
 #define QCA_REV_40XX(ar) ((ar)->hw_rev == ATH10K_HW_QCA4019)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 8e8e1eb4dd0a..d9ce865a5158 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -56,6 +56,7 @@ static const struct pci_device_id ath10k_pci_id_table[] = {
 	{ PCI_VDEVICE(ATHEROS, QCA6164_2_1_DEVICE_ID) }, /* PCI-E QCA6164 V2.1 */
 	{ PCI_VDEVICE(ATHEROS, QCA6174_2_1_DEVICE_ID) }, /* PCI-E QCA6174 V2.1 */
 	{ PCI_VDEVICE(ATHEROS, QCA99X0_2_0_DEVICE_ID) }, /* PCI-E QCA99X0 V2 */
+	{ PCI_VDEVICE(ATHEROS, QCA9888_2_0_DEVICE_ID) }, /* PCI-E QCA9888 V2 */
 	{ PCI_VDEVICE(ATHEROS, QCA9984_1_0_DEVICE_ID) }, /* PCI-E QCA9984 V1 */
 	{ PCI_VDEVICE(ATHEROS, QCA9377_1_0_DEVICE_ID) }, /* PCI-E QCA9377 V1 */
 	{0}
@@ -84,6 +85,8 @@ static const struct ath10k_pci_supp_chip ath10k_pci_supp_chips[] = {
 
 	{ QCA9984_1_0_DEVICE_ID, QCA9984_HW_1_0_CHIP_ID_REV },
 
+	{ QCA9888_2_0_DEVICE_ID, QCA9888_HW_2_0_CHIP_ID_REV },
+
 	{ QCA9377_1_0_DEVICE_ID, QCA9377_HW_1_0_CHIP_ID_REV },
 	{ QCA9377_1_0_DEVICE_ID, QCA9377_HW_1_1_CHIP_ID_REV },
 
@@ -847,6 +850,7 @@ static u32 ath10k_pci_targ_cpu_to_ce_addr(struct ath10k *ar, u32 addr)
 					  CORE_CTRL_ADDRESS) &
 		       0x7ff) << 21;
 		break;
+	case ATH10K_HW_QCA9888:
 	case ATH10K_HW_QCA99X0:
 	case ATH10K_HW_QCA9984:
 	case ATH10K_HW_QCA4019:
@@ -1575,6 +1579,7 @@ static void ath10k_pci_irq_msi_fw_mask(struct ath10k *ar)
 		break;
 	case ATH10K_HW_QCA99X0:
 	case ATH10K_HW_QCA9984:
+	case ATH10K_HW_QCA9888:
 	case ATH10K_HW_QCA4019:
 		/* TODO: Find appropriate register configuration for QCA99X0
 		 *  to mask irq/MSI.
@@ -1599,6 +1604,7 @@ static void ath10k_pci_irq_msi_fw_unmask(struct ath10k *ar)
 		break;
 	case ATH10K_HW_QCA99X0:
 	case ATH10K_HW_QCA9984:
+	case ATH10K_HW_QCA9888:
 	case ATH10K_HW_QCA4019:
 		/* TODO: Find appropriate register configuration for QCA99X0
 		 *  to unmask irq/MSI.
@@ -1939,6 +1945,7 @@ static int ath10k_pci_get_num_banks(struct ath10k *ar)
 	switch (ar_pci->pdev->device) {
 	case QCA988X_2_0_DEVICE_ID:
 	case QCA99X0_2_0_DEVICE_ID:
+	case QCA9888_2_0_DEVICE_ID:
 	case QCA9984_1_0_DEVICE_ID:
 		return 1;
 	case QCA6164_2_1_DEVICE_ID:
@@ -3013,6 +3020,12 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
 		pci_soft_reset = ath10k_pci_qca99x0_soft_chip_reset;
 		pci_hard_reset = ath10k_pci_qca99x0_chip_reset;
 		break;
+	case QCA9888_2_0_DEVICE_ID:
+		hw_rev = ATH10K_HW_QCA9888;
+		pci_ps = false;
+		pci_soft_reset = ath10k_pci_qca99x0_soft_chip_reset;
+		pci_hard_reset = ath10k_pci_qca99x0_chip_reset;
+		break;
 	case QCA9377_1_0_DEVICE_ID:
 		hw_rev = ATH10K_HW_QCA9377;
 		pci_ps = true;
-- 
1.7.9.5



From chaehyun.lim at gmail.com  Tue Jun 21 04:45:38 2016
From: chaehyun.lim at gmail.com (Chaehyun Lim)
Date: Tue, 21 Jun 2016 20:45:38 +0900
Subject: [PATCH 1/2] ath10k: remove unused <linux/semaphore.h>
Message-ID: <20160621114539.15313-1-chaehyun.lim@gmail.com>

<linux/semaphore.h> is not used anymore, so just remove it.

Signed-off-by: Chaehyun Lim <chaehyun.lim at gmail.com>
---
 drivers/net/wireless/ath/ath10k/htc.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/htc.h b/drivers/net/wireless/ath/ath10k/htc.h
index cc82718..0c55cd9 100644
--- a/drivers/net/wireless/ath/ath10k/htc.h
+++ b/drivers/net/wireless/ath/ath10k/htc.h
@@ -22,7 +22,6 @@
 #include <linux/list.h>
 #include <linux/bug.h>
 #include <linux/skbuff.h>
-#include <linux/semaphore.h>
 #include <linux/timer.h>
 
 struct ath10k;
-- 
2.9.0



From chaehyun.lim at gmail.com  Tue Jun 21 04:45:39 2016
From: chaehyun.lim at gmail.com (Chaehyun Lim)
Date: Tue, 21 Jun 2016 20:45:39 +0900
Subject: [PATCH 2/2] ath6kl: replace semaphore with mutex
In-Reply-To: <20160621114539.15313-1-chaehyun.lim@gmail.com>
References: <20160621114539.15313-1-chaehyun.lim@gmail.com>
Message-ID: <20160621114539.15313-2-chaehyun.lim@gmail.com>

It replaces struct semaphore sem with struct mutex mutex

Signed-off-by: Chaehyun Lim <chaehyun.lim at gmail.com>
---
 drivers/net/wireless/ath/ath6kl/cfg80211.c | 30 +++++++++++++++---------------
 drivers/net/wireless/ath/ath6kl/core.c     |  2 +-
 drivers/net/wireless/ath/ath6kl/core.h     |  2 +-
 drivers/net/wireless/ath/ath6kl/debug.c    | 12 ++++++------
 drivers/net/wireless/ath/ath6kl/init.c     |  6 +++---
 5 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index f6b5390..d4eb066 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -480,14 +480,14 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, struct net_device *dev,
 		return -EINVAL;
 	}
 
-	if (down_interruptible(&ar->sem)) {
+	if (mutex_lock_interruptible(&ar->mutex)) {
 		ath6kl_err("busy, couldn't get access\n");
 		return -ERESTARTSYS;
 	}
 
 	if (test_bit(DESTROY_IN_PROGRESS, &ar->flag)) {
 		ath6kl_err("busy, destroy in progress\n");
-		up(&ar->sem);
+		mutex_unlock(&ar->mutex);
 		return -EBUSY;
 	}
 
@@ -500,14 +500,14 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, struct net_device *dev,
 						 WMI_TIMEOUT);
 		if (signal_pending(current)) {
 			ath6kl_err("cmd queue drain timeout\n");
-			up(&ar->sem);
+			mutex_unlock(&ar->mutex);
 			return -EINTR;
 		}
 	}
 
 	status = ath6kl_set_assoc_req_ies(vif, sme->ie, sme->ie_len);
 	if (status) {
-		up(&ar->sem);
+		mutex_unlock(&ar->mutex);
 		return status;
 	}
 
@@ -522,7 +522,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, struct net_device *dev,
 						  vif->req_bssid,
 						  vif->ch_hint);
 
-		up(&ar->sem);
+		mutex_unlock(&ar->mutex);
 		if (status) {
 			ath6kl_err("wmi_reconnect_cmd failed\n");
 			return -EIO;
@@ -548,7 +548,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, struct net_device *dev,
 
 	status = ath6kl_set_auth_type(vif, sme->auth_type);
 	if (status) {
-		up(&ar->sem);
+		mutex_unlock(&ar->mutex);
 		return status;
 	}
 
@@ -570,7 +570,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, struct net_device *dev,
 		if (sme->key_idx > WMI_MAX_KEY_INDEX) {
 			ath6kl_err("key index %d out of bounds\n",
 				   sme->key_idx);
-			up(&ar->sem);
+			mutex_unlock(&ar->mutex);
 			return -ENOENT;
 		}
 
@@ -594,7 +594,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, struct net_device *dev,
 		if (ath6kl_wmi_bssfilter_cmd(ar->wmi, vif->fw_vif_idx,
 					     ALL_BSS_FILTER, 0) != 0) {
 			ath6kl_err("couldn't set bss filtering\n");
-			up(&ar->sem);
+			mutex_unlock(&ar->mutex);
 			return -EIO;
 		}
 	}
@@ -626,7 +626,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, struct net_device *dev,
 						       0);
 		if (status) {
 			ath6kl_err("couldn't set listen intervel\n");
-			up(&ar->sem);
+			mutex_unlock(&ar->mutex);
 			return status;
 		}
 	}
@@ -651,7 +651,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, struct net_device *dev,
 	ath6kl_wmi_scanparams_cmd(ar->wmi, vif->fw_vif_idx, 0, 0,
 				  sme->bg_scan_period, 0, 0, 0, 3, 0, 0, 0);
 
-	up(&ar->sem);
+	mutex_unlock(&ar->mutex);
 
 	if (status == -EINVAL) {
 		memset(vif->ssid, 0, sizeof(vif->ssid));
@@ -832,7 +832,7 @@ static int ath6kl_cfg80211_disconnect(struct wiphy *wiphy,
 		return -EBUSY;
 	}
 
-	if (down_interruptible(&ar->sem)) {
+	if (mutex_lock_interruptible(&ar->mutex)) {
 		ath6kl_err("busy, couldn't get access\n");
 		return -ERESTARTSYS;
 	}
@@ -845,7 +845,7 @@ static int ath6kl_cfg80211_disconnect(struct wiphy *wiphy,
 	if (!test_bit(SKIP_SCAN, &ar->flag))
 		memset(vif->req_bssid, 0, sizeof(vif->req_bssid));
 
-	up(&ar->sem);
+	mutex_unlock(&ar->mutex);
 
 	vif->sme_state = SME_DISCONNECTED;
 
@@ -1775,7 +1775,7 @@ static int ath6kl_get_station(struct wiphy *wiphy, struct net_device *dev,
 	if (memcmp(mac, vif->bssid, ETH_ALEN) != 0)
 		return -ENOENT;
 
-	if (down_interruptible(&ar->sem))
+	if (mutex_lock_interruptible(&ar->mutex))
 		return -EBUSY;
 
 	set_bit(STATS_UPDATE_PEND, &vif->flags);
@@ -1783,7 +1783,7 @@ static int ath6kl_get_station(struct wiphy *wiphy, struct net_device *dev,
 	ret = ath6kl_wmi_get_stats_cmd(ar->wmi, vif->fw_vif_idx);
 
 	if (ret != 0) {
-		up(&ar->sem);
+		mutex_unlock(&ar->mutex);
 		return -EIO;
 	}
 
@@ -1792,7 +1792,7 @@ static int ath6kl_get_station(struct wiphy *wiphy, struct net_device *dev,
 							  &vif->flags),
 						WMI_TIMEOUT);
 
-	up(&ar->sem);
+	mutex_unlock(&ar->mutex);
 
 	if (left == 0)
 		return -ETIMEDOUT;
diff --git a/drivers/net/wireless/ath/ath6kl/core.c b/drivers/net/wireless/ath/ath6kl/core.c
index ebb9f16..0da253a 100644
--- a/drivers/net/wireless/ath/ath6kl/core.c
+++ b/drivers/net/wireless/ath/ath6kl/core.c
@@ -283,7 +283,7 @@ struct ath6kl *ath6kl_core_create(struct device *dev)
 	spin_lock_init(&ar->list_lock);
 
 	init_waitqueue_head(&ar->event_wq);
-	sema_init(&ar->sem, 1);
+	mutex_init(&ar->mutex);
 
 	INIT_LIST_HEAD(&ar->amsdu_rx_buffer_queue);
 	INIT_LIST_HEAD(&ar->vif_list);
diff --git a/drivers/net/wireless/ath/ath6kl/core.h b/drivers/net/wireless/ath/ath6kl/core.h
index ac25f17..42848bd 100644
--- a/drivers/net/wireless/ath/ath6kl/core.h
+++ b/drivers/net/wireless/ath/ath6kl/core.h
@@ -722,7 +722,7 @@ struct ath6kl {
 	 */
 	spinlock_t lock;
 
-	struct semaphore sem;
+	struct mutex mutex;
 	u8 lrssi_roam_threshold;
 	struct ath6kl_version version;
 	u32 target_type;
diff --git a/drivers/net/wireless/ath/ath6kl/debug.c b/drivers/net/wireless/ath/ath6kl/debug.c
index e2b7809..9c1e709 100644
--- a/drivers/net/wireless/ath/ath6kl/debug.c
+++ b/drivers/net/wireless/ath/ath6kl/debug.c
@@ -102,13 +102,13 @@ int ath6kl_read_tgt_stats(struct ath6kl *ar, struct ath6kl_vif *vif)
 {
 	long left;
 
-	if (down_interruptible(&ar->sem))
+	if (mutex_lock_interruptible(&ar->mutex))
 		return -EBUSY;
 
 	set_bit(STATS_UPDATE_PEND, &vif->flags);
 
 	if (ath6kl_wmi_get_stats_cmd(ar->wmi, 0)) {
-		up(&ar->sem);
+		mutex_unlock(&ar->mutex);
 		return -EIO;
 	}
 
@@ -116,7 +116,7 @@ int ath6kl_read_tgt_stats(struct ath6kl *ar, struct ath6kl_vif *vif)
 						!test_bit(STATS_UPDATE_PEND,
 						&vif->flags), WMI_TIMEOUT);
 
-	up(&ar->sem);
+	mutex_unlock(&ar->mutex);
 
 	if (left <= 0)
 		return -ETIMEDOUT;
@@ -1167,20 +1167,20 @@ static ssize_t ath6kl_roam_table_read(struct file *file, char __user *user_buf,
 	unsigned int len, buf_len;
 	ssize_t ret_cnt;
 
-	if (down_interruptible(&ar->sem))
+	if (mutex_lock_interruptible(&ar->mutex))
 		return -EBUSY;
 
 	set_bit(ROAM_TBL_PEND, &ar->flag);
 
 	ret = ath6kl_wmi_get_roam_tbl_cmd(ar->wmi);
 	if (ret) {
-		up(&ar->sem);
+		mutex_unlock(&ar->sem);
 		return ret;
 	}
 
 	left = wait_event_interruptible_timeout(
 		ar->event_wq, !test_bit(ROAM_TBL_PEND, &ar->flag), WMI_TIMEOUT);
-	up(&ar->sem);
+	mutex_unlock(&ar->mutex);
 
 	if (left <= 0)
 		return -ETIMEDOUT;
diff --git a/drivers/net/wireless/ath/ath6kl/init.c b/drivers/net/wireless/ath/ath6kl/init.c
index 58fb227..377f1fa 100644
--- a/drivers/net/wireless/ath/ath6kl/init.c
+++ b/drivers/net/wireless/ath/ath6kl/init.c
@@ -1890,8 +1890,8 @@ void ath6kl_stop_txrx(struct ath6kl *ar)
 
 	set_bit(DESTROY_IN_PROGRESS, &ar->flag);
 
-	if (down_interruptible(&ar->sem)) {
-		ath6kl_err("down_interruptible failed\n");
+	if (mutex_lock_interruptible(&ar->mutex)) {
+		ath6kl_err("mutex_lock_interruptible failed\n");
 		return;
 	}
 
@@ -1938,6 +1938,6 @@ void ath6kl_stop_txrx(struct ath6kl *ar)
 	 */
 	ath6kl_init_hw_reset(ar);
 
-	up(&ar->sem);
+	mutex_unlock(&ar->mutex);
 }
 EXPORT_SYMBOL(ath6kl_stop_txrx);
-- 
2.9.0



From lkp at intel.com  Tue Jun 21 05:05:41 2016
From: lkp at intel.com (kbuild test robot)
Date: Tue, 21 Jun 2016 20:05:41 +0800
Subject: [PATCH 2/2] ath6kl: replace semaphore with mutex
In-Reply-To: <20160621114539.15313-2-chaehyun.lim@gmail.com>
Message-ID: <201606212039.Gp8V2yNe%fengguang.wu@intel.com>

Hi,

[auto build test ERROR on ath6kl/ath-next]
[also build test ERROR on v4.7-rc4 next-20160621]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Chaehyun-Lim/ath10k-remove-unused-linux-semaphore-h/20160621-195511
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   drivers/net/wireless/ath/ath6kl/debug.c: In function 'ath6kl_roam_table_read':
>> drivers/net/wireless/ath/ath6kl/debug.c:1177:19: error: 'struct ath6kl' has no member named 'sem'
      mutex_unlock(&ar->sem);
                      ^

vim +1177 drivers/net/wireless/ath/ath6kl/debug.c

  1171			return -EBUSY;
  1172	
  1173		set_bit(ROAM_TBL_PEND, &ar->flag);
  1174	
  1175		ret = ath6kl_wmi_get_roam_tbl_cmd(ar->wmi);
  1176		if (ret) {
> 1177			mutex_unlock(&ar->sem);
  1178			return ret;
  1179		}
  1180	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 46468 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160621/97c1d234/attachment-0001.obj>

From sergei.shtylyov at cogentembedded.com  Tue Jun 21 06:46:00 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 21 Jun 2016 16:46:00 +0300
Subject: [PATCH 1/2] ath10k: remove unused <linux/semaphore.h>
In-Reply-To: <20160621114539.15313-1-chaehyun.lim@gmail.com>
References: <20160621114539.15313-1-chaehyun.lim@gmail.com>
Message-ID: <bf7b2008-b333-2d79-a952-fda895da8479@cogentembedded.com>

Hello.

On 6/21/2016 2:45 PM, Chaehyun Lim wrote:

> <linux/semaphore.h> is not used anymore, so just remove it.

    s/it/#include/?

> Signed-off-by: Chaehyun Lim <chaehyun.lim at gmail.com>
[...]

> diff --git a/drivers/net/wireless/ath/ath10k/htc.h b/drivers/net/wireless/ath/ath10k/htc.h
> index cc82718..0c55cd9 100644
> --- a/drivers/net/wireless/ath/ath10k/htc.h
> +++ b/drivers/net/wireless/ath/ath10k/htc.h
> @@ -22,7 +22,6 @@
>  #include <linux/list.h>
>  #include <linux/bug.h>
>  #include <linux/skbuff.h>
> -#include <linux/semaphore.h>
>  #include <linux/timer.h>
>
>  struct ath10k;

MBR, Sergei



From greearb at candelatech.com  Tue Jun 21 07:10:28 2016
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 21 Jun 2016 07:10:28 -0700
Subject: Bug with: ath10k: enable parsing per station rx duration for 10.4?
In-Reply-To: <20160621051829.GA20604@atheros-ThinkPad-T61>
References: <5768770C.5050305@candelatech.com>
 <20160621051829.GA20604@atheros-ThinkPad-T61>
Message-ID: <57694AD4.3020101@candelatech.com>



On 06/20/2016 10:18 PM, Mohammed Shafi Shajakhan wrote:
> Hi Ben,
>
> thanks for reporting ...
>
> On Mon, Jun 20, 2016 at 04:06:52PM -0700, Ben Greear wrote:
>> I'm working on bringing up my hacked up version of 4.7 ath10k and 10.4 firmware, and I think
>> I may have found a regression.
>
> [shafi] let me know what is the issue.. some steps to recreate the issue.

ethtool -S wlan0
or similar should reproduce it.

You would see stats timeout messages in dmesg, and with a bit more debugging,
you notice that the driver is basically busy-spinning trying to get stats over
WMI and/or it is giving errors because skb pull fails because there actually is
not extd stats struct.

>>
>> My 10.4.3-ish firmware source has a bunch of:
>>
>> if (stats_id == WMI_REQUEST_PEER_STAT)
>> logic in it.  In other words, it is not using that id as a bitfield.
>
> [shafi] will check this.

I fixed my firmware to treat it as a bitfield, and to specifically un-set the EXTD stats
bit, and now it works with my 4.7.  Firmware fix should be backwards compatible.


>> Now, I can fix the firmware, but I am guessing that at least some stock
>> 10.4 firmware has this same issue, and of course any older firmware
>> that does not have this change will still be broken.
>>
>> So, do you want to back out this patch below, at least the part where it sends
>> in 0x9 as the stats_id?
>
> [shafi] request if you can check this please, there was some misunderstanding
> in the design when this feature got enabled in 10.4, we fixed it in
> https://patchwork.kernel.org/patch/9149357/

That might have fixed it, but it is not in 4.7, so I didn't have it
in my tree when testing yesterday.

Thanks,
Ben

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


From tmarble at info9.net  Tue Jun 21 07:42:20 2016
From: tmarble at info9.net (Tom Marble)
Date: Tue, 21 Jun 2016 09:42:20 -0500
Subject: Cannot initialize Compex WLE600VX for 802.11ac?
Message-ID: <57dtwgmmwmr.fsf@cerise.info9.net>


All:

I have configured a system specifically for 802.11ac using ath10k with
Compex WLE600VX [0] which is one of the QCA9880 Version 2 devices listed
on [1], but I'm unable to get it work.

This is an amd64 machine running Debian Jessie (stable), with
the latest kernel from kvalo [2] with all debugging enabled:
  CONFIG_ATH10K=m
  CONFIG_ATH10K_PCI=m
  CONFIG_ATH10K_DEBUG=y
  CONFIG_ATH10K_DEBUGFS=y
  CONFIG_ATH10K_TRACING=y

Linux six 4.7.0-rc3-wt-ath-tm1 #3 SMP Mon Jun 20 22:18:00 CDT 2016 x86_64 GNU/Linux

The firmware is also from klavo's git [3][4][5]. Upon boot the
kernel says:
  Jun 21 08:36:05 six kernel: [    4.193061] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
  Jun 21 08:36:05 six kernel: [    4.416764] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
  Jun 21 08:36:05 six kernel: [    5.608354] ath10k_pci 0000:02:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1

The hostapd software is built from the latest upstream [6], including
the configuration
  CONFIG_IEEE80211AC=y
  CONFIG_DRIVER_NL80211=y
  CONFIG_DRIVER_NL80211_QCA=y
  CONFIG_ACS=y

The hostapd config file /etc/hostapd/wlan0.conf is set exactly in
the "Full hostapd configuration" from [6] (with passwords changed).

Setting channel=0 to enable scanning results in finding channel 52
as the ideal channel, but then (full log in [7])...
# hostapd -dd /etc/hostapd/wlan0.conf | tee /tmp/wlan0.log
... 
  Mode: IEEE 802.11a  Channel: 52  Frequency: 5260 MHz
  DFS 0 channels required radar detection
  Could not set channel for kernel driver
  Interface initialization failed

Setting channel=52 and trying again fails with... (full log in [8]).
# hostapd -dd /etc/hostapd/wlan0.conf | tee /tmp/wlan0-52.log
...
  nl80211: Failed to start radar detection: -16 (Device or resource busy)


What suggestions do you have to help me identify the cause of 
this problem (and hopefully resolve it!)?

--Tom

[0] WLE600VX
    http://www.compex.com.sg/product/wle600vx/
[1] https://wireless.wiki.kernel.org/en/users/drivers/ath10k
[2] https://wireless.wiki.kernel.org/en/users/drivers/ath10k/sources
[3] https://wireless.wiki.kernel.org/en/users/drivers/ath10k/firmware
[4] board.bin
    https://github.com/kvalo/ath10k-firmware/blob/master/QCA988X/board.bin 
[5] firmware-5.bin
    https://github.com/kvalo/ath10k-firmware/blob/master/QCA988X/10.2.4/firmware-5.bin_10.2.4.70.44 
[6] https://wireless.wiki.kernel.org/en/users/drivers/ath10k/configuration
[7] channel=0 log
    http://paste.debian.net/740824/ 
[8] channel=52 log
    http://paste.debian.net/740826/ 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160621/a5cea3b4/attachment.sig>

From mohammed at codeaurora.org  Tue Jun 21 08:41:08 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Tue, 21 Jun 2016 21:11:08 +0530
Subject: Bug with: ath10k: enable parsing per station rx duration for 10.4?
In-Reply-To: <57694AD4.3020101@candelatech.com>
References: <5768770C.5050305@candelatech.com>
 <20160621051829.GA20604@atheros-ThinkPad-T61>
 <57694AD4.3020101@candelatech.com>
Message-ID: <20160621154107.GA21954@atheros-ThinkPad-T61>

On Tue, Jun 21, 2016 at 07:10:28AM -0700, Ben Greear wrote:
> 
> 
> On 06/20/2016 10:18 PM, Mohammed Shafi Shajakhan wrote:
> >Hi Ben,
> >
> >thanks for reporting ...
> >
> >On Mon, Jun 20, 2016 at 04:06:52PM -0700, Ben Greear wrote:
> >>I'm working on bringing up my hacked up version of 4.7 ath10k and 10.4 firmware, and I think
> >>I may have found a regression.
> >
> >[shafi] let me know what is the issue.. some steps to recreate the issue.
> 
> ethtool -S wlan0
> or similar should reproduce it.
> 
> You would see stats timeout messages in dmesg, and with a bit more debugging,
> you notice that the driver is basically busy-spinning trying to get stats over
> WMI and/or it is giving errors because skb pull fails because there actually is
> not extd stats struct.

https://patchwork.kernel.org/patch/9149357/
 should help (Kalle had a cleaned up version in his pending branch
> 
> >>
> >>My 10.4.3-ish firmware source has a bunch of:
> >>
> >>if (stats_id == WMI_REQUEST_PEER_STAT)
> >>logic in it.  In other words, it is not using that id as a bitfield.
> >
> >[shafi] will check this.
> 
> I fixed my firmware to treat it as a bitfield, and to specifically un-set the EXTD stats
> bit, and now it works with my 4.7.  Firmware fix should be backwards compatible.
> 
> 
> >>Now, I can fix the firmware, but I am guessing that at least some stock
> >>10.4 firmware has this same issue, and of course any older firmware
> >>that does not have this change will still be broken.
> >>
> >>So, do you want to back out this patch below, at least the part where it sends
> >>in 0x9 as the stats_id?
> >
> >[shafi] request if you can check this please, there was some misunderstanding
> >in the design when this feature got enabled in 10.4, we fixed it in
> >https://patchwork.kernel.org/patch/9149357/
> 
> That might have fixed it, but it is not in 4.7, so I didn't have it
> in my tree when testing yesterday.
> 
> Thanks,
> Ben
> 
> -- 
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com


From sunder_k at hotmail.com  Tue Jun 21 23:13:17 2016
From: sunder_k at hotmail.com (sunder Kumaresan)
Date: Wed, 22 Jun 2016 06:13:17 +0000
Subject: ath10k  firmware version - 10.4
Message-ID: <BAY172-W4820DFFAF81043D5407B3EE02C0@phx.gbl>

Hello all,


Trying to use  QCA9980 hardware with ath10k version using 10.4 version firmware.  The recommended kernel version is 4.2 from the link https://wireless.wiki.kernel.org/en/users/drivers/ath10k/firmware.


 From the link ,?git://git.kernel.org/pub/scm/linux/kernel/git/agruen/linux.git" kernel version 4.2.0(rc7).



In the file, drivers/net/wireless/ath/ath10k/pci.c supports for the following devices. 



static const struct pci_device_id ath10k_pci_id_table[] = {

        { PCI_VDEVICE(ATHEROS, QCA988X_2_0_DEVICE_ID) }, /* PCI-E QCA988X V2 */

        { PCI_VDEVICE(ATHEROS, QCA6174_2_1_DEVICE_ID) }, /* PCI-E QCA6174 V2.1 */

        {0}

};

 

It does not show up for QCA9980.



The kernel version beyond  4.4 provides support for QCA99X0. 



The kernel version 4.7 ath10k driver has been back-ported to 4.1 has been used  using yocto SDK 2.0 version .  The interface comes up.  



But, When boardData_AR900B_CUS239_5G_v2_001.bin  and boardData_AR900B_CUS260_2G_v2_002.bin  have been renamed as board xxx. bin files.  It shows up as mismatch in the magic number.



Want to know correct   version of Linux kernel  and its location. 

 


 



Best Regards,

k.sunder  		 	   		  

From kvalo at qca.qualcomm.com  Tue Jun 21 23:47:12 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Wed, 22 Jun 2016 06:47:12 +0000
Subject: Cannot initialize Compex WLE600VX for 802.11ac?
In-Reply-To: <57dtwgmmwmr.fsf@cerise.info9.net> (Tom Marble's message of "Tue, 
 21 Jun 2016 09:42:20 -0500")
References: <57dtwgmmwmr.fsf@cerise.info9.net>
Message-ID: <87y45xiuts.fsf@kamboji.qca.qualcomm.com>

Tom Marble <tmarble at info9.net> writes:

> Setting channel=0 to enable scanning results in finding channel 52
> as the ideal channel, but then (full log in [7])...
> # hostapd -dd /etc/hostapd/wlan0.conf | tee /tmp/wlan0.log
> ... 
>   Mode: IEEE 802.11a  Channel: 52  Frequency: 5260 MHz
>   DFS 0 channels required radar detection
>   Could not set channel for kernel driver
>   Interface initialization failed
>
> Setting channel=52 and trying again fails with... (full log in [8]).
> # hostapd -dd /etc/hostapd/wlan0.conf | tee /tmp/wlan0-52.log
> ...
>   nl80211: Failed to start radar detection: -16 (Device or resource busy)
>
>
> What suggestions do you have to help me identify the cause of 
> this problem (and hopefully resolve it!)?

Do you have CONFIG_ATH10K_DFS_CERTIFIED enabled? Also check that that
regulatory is correct with 'iw reg get' and 'iw phy0 info', especially
that 80 MHz channels are supported.

Also I would try first without DFS on channel 36 just to make it easier
to pinpoint the problem.

-- 
Kalle Valo

From arnagara at qti.qualcomm.com  Wed Jun 22 03:52:41 2016
From: arnagara at qti.qualcomm.com (Ashok Raj Nagarajan)
Date: Wed, 22 Jun 2016 16:22:41 +0530
Subject: [PATCH] ath10k: simplify pktlog htt event processing
Message-ID: <1466592761-6659-1-git-send-email-arnagara@qti.qualcomm.com>

It is expected that all pktlog events for 10.4 firmware based solutions
should come through CE8 where as in case of 10.2 firmware based solutions,
it should come through one of the HTT events (HTT_T2H_MSG_TYPE_PKTLOG).

But from experiments with 10.4 based solutions, it is observed that pktlog
event for ATH_PKTLOG_TYPE_TX_MSDU_ID is coming through HTT pktlog event.
Currently, we always parse with 10.2 pktlog header which will lead to
pktlog decoding issues (payload length mismatch exceptions)

For trace points, it is required to provide only the payload size. So
fixing this by simplifying the payload size calculation without the use of
ath10k pktlog headers.

While there, remove the unused ath10k pktlog headers.

Signed-off-by: Ashok Raj Nagarajan <arnagara at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/htt_rx.c |  8 +++-----
 drivers/net/wireless/ath/ath10k/hw.h     | 19 -------------------
 2 files changed, 3 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 80e6453..b2a9c4c 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2307,12 +2307,10 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
 		ath10k_htt_rx_delba(ar, resp);
 		break;
 	case HTT_T2H_MSG_TYPE_PKTLOG: {
-		struct ath10k_pktlog_hdr *hdr =
-			(struct ath10k_pktlog_hdr *)resp->pktlog_msg.payload;
-
 		trace_ath10k_htt_pktlog(ar, resp->pktlog_msg.payload,
-					sizeof(*hdr) +
-					__le16_to_cpu(hdr->size));
+					skb->len -
+					offsetof(struct htt_resp,
+						 pktlog_msg.payload));
 		break;
 	}
 	case HTT_T2H_MSG_TYPE_RX_FLUSH: {
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index f31d3ce..427b720 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -296,25 +296,6 @@ enum ath10k_mcast2ucast_mode {
 	ATH10K_MCAST2UCAST_ENABLED = 1,
 };
 
-struct ath10k_pktlog_hdr {
-	__le16 flags;
-	__le16 missed_cnt;
-	__le16 log_type;
-	__le16 size;
-	__le32 timestamp;
-	u8 payload[0];
-} __packed;
-
-struct ath10k_pktlog_10_4_hdr {
-	__le16 flags;
-	__le16 missed_cnt;
-	__le16 log_type;
-	__le16 size;
-	__le32 timestamp;
-	__le32 type_specific_data;
-	u8 payload[0];
-} __packed;
-
 enum ath10k_hw_rate_ofdm {
 	ATH10K_HW_RATE_OFDM_48M = 0,
 	ATH10K_HW_RATE_OFDM_24M,
-- 
1.9.1



From tmarble at info9.net  Wed Jun 22 06:10:34 2016
From: tmarble at info9.net (Tom Marble)
Date: Wed, 22 Jun 2016 08:10:34 -0500
Subject: Cannot initialize Compex WLE600VX for 802.11ac?
In-Reply-To: <87y45xiuts.fsf@kamboji.qca.qualcomm.com>
References: <57dtwgmmwmr.fsf@cerise.info9.net>
 <87y45xiuts.fsf@kamboji.qca.qualcomm.com>
Message-ID: <57dd1n9mks5.fsf@cerise.info9.net>

"Valo, Kalle" <kvalo at qca.qualcomm.com> writes:
> Do you have CONFIG_ATH10K_DFS_CERTIFIED enabled?

No.. the option isn't even commented out in my .config??
Is there are tree other than...
  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git

> Also check that that
> regulatory is correct with 'iw reg get' and 'iw phy0 info', especially
> that 80 MHz channels are supported.

root at six:/# iw reg get
country US: DFS-FCC
        (2402 - 2472 @ 40), (N/A, 30), (N/A)
        (5170 - 5250 @ 80), (N/A, 17), (N/A)
        (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS
        (5735 - 5835 @ 80), (N/A, 30), (N/A)
        (57240 - 63720 @ 2160), (N/A, 40), (N/A)
root at six:/#

(I cannot run 'iw phy0 info' at the moment as I'm away from the lab)

> Also I would try first without DFS on channel 36 just to make it easier
> to pinpoint the problem.

Okay, thanks!

--Tom


From eduardo.abinader at riverbed.com  Wed Jun 22 06:34:26 2016
From: eduardo.abinader at riverbed.com (Eduardo Abinader)
Date: Wed, 22 Jun 2016 15:34:26 +0200
Subject: [PATCH] ath10k: remove extra space on ath10k_update_channel_list
Message-ID: <576A93E2.9050901@riverbed.com>

just to comply to coding style.

Signed-off-by: Eduardo Abinader <eduardo.abinader at riverbed.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d4b7a16..d5f8e95 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2939,7 +2939,7 @@ static int ath10k_update_channel_list(struct ath10k *ar)
 			if (channel->flags & IEEE80211_CHAN_DISABLED)
 				continue;
 
-			ch->allow_ht   = true;
+			ch->allow_ht = true;
 
 			/* FIXME: when should we really allow VHT? */
 			ch->allow_vht = true;
-- 
2.5.0


From kvalo at qca.qualcomm.com  Wed Jun 22 07:08:40 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Wed, 22 Jun 2016 14:08:40 +0000
Subject: Cannot initialize Compex WLE600VX for 802.11ac?
In-Reply-To: <57dd1n9mks5.fsf@cerise.info9.net> (Tom Marble's message of "Wed, 
 22 Jun 2016 08:10:34 -0500")
References: <57dtwgmmwmr.fsf@cerise.info9.net>
 <87y45xiuts.fsf@kamboji.qca.qualcomm.com>	<57dd1n9mks5.fsf@cerise.info9.net>
Message-ID: <87r3bpfh94.fsf@kamboji.qca.qualcomm.com>

Tom Marble <tmarble at info9.net> writes:

> "Valo, Kalle" <kvalo at qca.qualcomm.com> writes:
>> Do you have CONFIG_ATH10K_DFS_CERTIFIED enabled?
>
> No.. the option isn't even commented out in my .config??

It depends on CFG80211_CERTIFICATION_ONUS so you need to enable that
first.

> Is there are tree other than...
>   git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git

That tree contains the latest ath10k code, so that's ok.

-- 
Kalle Valo

From julian.calaby at gmail.com  Wed Jun 22 18:25:19 2016
From: julian.calaby at gmail.com (Julian Calaby)
Date: Thu, 23 Jun 2016 11:25:19 +1000
Subject: [PATCH] ath10k: remove extra space on ath10k_update_channel_list
In-Reply-To: <576A93E2.9050901@riverbed.com>
References: <576A93E2.9050901@riverbed.com>
Message-ID: <CAGRGNgU01=zHXTOMNLQKepJMWvEOW_3pFysG_kkQEwvhW6skBw@mail.gmail.com>

Hi All,

On Wed, Jun 22, 2016 at 11:34 PM, Eduardo Abinader
<eduardo.abinader at riverbed.com> wrote:
> just to comply to coding style.
>
> Signed-off-by: Eduardo Abinader <eduardo.abinader at riverbed.com>

Looks right to me.

Reviewed-by: Julian Calaby <julian.calaby at gmail.com>

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


From tmarble at info9.net  Thu Jun 23 06:00:21 2016
From: tmarble at info9.net (Tom Marble)
Date: Thu, 23 Jun 2016 08:00:21 -0500
Subject: Cannot initialize Compex WLE600VX for 802.11ac?
In-Reply-To: <87r3bpfh94.fsf@kamboji.qca.qualcomm.com>
References: <57dtwgmmwmr.fsf@cerise.info9.net>
 <87y45xiuts.fsf@kamboji.qca.qualcomm.com> <57dd1n9mks5.fsf@cerise.info9.net>
 <87r3bpfh94.fsf@kamboji.qca.qualcomm.com>
Message-ID: <57doa6skql6.fsf@cerise.info9.net>

"Valo, Kalle" <kvalo at qca.qualcomm.com> writes:
> Tom Marble <tmarble at info9.net> writes:
>> "Valo, Kalle" <kvalo at qca.qualcomm.com> writes:
>>> Do you have CONFIG_ATH10K_DFS_CERTIFIED enabled?
>>
>> No.. the option isn't even commented out in my .config??
>
> It depends on CFG80211_CERTIFICATION_ONUS so you need to enable that
> first.

Okay, I've rebuild the kernel with that option. Here's the latest info:

root at six:/# uname -a
Linux six 4.7.0-rc3-wt-ath-tm2 #4 SMP Wed Jun 22 11:47:12 CDT 2016 x86_64 GNU/Linux
root at six:/# iw reg get
country US: DFS-FCC
        (2402 - 2472 @ 40), (N/A, 30), (N/A)
        (5170 - 5250 @ 80), (N/A, 17), (N/A)
        (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS
        (5735 - 5835 @ 80), (N/A, 30), (N/A)
        (57240 - 63720 @ 2160), (N/A, 40), (N/A)
root at six:/# iw phy0 info
  SEE http://paste.debian.net/747986/ 

Setting channel=0 to enable scanning results still fails
# hostapd -dd /etc/hostapd/wlan0.conf | tee /tmp/wlan0.log 
  SEE http://paste.debian.net/747988/

  nl80211: Failed to set fragmentation threshold 2346: -95 (Operation not supported)
  Could not set fragmentation threshold for kernel driver
  Interface initialization failed

Seems to have made it a little further... What should I try now?

--Tom



From tomasz.skapski at tieto.com  Thu Jun 23 06:27:00 2016
From: tomasz.skapski at tieto.com (Tomasz Skapski)
Date: Thu, 23 Jun 2016 15:27:00 +0200
Subject: Cannot initialize Compex WLE600VX for 802.11ac?
In-Reply-To: <57doa6skql6.fsf@cerise.info9.net>
References: <57dtwgmmwmr.fsf@cerise.info9.net>
 <87y45xiuts.fsf@kamboji.qca.qualcomm.com>
 <57dd1n9mks5.fsf@cerise.info9.net> <87r3bpfh94.fsf@kamboji.qca.qualcomm.com>
 <57doa6skql6.fsf@cerise.info9.net>
Message-ID: <CABkMH_rZNhxHtfaD3pz0ymSjvEKGxDycjDcwxKBZFKj8j2P_Jg@mail.gmail.com>

In your config file set 'fragm_threshold=-1', or comment it.
Regards,
Tomasz Sk?pski


On 23 June 2016 at 15:00, Tom Marble <tmarble at info9.net> wrote:
> "Valo, Kalle" <kvalo at qca.qualcomm.com> writes:
>> Tom Marble <tmarble at info9.net> writes:
>>> "Valo, Kalle" <kvalo at qca.qualcomm.com> writes:
>>>> Do you have CONFIG_ATH10K_DFS_CERTIFIED enabled?
>>>
>>> No.. the option isn't even commented out in my .config??
>>
>> It depends on CFG80211_CERTIFICATION_ONUS so you need to enable that
>> first.
>
> Okay, I've rebuild the kernel with that option. Here's the latest info:
>
> root at six:/# uname -a
> Linux six 4.7.0-rc3-wt-ath-tm2 #4 SMP Wed Jun 22 11:47:12 CDT 2016 x86_64 GNU/Linux
> root at six:/# iw reg get
> country US: DFS-FCC
>         (2402 - 2472 @ 40), (N/A, 30), (N/A)
>         (5170 - 5250 @ 80), (N/A, 17), (N/A)
>         (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS
>         (5735 - 5835 @ 80), (N/A, 30), (N/A)
>         (57240 - 63720 @ 2160), (N/A, 40), (N/A)
> root at six:/# iw phy0 info
>   SEE http://paste.debian.net/747986/
>
> Setting channel=0 to enable scanning results still fails
> # hostapd -dd /etc/hostapd/wlan0.conf | tee /tmp/wlan0.log
>   SEE http://paste.debian.net/747988/
>
>   nl80211: Failed to set fragmentation threshold 2346: -95 (Operation not supported)
>   Could not set fragmentation threshold for kernel driver
>   Interface initialization failed
>
> Seems to have made it a little further... What should I try now?
>
> --Tom
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From mohammed at qti.qualcomm.com  Thu Jun 23 09:40:01 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Thu, 23 Jun 2016 22:10:01 +0530
Subject: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for
 QCA99X0 and later
In-Reply-To: <1466700001-4883-1-git-send-email-mohammed@qca.qualcomm.com>
References: <1466700001-4883-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <1466700001-4883-2-git-send-email-mohammed@qca.qualcomm.com>

From: Mohammed Shafi Shajakhan <mohammed at 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

Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 3 +++
 drivers/net/wireless/ath/ath10k/core.h | 6 ++++++
 drivers/net/wireless/ath/ath10k/mac.c  | 1 +
 3 files changed, 10 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 689d6ce..9978e4a 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -181,6 +181,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
 			.board_size = QCA99X0_BOARD_DATA_SZ,
 			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+			.disable_null_func_workaround = true,
 		},
 	},
 	{
@@ -204,6 +205,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board = QCA9984_HW_1_0_BOARD_DATA_FILE,
 			.board_size = QCA99X0_BOARD_DATA_SZ,
 			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+			.disable_null_func_workaround = true,
 		},
 	},
 	{
@@ -262,6 +264,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
 			.board_size = QCA4019_BOARD_DATA_SZ,
 			.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
+			.disable_null_func_workaround = true,
 		},
 	},
 };
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 3da18c9..e8c728c 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -750,6 +750,12 @@ struct ath10k {
 			const char *board;
 			size_t board_size;
 			size_t board_ext_size;
+			/* Workaround of sending NULL data frames via
+			 * HTT mgmt TX and getting the proper ACK status does
+			 * not works for chipsets QCA99X0 and later, while
+			 * Tx data path reports the ACK status properly.
+			 */
+			bool disable_null_func_workaround;
 		} fw;
 	} hw_params;
 
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d4b7a16..f1e9672 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3236,6 +3236,7 @@ ath10k_mac_tx_h_get_txmode(struct ath10k *ar,
 	 * mode though because AP don't sleep.
 	 */
 	if (ar->htt.target_version_major < 3 &&
+	    !ar->hw_params.fw.disable_null_func_workaround &&
 	    (ieee80211_is_nullfunc(fc) || ieee80211_is_qos_nullfunc(fc)) &&
 	    !test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX,
 		      ar->running_fw->fw_file.fw_features))
-- 
1.9.1



From mohammed at qti.qualcomm.com  Thu Jun 23 09:40:00 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Thu, 23 Jun 2016 22:10:00 +0530
Subject: [PATCH 1/2] ath10k: Replace warning with an error message if HTT op
 version is unset
Message-ID: <1466700001-4883-1-git-send-email-mohammed@qca.qualcomm.com>

From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Print an ath10k error message rather a call trace when HTT op version is
not found from firmware META data (IE). This should be sufficient to figure
out what went wrong.

Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index dfb3db0..689d6ce 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1675,7 +1675,7 @@ static int ath10k_core_init_firmware_features(struct ath10k *ar)
 		case ATH10K_FW_WMI_OP_VERSION_10_4:
 		case ATH10K_FW_WMI_OP_VERSION_UNSET:
 		case ATH10K_FW_WMI_OP_VERSION_MAX:
-			WARN_ON(1);
+			ath10k_err(ar, "htt op version not found from fw meta data");
 			return -EINVAL;
 		}
 	}
-- 
1.9.1



From greearb at candelatech.com  Thu Jun 23 10:12:01 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 23 Jun 2016 10:12:01 -0700
Subject: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for
 QCA99X0 and later
In-Reply-To: <1466700001-4883-2-git-send-email-mohammed@qca.qualcomm.com>
References: <1466700001-4883-1-git-send-email-mohammed@qca.qualcomm.com>
 <1466700001-4883-2-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <576C1861.7020402@candelatech.com>

On 06/23/2016 09:40 AM, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan <mohammed at 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.

Thanks,
Ben

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



From tmarble at info9.net  Thu Jun 23 20:27:20 2016
From: tmarble at info9.net (Tom Marble)
Date: Thu, 23 Jun 2016 22:27:20 -0500
Subject: Cannot initialize Compex WLE600VX for 802.11ac?
In-Reply-To: <CABkMH_rZNhxHtfaD3pz0ymSjvEKGxDycjDcwxKBZFKj8j2P_Jg@mail.gmail.com>
References: <57dtwgmmwmr.fsf@cerise.info9.net>
 <87y45xiuts.fsf@kamboji.qca.qualcomm.com> <57dd1n9mks5.fsf@cerise.info9.net>
 <87r3bpfh94.fsf@kamboji.qca.qualcomm.com> <57doa6skql6.fsf@cerise.info9.net>
 <CABkMH_rZNhxHtfaD3pz0ymSjvEKGxDycjDcwxKBZFKj8j2P_Jg@mail.gmail.com>
Message-ID: <57dfus3l10n.fsf@cerise.info9.net>

Tomasz Skapski <tomasz.skapski at tieto.com> writes:
> In your config file set 'fragm_threshold=-1', or comment it.

Indeed this was the last critical configuration change...
Now I'm able to bring up the interface!

Then I was getting errors when 'ifup'-ing the interface
  RTNETLINK answers: File exists
which were resolved by ensuring that
1. The interface was flushed prior to being up'ed
   ip addr flush dev wlan0
2. The interface was *not* configured to add an (additional) gateway

Following this the interface would not stay up due to avahi-daemon
decideding it didn't like something and removing the address
  avahi-daemon[2925]: Withdrawing address record for 10.6.8.1 on wlan0.

The solution here was just removing avahi-daemon (and mDNS services).

Then the interface wasn't happy about IPv6
  IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not read

Even with setting (in /etc/hostapd/wlan0.conf ) this problem still occurred.
  ipaddr_type_availability=32

The solution was disabling IPv6 (at least for now.. I do want IPv6
eventually), in /etc/sysctl.conf
# NO IPV6                                                                        net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.wan0.disable_ipv6 = 1

I also rebuilt hostapd because it seems to have a version locked
dependency of libssl (for some reason?).

With the addition of dnsmasq (for DHCP and DNS proxying) and
simple nftables rules for nat/masquerade I now have a functioning AP!

Certain clients seemed to get "kicked off" the network which has
been mitigated by setting:
  ap_max_inactivity=600
  disassoc_low_ack=0

One problem that results in clients getting removed from the AP is:
Jun 23 19:07:28 six kernel: [  995.006727] wlan0: dropped frame to 00:01:02:03:37:15 (unauthorized port)

... and I'm not sure what's causing that?

Amusingly certain Android clients seem to constantly "fishing" to find
active networks (these messages occur every 15 seconds):
Jun 23 21:26:23 six kernel: [ 9330.082522] wlan1: STA 00:01:02:03:37:15 aid 1 enters power save mode
Jun 23 21:26:38 six kernel: [ 9345.059365] wlan1: STA 00:01:02:03:37:15 aid 1 exits power save mode
Jun 23 21:26:38 six kernel: [ 9345.059408] wlan1: STA 00:01:02:03:37:15 aid 1 sending 0 filtered/0 PS frames since STA \
not sleeping anymore
Jun 23 21:26:39 six kernel: [ 9345.364866] wlan1: STA 00:01:02:03:37:15 aid 1 enters power save mode

In other good news I added a second nic (wlan1) to handle 2.4 GHz
traffic in the form of a TP-LINK TL-WN722N which is supported by
the driver ath9k_htc. Using a separate instance of hostapd for wlan1
I now have a dual mode access point!

I found I had to move the TL-WN722N antenna as far away as possible
to minimize interference with the 5 GHz signal.

One strange thing I've noticed is that if I configure the wlan0 (5 GHz)
channel=52 on boot up it doesn't work... However if I have once
done channel=0 then on subsequent bounces of the interface I can have
it come up on a specific channel.

Thanks Tomasz and Kalle for your help!!!

--Tom


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160623/a0064c09/attachment.sig>

From mohammed at codeaurora.org  Sat Jun 25 11:53:50 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Sun, 26 Jun 2016 00:23:50 +0530
Subject: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for
 QCA99X0 and later
In-Reply-To: <576C1861.7020402@candelatech.com>
References: <1466700001-4883-1-git-send-email-mohammed@qca.qualcomm.com>
 <1466700001-4883-2-git-send-email-mohammed@qca.qualcomm.com>
 <576C1861.7020402@candelatech.com>
Message-ID: <20160625185350.GA25330@atheros-ThinkPad-T61>

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 at 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


From greearb at candelatech.com  Sat Jun 25 17:27:17 2016
From: greearb at candelatech.com (Ben Greear)
Date: Sat, 25 Jun 2016 17:27:17 -0700
Subject: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for
 QCA99X0 and later
In-Reply-To: <20160625185350.GA25330@atheros-ThinkPad-T61>
References: <1466700001-4883-1-git-send-email-mohammed@qca.qualcomm.com>
 <1466700001-4883-2-git-send-email-mohammed@qca.qualcomm.com>
 <576C1861.7020402@candelatech.com>
 <20160625185350.GA25330@atheros-ThinkPad-T61>
Message-ID: <576F2165.3010109@candelatech.com>

On 06/25/2016 11:53 AM, Mohammed Shafi Shajakhan wrote:
> 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 at 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 ..

Is there a better way than posting to the ath10k mailing list?  There are quite
a few more of my patches that are stuck in pending or ignored state.  If you
could review some of them and add them to your testing trees then it might help
them go upstream.

Maybe someone else with more time and resources could take over maintainer-ship of ath10k
and let Kalle focus on the drivers in general?

> "[ 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 ?

I have no good way to know what exact source creates the upstream firmware.  But, grep
around for FILTERED and you will probably see your firmware using that tx code.

It could easily be that both of our patches are correct and needed.

> 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 ?

I can fix my 10.1 if it is not already fixed.  If you are ready to have my
10.1 be the only supported 10.1, then we can do the tests.  If that is the
case, then you should add a feature flag for my firmware and fail to load any
other 10.1 firmware since it would then be guaranteed to fail since you are removing
workarounds for it...

I would rather focus on getting some of the debug patches upstream so that
I can actually make progress on firmware bugs found on stock kernels.  Without
them, I have to ask people to run patched drivers in order to get debug info,
and that is painful for all involved.

Thanks,
Ben

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



From rmanohar at qti.qualcomm.com  Sun Jun 26 22:51:28 2016
From: rmanohar at qti.qualcomm.com (Rajkumar Manoharan)
Date: Mon, 27 Jun 2016 11:21:28 +0530
Subject: [PATCH] ath10k: implement NAPI support
Message-ID: <20160627055128.7005-1-rmanohar@qti.qualcomm.com>

Add NAPI support for rx and tx completion. NAPI poll is scheduled
from interrupt handler. The design is as below

 - on interrupt
     - schedule napi and mask interrupts
 - on poll
   - process all pipes (no actual Tx/Rx)
   - process Rx within budget
   - if quota exceeds budget reschedule napi poll by returning budget
   - process Tx completions and update budget if necessary
   - process Tx fetch indications (pull-push)
   - push any other pending Tx (if possible)
   - before resched or napi completion replenish htt rx ring buffer
   - if work done < budget, complete napi poll and unmask interrupts

This change also get rid of two tasklets (intr_tq and txrx_compl_task).

Measured peak throughput with NAPI on IPQ4019 platform in controlled
environment. No noticeable reduction in throughput is seen and also
observed improvements in CPU usage. Approx. 15% CPU usage got reduced
in UDP uplink case.

DL: AP DUT Tx
UL: AP DUT Rx

IPQ4019 (avg. cpu usage %)
========
                TOT              +NAPI
              ===========      =============
TCP DL       644 Mbps (42%)    645 Mbps (36%)
TCP UL       673 Mbps (30%)    675 Mbps (26%)
UDP DL       682 Mbps (49%)    680 Mbps (49%)
UDP UL       720 Mbps (28%)    717 Mbps (11%)

Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/ahb.c    |   4 +-
 drivers/net/wireless/ath/ath10k/core.c   |   2 +
 drivers/net/wireless/ath/ath10k/core.h   |   8 ++
 drivers/net/wireless/ath/ath10k/htt.h    |   2 +-
 drivers/net/wireless/ath/ath10k/htt_rx.c | 154 +++++++++++++++++++------------
 drivers/net/wireless/ath/ath10k/pci.c    |  67 +++++++++-----
 drivers/net/wireless/ath/ath10k/pci.h    |   5 +-
 7 files changed, 149 insertions(+), 93 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/ahb.c b/drivers/net/wireless/ath/ath10k/ahb.c
index acec16b9cf49..9d4d5022be18 100644
--- a/drivers/net/wireless/ath/ath10k/ahb.c
+++ b/drivers/net/wireless/ath/ath10k/ahb.c
@@ -462,13 +462,11 @@ static void ath10k_ahb_halt_chip(struct ath10k *ar)
 static irqreturn_t ath10k_ahb_interrupt_handler(int irq, void *arg)
 {
 	struct ath10k *ar = arg;
-	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
 
 	if (!ath10k_pci_irq_pending(ar))
 		return IRQ_NONE;
 
 	ath10k_pci_disable_and_clear_legacy_irq(ar);
-	tasklet_schedule(&ar_pci->intr_tq);
 
 	return IRQ_HANDLED;
 }
@@ -831,7 +829,7 @@ static int ath10k_ahb_probe(struct platform_device *pdev)
 		goto err_resource_deinit;
 	}
 
-	ath10k_pci_init_irq_tasklets(ar);
+	ath10k_pci_init_napi(ar);
 
 	ret = ath10k_ahb_request_irq_legacy(ar);
 	if (ret)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index dfb3db0ee5d1..2639e7e0836b 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2223,6 +2223,8 @@ struct ath10k *ath10k_core_create(size_t priv_size, struct device *dev,
 	INIT_WORK(&ar->register_work, ath10k_core_register_work);
 	INIT_WORK(&ar->restart_work, ath10k_core_restart);
 
+	init_dummy_netdev(&ar->napi_dev);
+
 	ret = ath10k_debug_create(ar);
 	if (ret)
 		goto err_free_aux_wq;
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 3da18c9dbd7a..10878926b629 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -65,6 +65,10 @@
 #define ATH10K_KEEPALIVE_MAX_IDLE 3895
 #define ATH10K_KEEPALIVE_MAX_UNRESPONSIVE 3900
 
+/* NAPI poll budget */
+#define ATH10K_NAPI_BUDGET      64
+#define ATH10K_NAPI_QUOTA_LIMIT 60
+
 struct ath10k;
 
 enum ath10k_bus {
@@ -926,6 +930,10 @@ struct ath10k {
 	struct ath10k_thermal thermal;
 	struct ath10k_wow wow;
 
+	/* NAPI */
+	struct net_device napi_dev;
+	struct napi_struct napi;
+
 	/* must be last */
 	u8 drv_priv[0] __aligned(sizeof(void *));
 };
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 430a83e142aa..98c14247021b 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1665,7 +1665,6 @@ struct ath10k_htt {
 
 	/* This is used to group tx/rx completions separately and process them
 	 * in batches to reduce cache stalls */
-	struct tasklet_struct txrx_compl_task;
 	struct sk_buff_head rx_compl_q;
 	struct sk_buff_head rx_in_ord_compl_q;
 	struct sk_buff_head tx_fetch_ind_q;
@@ -1798,5 +1797,6 @@ int ath10k_htt_tx(struct ath10k_htt *htt,
 		  struct sk_buff *msdu);
 void ath10k_htt_rx_pktlog_completion_handler(struct ath10k *ar,
 					     struct sk_buff *skb);
+int ath10k_htt_txrx_compl_task(struct ath10k *ar, int budget);
 
 #endif
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 80e645302b54..c68b39bfc7bb 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -34,7 +34,6 @@
 #define HTT_RX_RING_REFILL_RESCHED_MS 5
 
 static int ath10k_htt_rx_get_csum_state(struct sk_buff *skb);
-static void ath10k_htt_txrx_compl_task(unsigned long ptr);
 
 static struct sk_buff *
 ath10k_htt_rx_find_skb_paddr(struct ath10k *ar, u32 paddr)
@@ -226,7 +225,6 @@ int ath10k_htt_rx_ring_refill(struct ath10k *ar)
 void ath10k_htt_rx_free(struct ath10k_htt *htt)
 {
 	del_timer_sync(&htt->rx_ring.refill_retry_timer);
-	tasklet_kill(&htt->txrx_compl_task);
 
 	skb_queue_purge(&htt->rx_compl_q);
 	skb_queue_purge(&htt->rx_in_ord_compl_q);
@@ -520,9 +518,6 @@ int ath10k_htt_rx_alloc(struct ath10k_htt *htt)
 	skb_queue_head_init(&htt->tx_fetch_ind_q);
 	atomic_set(&htt->num_mpdus_ready, 0);
 
-	tasklet_init(&htt->txrx_compl_task, ath10k_htt_txrx_compl_task,
-		     (unsigned long)htt);
-
 	ath10k_dbg(ar, ATH10K_DBG_BOOT, "htt rx ring size %d fill_level %d\n",
 		   htt->rx_ring.size, htt->rx_ring.fill_level);
 	return 0;
@@ -958,7 +953,7 @@ static void ath10k_process_rx(struct ath10k *ar,
 	trace_ath10k_rx_hdr(ar, skb->data, skb->len);
 	trace_ath10k_rx_payload(ar, skb->data, skb->len);
 
-	ieee80211_rx(ar->hw, skb);
+	ieee80211_rx_napi(ar->hw, NULL, skb, &ar->napi);
 }
 
 static int ath10k_htt_rx_nwifi_hdrlen(struct ath10k *ar,
@@ -1527,7 +1522,7 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
 	struct ath10k *ar = htt->ar;
 	static struct ieee80211_rx_status rx_status;
 	struct sk_buff_head amsdu;
-	int ret;
+	int ret, num_msdus;
 
 	__skb_queue_head_init(&amsdu);
 
@@ -1549,13 +1544,14 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
 		return ret;
 	}
 
+	num_msdus = skb_queue_len(&amsdu);
 	ath10k_htt_rx_h_ppdu(ar, &amsdu, &rx_status, 0xffff);
 	ath10k_htt_rx_h_unchain(ar, &amsdu, ret > 0);
 	ath10k_htt_rx_h_filter(ar, &amsdu, &rx_status);
 	ath10k_htt_rx_h_mpdu(ar, &amsdu, &rx_status);
 	ath10k_htt_rx_h_deliver(ar, &amsdu, &rx_status);
 
-	return 0;
+	return num_msdus;
 }
 
 static void ath10k_htt_rx_proc_rx_ind(struct ath10k_htt *htt,
@@ -1579,15 +1575,6 @@ static void ath10k_htt_rx_proc_rx_ind(struct ath10k_htt *htt,
 		mpdu_count += mpdu_ranges[i].mpdu_count;
 
 	atomic_add(mpdu_count, &htt->num_mpdus_ready);
-
-	tasklet_schedule(&htt->txrx_compl_task);
-}
-
-static void ath10k_htt_rx_frag_handler(struct ath10k_htt *htt)
-{
-	atomic_inc(&htt->num_mpdus_ready);
-
-	tasklet_schedule(&htt->txrx_compl_task);
 }
 
 static void ath10k_htt_rx_tx_compl_ind(struct ath10k *ar,
@@ -1772,14 +1759,15 @@ static void ath10k_htt_rx_h_rx_offload_prot(struct ieee80211_rx_status *status,
 			RX_FLAG_MMIC_STRIPPED;
 }
 
-static void ath10k_htt_rx_h_rx_offload(struct ath10k *ar,
-				       struct sk_buff_head *list)
+static int ath10k_htt_rx_h_rx_offload(struct ath10k *ar,
+				      struct sk_buff_head *list)
 {
 	struct ath10k_htt *htt = &ar->htt;
 	struct ieee80211_rx_status *status = &htt->rx_status;
 	struct htt_rx_offload_msdu *rx;
 	struct sk_buff *msdu;
 	size_t offset;
+	int num_msdu = 0;
 
 	while ((msdu = __skb_dequeue(list))) {
 		/* Offloaded frames don't have Rx descriptor. Instead they have
@@ -1819,10 +1807,12 @@ static void ath10k_htt_rx_h_rx_offload(struct ath10k *ar,
 		ath10k_htt_rx_h_rx_offload_prot(status, msdu);
 		ath10k_htt_rx_h_channel(ar, status, NULL, rx->vdev_id);
 		ath10k_process_rx(ar, status, msdu);
+		num_msdu++;
 	}
+	return num_msdu;
 }
 
-static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
+static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 {
 	struct ath10k_htt *htt = &ar->htt;
 	struct htt_resp *resp = (void *)skb->data;
@@ -1835,12 +1825,12 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 	u8 tid;
 	bool offload;
 	bool frag;
-	int ret;
+	int ret, num_msdus = 0;
 
 	lockdep_assert_held(&htt->rx_ring.lock);
 
 	if (htt->rx_confused)
-		return;
+		return -EIO;
 
 	skb_pull(skb, sizeof(resp->hdr));
 	skb_pull(skb, sizeof(resp->rx_in_ord_ind));
@@ -1859,7 +1849,7 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 
 	if (skb->len < msdu_count * sizeof(*resp->rx_in_ord_ind.msdu_descs)) {
 		ath10k_warn(ar, "dropping invalid in order rx indication\n");
-		return;
+		return -EINVAL;
 	}
 
 	/* The event can deliver more than 1 A-MSDU. Each A-MSDU is later
@@ -1870,14 +1860,14 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 	if (ret < 0) {
 		ath10k_warn(ar, "failed to pop paddr list: %d\n", ret);
 		htt->rx_confused = true;
-		return;
+		return -EIO;
 	}
 
 	/* Offloaded frames are very different and need to be handled
 	 * separately.
 	 */
 	if (offload)
-		ath10k_htt_rx_h_rx_offload(ar, &list);
+		num_msdus = ath10k_htt_rx_h_rx_offload(ar, &list);
 
 	while (!skb_queue_empty(&list)) {
 		__skb_queue_head_init(&amsdu);
@@ -1890,6 +1880,7 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 			 * better to report something than nothing though. This
 			 * should still give an idea about rx rate to the user.
 			 */
+			num_msdus += skb_queue_len(&amsdu);
 			ath10k_htt_rx_h_ppdu(ar, &amsdu, status, vdev_id);
 			ath10k_htt_rx_h_filter(ar, &amsdu, status);
 			ath10k_htt_rx_h_mpdu(ar, &amsdu, status);
@@ -1902,9 +1893,10 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 			ath10k_warn(ar, "failed to extract amsdu: %d\n", ret);
 			htt->rx_confused = true;
 			__skb_queue_purge(&list);
-			return;
+			return -EIO;
 		}
 	}
+	return num_msdus;
 }
 
 static void ath10k_htt_rx_tx_fetch_resp_id_confirm(struct ath10k *ar,
@@ -2267,7 +2259,6 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
 	}
 	case HTT_T2H_MSG_TYPE_TX_COMPL_IND:
 		ath10k_htt_rx_tx_compl_ind(htt->ar, skb);
-		tasklet_schedule(&htt->txrx_compl_task);
 		break;
 	case HTT_T2H_MSG_TYPE_SEC_IND: {
 		struct ath10k *ar = htt->ar;
@@ -2284,7 +2275,7 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
 	case HTT_T2H_MSG_TYPE_RX_FRAG_IND: {
 		ath10k_dbg_dump(ar, ATH10K_DBG_HTT_DUMP, NULL, "htt event: ",
 				skb->data, skb->len);
-		ath10k_htt_rx_frag_handler(htt);
+		atomic_inc(&htt->num_mpdus_ready);
 		break;
 	}
 	case HTT_T2H_MSG_TYPE_TEST:
@@ -2322,8 +2313,7 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
 		break;
 	}
 	case HTT_T2H_MSG_TYPE_RX_IN_ORD_PADDR_IND: {
-		skb_queue_tail(&htt->rx_in_ord_compl_q, skb);
-		tasklet_schedule(&htt->txrx_compl_task);
+		__skb_queue_tail(&htt->rx_in_ord_compl_q, skb);
 		return false;
 	}
 	case HTT_T2H_MSG_TYPE_TX_CREDIT_UPDATE_IND:
@@ -2349,7 +2339,6 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
 			break;
 		}
 		skb_queue_tail(&htt->tx_fetch_ind_q, tx_fetch_ind);
-		tasklet_schedule(&htt->txrx_compl_task);
 		break;
 	}
 	case HTT_T2H_MSG_TYPE_TX_FETCH_CONFIRM:
@@ -2378,27 +2367,77 @@ void ath10k_htt_rx_pktlog_completion_handler(struct ath10k *ar,
 }
 EXPORT_SYMBOL(ath10k_htt_rx_pktlog_completion_handler);
 
-static void ath10k_htt_txrx_compl_task(unsigned long ptr)
+int ath10k_htt_txrx_compl_task(struct ath10k *ar, int budget)
 {
-	struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
-	struct ath10k *ar = htt->ar;
+	struct ath10k_htt *htt = &ar->htt;
 	struct htt_tx_done tx_done = {};
-	struct sk_buff_head rx_ind_q;
 	struct sk_buff_head tx_ind_q;
 	struct sk_buff *skb;
 	unsigned long flags;
-	int num_mpdus;
+	int quota = 0, done, num_rx_msdus;
+	bool resched_napi = false;
 
-	__skb_queue_head_init(&rx_ind_q);
 	__skb_queue_head_init(&tx_ind_q);
 
-	spin_lock_irqsave(&htt->rx_in_ord_compl_q.lock, flags);
-	skb_queue_splice_init(&htt->rx_in_ord_compl_q, &rx_ind_q);
-	spin_unlock_irqrestore(&htt->rx_in_ord_compl_q.lock, flags);
+	/* Since in-ord-ind can deliver more than 1 A-MSDU in single event,
+	 * process it first to utilize full available quota.
+	 */
+	while (quota < budget) {
+		if (skb_queue_empty(&htt->rx_in_ord_compl_q))
+			break;
 
-	spin_lock_irqsave(&htt->tx_fetch_ind_q.lock, flags);
-	skb_queue_splice_init(&htt->tx_fetch_ind_q, &tx_ind_q);
-	spin_unlock_irqrestore(&htt->tx_fetch_ind_q.lock, flags);
+		skb = __skb_dequeue(&htt->rx_in_ord_compl_q);
+		if (!skb) {
+			resched_napi = true;
+			goto exit;
+		}
+
+		spin_lock_bh(&htt->rx_ring.lock);
+		num_rx_msdus = ath10k_htt_rx_in_ord_ind(ar, skb);
+		spin_unlock_bh(&htt->rx_ring.lock);
+		if (num_rx_msdus < 0) {
+			resched_napi = true;
+			goto exit;
+		}
+
+		dev_kfree_skb_any(skb);
+		if (num_rx_msdus > 0)
+			quota += num_rx_msdus;
+
+		if ((quota > ATH10K_NAPI_QUOTA_LIMIT) &&
+		    !skb_queue_empty(&htt->rx_in_ord_compl_q)) {
+			resched_napi = true;
+			goto exit;
+		}
+	}
+
+	while (quota < budget) {
+		/* no more data to receive */
+		if (!atomic_read(&htt->num_mpdus_ready))
+			break;
+
+		num_rx_msdus = ath10k_htt_rx_handle_amsdu(htt);
+		if (num_rx_msdus < 0) {
+			resched_napi = true;
+			goto exit;
+		}
+
+		quota += num_rx_msdus;
+		atomic_dec(&htt->num_mpdus_ready);
+		if ((quota > ATH10K_NAPI_QUOTA_LIMIT) &&
+		    atomic_read(&htt->num_mpdus_ready)) {
+			resched_napi = true;
+			goto exit;
+		}
+	}
+
+	/* From NAPI documentation:
+	 *  The napi poll() function may also process TX completions, in which
+	 *  case if it processes the entire TX ring then it should count that
+	 *  work as the rest of the budget.
+	 */
+	if ((quota < budget) && !kfifo_is_empty(&htt->txdone_fifo))
+		quota = budget;
 
 	/* kfifo_get: called only within txrx_tasklet so it's neatly serialized.
 	 * From kfifo_get() documentation:
@@ -2408,27 +2447,22 @@ static void ath10k_htt_txrx_compl_task(unsigned long ptr)
 	while (kfifo_get(&htt->txdone_fifo, &tx_done))
 		ath10k_txrx_tx_unref(htt, &tx_done);
 
+	spin_lock_irqsave(&htt->tx_fetch_ind_q.lock, flags);
+	skb_queue_splice_init(&htt->tx_fetch_ind_q, &tx_ind_q);
+	spin_unlock_irqrestore(&htt->tx_fetch_ind_q.lock, flags);
+
 	while ((skb = __skb_dequeue(&tx_ind_q))) {
 		ath10k_htt_rx_tx_fetch_ind(ar, skb);
 		dev_kfree_skb_any(skb);
 	}
 
-	num_mpdus = atomic_read(&htt->num_mpdus_ready);
-
-	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))) {
-		spin_lock_bh(&htt->rx_ring.lock);
-		ath10k_htt_rx_in_ord_ind(ar, skb);
-		spin_unlock_bh(&htt->rx_ring.lock);
-		dev_kfree_skb_any(skb);
-	}
-
+exit:
 	ath10k_htt_rx_msdu_buff_replenish(htt);
+	/* In case of rx failure or more data to read, report budget
+	 * to reschedule NAPI poll
+	 */
+	done = resched_napi ? budget : quota;
+
+	return done;
 }
+EXPORT_SYMBOL(ath10k_htt_txrx_compl_task);
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index f06dd3941bac..9169ab92a16a 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1502,12 +1502,10 @@ void ath10k_pci_hif_send_complete_check(struct ath10k *ar, u8 pipe,
 	ath10k_ce_per_engine_service(ar, pipe);
 }
 
-void ath10k_pci_kill_tasklet(struct ath10k *ar)
+static void ath10k_pci_rx_retry_sync(struct ath10k *ar)
 {
 	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
 
-	tasklet_kill(&ar_pci->intr_tq);
-
 	del_timer_sync(&ar_pci->rx_post_retry);
 }
 
@@ -1747,7 +1745,7 @@ void ath10k_pci_ce_deinit(struct ath10k *ar)
 
 void ath10k_pci_flush(struct ath10k *ar)
 {
-	ath10k_pci_kill_tasklet(ar);
+	ath10k_pci_rx_retry_sync(ar);
 	ath10k_pci_buffer_cleanup(ar);
 }
 
@@ -2754,35 +2752,53 @@ static irqreturn_t ath10k_pci_interrupt_handler(int irq, void *arg)
 		return IRQ_NONE;
 	}
 
-	if (ar_pci->oper_irq_mode == ATH10K_PCI_IRQ_LEGACY) {
-		if (!ath10k_pci_irq_pending(ar))
-			return IRQ_NONE;
-
-		ath10k_pci_disable_and_clear_legacy_irq(ar);
-	}
+	if ((ar_pci->oper_irq_mode == ATH10K_PCI_IRQ_LEGACY) &&
+	    !ath10k_pci_irq_pending(ar))
+		return IRQ_NONE;
 
-	tasklet_schedule(&ar_pci->intr_tq);
+	ath10k_pci_disable_and_clear_legacy_irq(ar);
+	ath10k_pci_irq_msi_fw_mask(ar);
+	napi_schedule(&ar->napi);
 
 	return IRQ_HANDLED;
 }
 
-static void ath10k_pci_tasklet(unsigned long data)
+static int ath10k_pci_napi_poll(struct napi_struct *ctx, int budget)
 {
-	struct ath10k *ar = (struct ath10k *)data;
-	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
+	struct ath10k *ar = container_of(ctx, struct ath10k, napi);
+	int done = 0;
 
 	if (ath10k_pci_has_fw_crashed(ar)) {
-		ath10k_pci_irq_disable(ar);
 		ath10k_pci_fw_crashed_clear(ar);
 		ath10k_pci_fw_crashed_dump(ar);
-		return;
+		napi_complete(ctx);
+		return done;
 	}
 
 	ath10k_ce_per_engine_service_any(ar);
 
-	/* Re-enable legacy irq that was disabled in the irq handler */
-	if (ar_pci->oper_irq_mode == ATH10K_PCI_IRQ_LEGACY)
+	done = ath10k_htt_txrx_compl_task(ar, budget);
+
+	if (done < budget) {
+		napi_complete(ctx);
+		/* In case of MSI, it is possible that interrupts are received
+		 * while NAPI poll is inprogress. So pending interrupts that are
+		 * received after processing all copy engine pipes by NAPI poll
+		 * will not be handled again. This is causing failure to
+		 * complete boot sequence in x86 platform. So before enabling
+		 * interrupts safer to check for pending interrupts for
+		 * immediate servicing.
+		 */
+		if (CE_INTERRUPT_SUMMARY(ar)) {
+			napi_reschedule(&ar->napi);
+			goto out;
+		}
 		ath10k_pci_enable_legacy_irq(ar);
+		ath10k_pci_irq_msi_fw_unmask(ar);
+	}
+
+out:
+	return done;
 }
 
 static int ath10k_pci_request_irq_msi(struct ath10k *ar)
@@ -2840,11 +2856,11 @@ static void ath10k_pci_free_irq(struct ath10k *ar)
 	free_irq(ar_pci->pdev->irq, ar);
 }
 
-void ath10k_pci_init_irq_tasklets(struct ath10k *ar)
+void ath10k_pci_init_napi(struct ath10k *ar)
 {
-	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
-
-	tasklet_init(&ar_pci->intr_tq, ath10k_pci_tasklet, (unsigned long)ar);
+	netif_napi_add(&ar->napi_dev, &ar->napi, ath10k_pci_napi_poll,
+		       ATH10K_NAPI_BUDGET);
+	napi_enable(&ar->napi);
 }
 
 static int ath10k_pci_init_irq(struct ath10k *ar)
@@ -2852,7 +2868,7 @@ static int ath10k_pci_init_irq(struct ath10k *ar)
 	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
 	int ret;
 
-	ath10k_pci_init_irq_tasklets(ar);
+	ath10k_pci_init_napi(ar);
 
 	if (ath10k_pci_irq_mode != ATH10K_PCI_IRQ_AUTO)
 		ath10k_info(ar, "limiting irq mode to: %d\n",
@@ -3113,7 +3129,8 @@ int ath10k_pci_setup_resource(struct ath10k *ar)
 
 void ath10k_pci_release_resource(struct ath10k *ar)
 {
-	ath10k_pci_kill_tasklet(ar);
+	ath10k_pci_rx_retry_sync(ar);
+	netif_napi_del(&ar->napi);
 	ath10k_pci_ce_deinit(ar);
 	ath10k_pci_free_pipes(ar);
 }
@@ -3274,7 +3291,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
 
 err_free_irq:
 	ath10k_pci_free_irq(ar);
-	ath10k_pci_kill_tasklet(ar);
+	ath10k_pci_rx_retry_sync(ar);
 
 err_deinit_irq:
 	ath10k_pci_deinit_irq(ar);
diff --git a/drivers/net/wireless/ath/ath10k/pci.h b/drivers/net/wireless/ath/ath10k/pci.h
index 6eca1df2ce60..974e463e8b95 100644
--- a/drivers/net/wireless/ath/ath10k/pci.h
+++ b/drivers/net/wireless/ath/ath10k/pci.h
@@ -177,8 +177,6 @@ struct ath10k_pci {
 	/* Operating interrupt mode */
 	enum ath10k_pci_irq_mode oper_irq_mode;
 
-	struct tasklet_struct intr_tq;
-
 	struct ath10k_pci_pipe pipe_info[CE_COUNT_MAX];
 
 	/* Copy Engine used for Diagnostic Accesses */
@@ -294,8 +292,7 @@ void ath10k_pci_free_pipes(struct ath10k *ar);
 void ath10k_pci_free_pipes(struct ath10k *ar);
 void ath10k_pci_rx_replenish_retry(unsigned long ptr);
 void ath10k_pci_ce_deinit(struct ath10k *ar);
-void ath10k_pci_init_irq_tasklets(struct ath10k *ar);
-void ath10k_pci_kill_tasklet(struct ath10k *ar);
+void ath10k_pci_init_napi(struct ath10k *ar);
 int ath10k_pci_init_pipes(struct ath10k *ar);
 int ath10k_pci_init_config(struct ath10k *ar);
 void ath10k_pci_rx_post(struct ath10k *ar);
-- 
2.9.0



From c_traja at qti.qualcomm.com  Mon Jun 27 00:59:11 2016
From: c_traja at qti.qualcomm.com (c_traja at qti.qualcomm.com)
Date: Mon, 27 Jun 2016 13:29:11 +0530
Subject: [PATCH 0/3] Add testmode support for 10.4
Message-ID: <1467014351-30894-1-git-send-email-c_traja@qti.qualcomm.com>

From: Tamizh chelvam <tamizhchelvam at codeaurora.org>

*The below patches add testmode support for 10.4.

*Some of the codeswap related code in ath10k for example code
which  initializes the code swap segment works only on normal fw,
below patches  make such code generic so that it can be used
for utf binary as well.

Tamizh chelvam (3):
  ath10k: move firmware_swap_code_seg_info to ath10k_fw_file
  ath10k: handle testmode events for 10.2 and 10.4 based firmware
  ath10k: add testmode support for 10.4 firmware

 drivers/net/wireless/ath/ath10k/core.c     |    6 +++---
 drivers/net/wireless/ath/ath10k/core.h     |    6 ++----
 drivers/net/wireless/ath/ath10k/swap.c     |   26 ++++++++++++++------------
 drivers/net/wireless/ath/ath10k/swap.h     |   11 ++++++++---
 drivers/net/wireless/ath/ath10k/testmode.c |   23 +++++++++++++++++++++++
 drivers/net/wireless/ath/ath10k/wmi.c      |   26 ++++++++++++++++++++++++++
 6 files changed, 76 insertions(+), 22 deletions(-)

-- 
1.7.9.5



From c_traja at qti.qualcomm.com  Mon Jun 27 01:49:37 2016
From: c_traja at qti.qualcomm.com (c_traja at qti.qualcomm.com)
Date: Mon, 27 Jun 2016 14:19:37 +0530
Subject: [PATCH 0/3] Add testmode support for 10.4
Message-ID: <1467017377-25145-1-git-send-email-c_traja@qti.qualcomm.com>

From: Tamizh chelvam <tamizhchelvam at codeaurora.org>

*The below patches add testmode support for 10.4.

*Some of the codeswap related code in ath10k for example code
which  initializes the code swap segment works only on normal fw,
below patches  make such code generic so that it can be used
for utf binary as well.

Tamizh chelvam (3):
  ath10k: move firmware_swap_code_seg_info to ath10k_fw_file
  ath10k: handle testmode events for 10.2 and 10.4 based firmware
  ath10k: add testmode support for 10.4 firmware

 drivers/net/wireless/ath/ath10k/core.c     |    6 +++---
 drivers/net/wireless/ath/ath10k/core.h     |    6 ++----
 drivers/net/wireless/ath/ath10k/swap.c     |   26 ++++++++++++++------------
 drivers/net/wireless/ath/ath10k/swap.h     |   11 ++++++++---
 drivers/net/wireless/ath/ath10k/testmode.c |   23 +++++++++++++++++++++++
 drivers/net/wireless/ath/ath10k/wmi.c      |   26 ++++++++++++++++++++++++++
 6 files changed, 76 insertions(+), 22 deletions(-)

-- 
1.7.9.5



From c_traja at qti.qualcomm.com  Mon Jun 27 01:50:10 2016
From: c_traja at qti.qualcomm.com (c_traja at qti.qualcomm.com)
Date: Mon, 27 Jun 2016 14:20:10 +0530
Subject: [PATCH 1/3] ath10k: move firmware_swap_code_seg_info to ath10k_fw_file
Message-ID: <1467017410-32128-1-git-send-email-c_traja@qti.qualcomm.com>

From: Tamizh chelvam <c_traja at qti.qualcomm.com>

Preparation to make use of firmware_swap_code_seg_info for
UTF binary.

Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c |    6 +++---
 drivers/net/wireless/ath/ath10k/core.h |    6 ++----
 drivers/net/wireless/ath/ath10k/swap.c |   26 ++++++++++++++------------
 drivers/net/wireless/ath/ath10k/swap.h |   11 ++++++++---
 4 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index dfb3db0..0a1946b 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -723,7 +723,7 @@ static int ath10k_download_fw(struct ath10k *ar)
 	data = ar->running_fw->fw_file.firmware_data;
 	data_len = ar->running_fw->fw_file.firmware_len;
 
-	ret = ath10k_swap_code_seg_configure(ar);
+	ret = ath10k_swap_code_seg_configure(ar, &ar->running_fw->fw_file);
 	if (ret) {
 		ath10k_err(ar, "failed to configure fw code swap: %d\n",
 			   ret);
@@ -765,7 +765,7 @@ static void ath10k_core_free_firmware_files(struct ath10k *ar)
 	if (!IS_ERR(ar->pre_cal_file))
 		release_firmware(ar->pre_cal_file);
 
-	ath10k_swap_code_seg_release(ar);
+	ath10k_swap_code_seg_release(ar, &ar->normal_mode_fw.fw_file);
 
 	ar->normal_mode_fw.fw_file.otp_data = NULL;
 	ar->normal_mode_fw.fw_file.otp_len = 0;
@@ -2009,7 +2009,7 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
 		goto err_free_firmware_files;
 	}
 
-	ret = ath10k_swap_code_seg_init(ar);
+	ret = ath10k_swap_code_seg_init(ar, &ar->normal_mode_fw.fw_file);
 	if (ret) {
 		ath10k_err(ar, "failed to initialize code swap segment: %d\n",
 			   ret);
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 3da18c9..e69e7e7 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -654,6 +654,8 @@ struct ath10k_fw_file {
 
 	const void *codeswap_data;
 	size_t codeswap_len;
+	/* FIXME: add a comment */
+	struct ath10k_swap_code_seg_info *firmware_swap_code_seg_info;
 };
 
 struct ath10k_fw_components {
@@ -765,10 +767,6 @@ struct ath10k {
 	const struct firmware *cal_file;
 
 	struct {
-		struct ath10k_swap_code_seg_info *firmware_swap_code_seg_info;
-	} swap;
-
-	struct {
 		u32 vendor;
 		u32 device;
 		u32 subsystem_vendor;
diff --git a/drivers/net/wireless/ath/ath10k/swap.c b/drivers/net/wireless/ath/ath10k/swap.c
index 0c5f586..c904a41 100644
--- a/drivers/net/wireless/ath/ath10k/swap.c
+++ b/drivers/net/wireless/ath/ath10k/swap.c
@@ -134,17 +134,18 @@ ath10k_swap_code_seg_alloc(struct ath10k *ar, size_t swap_bin_len)
 	return seg_info;
 }
 
-int ath10k_swap_code_seg_configure(struct ath10k *ar)
+int ath10k_swap_code_seg_configure(struct ath10k *ar,
+				   const struct ath10k_fw_file *fw_file)
 {
 	int ret;
 	struct ath10k_swap_code_seg_info *seg_info = NULL;
 
-	if (!ar->swap.firmware_swap_code_seg_info)
+	if (fw_file->firmware_swap_code_seg_info)
 		return 0;
 
 	ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot found firmware code swap binary\n");
 
-	seg_info = ar->swap.firmware_swap_code_seg_info;
+	seg_info = fw_file->firmware_swap_code_seg_info;
 
 	ret = ath10k_bmi_write_memory(ar, seg_info->target_addr,
 				      &seg_info->seg_hw_info,
@@ -158,28 +159,29 @@ int ath10k_swap_code_seg_configure(struct ath10k *ar)
 	return 0;
 }
 
-void ath10k_swap_code_seg_release(struct ath10k *ar)
+void ath10k_swap_code_seg_release(struct ath10k *ar,
+				  struct ath10k_fw_file *fw_file)
 {
-	ath10k_swap_code_seg_free(ar, ar->swap.firmware_swap_code_seg_info);
+	ath10k_swap_code_seg_free(ar, fw_file->firmware_swap_code_seg_info);
 
 	/* FIXME: these two assignments look to bein wrong place! Shouldn't
 	 * they be in ath10k_core_free_firmware_files() like the rest?
 	 */
-	ar->normal_mode_fw.fw_file.codeswap_data = NULL;
-	ar->normal_mode_fw.fw_file.codeswap_len = 0;
+	fw_file->codeswap_data = NULL;
+	fw_file->codeswap_len = 0;
 
-	ar->swap.firmware_swap_code_seg_info = NULL;
+	fw_file->firmware_swap_code_seg_info = NULL;
 }
 
-int ath10k_swap_code_seg_init(struct ath10k *ar)
+int ath10k_swap_code_seg_init(struct ath10k *ar, struct ath10k_fw_file *fw_file)
 {
 	int ret;
 	struct ath10k_swap_code_seg_info *seg_info;
 	const void *codeswap_data;
 	size_t codeswap_len;
 
-	codeswap_data = ar->normal_mode_fw.fw_file.codeswap_data;
-	codeswap_len = ar->normal_mode_fw.fw_file.codeswap_len;
+	codeswap_data = fw_file->codeswap_data;
+	codeswap_len = fw_file->codeswap_len;
 
 	if (!codeswap_len || !codeswap_data)
 		return 0;
@@ -200,7 +202,7 @@ int ath10k_swap_code_seg_init(struct ath10k *ar)
 		return ret;
 	}
 
-	ar->swap.firmware_swap_code_seg_info = seg_info;
+	fw_file->firmware_swap_code_seg_info = seg_info;
 
 	return 0;
 }
diff --git a/drivers/net/wireless/ath/ath10k/swap.h b/drivers/net/wireless/ath/ath10k/swap.h
index 36991c7..f5dc047 100644
--- a/drivers/net/wireless/ath/ath10k/swap.h
+++ b/drivers/net/wireless/ath/ath10k/swap.h
@@ -23,6 +23,8 @@
 /* Currently only one swap segment is supported */
 #define ATH10K_SWAP_CODE_SEG_NUM_SUPPORTED	1
 
+struct ath10k_fw_file;
+
 struct ath10k_swap_code_seg_tlv {
 	__le32 address;
 	__le32 length;
@@ -58,8 +60,11 @@ struct ath10k_swap_code_seg_info {
 	dma_addr_t paddr[ATH10K_SWAP_CODE_SEG_NUM_SUPPORTED];
 };
 
-int ath10k_swap_code_seg_configure(struct ath10k *ar);
-void ath10k_swap_code_seg_release(struct ath10k *ar);
-int ath10k_swap_code_seg_init(struct ath10k *ar);
+int ath10k_swap_code_seg_configure(struct ath10k *ar,
+				   const struct ath10k_fw_file *fw_file);
+void ath10k_swap_code_seg_release(struct ath10k *ar,
+				  struct ath10k_fw_file *fw_file);
+int ath10k_swap_code_seg_init(struct ath10k *ar,
+			      struct ath10k_fw_file *fw_file);
 
 #endif
-- 
1.7.9.5



From c_traja at qti.qualcomm.com  Mon Jun 27 01:50:50 2016
From: c_traja at qti.qualcomm.com (c_traja at qti.qualcomm.com)
Date: Mon, 27 Jun 2016 14:20:50 +0530
Subject: [PATCH 2/3] ath10k: handle testmode events for 10.2 and 10.4 based
 firmware
Message-ID: <1467017450-7552-1-git-send-email-c_traja@qti.qualcomm.com>

From: Tamizh chelvam <c_traja at qti.qualcomm.com>

Currently testmode events for 10.x firmware are processed from
10.1 wmi event processing. This patch is used to handle testmode
events in 10.2 and 10.4 based firmware.

Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.c |   26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 6279ab4..72b5483 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5095,6 +5095,7 @@ static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, struct sk_buff *skb)
 {
 	struct wmi_cmd_hdr *cmd_hdr;
 	enum wmi_10_2_event_id id;
+	bool consumed;
 
 	cmd_hdr = (struct wmi_cmd_hdr *)skb->data;
 	id = MS(__le32_to_cpu(cmd_hdr->cmd_id), WMI_CMD_HDR_CMD_ID);
@@ -5104,6 +5105,18 @@ static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, struct sk_buff *skb)
 
 	trace_ath10k_wmi_event(ar, id, skb->data, skb->len);
 
+	consumed = ath10k_tm_event_wmi(ar, id, skb);
+
+	/* Ready event must be handled normally also in UTF mode so that we
+	 * know the UTF firmware has booted, others we are just bypass WMI
+	 * events to testmode.
+	 */
+	if (consumed && id != WMI_10_2_READY_EVENTID) {
+		ath10k_dbg(ar, ATH10K_DBG_WMI,
+			   "wmi testmode consumed 0x%x\n", id);
+		goto out;
+	}
+
 	switch (id) {
 	case WMI_10_2_MGMT_RX_EVENTID:
 		ath10k_wmi_event_mgmt_rx(ar, skb);
@@ -5219,6 +5232,7 @@ static void ath10k_wmi_10_4_op_rx(struct ath10k *ar, struct sk_buff *skb)
 {
 	struct wmi_cmd_hdr *cmd_hdr;
 	enum wmi_10_4_event_id id;
+	bool consumed;
 
 	cmd_hdr = (struct wmi_cmd_hdr *)skb->data;
 	id = MS(__le32_to_cpu(cmd_hdr->cmd_id), WMI_CMD_HDR_CMD_ID);
@@ -5228,6 +5242,18 @@ static void ath10k_wmi_10_4_op_rx(struct ath10k *ar, struct sk_buff *skb)
 
 	trace_ath10k_wmi_event(ar, id, skb->data, skb->len);
 
+	consumed = ath10k_tm_event_wmi(ar, id, skb);
+
+	/* Ready event must be handled normally also in UTF mode so that we
+	 * know the UTF firmware has booted, others we are just bypass WMI
+	 * events to testmode.
+	 */
+	if (consumed && id != WMI_10_4_READY_EVENTID) {
+		ath10k_dbg(ar, ATH10K_DBG_WMI,
+			   "wmi testmode consumed 0x%x\n", id);
+		goto out;
+	}
+
 	switch (id) {
 	case WMI_10_4_MGMT_RX_EVENTID:
 		ath10k_wmi_event_mgmt_rx(ar, skb);
-- 
1.7.9.5



From c_traja at qti.qualcomm.com  Mon Jun 27 01:51:20 2016
From: c_traja at qti.qualcomm.com (c_traja at qti.qualcomm.com)
Date: Mon, 27 Jun 2016 14:21:20 +0530
Subject: [PATCH 3/3] ath10k: add testmode support for 10.4 firmware
Message-ID: <1467017480-12374-1-git-send-email-c_traja@qti.qualcomm.com>

From: Tamizh chelvam <c_traja at qti.qualcomm.com>

This patch adds testmode support for QCA99X0 chipsets which uses
10.4 firmware and added code swap support for UTF binary.

Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/testmode.c |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/testmode.c b/drivers/net/wireless/ath/ath10k/testmode.c
index 120f423..2c10c0e 100644
--- a/drivers/net/wireless/ath/ath10k/testmode.c
+++ b/drivers/net/wireless/ath/ath10k/testmode.c
@@ -23,6 +23,7 @@
 #include "wmi.h"
 #include "hif.h"
 #include "hw.h"
+#include "core.h"
 
 #include "testmode_i.h"
 
@@ -240,6 +241,18 @@ static int ath10k_tm_cmd_utf_start(struct ath10k *ar, struct nlattr *tb[])
 		goto err;
 	}
 
+	if (ar->testmode.utf_mode_fw.fw_file.codeswap_data &&
+	    ar->testmode.utf_mode_fw.fw_file.codeswap_len) {
+		ret = ath10k_swap_code_seg_init(ar,
+					&ar->testmode.utf_mode_fw.fw_file);
+		if (ret) {
+			ath10k_warn(ar,
+				"failed to init utf code swap segment: %d\n",
+				ret);
+			goto err_release_utf_mode_fw;
+		}
+	}
+
 	spin_lock_bh(&ar->data_lock);
 	ar->testmode.utf_monitor = true;
 	spin_unlock_bh(&ar->data_lock);
@@ -279,6 +292,11 @@ err_power_down:
 	ath10k_hif_power_down(ar);
 
 err_release_utf_mode_fw:
+	if (ar->testmode.utf_mode_fw.fw_file.codeswap_data &&
+	    ar->testmode.utf_mode_fw.fw_file.codeswap_len)
+		ath10k_swap_code_seg_release(ar,
+					&ar->testmode.utf_mode_fw.fw_file);
+
 	release_firmware(ar->testmode.utf_mode_fw.fw_file.firmware);
 	ar->testmode.utf_mode_fw.fw_file.firmware = NULL;
 
@@ -301,6 +319,11 @@ static void __ath10k_tm_cmd_utf_stop(struct ath10k *ar)
 
 	spin_unlock_bh(&ar->data_lock);
 
+	if (ar->testmode.utf_mode_fw.fw_file.codeswap_data &&
+	    ar->testmode.utf_mode_fw.fw_file.codeswap_len)
+		ath10k_swap_code_seg_release(ar,
+					&ar->testmode.utf_mode_fw.fw_file);
+
 	release_firmware(ar->testmode.utf_mode_fw.fw_file.firmware);
 	ar->testmode.utf_mode_fw.fw_file.firmware = NULL;
 
-- 
1.7.9.5



From gaurang at vt.edu  Mon Jun 27 01:58:38 2016
From: gaurang at vt.edu (Gaurang Ramesh Naik)
Date: Mon, 27 Jun 2016 04:58:38 -0400
Subject: Set the primary channel in HT40 mode
Message-ID: <CAFc9h7vWsEyU7V4X0ehzjsmgw=a_hym0SVrF4Gay=5jJTL2VFA@mail.gmail.com>

Hi All,

I have some difficulty in understanding how HT40, HT40- and HT40+
modes work. My objective is to set a particular 20 MHz channel as the
primary channel when channel bonding is enabled. From what I
understand, HT40- means secondary channel is below the primary, while
HT40+ means secondary channel is above the primary channel. I am
particularly dealing with channels 149, 153, 157 and 161.

When I set the channel to say 157, whether I use HT40+ or HT40-, the
primary channel is always set to channel 161. I am inferring this
because when I scan using iwlist scan, my SSID shows on Channel 161.
Does ath10k not set the primary and secondary channel in this manner?

If not, is there a mechanism by which I can explicitly mention which
channel must be primary, and which must be secondary? Also, how is the
primary channel decided for VHT80 mode?

Note: I am using OpenWrt in my AP. So I set the htmode as an option in
the /etc/config/wireless file.

Thanks,
Gaurang.


From c_traja at qti.qualcomm.com  Mon Jun 27 02:06:11 2016
From: c_traja at qti.qualcomm.com (c_traja at qti.qualcomm.com)
Date: Mon, 27 Jun 2016 14:36:11 +0530
Subject: [PATCHV2 0/3] Add testmode support for 10.4
Message-ID: <1467018371-24416-1-git-send-email-c_traja@qti.qualcomm.com>

From: Tamizh chelvam <c_traja at qti.qualcomm.com>

*The below patches add testmode support for 10.4.

*Some of the codeswap related code in ath10k for example code
which  initializes the code swap segment works only on normal fw,
below patches  make such code generic so that it can be used
for utf binary as well.

Tamizh chelvam (3):
  ath10k: move firmware_swap_code_seg_info to ath10k_fw_file
  ath10k: handle testmode events for 10.2 and 10.4 based firmware
  ath10k: add testmode support for 10.4 firmware

V2:
  * changed author and signed off mail id.

 drivers/net/wireless/ath/ath10k/core.c     |    6 +++---
 drivers/net/wireless/ath/ath10k/core.h     |    6 ++----
 drivers/net/wireless/ath/ath10k/swap.c     |   26 ++++++++++++++------------
 drivers/net/wireless/ath/ath10k/swap.h     |   11 ++++++++---
 drivers/net/wireless/ath/ath10k/testmode.c |   23 +++++++++++++++++++++++
 drivers/net/wireless/ath/ath10k/wmi.c      |   26 ++++++++++++++++++++++++++
 6 files changed, 76 insertions(+), 22 deletions(-)

-- 
1.7.9.5



From c_traja at qti.qualcomm.com  Mon Jun 27 02:06:44 2016
From: c_traja at qti.qualcomm.com (c_traja at qti.qualcomm.com)
Date: Mon, 27 Jun 2016 14:36:44 +0530
Subject: [PATCHV2 1/3] ath10k: move firmware_swap_code_seg_info to
 ath10k_fw_file
Message-ID: <1467018404-24460-1-git-send-email-c_traja@qti.qualcomm.com>

From: Tamizh chelvam <c_traja at qti.qualcomm.com>

Preparation to make use of firmware_swap_code_seg_info for
UTF binary.

Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c |    6 +++---
 drivers/net/wireless/ath/ath10k/core.h |    6 ++----
 drivers/net/wireless/ath/ath10k/swap.c |   26 ++++++++++++++------------
 drivers/net/wireless/ath/ath10k/swap.h |   11 ++++++++---
 4 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index dfb3db0..0a1946b 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -723,7 +723,7 @@ static int ath10k_download_fw(struct ath10k *ar)
 	data = ar->running_fw->fw_file.firmware_data;
 	data_len = ar->running_fw->fw_file.firmware_len;
 
-	ret = ath10k_swap_code_seg_configure(ar);
+	ret = ath10k_swap_code_seg_configure(ar, &ar->running_fw->fw_file);
 	if (ret) {
 		ath10k_err(ar, "failed to configure fw code swap: %d\n",
 			   ret);
@@ -765,7 +765,7 @@ static void ath10k_core_free_firmware_files(struct ath10k *ar)
 	if (!IS_ERR(ar->pre_cal_file))
 		release_firmware(ar->pre_cal_file);
 
-	ath10k_swap_code_seg_release(ar);
+	ath10k_swap_code_seg_release(ar, &ar->normal_mode_fw.fw_file);
 
 	ar->normal_mode_fw.fw_file.otp_data = NULL;
 	ar->normal_mode_fw.fw_file.otp_len = 0;
@@ -2009,7 +2009,7 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
 		goto err_free_firmware_files;
 	}
 
-	ret = ath10k_swap_code_seg_init(ar);
+	ret = ath10k_swap_code_seg_init(ar, &ar->normal_mode_fw.fw_file);
 	if (ret) {
 		ath10k_err(ar, "failed to initialize code swap segment: %d\n",
 			   ret);
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 3da18c9..e69e7e7 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -654,6 +654,8 @@ struct ath10k_fw_file {
 
 	const void *codeswap_data;
 	size_t codeswap_len;
+	/* FIXME: add a comment */
+	struct ath10k_swap_code_seg_info *firmware_swap_code_seg_info;
 };
 
 struct ath10k_fw_components {
@@ -765,10 +767,6 @@ struct ath10k {
 	const struct firmware *cal_file;
 
 	struct {
-		struct ath10k_swap_code_seg_info *firmware_swap_code_seg_info;
-	} swap;
-
-	struct {
 		u32 vendor;
 		u32 device;
 		u32 subsystem_vendor;
diff --git a/drivers/net/wireless/ath/ath10k/swap.c b/drivers/net/wireless/ath/ath10k/swap.c
index 0c5f586..c904a41 100644
--- a/drivers/net/wireless/ath/ath10k/swap.c
+++ b/drivers/net/wireless/ath/ath10k/swap.c
@@ -134,17 +134,18 @@ ath10k_swap_code_seg_alloc(struct ath10k *ar, size_t swap_bin_len)
 	return seg_info;
 }
 
-int ath10k_swap_code_seg_configure(struct ath10k *ar)
+int ath10k_swap_code_seg_configure(struct ath10k *ar,
+				   const struct ath10k_fw_file *fw_file)
 {
 	int ret;
 	struct ath10k_swap_code_seg_info *seg_info = NULL;
 
-	if (!ar->swap.firmware_swap_code_seg_info)
+	if (fw_file->firmware_swap_code_seg_info)
 		return 0;
 
 	ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot found firmware code swap binary\n");
 
-	seg_info = ar->swap.firmware_swap_code_seg_info;
+	seg_info = fw_file->firmware_swap_code_seg_info;
 
 	ret = ath10k_bmi_write_memory(ar, seg_info->target_addr,
 				      &seg_info->seg_hw_info,
@@ -158,28 +159,29 @@ int ath10k_swap_code_seg_configure(struct ath10k *ar)
 	return 0;
 }
 
-void ath10k_swap_code_seg_release(struct ath10k *ar)
+void ath10k_swap_code_seg_release(struct ath10k *ar,
+				  struct ath10k_fw_file *fw_file)
 {
-	ath10k_swap_code_seg_free(ar, ar->swap.firmware_swap_code_seg_info);
+	ath10k_swap_code_seg_free(ar, fw_file->firmware_swap_code_seg_info);
 
 	/* FIXME: these two assignments look to bein wrong place! Shouldn't
 	 * they be in ath10k_core_free_firmware_files() like the rest?
 	 */
-	ar->normal_mode_fw.fw_file.codeswap_data = NULL;
-	ar->normal_mode_fw.fw_file.codeswap_len = 0;
+	fw_file->codeswap_data = NULL;
+	fw_file->codeswap_len = 0;
 
-	ar->swap.firmware_swap_code_seg_info = NULL;
+	fw_file->firmware_swap_code_seg_info = NULL;
 }
 
-int ath10k_swap_code_seg_init(struct ath10k *ar)
+int ath10k_swap_code_seg_init(struct ath10k *ar, struct ath10k_fw_file *fw_file)
 {
 	int ret;
 	struct ath10k_swap_code_seg_info *seg_info;
 	const void *codeswap_data;
 	size_t codeswap_len;
 
-	codeswap_data = ar->normal_mode_fw.fw_file.codeswap_data;
-	codeswap_len = ar->normal_mode_fw.fw_file.codeswap_len;
+	codeswap_data = fw_file->codeswap_data;
+	codeswap_len = fw_file->codeswap_len;
 
 	if (!codeswap_len || !codeswap_data)
 		return 0;
@@ -200,7 +202,7 @@ int ath10k_swap_code_seg_init(struct ath10k *ar)
 		return ret;
 	}
 
-	ar->swap.firmware_swap_code_seg_info = seg_info;
+	fw_file->firmware_swap_code_seg_info = seg_info;
 
 	return 0;
 }
diff --git a/drivers/net/wireless/ath/ath10k/swap.h b/drivers/net/wireless/ath/ath10k/swap.h
index 36991c7..f5dc047 100644
--- a/drivers/net/wireless/ath/ath10k/swap.h
+++ b/drivers/net/wireless/ath/ath10k/swap.h
@@ -23,6 +23,8 @@
 /* Currently only one swap segment is supported */
 #define ATH10K_SWAP_CODE_SEG_NUM_SUPPORTED	1
 
+struct ath10k_fw_file;
+
 struct ath10k_swap_code_seg_tlv {
 	__le32 address;
 	__le32 length;
@@ -58,8 +60,11 @@ struct ath10k_swap_code_seg_info {
 	dma_addr_t paddr[ATH10K_SWAP_CODE_SEG_NUM_SUPPORTED];
 };
 
-int ath10k_swap_code_seg_configure(struct ath10k *ar);
-void ath10k_swap_code_seg_release(struct ath10k *ar);
-int ath10k_swap_code_seg_init(struct ath10k *ar);
+int ath10k_swap_code_seg_configure(struct ath10k *ar,
+				   const struct ath10k_fw_file *fw_file);
+void ath10k_swap_code_seg_release(struct ath10k *ar,
+				  struct ath10k_fw_file *fw_file);
+int ath10k_swap_code_seg_init(struct ath10k *ar,
+			      struct ath10k_fw_file *fw_file);
 
 #endif
-- 
1.7.9.5



From c_traja at qti.qualcomm.com  Mon Jun 27 02:07:07 2016
From: c_traja at qti.qualcomm.com (c_traja at qti.qualcomm.com)
Date: Mon, 27 Jun 2016 14:37:07 +0530
Subject: [PATCHV2 2/3] ath10k: handle testmode events for 10.2 and 10.4 based
 firmware
Message-ID: <1467018427-24495-1-git-send-email-c_traja@qti.qualcomm.com>

From: Tamizh chelvam <c_traja at qti.qualcomm.com>

Currently testmode events for 10.x firmware are processed from
10.1 wmi event processing. This patch is used to handle testmode
events in 10.2 and 10.4 based firmware.

Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.c |   26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 6279ab4..72b5483 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5095,6 +5095,7 @@ static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, struct sk_buff *skb)
 {
 	struct wmi_cmd_hdr *cmd_hdr;
 	enum wmi_10_2_event_id id;
+	bool consumed;
 
 	cmd_hdr = (struct wmi_cmd_hdr *)skb->data;
 	id = MS(__le32_to_cpu(cmd_hdr->cmd_id), WMI_CMD_HDR_CMD_ID);
@@ -5104,6 +5105,18 @@ static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, struct sk_buff *skb)
 
 	trace_ath10k_wmi_event(ar, id, skb->data, skb->len);
 
+	consumed = ath10k_tm_event_wmi(ar, id, skb);
+
+	/* Ready event must be handled normally also in UTF mode so that we
+	 * know the UTF firmware has booted, others we are just bypass WMI
+	 * events to testmode.
+	 */
+	if (consumed && id != WMI_10_2_READY_EVENTID) {
+		ath10k_dbg(ar, ATH10K_DBG_WMI,
+			   "wmi testmode consumed 0x%x\n", id);
+		goto out;
+	}
+
 	switch (id) {
 	case WMI_10_2_MGMT_RX_EVENTID:
 		ath10k_wmi_event_mgmt_rx(ar, skb);
@@ -5219,6 +5232,7 @@ static void ath10k_wmi_10_4_op_rx(struct ath10k *ar, struct sk_buff *skb)
 {
 	struct wmi_cmd_hdr *cmd_hdr;
 	enum wmi_10_4_event_id id;
+	bool consumed;
 
 	cmd_hdr = (struct wmi_cmd_hdr *)skb->data;
 	id = MS(__le32_to_cpu(cmd_hdr->cmd_id), WMI_CMD_HDR_CMD_ID);
@@ -5228,6 +5242,18 @@ static void ath10k_wmi_10_4_op_rx(struct ath10k *ar, struct sk_buff *skb)
 
 	trace_ath10k_wmi_event(ar, id, skb->data, skb->len);
 
+	consumed = ath10k_tm_event_wmi(ar, id, skb);
+
+	/* Ready event must be handled normally also in UTF mode so that we
+	 * know the UTF firmware has booted, others we are just bypass WMI
+	 * events to testmode.
+	 */
+	if (consumed && id != WMI_10_4_READY_EVENTID) {
+		ath10k_dbg(ar, ATH10K_DBG_WMI,
+			   "wmi testmode consumed 0x%x\n", id);
+		goto out;
+	}
+
 	switch (id) {
 	case WMI_10_4_MGMT_RX_EVENTID:
 		ath10k_wmi_event_mgmt_rx(ar, skb);
-- 
1.7.9.5



From c_traja at qti.qualcomm.com  Mon Jun 27 02:07:34 2016
From: c_traja at qti.qualcomm.com (c_traja at qti.qualcomm.com)
Date: Mon, 27 Jun 2016 14:37:34 +0530
Subject: [PATCHV2 3/3] ath10k: add testmode support for 10.4 firmware
Message-ID: <1467018454-24530-1-git-send-email-c_traja@qti.qualcomm.com>

From: Tamizh chelvam <c_traja at qti.qualcomm.com>

This patch adds testmode support for QCA99X0 chipsets which uses
10.4 firmware and added code swap support for UTF binary.

Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/testmode.c |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/testmode.c b/drivers/net/wireless/ath/ath10k/testmode.c
index 120f423..2c10c0e 100644
--- a/drivers/net/wireless/ath/ath10k/testmode.c
+++ b/drivers/net/wireless/ath/ath10k/testmode.c
@@ -23,6 +23,7 @@
 #include "wmi.h"
 #include "hif.h"
 #include "hw.h"
+#include "core.h"
 
 #include "testmode_i.h"
 
@@ -240,6 +241,18 @@ static int ath10k_tm_cmd_utf_start(struct ath10k *ar, struct nlattr *tb[])
 		goto err;
 	}
 
+	if (ar->testmode.utf_mode_fw.fw_file.codeswap_data &&
+	    ar->testmode.utf_mode_fw.fw_file.codeswap_len) {
+		ret = ath10k_swap_code_seg_init(ar,
+					&ar->testmode.utf_mode_fw.fw_file);
+		if (ret) {
+			ath10k_warn(ar,
+				"failed to init utf code swap segment: %d\n",
+				ret);
+			goto err_release_utf_mode_fw;
+		}
+	}
+
 	spin_lock_bh(&ar->data_lock);
 	ar->testmode.utf_monitor = true;
 	spin_unlock_bh(&ar->data_lock);
@@ -279,6 +292,11 @@ err_power_down:
 	ath10k_hif_power_down(ar);
 
 err_release_utf_mode_fw:
+	if (ar->testmode.utf_mode_fw.fw_file.codeswap_data &&
+	    ar->testmode.utf_mode_fw.fw_file.codeswap_len)
+		ath10k_swap_code_seg_release(ar,
+					&ar->testmode.utf_mode_fw.fw_file);
+
 	release_firmware(ar->testmode.utf_mode_fw.fw_file.firmware);
 	ar->testmode.utf_mode_fw.fw_file.firmware = NULL;
 
@@ -301,6 +319,11 @@ static void __ath10k_tm_cmd_utf_stop(struct ath10k *ar)
 
 	spin_unlock_bh(&ar->data_lock);
 
+	if (ar->testmode.utf_mode_fw.fw_file.codeswap_data &&
+	    ar->testmode.utf_mode_fw.fw_file.codeswap_len)
+		ath10k_swap_code_seg_release(ar,
+					&ar->testmode.utf_mode_fw.fw_file);
+
 	release_firmware(ar->testmode.utf_mode_fw.fw_file.firmware);
 	ar->testmode.utf_mode_fw.fw_file.firmware = NULL;
 
-- 
1.7.9.5



From michal.kazior at tieto.com  Mon Jun 27 02:27:27 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 27 Jun 2016 11:27:27 +0200
Subject: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for
 QCA99X0 and later
In-Reply-To: <1466700001-4883-2-git-send-email-mohammed@qca.qualcomm.com>
References: <1466700001-4883-1-git-send-email-mohammed@qca.qualcomm.com>
 <1466700001-4883-2-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <CA+BoTQnUvF2Zy7_WuEi0V+KjByRghVmoeR6yrs6hu6ag=KmBqQ@mail.gmail.com>

On 23 June 2016 at 18:40, Mohammed Shafi Shajakhan
<mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at 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
>
> Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> ---
>  drivers/net/wireless/ath/ath10k/core.c | 3 +++
>  drivers/net/wireless/ath/ath10k/core.h | 6 ++++++
>  drivers/net/wireless/ath/ath10k/mac.c  | 1 +
>  3 files changed, 10 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> index 689d6ce..9978e4a 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -181,6 +181,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
>                         .board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
>                         .board_size = QCA99X0_BOARD_DATA_SZ,
>                         .board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> +                       .disable_null_func_workaround = true,

Tx completion (bugs) are firmware specific, not hardware. This should
be expressed via features bits in ath10k FW API, no?


Micha?


From michal.kazior at tieto.com  Mon Jun 27 04:08:22 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 27 Jun 2016 13:08:22 +0200
Subject: ath10k firmware version - 10.4
In-Reply-To: <BAY172-W4820DFFAF81043D5407B3EE02C0@phx.gbl>
References: <BAY172-W4820DFFAF81043D5407B3EE02C0@phx.gbl>
Message-ID: <CA+BoTQnyx7bFjoSBn3MFzCB+RNQ4oh1OOes+jFTsKDDG8DWMKw@mail.gmail.com>

On 22 June 2016 at 08:13, sunder Kumaresan <sunder_k at hotmail.com> wrote:
> Hello all,
[...]
> But, When boardData_AR900B_CUS239_5G_v2_001.bin  and boardData_AR900B_CUS260_2G_v2_002.bin  have been renamed as board xxx. bin files.  It shows up as mismatch in the magic number.

I'm *guessing* you've renamed these files to board-2.bin. This will
not work becuase board-2.bin is a TLV wrapper.

I don't see board-2.bin for qca99x0 in Kalle's firmware github repo.
You can try using one from
https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/tree/ath10k/QCA99X0/hw2.0


Micha?

PS. Please fix your email client. It inserts a lot of empty newlines
making it really difficult to read.


From michal.kazior at tieto.com  Mon Jun 27 04:22:49 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 27 Jun 2016 13:22:49 +0200
Subject: [RFT] mac80211: fix fq lockdep warnings
In-Reply-To: <878txzo7c6.fsf@kamboji.qca.qualcomm.com>
References: <878txzo7c6.fsf@kamboji.qca.qualcomm.com>
Message-ID: <1467026569-19329-1-git-send-email-michal.kazior@tieto.com>

Some lockdep assertions were not fulfilled and
resulted in a kernel warning/call trace.

Existing code sequences should've guranteed safety
but it's always good to be extra careful.

The call trace could look like this:

 [ 237.335805] ------------[ cut here ]------------
 [ 237.335852] WARNING: CPU: 3 PID: 1921 at include/net/fq_impl.h:22 fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.335855] Modules linked in: ath10k_pci(E-) ath10k_core(E) ath(E) mac80211(E) cfg80211(E)
 [ 237.335913] CPU: 3 PID: 1921 Comm: rmmod Tainted: G        W   E   4.7.0-rc4-wt-ath+ #1377
 [ 237.335916] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD Ver. F.04 01/27/2010
 [ 237.335918]  00200286 00200286 eff85dac c14151e2 f901574e 00000000 eff85de0 c1081075
 [ 237.335928]  c1ab91f0 00000003 00000781 f901574e 00000016 f8fbabad f8fbabad 00000016
 [ 237.335938]  eb24ff60 00000000 ef3886c0 eff85df4 c10810ba 00000009 00000000 00000000
 [ 237.335948] Call Trace:
 [ 237.335953]  [<c14151e2>] dump_stack+0x76/0xb4
 [ 237.335957]  [<c1081075>] __warn+0xe5/0x100
 [ 237.336002]  [<f8fbabad>] ? fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.336046]  [<f8fbabad>] ? fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.336053]  [<c10810ba>] warn_slowpath_null+0x2a/0x30
 [ 237.336095]  [<f8fbabad>] fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.336137]  [<f8fbc67a>] fq_flow_reset.constprop.56+0x2a/0x90 [mac80211]
 [ 237.336180]  [<f8fbc79a>] fq_reset.constprop.59+0x2a/0x50 [mac80211]
 [ 237.336222]  [<f8fc04e8>] ieee80211_txq_teardown_flows+0x38/0x40 [mac80211]
 [ 237.336258]  [<f8f7c1a4>] ieee80211_unregister_hw+0xe4/0x120 [mac80211]
 [ 237.336275]  [<f933f536>] ath10k_mac_unregister+0x16/0x50 [ath10k_core]
 [ 237.336292]  [<f934592d>] ath10k_core_unregister+0x3d/0x90 [ath10k_core]
 [ 237.336301]  [<f85f8836>] ath10k_pci_remove+0x36/0xa0 [ath10k_pci]
 [ 237.336307]  [<c1470388>] pci_device_remove+0x38/0xb0
 ...

Fixes: 5caa328e3811 ("mac80211: implement codel on fair queuing flows")
Fixes: fa962b92120b ("mac80211: implement fair queueing per txq")
Reported-by: Valo, Kalle <kvalo at qca.qualcomm.com>
Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---

Hi Kalle,

Can you verify this fixes call traces you're
seeing, please?


 net/mac80211/tx.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 44ec605a5682..1975c22132c6 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1445,7 +1445,9 @@ int ieee80211_txq_setup_flows(struct ieee80211_local *local)
 	local->cvars = kcalloc(fq->flows_cnt, sizeof(local->cvars[0]),
 			       GFP_KERNEL);
 	if (!local->cvars) {
+		spin_lock_bh(&fq->lock);
 		fq_reset(fq, fq_skb_free_func);
+		spin_unlock_bh(&fq->lock);
 		return -ENOMEM;
 	}
 
@@ -1465,7 +1467,9 @@ void ieee80211_txq_teardown_flows(struct ieee80211_local *local)
 	kfree(local->cvars);
 	local->cvars = NULL;
 
+	spin_lock_bh(&fq->lock);
 	fq_reset(fq, fq_skb_free_func);
+	spin_unlock_bh(&fq->lock);
 }
 
 struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
-- 
2.1.4



From michal.kazior at tieto.com  Mon Jun 27 04:52:22 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 27 Jun 2016 13:52:22 +0200
Subject: Cannot initialize Compex WLE600VX for 802.11ac?
In-Reply-To: <57dfus3l10n.fsf@cerise.info9.net>
References: <57dtwgmmwmr.fsf@cerise.info9.net>
 <87y45xiuts.fsf@kamboji.qca.qualcomm.com>
 <57dd1n9mks5.fsf@cerise.info9.net> <87r3bpfh94.fsf@kamboji.qca.qualcomm.com>
 <57doa6skql6.fsf@cerise.info9.net>
 <CABkMH_rZNhxHtfaD3pz0ymSjvEKGxDycjDcwxKBZFKj8j2P_Jg@mail.gmail.com>
 <57dfus3l10n.fsf@cerise.info9.net>
Message-ID: <CA+BoTQnevnhYg2aXWJWRESADJ_dkDHNg3KGjpP=0-aAjmjKcDg@mail.gmail.com>

On 24 June 2016 at 05:27, Tom Marble <tmarble at info9.net> wrote:
> Tomasz Skapski <tomasz.skapski at tieto.com> writes:
>> In your config file set 'fragm_threshold=-1', or comment it.
>
> Indeed this was the last critical configuration change...
> Now I'm able to bring up the interface!
>
> Then I was getting errors when 'ifup'-ing the interface
>   RTNETLINK answers: File exists
> which were resolved by ensuring that
> 1. The interface was flushed prior to being up'ed
>    ip addr flush dev wlan0
> 2. The interface was *not* configured to add an (additional) gateway
>
> Following this the interface would not stay up due to avahi-daemon
> decideding it didn't like something and removing the address
>   avahi-daemon[2925]: Withdrawing address record for 10.6.8.1 on wlan0.
>
> The solution here was just removing avahi-daemon (and mDNS services).
>
> Then the interface wasn't happy about IPv6
>   IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not read

This is normal. Try down/up your ethernet interface and you'll see the
same thing.


> Even with setting (in /etc/hostapd/wlan0.conf ) this problem still occurred.
>   ipaddr_type_availability=32
>
> The solution was disabling IPv6 (at least for now.. I do want IPv6
> eventually), in /etc/sysctl.conf
> # NO IPV6                                                                        net.ipv6.conf.all.disable_ipv6 = 1
> net.ipv6.conf.default.disable_ipv6 = 1
> net.ipv6.conf.lo.disable_ipv6 = 1
> net.ipv6.conf.eth0.disable_ipv6 = 1
> net.ipv6.conf.wan0.disable_ipv6 = 1

Do you really need to disable ipv6?


> I also rebuilt hostapd because it seems to have a version locked
> dependency of libssl (for some reason?).
>
> With the addition of dnsmasq (for DHCP and DNS proxying) and
> simple nftables rules for nat/masquerade I now have a functioning AP!
>
> Certain clients seemed to get "kicked off" the network which has
> been mitigated by setting:
>   ap_max_inactivity=600
>   disassoc_low_ack=0

Try using disassoc_low_ack=1 which enables station inactivity
detection up to firmware/driver (there are some bugs with sending
nullfunc frames depending on fw/hw/driver combo).


[...]
> One strange thing I've noticed is that if I configure the wlan0 (5 GHz)
> channel=52 on boot up it doesn't work... However if I have once
> done channel=0 then on subsequent bounces of the interface I can have
> it come up on a specific channel.

(haven't followed the entire thread, so sorry if I re-iterate something).

Channel availability can get messy and quirky (unless that has changed
in recent kernels?) with multiple wireless cards on the same system.
So there's that.


Michal


From michal.kazior at tieto.com  Mon Jun 27 04:57:48 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 27 Jun 2016 13:57:48 +0200
Subject: Set the primary channel in HT40 mode
In-Reply-To: <CAFc9h7vWsEyU7V4X0ehzjsmgw=a_hym0SVrF4Gay=5jJTL2VFA@mail.gmail.com>
References: <CAFc9h7vWsEyU7V4X0ehzjsmgw=a_hym0SVrF4Gay=5jJTL2VFA@mail.gmail.com>
Message-ID: <CA+BoTQ=-x_xApaiYcYF6FeoVcboc+BV61gA2JfOSdA9SitcuUw@mail.gmail.com>

On 27 June 2016 at 10:58, Gaurang Ramesh Naik <gaurang at vt.edu> wrote:
> Hi All,
>
> I have some difficulty in understanding how HT40, HT40- and HT40+
> modes work. My objective is to set a particular 20 MHz channel as the
> primary channel when channel bonding is enabled. From what I
> understand, HT40- means secondary channel is below the primary, while
> HT40+ means secondary channel is above the primary channel. I am
> particularly dealing with channels 149, 153, 157 and 161.

http://securityuncorked.com/wordpress/wp-content/uploads/2013/11/graphic-80211-acChannels-all.png


> When I set the channel to say 157, whether I use HT40+ or HT40-, the
> primary channel is always set to channel 161. I am inferring this
> because when I scan using iwlist scan, my SSID shows on Channel 161.
> Does ath10k not set the primary and secondary channel in this manner?

ath10k doesn't care. hostapd can do a channel swap if it detects OBSS.
Not sure how much OpenWRT scripts mingle in (I'm guessing you're using
`uci`, hence the mention).


> If not, is there a mechanism by which I can explicitly mention which
> channel must be primary, and which must be secondary?

You can't. OBSS can still end up swapping your primary and extension channels.


> Also, how is the
> primary channel decided for VHT80 mode?

VHT80 is backward compat for HT40 and HT20 clients. See the channel
allocation link above.


Micha?


From tmarble at info9.net  Mon Jun 27 05:42:44 2016
From: tmarble at info9.net (Tom Marble)
Date: Mon, 27 Jun 2016 07:42:44 -0500
Subject: Cannot initialize Compex WLE600VX for 802.11ac?
In-Reply-To: <CA+BoTQnevnhYg2aXWJWRESADJ_dkDHNg3KGjpP=0-aAjmjKcDg@mail.gmail.com>
References: <57dtwgmmwmr.fsf@cerise.info9.net>
 <87y45xiuts.fsf@kamboji.qca.qualcomm.com> <57dd1n9mks5.fsf@cerise.info9.net>
 <87r3bpfh94.fsf@kamboji.qca.qualcomm.com> <57doa6skql6.fsf@cerise.info9.net>
 <CABkMH_rZNhxHtfaD3pz0ymSjvEKGxDycjDcwxKBZFKj8j2P_Jg@mail.gmail.com>
 <57dfus3l10n.fsf@cerise.info9.net>
 <CA+BoTQnevnhYg2aXWJWRESADJ_dkDHNg3KGjpP=0-aAjmjKcDg@mail.gmail.com>
Message-ID: <57da8i6sszf.fsf@cerise.info9.net>

Michal Kazior <michal.kazior at tieto.com> writes:
> On 24 June 2016 at 05:27, Tom Marble <tmarble at info9.net> wrote:
>> The solution here was just removing avahi-daemon (and mDNS services).
>>
>> Then the interface wasn't happy about IPv6
>>   IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not read
>
> This is normal. Try down/up your ethernet interface and you'll see the
> same thing.

Ok.

>> Even with setting (in /etc/hostapd/wlan0.conf ) this problem still occurred.
>>   ipaddr_type_availability=32
>>
>> The solution was disabling IPv6 (at least for now.. I do want IPv6
>> eventually), in /etc/sysctl.conf
>> # NO IPV6                                                                        net.ipv6.conf.all.disable_ipv6 = 1
>> net.ipv6.conf.default.disable_ipv6 = 1
>> net.ipv6.conf.lo.disable_ipv6 = 1
>> net.ipv6.conf.eth0.disable_ipv6 = 1
>> net.ipv6.conf.wan0.disable_ipv6 = 1
>
> Do you really need to disable ipv6?

No.. I *want* IPv6! I'm going to try adding it back in now
to see if I can get it to work.

>> Certain clients seemed to get "kicked off" the network which has
>> been mitigated by setting:
>>   ap_max_inactivity=600
>>   disassoc_low_ack=0
>
> Try using disassoc_low_ack=1 which enables station inactivity
> detection up to firmware/driver (there are some bugs with sending
> nullfunc frames depending on fw/hw/driver combo).

I'll try that!

>> One strange thing I've noticed is that if I configure the wlan0 (5 GHz)
>> channel=52 on boot up it doesn't work... However if I have once
>> done channel=0 then on subsequent bounces of the interface I can have
>> it come up on a specific channel.
>
> (haven't followed the entire thread, so sorry if I re-iterate something).
>
> Channel availability can get messy and quirky (unless that has changed
> in recent kernels?) with multiple wireless cards on the same system.
> So there's that.

I realize this can be tricky. My current thought is to bring
up wlan0 (5 GHz) first and then bring up wlan1 (2.4 GHz).

I'll report my findings after my next round of tests.

Thanks!

--Tom


From kamran.nishat at gmail.com  Mon Jun 27 06:32:34 2016
From: kamran.nishat at gmail.com (Kamran Nishat)
Date: Mon, 27 Jun 2016 18:32:34 +0500
Subject: Set the primary channel in HT40 mode
In-Reply-To: <CA+BoTQ=-x_xApaiYcYF6FeoVcboc+BV61gA2JfOSdA9SitcuUw@mail.gmail.com>
References: <CAFc9h7vWsEyU7V4X0ehzjsmgw=a_hym0SVrF4Gay=5jJTL2VFA@mail.gmail.com>
 <CA+BoTQ=-x_xApaiYcYF6FeoVcboc+BV61gA2JfOSdA9SitcuUw@mail.gmail.com>
Message-ID: <CADxDmp6yZLuHwW_MGQ2VTqUx2EhCR2BRTkOPuZTorPvkwL9rUA@mail.gmail.com>

Dear Michal,
You can change in hostapd code to stop OBSS. Change function
hostapd_2040_coex_action to avoid primary change in case of OBSS.

Kamran

On Mon, Jun 27, 2016 at 4:57 PM, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 27 June 2016 at 10:58, Gaurang Ramesh Naik <gaurang at vt.edu> wrote:
>> Hi All,
>>
>> I have some difficulty in understanding how HT40, HT40- and HT40+
>> modes work. My objective is to set a particular 20 MHz channel as the
>> primary channel when channel bonding is enabled. From what I
>> understand, HT40- means secondary channel is below the primary, while
>> HT40+ means secondary channel is above the primary channel. I am
>> particularly dealing with channels 149, 153, 157 and 161.
>
> http://securityuncorked.com/wordpress/wp-content/uploads/2013/11/graphic-80211-acChannels-all.png
>
>
>> When I set the channel to say 157, whether I use HT40+ or HT40-, the
>> primary channel is always set to channel 161. I am inferring this
>> because when I scan using iwlist scan, my SSID shows on Channel 161.
>> Does ath10k not set the primary and secondary channel in this manner?
>
> ath10k doesn't care. hostapd can do a channel swap if it detects OBSS.
> Not sure how much OpenWRT scripts mingle in (I'm guessing you're using
> `uci`, hence the mention).
>
>
>> If not, is there a mechanism by which I can explicitly mention which
>> channel must be primary, and which must be secondary?
>
> You can't. OBSS can still end up swapping your primary and extension channels.
>
>
>> Also, how is the
>> primary channel decided for VHT80 mode?
>
> VHT80 is backward compat for HT40 and HT20 clients. See the channel
> allocation link above.
>
>
> Micha?
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From mohammed at codeaurora.org  Mon Jun 27 07:36:00 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Mon, 27 Jun 2016 20:06:00 +0530
Subject: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for
 QCA99X0 and later
In-Reply-To: <CA+BoTQnUvF2Zy7_WuEi0V+KjByRghVmoeR6yrs6hu6ag=KmBqQ@mail.gmail.com>
References: <1466700001-4883-1-git-send-email-mohammed@qca.qualcomm.com>
 <1466700001-4883-2-git-send-email-mohammed@qca.qualcomm.com>
 <CA+BoTQnUvF2Zy7_WuEi0V+KjByRghVmoeR6yrs6hu6ag=KmBqQ@mail.gmail.com>
Message-ID: <20160627143600.GA5292@atheros-ThinkPad-T61>

Hi Michal,

thanks for the review ..

On Mon, Jun 27, 2016 at 11:27:27AM +0200, Michal Kazior wrote:
> On 23 June 2016 at 18:40, Mohammed Shafi Shajakhan
> <mohammed at qti.qualcomm.com> wrote:
> > From: Mohammed Shafi Shajakhan <mohammed at 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
> >
> > Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>
> > Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> > ---
> >  drivers/net/wireless/ath/ath10k/core.c | 3 +++
> >  drivers/net/wireless/ath/ath10k/core.h | 6 ++++++
> >  drivers/net/wireless/ath/ath10k/mac.c  | 1 +
> >  3 files changed, 10 insertions(+)
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> > index 689d6ce..9978e4a 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.c
> > +++ b/drivers/net/wireless/ath/ath10k/core.c
> > @@ -181,6 +181,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
> >                         .board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
> >                         .board_size = QCA99X0_BOARD_DATA_SZ,
> >                         .board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> > +                       .disable_null_func_workaround = true,
> 
> Tx completion (bugs) are firmware specific, not hardware. This should
> be expressed via features bits in ath10k FW API, no?
> 
>
[shafi] Are you suggesting me to introduce something like
"ATH10K_FW_FEATURE_SUPPORTS_SKIP_CLOCK_INIT" ? Kalle any suggestions ?

Also how about getting this workaround completely if Ben had fixed this in his tree,
will this affect older 10.2.4 ?

regards,
shafi



From s.gottschall at dd-wrt.com  Mon Jun 27 15:45:41 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Tue, 28 Jun 2016 00:45:41 +0200
Subject: [PATCH] ath10k: implement NAPI support
In-Reply-To: <20160627055128.7005-1-rmanohar@qti.qualcomm.com>
References: <20160627055128.7005-1-rmanohar@qti.qualcomm.com>
Message-ID: <82ef94b8-69dd-7ff7-35ab-f865251528a4@dd-wrt.com>

broken patch

   CC [M] 
/home/seg/DEV/pb42/src/router/private/compat-wireless-2016-05-12/drivers/net/wireless/ath/ath10k/htt_tx.o
/home/seg/DEV/pb42/src/router/private/compat-wireless-2016-05-12/drivers/net/wireless/ath/ath10k/htt_tx.c: 
In function 'ath10k_htt_tx_free':
/home/seg/DEV/pb42/src/router/private/compat-wireless-2016-05-12/drivers/net/wireless/ath/ath10k/htt_tx.c:391:19: 
error: 'struct ath10k_htt' has no member named 'txrx_compl_task'

Sebastian

Am 27.06.2016 um 07:51 schrieb Rajkumar Manoharan:
> Add NAPI support for rx and tx completion. NAPI poll is scheduled
> from interrupt handler. The design is as below
>
>   - on interrupt
>       - schedule napi and mask interrupts
>   - on poll
>     - process all pipes (no actual Tx/Rx)
>     - process Rx within budget
>     - if quota exceeds budget reschedule napi poll by returning budget
>     - process Tx completions and update budget if necessary
>     - process Tx fetch indications (pull-push)
>     - push any other pending Tx (if possible)
>     - before resched or napi completion replenish htt rx ring buffer
>     - if work done < budget, complete napi poll and unmask interrupts
>
> This change also get rid of two tasklets (intr_tq and txrx_compl_task).
>
> Measured peak throughput with NAPI on IPQ4019 platform in controlled
> environment. No noticeable reduction in throughput is seen and also
> observed improvements in CPU usage. Approx. 15% CPU usage got reduced
> in UDP uplink case.
>
> DL: AP DUT Tx
> UL: AP DUT Rx
>
> IPQ4019 (avg. cpu usage %)
> ========
>                  TOT              +NAPI
>                ===========      =============
> TCP DL       644 Mbps (42%)    645 Mbps (36%)
> TCP UL       673 Mbps (30%)    675 Mbps (26%)
> UDP DL       682 Mbps (49%)    680 Mbps (49%)
> UDP UL       720 Mbps (28%)    717 Mbps (11%)
>
> Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
> ---
>   drivers/net/wireless/ath/ath10k/ahb.c    |   4 +-
>   drivers/net/wireless/ath/ath10k/core.c   |   2 +
>   drivers/net/wireless/ath/ath10k/core.h   |   8 ++
>   drivers/net/wireless/ath/ath10k/htt.h    |   2 +-
>   drivers/net/wireless/ath/ath10k/htt_rx.c | 154 +++++++++++++++++++------------
>   drivers/net/wireless/ath/ath10k/pci.c    |  67 +++++++++-----
>   drivers/net/wireless/ath/ath10k/pci.h    |   5 +-
>   7 files changed, 149 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/ahb.c b/drivers/net/wireless/ath/ath10k/ahb.c
> index acec16b9cf49..9d4d5022be18 100644
> --- a/drivers/net/wireless/ath/ath10k/ahb.c
> +++ b/drivers/net/wireless/ath/ath10k/ahb.c
> @@ -462,13 +462,11 @@ static void ath10k_ahb_halt_chip(struct ath10k *ar)
>   static irqreturn_t ath10k_ahb_interrupt_handler(int irq, void *arg)
>   {
>   	struct ath10k *ar = arg;
> -	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
>   
>   	if (!ath10k_pci_irq_pending(ar))
>   		return IRQ_NONE;
>   
>   	ath10k_pci_disable_and_clear_legacy_irq(ar);
> -	tasklet_schedule(&ar_pci->intr_tq);
>   
>   	return IRQ_HANDLED;
>   }
> @@ -831,7 +829,7 @@ static int ath10k_ahb_probe(struct platform_device *pdev)
>   		goto err_resource_deinit;
>   	}
>   
> -	ath10k_pci_init_irq_tasklets(ar);
> +	ath10k_pci_init_napi(ar);
>   
>   	ret = ath10k_ahb_request_irq_legacy(ar);
>   	if (ret)
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> index dfb3db0ee5d1..2639e7e0836b 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -2223,6 +2223,8 @@ struct ath10k *ath10k_core_create(size_t priv_size, struct device *dev,
>   	INIT_WORK(&ar->register_work, ath10k_core_register_work);
>   	INIT_WORK(&ar->restart_work, ath10k_core_restart);
>   
> +	init_dummy_netdev(&ar->napi_dev);
> +
>   	ret = ath10k_debug_create(ar);
>   	if (ret)
>   		goto err_free_aux_wq;
> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> index 3da18c9dbd7a..10878926b629 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -65,6 +65,10 @@
>   #define ATH10K_KEEPALIVE_MAX_IDLE 3895
>   #define ATH10K_KEEPALIVE_MAX_UNRESPONSIVE 3900
>   
> +/* NAPI poll budget */
> +#define ATH10K_NAPI_BUDGET      64
> +#define ATH10K_NAPI_QUOTA_LIMIT 60
> +
>   struct ath10k;
>   
>   enum ath10k_bus {
> @@ -926,6 +930,10 @@ struct ath10k {
>   	struct ath10k_thermal thermal;
>   	struct ath10k_wow wow;
>   
> +	/* NAPI */
> +	struct net_device napi_dev;
> +	struct napi_struct napi;
> +
>   	/* must be last */
>   	u8 drv_priv[0] __aligned(sizeof(void *));
>   };
> diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
> index 430a83e142aa..98c14247021b 100644
> --- a/drivers/net/wireless/ath/ath10k/htt.h
> +++ b/drivers/net/wireless/ath/ath10k/htt.h
> @@ -1665,7 +1665,6 @@ struct ath10k_htt {
>   
>   	/* This is used to group tx/rx completions separately and process them
>   	 * in batches to reduce cache stalls */
> -	struct tasklet_struct txrx_compl_task;
>   	struct sk_buff_head rx_compl_q;
>   	struct sk_buff_head rx_in_ord_compl_q;
>   	struct sk_buff_head tx_fetch_ind_q;
> @@ -1798,5 +1797,6 @@ int ath10k_htt_tx(struct ath10k_htt *htt,
>   		  struct sk_buff *msdu);
>   void ath10k_htt_rx_pktlog_completion_handler(struct ath10k *ar,
>   					     struct sk_buff *skb);
> +int ath10k_htt_txrx_compl_task(struct ath10k *ar, int budget);
>   
>   #endif
> diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
> index 80e645302b54..c68b39bfc7bb 100644
> --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
> +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
> @@ -34,7 +34,6 @@
>   #define HTT_RX_RING_REFILL_RESCHED_MS 5
>   
>   static int ath10k_htt_rx_get_csum_state(struct sk_buff *skb);
> -static void ath10k_htt_txrx_compl_task(unsigned long ptr);
>   
>   static struct sk_buff *
>   ath10k_htt_rx_find_skb_paddr(struct ath10k *ar, u32 paddr)
> @@ -226,7 +225,6 @@ int ath10k_htt_rx_ring_refill(struct ath10k *ar)
>   void ath10k_htt_rx_free(struct ath10k_htt *htt)
>   {
>   	del_timer_sync(&htt->rx_ring.refill_retry_timer);
> -	tasklet_kill(&htt->txrx_compl_task);
>   
>   	skb_queue_purge(&htt->rx_compl_q);
>   	skb_queue_purge(&htt->rx_in_ord_compl_q);
> @@ -520,9 +518,6 @@ int ath10k_htt_rx_alloc(struct ath10k_htt *htt)
>   	skb_queue_head_init(&htt->tx_fetch_ind_q);
>   	atomic_set(&htt->num_mpdus_ready, 0);
>   
> -	tasklet_init(&htt->txrx_compl_task, ath10k_htt_txrx_compl_task,
> -		     (unsigned long)htt);
> -
>   	ath10k_dbg(ar, ATH10K_DBG_BOOT, "htt rx ring size %d fill_level %d\n",
>   		   htt->rx_ring.size, htt->rx_ring.fill_level);
>   	return 0;
> @@ -958,7 +953,7 @@ static void ath10k_process_rx(struct ath10k *ar,
>   	trace_ath10k_rx_hdr(ar, skb->data, skb->len);
>   	trace_ath10k_rx_payload(ar, skb->data, skb->len);
>   
> -	ieee80211_rx(ar->hw, skb);
> +	ieee80211_rx_napi(ar->hw, NULL, skb, &ar->napi);
>   }
>   
>   static int ath10k_htt_rx_nwifi_hdrlen(struct ath10k *ar,
> @@ -1527,7 +1522,7 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
>   	struct ath10k *ar = htt->ar;
>   	static struct ieee80211_rx_status rx_status;
>   	struct sk_buff_head amsdu;
> -	int ret;
> +	int ret, num_msdus;
>   
>   	__skb_queue_head_init(&amsdu);
>   
> @@ -1549,13 +1544,14 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
>   		return ret;
>   	}
>   
> +	num_msdus = skb_queue_len(&amsdu);
>   	ath10k_htt_rx_h_ppdu(ar, &amsdu, &rx_status, 0xffff);
>   	ath10k_htt_rx_h_unchain(ar, &amsdu, ret > 0);
>   	ath10k_htt_rx_h_filter(ar, &amsdu, &rx_status);
>   	ath10k_htt_rx_h_mpdu(ar, &amsdu, &rx_status);
>   	ath10k_htt_rx_h_deliver(ar, &amsdu, &rx_status);
>   
> -	return 0;
> +	return num_msdus;
>   }
>   
>   static void ath10k_htt_rx_proc_rx_ind(struct ath10k_htt *htt,
> @@ -1579,15 +1575,6 @@ static void ath10k_htt_rx_proc_rx_ind(struct ath10k_htt *htt,
>   		mpdu_count += mpdu_ranges[i].mpdu_count;
>   
>   	atomic_add(mpdu_count, &htt->num_mpdus_ready);
> -
> -	tasklet_schedule(&htt->txrx_compl_task);
> -}
> -
> -static void ath10k_htt_rx_frag_handler(struct ath10k_htt *htt)
> -{
> -	atomic_inc(&htt->num_mpdus_ready);
> -
> -	tasklet_schedule(&htt->txrx_compl_task);
>   }
>   
>   static void ath10k_htt_rx_tx_compl_ind(struct ath10k *ar,
> @@ -1772,14 +1759,15 @@ static void ath10k_htt_rx_h_rx_offload_prot(struct ieee80211_rx_status *status,
>   			RX_FLAG_MMIC_STRIPPED;
>   }
>   
> -static void ath10k_htt_rx_h_rx_offload(struct ath10k *ar,
> -				       struct sk_buff_head *list)
> +static int ath10k_htt_rx_h_rx_offload(struct ath10k *ar,
> +				      struct sk_buff_head *list)
>   {
>   	struct ath10k_htt *htt = &ar->htt;
>   	struct ieee80211_rx_status *status = &htt->rx_status;
>   	struct htt_rx_offload_msdu *rx;
>   	struct sk_buff *msdu;
>   	size_t offset;
> +	int num_msdu = 0;
>   
>   	while ((msdu = __skb_dequeue(list))) {
>   		/* Offloaded frames don't have Rx descriptor. Instead they have
> @@ -1819,10 +1807,12 @@ static void ath10k_htt_rx_h_rx_offload(struct ath10k *ar,
>   		ath10k_htt_rx_h_rx_offload_prot(status, msdu);
>   		ath10k_htt_rx_h_channel(ar, status, NULL, rx->vdev_id);
>   		ath10k_process_rx(ar, status, msdu);
> +		num_msdu++;
>   	}
> +	return num_msdu;
>   }
>   
> -static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
> +static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
>   {
>   	struct ath10k_htt *htt = &ar->htt;
>   	struct htt_resp *resp = (void *)skb->data;
> @@ -1835,12 +1825,12 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
>   	u8 tid;
>   	bool offload;
>   	bool frag;
> -	int ret;
> +	int ret, num_msdus = 0;
>   
>   	lockdep_assert_held(&htt->rx_ring.lock);
>   
>   	if (htt->rx_confused)
> -		return;
> +		return -EIO;
>   
>   	skb_pull(skb, sizeof(resp->hdr));
>   	skb_pull(skb, sizeof(resp->rx_in_ord_ind));
> @@ -1859,7 +1849,7 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
>   
>   	if (skb->len < msdu_count * sizeof(*resp->rx_in_ord_ind.msdu_descs)) {
>   		ath10k_warn(ar, "dropping invalid in order rx indication\n");
> -		return;
> +		return -EINVAL;
>   	}
>   
>   	/* The event can deliver more than 1 A-MSDU. Each A-MSDU is later
> @@ -1870,14 +1860,14 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
>   	if (ret < 0) {
>   		ath10k_warn(ar, "failed to pop paddr list: %d\n", ret);
>   		htt->rx_confused = true;
> -		return;
> +		return -EIO;
>   	}
>   
>   	/* Offloaded frames are very different and need to be handled
>   	 * separately.
>   	 */
>   	if (offload)
> -		ath10k_htt_rx_h_rx_offload(ar, &list);
> +		num_msdus = ath10k_htt_rx_h_rx_offload(ar, &list);
>   
>   	while (!skb_queue_empty(&list)) {
>   		__skb_queue_head_init(&amsdu);
> @@ -1890,6 +1880,7 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
>   			 * better to report something than nothing though. This
>   			 * should still give an idea about rx rate to the user.
>   			 */
> +			num_msdus += skb_queue_len(&amsdu);
>   			ath10k_htt_rx_h_ppdu(ar, &amsdu, status, vdev_id);
>   			ath10k_htt_rx_h_filter(ar, &amsdu, status);
>   			ath10k_htt_rx_h_mpdu(ar, &amsdu, status);
> @@ -1902,9 +1893,10 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
>   			ath10k_warn(ar, "failed to extract amsdu: %d\n", ret);
>   			htt->rx_confused = true;
>   			__skb_queue_purge(&list);
> -			return;
> +			return -EIO;
>   		}
>   	}
> +	return num_msdus;
>   }
>   
>   static void ath10k_htt_rx_tx_fetch_resp_id_confirm(struct ath10k *ar,
> @@ -2267,7 +2259,6 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
>   	}
>   	case HTT_T2H_MSG_TYPE_TX_COMPL_IND:
>   		ath10k_htt_rx_tx_compl_ind(htt->ar, skb);
> -		tasklet_schedule(&htt->txrx_compl_task);
>   		break;
>   	case HTT_T2H_MSG_TYPE_SEC_IND: {
>   		struct ath10k *ar = htt->ar;
> @@ -2284,7 +2275,7 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
>   	case HTT_T2H_MSG_TYPE_RX_FRAG_IND: {
>   		ath10k_dbg_dump(ar, ATH10K_DBG_HTT_DUMP, NULL, "htt event: ",
>   				skb->data, skb->len);
> -		ath10k_htt_rx_frag_handler(htt);
> +		atomic_inc(&htt->num_mpdus_ready);
>   		break;
>   	}
>   	case HTT_T2H_MSG_TYPE_TEST:
> @@ -2322,8 +2313,7 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
>   		break;
>   	}
>   	case HTT_T2H_MSG_TYPE_RX_IN_ORD_PADDR_IND: {
> -		skb_queue_tail(&htt->rx_in_ord_compl_q, skb);
> -		tasklet_schedule(&htt->txrx_compl_task);
> +		__skb_queue_tail(&htt->rx_in_ord_compl_q, skb);
>   		return false;
>   	}
>   	case HTT_T2H_MSG_TYPE_TX_CREDIT_UPDATE_IND:
> @@ -2349,7 +2339,6 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
>   			break;
>   		}
>   		skb_queue_tail(&htt->tx_fetch_ind_q, tx_fetch_ind);
> -		tasklet_schedule(&htt->txrx_compl_task);
>   		break;
>   	}
>   	case HTT_T2H_MSG_TYPE_TX_FETCH_CONFIRM:
> @@ -2378,27 +2367,77 @@ void ath10k_htt_rx_pktlog_completion_handler(struct ath10k *ar,
>   }
>   EXPORT_SYMBOL(ath10k_htt_rx_pktlog_completion_handler);
>   
> -static void ath10k_htt_txrx_compl_task(unsigned long ptr)
> +int ath10k_htt_txrx_compl_task(struct ath10k *ar, int budget)
>   {
> -	struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
> -	struct ath10k *ar = htt->ar;
> +	struct ath10k_htt *htt = &ar->htt;
>   	struct htt_tx_done tx_done = {};
> -	struct sk_buff_head rx_ind_q;
>   	struct sk_buff_head tx_ind_q;
>   	struct sk_buff *skb;
>   	unsigned long flags;
> -	int num_mpdus;
> +	int quota = 0, done, num_rx_msdus;
> +	bool resched_napi = false;
>   
> -	__skb_queue_head_init(&rx_ind_q);
>   	__skb_queue_head_init(&tx_ind_q);
>   
> -	spin_lock_irqsave(&htt->rx_in_ord_compl_q.lock, flags);
> -	skb_queue_splice_init(&htt->rx_in_ord_compl_q, &rx_ind_q);
> -	spin_unlock_irqrestore(&htt->rx_in_ord_compl_q.lock, flags);
> +	/* Since in-ord-ind can deliver more than 1 A-MSDU in single event,
> +	 * process it first to utilize full available quota.
> +	 */
> +	while (quota < budget) {
> +		if (skb_queue_empty(&htt->rx_in_ord_compl_q))
> +			break;
>   
> -	spin_lock_irqsave(&htt->tx_fetch_ind_q.lock, flags);
> -	skb_queue_splice_init(&htt->tx_fetch_ind_q, &tx_ind_q);
> -	spin_unlock_irqrestore(&htt->tx_fetch_ind_q.lock, flags);
> +		skb = __skb_dequeue(&htt->rx_in_ord_compl_q);
> +		if (!skb) {
> +			resched_napi = true;
> +			goto exit;
> +		}
> +
> +		spin_lock_bh(&htt->rx_ring.lock);
> +		num_rx_msdus = ath10k_htt_rx_in_ord_ind(ar, skb);
> +		spin_unlock_bh(&htt->rx_ring.lock);
> +		if (num_rx_msdus < 0) {
> +			resched_napi = true;
> +			goto exit;
> +		}
> +
> +		dev_kfree_skb_any(skb);
> +		if (num_rx_msdus > 0)
> +			quota += num_rx_msdus;
> +
> +		if ((quota > ATH10K_NAPI_QUOTA_LIMIT) &&
> +		    !skb_queue_empty(&htt->rx_in_ord_compl_q)) {
> +			resched_napi = true;
> +			goto exit;
> +		}
> +	}
> +
> +	while (quota < budget) {
> +		/* no more data to receive */
> +		if (!atomic_read(&htt->num_mpdus_ready))
> +			break;
> +
> +		num_rx_msdus = ath10k_htt_rx_handle_amsdu(htt);
> +		if (num_rx_msdus < 0) {
> +			resched_napi = true;
> +			goto exit;
> +		}
> +
> +		quota += num_rx_msdus;
> +		atomic_dec(&htt->num_mpdus_ready);
> +		if ((quota > ATH10K_NAPI_QUOTA_LIMIT) &&
> +		    atomic_read(&htt->num_mpdus_ready)) {
> +			resched_napi = true;
> +			goto exit;
> +		}
> +	}
> +
> +	/* From NAPI documentation:
> +	 *  The napi poll() function may also process TX completions, in which
> +	 *  case if it processes the entire TX ring then it should count that
> +	 *  work as the rest of the budget.
> +	 */
> +	if ((quota < budget) && !kfifo_is_empty(&htt->txdone_fifo))
> +		quota = budget;
>   
>   	/* kfifo_get: called only within txrx_tasklet so it's neatly serialized.
>   	 * From kfifo_get() documentation:
> @@ -2408,27 +2447,22 @@ static void ath10k_htt_txrx_compl_task(unsigned long ptr)
>   	while (kfifo_get(&htt->txdone_fifo, &tx_done))
>   		ath10k_txrx_tx_unref(htt, &tx_done);
>   
> +	spin_lock_irqsave(&htt->tx_fetch_ind_q.lock, flags);
> +	skb_queue_splice_init(&htt->tx_fetch_ind_q, &tx_ind_q);
> +	spin_unlock_irqrestore(&htt->tx_fetch_ind_q.lock, flags);
> +
>   	while ((skb = __skb_dequeue(&tx_ind_q))) {
>   		ath10k_htt_rx_tx_fetch_ind(ar, skb);
>   		dev_kfree_skb_any(skb);
>   	}
>   
> -	num_mpdus = atomic_read(&htt->num_mpdus_ready);
> -
> -	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))) {
> -		spin_lock_bh(&htt->rx_ring.lock);
> -		ath10k_htt_rx_in_ord_ind(ar, skb);
> -		spin_unlock_bh(&htt->rx_ring.lock);
> -		dev_kfree_skb_any(skb);
> -	}
> -
> +exit:
>   	ath10k_htt_rx_msdu_buff_replenish(htt);
> +	/* In case of rx failure or more data to read, report budget
> +	 * to reschedule NAPI poll
> +	 */
> +	done = resched_napi ? budget : quota;
> +
> +	return done;
>   }
> +EXPORT_SYMBOL(ath10k_htt_txrx_compl_task);
> diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
> index f06dd3941bac..9169ab92a16a 100644
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -1502,12 +1502,10 @@ void ath10k_pci_hif_send_complete_check(struct ath10k *ar, u8 pipe,
>   	ath10k_ce_per_engine_service(ar, pipe);
>   }
>   
> -void ath10k_pci_kill_tasklet(struct ath10k *ar)
> +static void ath10k_pci_rx_retry_sync(struct ath10k *ar)
>   {
>   	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
>   
> -	tasklet_kill(&ar_pci->intr_tq);
> -
>   	del_timer_sync(&ar_pci->rx_post_retry);
>   }
>   
> @@ -1747,7 +1745,7 @@ void ath10k_pci_ce_deinit(struct ath10k *ar)
>   
>   void ath10k_pci_flush(struct ath10k *ar)
>   {
> -	ath10k_pci_kill_tasklet(ar);
> +	ath10k_pci_rx_retry_sync(ar);
>   	ath10k_pci_buffer_cleanup(ar);
>   }
>   
> @@ -2754,35 +2752,53 @@ static irqreturn_t ath10k_pci_interrupt_handler(int irq, void *arg)
>   		return IRQ_NONE;
>   	}
>   
> -	if (ar_pci->oper_irq_mode == ATH10K_PCI_IRQ_LEGACY) {
> -		if (!ath10k_pci_irq_pending(ar))
> -			return IRQ_NONE;
> -
> -		ath10k_pci_disable_and_clear_legacy_irq(ar);
> -	}
> +	if ((ar_pci->oper_irq_mode == ATH10K_PCI_IRQ_LEGACY) &&
> +	    !ath10k_pci_irq_pending(ar))
> +		return IRQ_NONE;
>   
> -	tasklet_schedule(&ar_pci->intr_tq);
> +	ath10k_pci_disable_and_clear_legacy_irq(ar);
> +	ath10k_pci_irq_msi_fw_mask(ar);
> +	napi_schedule(&ar->napi);
>   
>   	return IRQ_HANDLED;
>   }
>   
> -static void ath10k_pci_tasklet(unsigned long data)
> +static int ath10k_pci_napi_poll(struct napi_struct *ctx, int budget)
>   {
> -	struct ath10k *ar = (struct ath10k *)data;
> -	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
> +	struct ath10k *ar = container_of(ctx, struct ath10k, napi);
> +	int done = 0;
>   
>   	if (ath10k_pci_has_fw_crashed(ar)) {
> -		ath10k_pci_irq_disable(ar);
>   		ath10k_pci_fw_crashed_clear(ar);
>   		ath10k_pci_fw_crashed_dump(ar);
> -		return;
> +		napi_complete(ctx);
> +		return done;
>   	}
>   
>   	ath10k_ce_per_engine_service_any(ar);
>   
> -	/* Re-enable legacy irq that was disabled in the irq handler */
> -	if (ar_pci->oper_irq_mode == ATH10K_PCI_IRQ_LEGACY)
> +	done = ath10k_htt_txrx_compl_task(ar, budget);
> +
> +	if (done < budget) {
> +		napi_complete(ctx);
> +		/* In case of MSI, it is possible that interrupts are received
> +		 * while NAPI poll is inprogress. So pending interrupts that are
> +		 * received after processing all copy engine pipes by NAPI poll
> +		 * will not be handled again. This is causing failure to
> +		 * complete boot sequence in x86 platform. So before enabling
> +		 * interrupts safer to check for pending interrupts for
> +		 * immediate servicing.
> +		 */
> +		if (CE_INTERRUPT_SUMMARY(ar)) {
> +			napi_reschedule(&ar->napi);
> +			goto out;
> +		}
>   		ath10k_pci_enable_legacy_irq(ar);
> +		ath10k_pci_irq_msi_fw_unmask(ar);
> +	}
> +
> +out:
> +	return done;
>   }
>   
>   static int ath10k_pci_request_irq_msi(struct ath10k *ar)
> @@ -2840,11 +2856,11 @@ static void ath10k_pci_free_irq(struct ath10k *ar)
>   	free_irq(ar_pci->pdev->irq, ar);
>   }
>   
> -void ath10k_pci_init_irq_tasklets(struct ath10k *ar)
> +void ath10k_pci_init_napi(struct ath10k *ar)
>   {
> -	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
> -
> -	tasklet_init(&ar_pci->intr_tq, ath10k_pci_tasklet, (unsigned long)ar);
> +	netif_napi_add(&ar->napi_dev, &ar->napi, ath10k_pci_napi_poll,
> +		       ATH10K_NAPI_BUDGET);
> +	napi_enable(&ar->napi);
>   }
>   
>   static int ath10k_pci_init_irq(struct ath10k *ar)
> @@ -2852,7 +2868,7 @@ static int ath10k_pci_init_irq(struct ath10k *ar)
>   	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
>   	int ret;
>   
> -	ath10k_pci_init_irq_tasklets(ar);
> +	ath10k_pci_init_napi(ar);
>   
>   	if (ath10k_pci_irq_mode != ATH10K_PCI_IRQ_AUTO)
>   		ath10k_info(ar, "limiting irq mode to: %d\n",
> @@ -3113,7 +3129,8 @@ int ath10k_pci_setup_resource(struct ath10k *ar)
>   
>   void ath10k_pci_release_resource(struct ath10k *ar)
>   {
> -	ath10k_pci_kill_tasklet(ar);
> +	ath10k_pci_rx_retry_sync(ar);
> +	netif_napi_del(&ar->napi);
>   	ath10k_pci_ce_deinit(ar);
>   	ath10k_pci_free_pipes(ar);
>   }
> @@ -3274,7 +3291,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
>   
>   err_free_irq:
>   	ath10k_pci_free_irq(ar);
> -	ath10k_pci_kill_tasklet(ar);
> +	ath10k_pci_rx_retry_sync(ar);
>   
>   err_deinit_irq:
>   	ath10k_pci_deinit_irq(ar);
> diff --git a/drivers/net/wireless/ath/ath10k/pci.h b/drivers/net/wireless/ath/ath10k/pci.h
> index 6eca1df2ce60..974e463e8b95 100644
> --- a/drivers/net/wireless/ath/ath10k/pci.h
> +++ b/drivers/net/wireless/ath/ath10k/pci.h
> @@ -177,8 +177,6 @@ struct ath10k_pci {
>   	/* Operating interrupt mode */
>   	enum ath10k_pci_irq_mode oper_irq_mode;
>   
> -	struct tasklet_struct intr_tq;
> -
>   	struct ath10k_pci_pipe pipe_info[CE_COUNT_MAX];
>   
>   	/* Copy Engine used for Diagnostic Accesses */
> @@ -294,8 +292,7 @@ void ath10k_pci_free_pipes(struct ath10k *ar);
>   void ath10k_pci_free_pipes(struct ath10k *ar);
>   void ath10k_pci_rx_replenish_retry(unsigned long ptr);
>   void ath10k_pci_ce_deinit(struct ath10k *ar);
> -void ath10k_pci_init_irq_tasklets(struct ath10k *ar);
> -void ath10k_pci_kill_tasklet(struct ath10k *ar);
> +void ath10k_pci_init_napi(struct ath10k *ar);
>   int ath10k_pci_init_pipes(struct ath10k *ar);
>   int ath10k_pci_init_config(struct ath10k *ar);
>   void ath10k_pci_rx_post(struct ath10k *ar);


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From s.gottschall at dd-wrt.com  Mon Jun 27 15:51:53 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Tue, 28 Jun 2016 00:51:53 +0200
Subject: [PATCH] ath10k: implement NAPI support
In-Reply-To: <82ef94b8-69dd-7ff7-35ab-f865251528a4@dd-wrt.com>
References: <20160627055128.7005-1-rmanohar@qti.qualcomm.com>
 <82ef94b8-69dd-7ff7-35ab-f865251528a4@dd-wrt.com>
Message-ID: <7a397cf9-07ec-4f7f-5040-c41752b6cf51@dd-wrt.com>

forget about it. it was caused by another patch here on this list.

Am 28.06.2016 um 00:45 schrieb Sebastian Gottschall:
> broken patch
>
>   CC [M] 
> /home/seg/DEV/pb42/src/router/private/compat-wireless-2016-05-12/drivers/net/wireless/ath/ath10k/htt_tx.o
> /home/seg/DEV/pb42/src/router/private/compat-wireless-2016-05-12/drivers/net/wireless/ath/ath10k/htt_tx.c: 
> In function 'ath10k_htt_tx_free':
> /home/seg/DEV/pb42/src/router/private/compat-wireless-2016-05-12/drivers/net/wireless/ath/ath10k/htt_tx.c:391:19: 
> error: 'struct ath10k_htt' has no member named 'txrx_compl_task'
>
> Sebastian
>
> Am 27.06.2016 um 07:51 schrieb Rajkumar Manoharan:
>> Add NAPI support for rx and tx completion. NAPI poll is scheduled
>> from interrupt handler. The design is as below
>>
>>   - on interrupt
>>       - schedule napi and mask interrupts
>>   - on poll
>>     - process all pipes (no actual Tx/Rx)
>>     - process Rx within budget
>>     - if quota exceeds budget reschedule napi poll by returning budget
>>     - process Tx completions and update budget if necessary
>>     - process Tx fetch indications (pull-push)
>>     - push any other pending Tx (if possible)
>>     - before resched or napi completion replenish htt rx ring buffer
>>     - if work done < budget, complete napi poll and unmask interrupts
>>
>> This change also get rid of two tasklets (intr_tq and txrx_compl_task).
>>
>> Measured peak throughput with NAPI on IPQ4019 platform in controlled
>> environment. No noticeable reduction in throughput is seen and also
>> observed improvements in CPU usage. Approx. 15% CPU usage got reduced
>> in UDP uplink case.
>>
>> DL: AP DUT Tx
>> UL: AP DUT Rx
>>
>> IPQ4019 (avg. cpu usage %)
>> ========
>>                  TOT              +NAPI
>>                ===========      =============
>> TCP DL       644 Mbps (42%)    645 Mbps (36%)
>> TCP UL       673 Mbps (30%)    675 Mbps (26%)
>> UDP DL       682 Mbps (49%)    680 Mbps (49%)
>> UDP UL       720 Mbps (28%)    717 Mbps (11%)
>>
>> Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
>> ---
>>   drivers/net/wireless/ath/ath10k/ahb.c    |   4 +-
>>   drivers/net/wireless/ath/ath10k/core.c   |   2 +
>>   drivers/net/wireless/ath/ath10k/core.h   |   8 ++
>>   drivers/net/wireless/ath/ath10k/htt.h    |   2 +-
>>   drivers/net/wireless/ath/ath10k/htt_rx.c | 154 
>> +++++++++++++++++++------------
>>   drivers/net/wireless/ath/ath10k/pci.c    |  67 +++++++++-----
>>   drivers/net/wireless/ath/ath10k/pci.h    |   5 +-
>>   7 files changed, 149 insertions(+), 93 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/ahb.c 
>> b/drivers/net/wireless/ath/ath10k/ahb.c
>> index acec16b9cf49..9d4d5022be18 100644
>> --- a/drivers/net/wireless/ath/ath10k/ahb.c
>> +++ b/drivers/net/wireless/ath/ath10k/ahb.c
>> @@ -462,13 +462,11 @@ static void ath10k_ahb_halt_chip(struct ath10k 
>> *ar)
>>   static irqreturn_t ath10k_ahb_interrupt_handler(int irq, void *arg)
>>   {
>>       struct ath10k *ar = arg;
>> -    struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
>>         if (!ath10k_pci_irq_pending(ar))
>>           return IRQ_NONE;
>>         ath10k_pci_disable_and_clear_legacy_irq(ar);
>> -    tasklet_schedule(&ar_pci->intr_tq);
>>         return IRQ_HANDLED;
>>   }
>> @@ -831,7 +829,7 @@ static int ath10k_ahb_probe(struct 
>> platform_device *pdev)
>>           goto err_resource_deinit;
>>       }
>>   -    ath10k_pci_init_irq_tasklets(ar);
>> +    ath10k_pci_init_napi(ar);
>>         ret = ath10k_ahb_request_irq_legacy(ar);
>>       if (ret)
>> diff --git a/drivers/net/wireless/ath/ath10k/core.c 
>> b/drivers/net/wireless/ath/ath10k/core.c
>> index dfb3db0ee5d1..2639e7e0836b 100644
>> --- a/drivers/net/wireless/ath/ath10k/core.c
>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>> @@ -2223,6 +2223,8 @@ struct ath10k *ath10k_core_create(size_t 
>> priv_size, struct device *dev,
>>       INIT_WORK(&ar->register_work, ath10k_core_register_work);
>>       INIT_WORK(&ar->restart_work, ath10k_core_restart);
>>   +    init_dummy_netdev(&ar->napi_dev);
>> +
>>       ret = ath10k_debug_create(ar);
>>       if (ret)
>>           goto err_free_aux_wq;
>> diff --git a/drivers/net/wireless/ath/ath10k/core.h 
>> b/drivers/net/wireless/ath/ath10k/core.h
>> index 3da18c9dbd7a..10878926b629 100644
>> --- a/drivers/net/wireless/ath/ath10k/core.h
>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>> @@ -65,6 +65,10 @@
>>   #define ATH10K_KEEPALIVE_MAX_IDLE 3895
>>   #define ATH10K_KEEPALIVE_MAX_UNRESPONSIVE 3900
>>   +/* NAPI poll budget */
>> +#define ATH10K_NAPI_BUDGET      64
>> +#define ATH10K_NAPI_QUOTA_LIMIT 60
>> +
>>   struct ath10k;
>>     enum ath10k_bus {
>> @@ -926,6 +930,10 @@ struct ath10k {
>>       struct ath10k_thermal thermal;
>>       struct ath10k_wow wow;
>>   +    /* NAPI */
>> +    struct net_device napi_dev;
>> +    struct napi_struct napi;
>> +
>>       /* must be last */
>>       u8 drv_priv[0] __aligned(sizeof(void *));
>>   };
>> diff --git a/drivers/net/wireless/ath/ath10k/htt.h 
>> b/drivers/net/wireless/ath/ath10k/htt.h
>> index 430a83e142aa..98c14247021b 100644
>> --- a/drivers/net/wireless/ath/ath10k/htt.h
>> +++ b/drivers/net/wireless/ath/ath10k/htt.h
>> @@ -1665,7 +1665,6 @@ struct ath10k_htt {
>>         /* This is used to group tx/rx completions separately and 
>> process them
>>        * in batches to reduce cache stalls */
>> -    struct tasklet_struct txrx_compl_task;
>>       struct sk_buff_head rx_compl_q;
>>       struct sk_buff_head rx_in_ord_compl_q;
>>       struct sk_buff_head tx_fetch_ind_q;
>> @@ -1798,5 +1797,6 @@ int ath10k_htt_tx(struct ath10k_htt *htt,
>>             struct sk_buff *msdu);
>>   void ath10k_htt_rx_pktlog_completion_handler(struct ath10k *ar,
>>                            struct sk_buff *skb);
>> +int ath10k_htt_txrx_compl_task(struct ath10k *ar, int budget);
>>     #endif
>> diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
>> b/drivers/net/wireless/ath/ath10k/htt_rx.c
>> index 80e645302b54..c68b39bfc7bb 100644
>> --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
>> +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
>> @@ -34,7 +34,6 @@
>>   #define HTT_RX_RING_REFILL_RESCHED_MS 5
>>     static int ath10k_htt_rx_get_csum_state(struct sk_buff *skb);
>> -static void ath10k_htt_txrx_compl_task(unsigned long ptr);
>>     static struct sk_buff *
>>   ath10k_htt_rx_find_skb_paddr(struct ath10k *ar, u32 paddr)
>> @@ -226,7 +225,6 @@ int ath10k_htt_rx_ring_refill(struct ath10k *ar)
>>   void ath10k_htt_rx_free(struct ath10k_htt *htt)
>>   {
>>       del_timer_sync(&htt->rx_ring.refill_retry_timer);
>> -    tasklet_kill(&htt->txrx_compl_task);
>>         skb_queue_purge(&htt->rx_compl_q);
>>       skb_queue_purge(&htt->rx_in_ord_compl_q);
>> @@ -520,9 +518,6 @@ int ath10k_htt_rx_alloc(struct ath10k_htt *htt)
>>       skb_queue_head_init(&htt->tx_fetch_ind_q);
>>       atomic_set(&htt->num_mpdus_ready, 0);
>>   -    tasklet_init(&htt->txrx_compl_task, ath10k_htt_txrx_compl_task,
>> -             (unsigned long)htt);
>> -
>>       ath10k_dbg(ar, ATH10K_DBG_BOOT, "htt rx ring size %d fill_level 
>> %d\n",
>>              htt->rx_ring.size, htt->rx_ring.fill_level);
>>       return 0;
>> @@ -958,7 +953,7 @@ static void ath10k_process_rx(struct ath10k *ar,
>>       trace_ath10k_rx_hdr(ar, skb->data, skb->len);
>>       trace_ath10k_rx_payload(ar, skb->data, skb->len);
>>   -    ieee80211_rx(ar->hw, skb);
>> +    ieee80211_rx_napi(ar->hw, NULL, skb, &ar->napi);
>>   }
>>     static int ath10k_htt_rx_nwifi_hdrlen(struct ath10k *ar,
>> @@ -1527,7 +1522,7 @@ static int ath10k_htt_rx_handle_amsdu(struct 
>> ath10k_htt *htt)
>>       struct ath10k *ar = htt->ar;
>>       static struct ieee80211_rx_status rx_status;
>>       struct sk_buff_head amsdu;
>> -    int ret;
>> +    int ret, num_msdus;
>>         __skb_queue_head_init(&amsdu);
>>   @@ -1549,13 +1544,14 @@ static int 
>> ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
>>           return ret;
>>       }
>>   +    num_msdus = skb_queue_len(&amsdu);
>>       ath10k_htt_rx_h_ppdu(ar, &amsdu, &rx_status, 0xffff);
>>       ath10k_htt_rx_h_unchain(ar, &amsdu, ret > 0);
>>       ath10k_htt_rx_h_filter(ar, &amsdu, &rx_status);
>>       ath10k_htt_rx_h_mpdu(ar, &amsdu, &rx_status);
>>       ath10k_htt_rx_h_deliver(ar, &amsdu, &rx_status);
>>   -    return 0;
>> +    return num_msdus;
>>   }
>>     static void ath10k_htt_rx_proc_rx_ind(struct ath10k_htt *htt,
>> @@ -1579,15 +1575,6 @@ static void ath10k_htt_rx_proc_rx_ind(struct 
>> ath10k_htt *htt,
>>           mpdu_count += mpdu_ranges[i].mpdu_count;
>>         atomic_add(mpdu_count, &htt->num_mpdus_ready);
>> -
>> -    tasklet_schedule(&htt->txrx_compl_task);
>> -}
>> -
>> -static void ath10k_htt_rx_frag_handler(struct ath10k_htt *htt)
>> -{
>> -    atomic_inc(&htt->num_mpdus_ready);
>> -
>> -    tasklet_schedule(&htt->txrx_compl_task);
>>   }
>>     static void ath10k_htt_rx_tx_compl_ind(struct ath10k *ar,
>> @@ -1772,14 +1759,15 @@ static void 
>> ath10k_htt_rx_h_rx_offload_prot(struct ieee80211_rx_status *status,
>>               RX_FLAG_MMIC_STRIPPED;
>>   }
>>   -static void ath10k_htt_rx_h_rx_offload(struct ath10k *ar,
>> -                       struct sk_buff_head *list)
>> +static int ath10k_htt_rx_h_rx_offload(struct ath10k *ar,
>> +                      struct sk_buff_head *list)
>>   {
>>       struct ath10k_htt *htt = &ar->htt;
>>       struct ieee80211_rx_status *status = &htt->rx_status;
>>       struct htt_rx_offload_msdu *rx;
>>       struct sk_buff *msdu;
>>       size_t offset;
>> +    int num_msdu = 0;
>>         while ((msdu = __skb_dequeue(list))) {
>>           /* Offloaded frames don't have Rx descriptor. Instead they 
>> have
>> @@ -1819,10 +1807,12 @@ static void ath10k_htt_rx_h_rx_offload(struct 
>> ath10k *ar,
>>           ath10k_htt_rx_h_rx_offload_prot(status, msdu);
>>           ath10k_htt_rx_h_channel(ar, status, NULL, rx->vdev_id);
>>           ath10k_process_rx(ar, status, msdu);
>> +        num_msdu++;
>>       }
>> +    return num_msdu;
>>   }
>>   -static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct 
>> sk_buff *skb)
>> +static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct 
>> sk_buff *skb)
>>   {
>>       struct ath10k_htt *htt = &ar->htt;
>>       struct htt_resp *resp = (void *)skb->data;
>> @@ -1835,12 +1825,12 @@ static void ath10k_htt_rx_in_ord_ind(struct 
>> ath10k *ar, struct sk_buff *skb)
>>       u8 tid;
>>       bool offload;
>>       bool frag;
>> -    int ret;
>> +    int ret, num_msdus = 0;
>>         lockdep_assert_held(&htt->rx_ring.lock);
>>         if (htt->rx_confused)
>> -        return;
>> +        return -EIO;
>>         skb_pull(skb, sizeof(resp->hdr));
>>       skb_pull(skb, sizeof(resp->rx_in_ord_ind));
>> @@ -1859,7 +1849,7 @@ static void ath10k_htt_rx_in_ord_ind(struct 
>> ath10k *ar, struct sk_buff *skb)
>>         if (skb->len < msdu_count * 
>> sizeof(*resp->rx_in_ord_ind.msdu_descs)) {
>>           ath10k_warn(ar, "dropping invalid in order rx indication\n");
>> -        return;
>> +        return -EINVAL;
>>       }
>>         /* The event can deliver more than 1 A-MSDU. Each A-MSDU is 
>> later
>> @@ -1870,14 +1860,14 @@ static void ath10k_htt_rx_in_ord_ind(struct 
>> ath10k *ar, struct sk_buff *skb)
>>       if (ret < 0) {
>>           ath10k_warn(ar, "failed to pop paddr list: %d\n", ret);
>>           htt->rx_confused = true;
>> -        return;
>> +        return -EIO;
>>       }
>>         /* Offloaded frames are very different and need to be handled
>>        * separately.
>>        */
>>       if (offload)
>> -        ath10k_htt_rx_h_rx_offload(ar, &list);
>> +        num_msdus = ath10k_htt_rx_h_rx_offload(ar, &list);
>>         while (!skb_queue_empty(&list)) {
>>           __skb_queue_head_init(&amsdu);
>> @@ -1890,6 +1880,7 @@ static void ath10k_htt_rx_in_ord_ind(struct 
>> ath10k *ar, struct sk_buff *skb)
>>                * better to report something than nothing though. This
>>                * should still give an idea about rx rate to the user.
>>                */
>> +            num_msdus += skb_queue_len(&amsdu);
>>               ath10k_htt_rx_h_ppdu(ar, &amsdu, status, vdev_id);
>>               ath10k_htt_rx_h_filter(ar, &amsdu, status);
>>               ath10k_htt_rx_h_mpdu(ar, &amsdu, status);
>> @@ -1902,9 +1893,10 @@ static void ath10k_htt_rx_in_ord_ind(struct 
>> ath10k *ar, struct sk_buff *skb)
>>               ath10k_warn(ar, "failed to extract amsdu: %d\n", ret);
>>               htt->rx_confused = true;
>>               __skb_queue_purge(&list);
>> -            return;
>> +            return -EIO;
>>           }
>>       }
>> +    return num_msdus;
>>   }
>>     static void ath10k_htt_rx_tx_fetch_resp_id_confirm(struct ath10k 
>> *ar,
>> @@ -2267,7 +2259,6 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k 
>> *ar, struct sk_buff *skb)
>>       }
>>       case HTT_T2H_MSG_TYPE_TX_COMPL_IND:
>>           ath10k_htt_rx_tx_compl_ind(htt->ar, skb);
>> -        tasklet_schedule(&htt->txrx_compl_task);
>>           break;
>>       case HTT_T2H_MSG_TYPE_SEC_IND: {
>>           struct ath10k *ar = htt->ar;
>> @@ -2284,7 +2275,7 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k 
>> *ar, struct sk_buff *skb)
>>       case HTT_T2H_MSG_TYPE_RX_FRAG_IND: {
>>           ath10k_dbg_dump(ar, ATH10K_DBG_HTT_DUMP, NULL, "htt event: ",
>>                   skb->data, skb->len);
>> -        ath10k_htt_rx_frag_handler(htt);
>> +        atomic_inc(&htt->num_mpdus_ready);
>>           break;
>>       }
>>       case HTT_T2H_MSG_TYPE_TEST:
>> @@ -2322,8 +2313,7 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k 
>> *ar, struct sk_buff *skb)
>>           break;
>>       }
>>       case HTT_T2H_MSG_TYPE_RX_IN_ORD_PADDR_IND: {
>> -        skb_queue_tail(&htt->rx_in_ord_compl_q, skb);
>> -        tasklet_schedule(&htt->txrx_compl_task);
>> +        __skb_queue_tail(&htt->rx_in_ord_compl_q, skb);
>>           return false;
>>       }
>>       case HTT_T2H_MSG_TYPE_TX_CREDIT_UPDATE_IND:
>> @@ -2349,7 +2339,6 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k 
>> *ar, struct sk_buff *skb)
>>               break;
>>           }
>>           skb_queue_tail(&htt->tx_fetch_ind_q, tx_fetch_ind);
>> -        tasklet_schedule(&htt->txrx_compl_task);
>>           break;
>>       }
>>       case HTT_T2H_MSG_TYPE_TX_FETCH_CONFIRM:
>> @@ -2378,27 +2367,77 @@ void 
>> ath10k_htt_rx_pktlog_completion_handler(struct ath10k *ar,
>>   }
>>   EXPORT_SYMBOL(ath10k_htt_rx_pktlog_completion_handler);
>>   -static void ath10k_htt_txrx_compl_task(unsigned long ptr)
>> +int ath10k_htt_txrx_compl_task(struct ath10k *ar, int budget)
>>   {
>> -    struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
>> -    struct ath10k *ar = htt->ar;
>> +    struct ath10k_htt *htt = &ar->htt;
>>       struct htt_tx_done tx_done = {};
>> -    struct sk_buff_head rx_ind_q;
>>       struct sk_buff_head tx_ind_q;
>>       struct sk_buff *skb;
>>       unsigned long flags;
>> -    int num_mpdus;
>> +    int quota = 0, done, num_rx_msdus;
>> +    bool resched_napi = false;
>>   -    __skb_queue_head_init(&rx_ind_q);
>>       __skb_queue_head_init(&tx_ind_q);
>>   -    spin_lock_irqsave(&htt->rx_in_ord_compl_q.lock, flags);
>> -    skb_queue_splice_init(&htt->rx_in_ord_compl_q, &rx_ind_q);
>> -    spin_unlock_irqrestore(&htt->rx_in_ord_compl_q.lock, flags);
>> +    /* Since in-ord-ind can deliver more than 1 A-MSDU in single event,
>> +     * process it first to utilize full available quota.
>> +     */
>> +    while (quota < budget) {
>> +        if (skb_queue_empty(&htt->rx_in_ord_compl_q))
>> +            break;
>>   -    spin_lock_irqsave(&htt->tx_fetch_ind_q.lock, flags);
>> -    skb_queue_splice_init(&htt->tx_fetch_ind_q, &tx_ind_q);
>> -    spin_unlock_irqrestore(&htt->tx_fetch_ind_q.lock, flags);
>> +        skb = __skb_dequeue(&htt->rx_in_ord_compl_q);
>> +        if (!skb) {
>> +            resched_napi = true;
>> +            goto exit;
>> +        }
>> +
>> +        spin_lock_bh(&htt->rx_ring.lock);
>> +        num_rx_msdus = ath10k_htt_rx_in_ord_ind(ar, skb);
>> +        spin_unlock_bh(&htt->rx_ring.lock);
>> +        if (num_rx_msdus < 0) {
>> +            resched_napi = true;
>> +            goto exit;
>> +        }
>> +
>> +        dev_kfree_skb_any(skb);
>> +        if (num_rx_msdus > 0)
>> +            quota += num_rx_msdus;
>> +
>> +        if ((quota > ATH10K_NAPI_QUOTA_LIMIT) &&
>> +            !skb_queue_empty(&htt->rx_in_ord_compl_q)) {
>> +            resched_napi = true;
>> +            goto exit;
>> +        }
>> +    }
>> +
>> +    while (quota < budget) {
>> +        /* no more data to receive */
>> +        if (!atomic_read(&htt->num_mpdus_ready))
>> +            break;
>> +
>> +        num_rx_msdus = ath10k_htt_rx_handle_amsdu(htt);
>> +        if (num_rx_msdus < 0) {
>> +            resched_napi = true;
>> +            goto exit;
>> +        }
>> +
>> +        quota += num_rx_msdus;
>> +        atomic_dec(&htt->num_mpdus_ready);
>> +        if ((quota > ATH10K_NAPI_QUOTA_LIMIT) &&
>> +            atomic_read(&htt->num_mpdus_ready)) {
>> +            resched_napi = true;
>> +            goto exit;
>> +        }
>> +    }
>> +
>> +    /* From NAPI documentation:
>> +     *  The napi poll() function may also process TX completions, in 
>> which
>> +     *  case if it processes the entire TX ring then it should count 
>> that
>> +     *  work as the rest of the budget.
>> +     */
>> +    if ((quota < budget) && !kfifo_is_empty(&htt->txdone_fifo))
>> +        quota = budget;
>>         /* kfifo_get: called only within txrx_tasklet so it's neatly 
>> serialized.
>>        * From kfifo_get() documentation:
>> @@ -2408,27 +2447,22 @@ static void 
>> ath10k_htt_txrx_compl_task(unsigned long ptr)
>>       while (kfifo_get(&htt->txdone_fifo, &tx_done))
>>           ath10k_txrx_tx_unref(htt, &tx_done);
>>   +    spin_lock_irqsave(&htt->tx_fetch_ind_q.lock, flags);
>> +    skb_queue_splice_init(&htt->tx_fetch_ind_q, &tx_ind_q);
>> +    spin_unlock_irqrestore(&htt->tx_fetch_ind_q.lock, flags);
>> +
>>       while ((skb = __skb_dequeue(&tx_ind_q))) {
>>           ath10k_htt_rx_tx_fetch_ind(ar, skb);
>>           dev_kfree_skb_any(skb);
>>       }
>>   -    num_mpdus = atomic_read(&htt->num_mpdus_ready);
>> -
>> -    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))) {
>> -        spin_lock_bh(&htt->rx_ring.lock);
>> -        ath10k_htt_rx_in_ord_ind(ar, skb);
>> -        spin_unlock_bh(&htt->rx_ring.lock);
>> -        dev_kfree_skb_any(skb);
>> -    }
>> -
>> +exit:
>>       ath10k_htt_rx_msdu_buff_replenish(htt);
>> +    /* In case of rx failure or more data to read, report budget
>> +     * to reschedule NAPI poll
>> +     */
>> +    done = resched_napi ? budget : quota;
>> +
>> +    return done;
>>   }
>> +EXPORT_SYMBOL(ath10k_htt_txrx_compl_task);
>> diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
>> b/drivers/net/wireless/ath/ath10k/pci.c
>> index f06dd3941bac..9169ab92a16a 100644
>> --- a/drivers/net/wireless/ath/ath10k/pci.c
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c
>> @@ -1502,12 +1502,10 @@ void 
>> ath10k_pci_hif_send_complete_check(struct ath10k *ar, u8 pipe,
>>       ath10k_ce_per_engine_service(ar, pipe);
>>   }
>>   -void ath10k_pci_kill_tasklet(struct ath10k *ar)
>> +static void ath10k_pci_rx_retry_sync(struct ath10k *ar)
>>   {
>>       struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
>>   -    tasklet_kill(&ar_pci->intr_tq);
>> -
>>       del_timer_sync(&ar_pci->rx_post_retry);
>>   }
>>   @@ -1747,7 +1745,7 @@ void ath10k_pci_ce_deinit(struct ath10k *ar)
>>     void ath10k_pci_flush(struct ath10k *ar)
>>   {
>> -    ath10k_pci_kill_tasklet(ar);
>> +    ath10k_pci_rx_retry_sync(ar);
>>       ath10k_pci_buffer_cleanup(ar);
>>   }
>>   @@ -2754,35 +2752,53 @@ static irqreturn_t 
>> ath10k_pci_interrupt_handler(int irq, void *arg)
>>           return IRQ_NONE;
>>       }
>>   -    if (ar_pci->oper_irq_mode == ATH10K_PCI_IRQ_LEGACY) {
>> -        if (!ath10k_pci_irq_pending(ar))
>> -            return IRQ_NONE;
>> -
>> -        ath10k_pci_disable_and_clear_legacy_irq(ar);
>> -    }
>> +    if ((ar_pci->oper_irq_mode == ATH10K_PCI_IRQ_LEGACY) &&
>> +        !ath10k_pci_irq_pending(ar))
>> +        return IRQ_NONE;
>>   -    tasklet_schedule(&ar_pci->intr_tq);
>> +    ath10k_pci_disable_and_clear_legacy_irq(ar);
>> +    ath10k_pci_irq_msi_fw_mask(ar);
>> +    napi_schedule(&ar->napi);
>>         return IRQ_HANDLED;
>>   }
>>   -static void ath10k_pci_tasklet(unsigned long data)
>> +static int ath10k_pci_napi_poll(struct napi_struct *ctx, int budget)
>>   {
>> -    struct ath10k *ar = (struct ath10k *)data;
>> -    struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
>> +    struct ath10k *ar = container_of(ctx, struct ath10k, napi);
>> +    int done = 0;
>>         if (ath10k_pci_has_fw_crashed(ar)) {
>> -        ath10k_pci_irq_disable(ar);
>>           ath10k_pci_fw_crashed_clear(ar);
>>           ath10k_pci_fw_crashed_dump(ar);
>> -        return;
>> +        napi_complete(ctx);
>> +        return done;
>>       }
>>         ath10k_ce_per_engine_service_any(ar);
>>   -    /* Re-enable legacy irq that was disabled in the irq handler */
>> -    if (ar_pci->oper_irq_mode == ATH10K_PCI_IRQ_LEGACY)
>> +    done = ath10k_htt_txrx_compl_task(ar, budget);
>> +
>> +    if (done < budget) {
>> +        napi_complete(ctx);
>> +        /* In case of MSI, it is possible that interrupts are received
>> +         * while NAPI poll is inprogress. So pending interrupts that 
>> are
>> +         * received after processing all copy engine pipes by NAPI poll
>> +         * will not be handled again. This is causing failure to
>> +         * complete boot sequence in x86 platform. So before enabling
>> +         * interrupts safer to check for pending interrupts for
>> +         * immediate servicing.
>> +         */
>> +        if (CE_INTERRUPT_SUMMARY(ar)) {
>> +            napi_reschedule(&ar->napi);
>> +            goto out;
>> +        }
>>           ath10k_pci_enable_legacy_irq(ar);
>> +        ath10k_pci_irq_msi_fw_unmask(ar);
>> +    }
>> +
>> +out:
>> +    return done;
>>   }
>>     static int ath10k_pci_request_irq_msi(struct ath10k *ar)
>> @@ -2840,11 +2856,11 @@ static void ath10k_pci_free_irq(struct ath10k 
>> *ar)
>>       free_irq(ar_pci->pdev->irq, ar);
>>   }
>>   -void ath10k_pci_init_irq_tasklets(struct ath10k *ar)
>> +void ath10k_pci_init_napi(struct ath10k *ar)
>>   {
>> -    struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
>> -
>> -    tasklet_init(&ar_pci->intr_tq, ath10k_pci_tasklet, (unsigned 
>> long)ar);
>> +    netif_napi_add(&ar->napi_dev, &ar->napi, ath10k_pci_napi_poll,
>> +               ATH10K_NAPI_BUDGET);
>> +    napi_enable(&ar->napi);
>>   }
>>     static int ath10k_pci_init_irq(struct ath10k *ar)
>> @@ -2852,7 +2868,7 @@ static int ath10k_pci_init_irq(struct ath10k *ar)
>>       struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
>>       int ret;
>>   -    ath10k_pci_init_irq_tasklets(ar);
>> +    ath10k_pci_init_napi(ar);
>>         if (ath10k_pci_irq_mode != ATH10K_PCI_IRQ_AUTO)
>>           ath10k_info(ar, "limiting irq mode to: %d\n",
>> @@ -3113,7 +3129,8 @@ int ath10k_pci_setup_resource(struct ath10k *ar)
>>     void ath10k_pci_release_resource(struct ath10k *ar)
>>   {
>> -    ath10k_pci_kill_tasklet(ar);
>> +    ath10k_pci_rx_retry_sync(ar);
>> +    netif_napi_del(&ar->napi);
>>       ath10k_pci_ce_deinit(ar);
>>       ath10k_pci_free_pipes(ar);
>>   }
>> @@ -3274,7 +3291,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
>>     err_free_irq:
>>       ath10k_pci_free_irq(ar);
>> -    ath10k_pci_kill_tasklet(ar);
>> +    ath10k_pci_rx_retry_sync(ar);
>>     err_deinit_irq:
>>       ath10k_pci_deinit_irq(ar);
>> diff --git a/drivers/net/wireless/ath/ath10k/pci.h 
>> b/drivers/net/wireless/ath/ath10k/pci.h
>> index 6eca1df2ce60..974e463e8b95 100644
>> --- a/drivers/net/wireless/ath/ath10k/pci.h
>> +++ b/drivers/net/wireless/ath/ath10k/pci.h
>> @@ -177,8 +177,6 @@ struct ath10k_pci {
>>       /* Operating interrupt mode */
>>       enum ath10k_pci_irq_mode oper_irq_mode;
>>   -    struct tasklet_struct intr_tq;
>> -
>>       struct ath10k_pci_pipe pipe_info[CE_COUNT_MAX];
>>         /* Copy Engine used for Diagnostic Accesses */
>> @@ -294,8 +292,7 @@ void ath10k_pci_free_pipes(struct ath10k *ar);
>>   void ath10k_pci_free_pipes(struct ath10k *ar);
>>   void ath10k_pci_rx_replenish_retry(unsigned long ptr);
>>   void ath10k_pci_ce_deinit(struct ath10k *ar);
>> -void ath10k_pci_init_irq_tasklets(struct ath10k *ar);
>> -void ath10k_pci_kill_tasklet(struct ath10k *ar);
>> +void ath10k_pci_init_napi(struct ath10k *ar);
>>   int ath10k_pci_init_pipes(struct ath10k *ar);
>>   int ath10k_pci_init_config(struct ath10k *ar);
>>   void ath10k_pci_rx_post(struct ath10k *ar);
>
>


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From michal.kazior at tieto.com  Mon Jun 27 23:48:38 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 28 Jun 2016 08:48:38 +0200
Subject: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for
 QCA99X0 and later
In-Reply-To: <20160627143600.GA5292@atheros-ThinkPad-T61>
References: <1466700001-4883-1-git-send-email-mohammed@qca.qualcomm.com>
 <1466700001-4883-2-git-send-email-mohammed@qca.qualcomm.com>
 <CA+BoTQnUvF2Zy7_WuEi0V+KjByRghVmoeR6yrs6hu6ag=KmBqQ@mail.gmail.com>
 <20160627143600.GA5292@atheros-ThinkPad-T61>
Message-ID: <CA+BoTQn+HeishCMf4hjpWjLBmvFG2r0gosBv77RTyk7+uOAvPA@mail.gmail.com>

On 27 June 2016 at 16:36, Mohammed Shafi Shajakhan
<mohammed at codeaurora.org> wrote:
> Hi Michal,
>
> thanks for the review ..
>
> On Mon, Jun 27, 2016 at 11:27:27AM +0200, Michal Kazior wrote:
>> On 23 June 2016 at 18:40, Mohammed Shafi Shajakhan
>> <mohammed at qti.qualcomm.com> wrote:
>> > From: Mohammed Shafi Shajakhan <mohammed at 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
>> >
>> > Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>
>> > Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
>> > ---
>> >  drivers/net/wireless/ath/ath10k/core.c | 3 +++
>> >  drivers/net/wireless/ath/ath10k/core.h | 6 ++++++
>> >  drivers/net/wireless/ath/ath10k/mac.c  | 1 +
>> >  3 files changed, 10 insertions(+)
>> >
>> > diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
>> > index 689d6ce..9978e4a 100644
>> > --- a/drivers/net/wireless/ath/ath10k/core.c
>> > +++ b/drivers/net/wireless/ath/ath10k/core.c
>> > @@ -181,6 +181,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
>> >                         .board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
>> >                         .board_size = QCA99X0_BOARD_DATA_SZ,
>> >                         .board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
>> > +                       .disable_null_func_workaround = true,
>>
>> Tx completion (bugs) are firmware specific, not hardware. This should
>> be expressed via features bits in ath10k FW API, no?
>>
>>
> [shafi] Are you suggesting me to introduce something like
> "ATH10K_FW_FEATURE_SUPPORTS_SKIP_CLOCK_INIT" ? Kalle any suggestions ?
>
> Also how about getting this workaround completely if Ben had fixed this in his tree,
> will this affect older 10.2.4 ?

There's still 636.

We could probably get rid of this as long as:
 - ath10k can express the need to use Probe Requests for AP probing
(in client mode) and beacon loss handling purposes instead of NullFunc
to mac80211
 - everyone uses hostapd with disassoc_low_ack=1 with affected
firmware revisions
 - supplicant uses disassoc_low_ack=1 for p2p go
 - I have no idea about mesh/ibss but they might require some work as well

Otherwise you'll introduce regressions.


Micha?


From johannes at sipsolutions.net  Tue Jun 28 03:48:38 2016
From: johannes at sipsolutions.net (Johannes Berg)
Date: Tue, 28 Jun 2016 12:48:38 +0200
Subject: [PATCH 1/2] cfg80211: Add support to set tx power for a station
 associated
In-Reply-To: <1465926256-6463-1-git-send-email-arnagara@qti.qualcomm.com>
References: <1465926256-6463-1-git-send-email-arnagara@qti.qualcomm.com>
Message-ID: <1467110918.2493.9.camel@sipsolutions.net>

On Tue, 2016-06-14 at 23:14 +0530, Ashok Raj Nagarajan wrote:
> This patch adds support to set transmit power setting type and
> transmit power level attributes to NL80211_CMD_SET_STATION in order
> to facilitate adjusting the transmit power level of a station
> associated to the AP.

Why would you ever need to do that manually? Please give more
explanation in the commit message.

We have minstrel-blues (which never made it into the code, but that's
just because the submitter went away) doing power adjustments, so you
need to explain why this should be necessary.

johannes


From kvalo at qca.qualcomm.com  Wed Jun 29 01:24:25 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Wed, 29 Jun 2016 08:24:25 +0000
Subject: [RFT] mac80211: fix fq lockdep warnings
In-Reply-To: <1467026569-19329-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Mon, 27 Jun 2016 13:22:49 +0200")
References: <878txzo7c6.fsf@kamboji.qca.qualcomm.com>
 <1467026569-19329-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <874m8c9zd5.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> Some lockdep assertions were not fulfilled and
> resulted in a kernel warning/call trace.
>
> Existing code sequences should've guranteed safety
> but it's always good to be extra careful.
>
> The call trace could look like this:
>
>  [ 237.335805] ------------[ cut here ]------------
>  [ 237.335852] WARNING: CPU: 3 PID: 1921 at include/net/fq_impl.h:22 fq_flow_dequeue+0xed/0x140 [mac80211]
>  [ 237.335855] Modules linked in: ath10k_pci(E-) ath10k_core(E) ath(E) mac80211(E) cfg80211(E)
>  [ 237.335913] CPU: 3 PID: 1921 Comm: rmmod Tainted: G        W   E   4.7.0-rc4-wt-ath+ #1377
>  [ 237.335916] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD Ver. F.04 01/27/2010
>  [ 237.335918]  00200286 00200286 eff85dac c14151e2 f901574e 00000000 eff85de0 c1081075
>  [ 237.335928]  c1ab91f0 00000003 00000781 f901574e 00000016 f8fbabad f8fbabad 00000016
>  [ 237.335938]  eb24ff60 00000000 ef3886c0 eff85df4 c10810ba 00000009 00000000 00000000
>  [ 237.335948] Call Trace:
>  [ 237.335953]  [<c14151e2>] dump_stack+0x76/0xb4
>  [ 237.335957]  [<c1081075>] __warn+0xe5/0x100
>  [ 237.336002]  [<f8fbabad>] ? fq_flow_dequeue+0xed/0x140 [mac80211]
>  [ 237.336046]  [<f8fbabad>] ? fq_flow_dequeue+0xed/0x140 [mac80211]
>  [ 237.336053]  [<c10810ba>] warn_slowpath_null+0x2a/0x30
>  [ 237.336095]  [<f8fbabad>] fq_flow_dequeue+0xed/0x140 [mac80211]
>  [ 237.336137]  [<f8fbc67a>] fq_flow_reset.constprop.56+0x2a/0x90 [mac80211]
>  [ 237.336180]  [<f8fbc79a>] fq_reset.constprop.59+0x2a/0x50 [mac80211]
>  [ 237.336222]  [<f8fc04e8>] ieee80211_txq_teardown_flows+0x38/0x40 [mac80211]
>  [ 237.336258]  [<f8f7c1a4>] ieee80211_unregister_hw+0xe4/0x120 [mac80211]
>  [ 237.336275]  [<f933f536>] ath10k_mac_unregister+0x16/0x50 [ath10k_core]
>  [ 237.336292]  [<f934592d>] ath10k_core_unregister+0x3d/0x90 [ath10k_core]
>  [ 237.336301]  [<f85f8836>] ath10k_pci_remove+0x36/0xa0 [ath10k_pci]
>  [ 237.336307]  [<c1470388>] pci_device_remove+0x38/0xb0
>  ...
>
> Fixes: 5caa328e3811 ("mac80211: implement codel on fair queuing flows")
> Fixes: fa962b92120b ("mac80211: implement fair queueing per txq")
> Reported-by: Valo, Kalle <kvalo at qca.qualcomm.com>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Tested-by: Kalle Valo <kvalo at qca.qualcomm.com>

> Can you verify this fixes call traces you're
> seeing, please?

Yup, I don't see the warnings anymore. I tried multiple times, rebooting
etc. Thanks for fixing this.

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Wed Jun 29 01:58:11 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Wed, 29 Jun 2016 08:58:11 +0000
Subject: [RFC/RFT] ath10k: disable wake_tx_queue for older devices
In-Reply-To: <CACiydbLvke0UxJbg2sn0q-=FwXpmX+FKUV7wwEMT=qUYekJrJA@mail.gmail.com>	(Roman
 Yeryomin's message of "Wed, 8 Jun 2016 14:39:03 +0300")
References: <1463489221-24989-1-git-send-email-michal.kazior@tieto.com>
 <87inxrzqa5.fsf@kamboji.qca.qualcomm.com>
 <CACiydbLvke0UxJbg2sn0q-=FwXpmX+FKUV7wwEMT=qUYekJrJA@mail.gmail.com>
Message-ID: <87oa6k8j8d.fsf@kamboji.qca.qualcomm.com>

Roman Yeryomin <leroi.lists at gmail.com> writes:

> On 2 June 2016 at 16:14, Valo, Kalle <kvalo at qca.qualcomm.com> wrote:
>> Michal Kazior <michal.kazior at tieto.com> writes:
>>
>>> Some setups suffer performance regressions with
>>> current wake_tx_queue implementation.
>>>
>>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>>> ---
>>> Hi Roman,
>>>
>>> Can you give this patch a try and see if it helps
>>> with your performance problems, please?
>>
>> Did anyone seeing the performance regression manage to test this? It
>> would be good to get feedback, good or bad, before I push this to 4.7.
>>
>> Full patch here:
>>
>> https://patchwork.kernel.org/patch/9111981/
>
> Sorry, didn't try yet, bad timing for me :(
> Will try to test by the end of the week

Roman, did you have a chance to test this?

Michal, could you submit this patch as a formal patch, please? I think
we should take it even if Roman hasn't tested it.

-- 
Kalle Valo

From mohammed at codeaurora.org  Wed Jun 29 02:47:54 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Wed, 29 Jun 2016 15:17:54 +0530
Subject: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for
 QCA99X0 and later
In-Reply-To: <CA+BoTQn+HeishCMf4hjpWjLBmvFG2r0gosBv77RTyk7+uOAvPA@mail.gmail.com>
References: <1466700001-4883-1-git-send-email-mohammed@qca.qualcomm.com>
 <1466700001-4883-2-git-send-email-mohammed@qca.qualcomm.com>
 <CA+BoTQnUvF2Zy7_WuEi0V+KjByRghVmoeR6yrs6hu6ag=KmBqQ@mail.gmail.com>
 <20160627143600.GA5292@atheros-ThinkPad-T61>
 <CA+BoTQn+HeishCMf4hjpWjLBmvFG2r0gosBv77RTyk7+uOAvPA@mail.gmail.com>
Message-ID: <20160629094754.GA8867@atheros-ThinkPad-T61>

Hello Michal/ Kalle,

On Tue, Jun 28, 2016 at 08:48:38AM +0200, Michal Kazior wrote:
> On 27 June 2016 at 16:36, Mohammed Shafi Shajakhan
> <mohammed at codeaurora.org> wrote:
> > Hi Michal,
> >
> > thanks for the review ..
> >
> > On Mon, Jun 27, 2016 at 11:27:27AM +0200, Michal Kazior wrote:
> >> On 23 June 2016 at 18:40, Mohammed Shafi Shajakhan
> >> <mohammed at qti.qualcomm.com> wrote:
> >> > From: Mohammed Shafi Shajakhan <mohammed at 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
> >> >
> >> > Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>
> >> > Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> >> > ---
> >> >  drivers/net/wireless/ath/ath10k/core.c | 3 +++
> >> >  drivers/net/wireless/ath/ath10k/core.h | 6 ++++++
> >> >  drivers/net/wireless/ath/ath10k/mac.c  | 1 +
> >> >  3 files changed, 10 insertions(+)
> >> >
> >> > diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> >> > index 689d6ce..9978e4a 100644
> >> > --- a/drivers/net/wireless/ath/ath10k/core.c
> >> > +++ b/drivers/net/wireless/ath/ath10k/core.c
> >> > @@ -181,6 +181,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
> >> >                         .board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
> >> >                         .board_size = QCA99X0_BOARD_DATA_SZ,
> >> >                         .board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> >> > +                       .disable_null_func_workaround = true,
> >>
> >> Tx completion (bugs) are firmware specific, not hardware. This should
> >> be expressed via features bits in ath10k FW API, no?
> >>
> >>
> > [shafi] Are you suggesting me to introduce something like
> > "ATH10K_FW_FEATURE_SUPPORTS_SKIP_CLOCK_INIT" ? Kalle any suggestions ?
> >
> > Also how about getting this workaround completely if Ben had fixed this in his tree,
> > will this affect older 10.2.4 ?
> 
> There's still 636.
> 
> We could probably get rid of this as long as:
>  - ath10k can express the need to use Probe Requests for AP probing
> (in client mode) and beacon loss handling purposes instead of NullFunc
> to mac80211
>  - everyone uses hostapd with disassoc_low_ack=1 with affected
> firmware revisions
>  - supplicant uses disassoc_low_ack=1 for p2p go
>  - I have no idea about mesh/ibss but they might require some work as well
> 
> Otherwise you'll introduce regressions.
>

[shafi] sure then we will disable this for 10.4 (QCA99X0 and later)

*firmware feature requires a new firmware updated this feature, so the bug
will be present for all the older firmware, please correct me if my
understanding is wrong

*We discussed wmi_op_version is not the way to go (in the sense just disable it
for 10.4 alone)

Let me know if there is any other suggestion (the existing change though bit
cleanly is very explicit regarding the chipsets that this workaround is not
needed), thank you !

regards,
shafi



From michal.kazior at tieto.com  Wed Jun 29 04:52:26 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 29 Jun 2016 13:52:26 +0200
Subject: [PATCH] ath10k: disable wake_tx_queue for older devices
In-Reply-To: <1463489221-24989-1-git-send-email-michal.kazior@tieto.com>
References: <1463489221-24989-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1467201146-6844-1-git-send-email-michal.kazior@tieto.com>

Ideally wake_tx_queue should be used regardless as
it is a requirement for reducing bufferbloat and
implementing airtime fairness in the future.

However some setups (typically low-end platforms
hosting QCA988X) suffer performance regressions
with the current wake_tx_queue implementation.
Therefore disable it unless it is really
beneficial with current codebase (which is when
firmware supports smart pull-push tx scheduling).

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---

Notes:
    v1:
     - improve commit log

 drivers/net/wireless/ath/ath10k/core.h |  1 +
 drivers/net/wireless/ath/ath10k/mac.c  | 24 ++++++++++++++++++++++--
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 3da18c9dbd7a..de580af2e5ef 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -667,6 +667,7 @@ struct ath10k_fw_components {
 struct ath10k {
 	struct ath_common ath_common;
 	struct ieee80211_hw *hw;
+	struct ieee80211_ops *ops;
 	struct device *dev;
 	u8 mac_addr[ETH_ALEN];
 
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d4b7a168f7c0..958bc6c91aac 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7471,21 +7471,32 @@ static const struct ieee80211_channel ath10k_5ghz_channels[] = {
 struct ath10k *ath10k_mac_create(size_t priv_size)
 {
 	struct ieee80211_hw *hw;
+	struct ieee80211_ops *ops;
 	struct ath10k *ar;
 
-	hw = ieee80211_alloc_hw(sizeof(struct ath10k) + priv_size, &ath10k_ops);
-	if (!hw)
+	ops = kmemdup(&ath10k_ops, sizeof(ath10k_ops), GFP_KERNEL);
+	if (!ops)
 		return NULL;
 
+	hw = ieee80211_alloc_hw(sizeof(struct ath10k) + priv_size, ops);
+	if (!hw) {
+		kfree(ops);
+		return NULL;
+	}
+
 	ar = hw->priv;
 	ar->hw = hw;
+	ar->ops = ops;
 
 	return ar;
 }
 
 void ath10k_mac_destroy(struct ath10k *ar)
 {
+	struct ieee80211_ops *ops = ar->ops;
+
 	ieee80211_free_hw(ar->hw);
+	kfree(ops);
 }
 
 static const struct ieee80211_iface_limit ath10k_if_limits[] = {
@@ -7919,6 +7930,15 @@ int ath10k_mac_register(struct ath10k *ar)
 			ath10k_warn(ar, "failed to initialise DFS pattern detector\n");
 	}
 
+	/* Current wake_tx_queue implementation imposes a significant
+	 * performance penalty in some setups. The tx scheduling code needs
+	 * more work anyway so disable the wake_tx_queue unless firmware
+	 * supports the pull-push mechanism.
+	 */
+	if (!test_bit(ATH10K_FW_FEATURE_PEER_FLOW_CONTROL,
+		      ar->running_fw->fw_file.fw_features))
+		ar->ops->wake_tx_queue = NULL;
+
 	ret = ath_regd_init(&ar->ath_common.regulatory, ar->hw->wiphy,
 			    ath10k_reg_notifier);
 	if (ret) {
-- 
2.1.4



From michal.kazior at tieto.com  Wed Jun 29 05:00:34 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 29 Jun 2016 14:00:34 +0200
Subject: [PATCH] mac80211: fix fq lockdep warnings
In-Reply-To: <1467026569-19329-1-git-send-email-michal.kazior@tieto.com>
References: <1467026569-19329-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1467201634-11060-1-git-send-email-michal.kazior@tieto.com>

Some lockdep assertions were not fulfilled and
resulted in a kernel warning/call trace if driver
used intermediate software queues (e.g. ath10k).

Existing code sequences should've guranteed safety
but it's always good to be extra careful.

The call trace could look like this:

 [ 237.335805] ------------[ cut here ]------------
 [ 237.335852] WARNING: CPU: 3 PID: 1921 at include/net/fq_impl.h:22 fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.335855] Modules linked in: ath10k_pci(E-) ath10k_core(E) ath(E) mac80211(E) cfg80211(E)
 [ 237.335913] CPU: 3 PID: 1921 Comm: rmmod Tainted: G        W   E   4.7.0-rc4-wt-ath+ #1377
 [ 237.335916] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD Ver. F.04 01/27/2010
 [ 237.335918]  00200286 00200286 eff85dac c14151e2 f901574e 00000000 eff85de0 c1081075
 [ 237.335928]  c1ab91f0 00000003 00000781 f901574e 00000016 f8fbabad f8fbabad 00000016
 [ 237.335938]  eb24ff60 00000000 ef3886c0 eff85df4 c10810ba 00000009 00000000 00000000
 [ 237.335948] Call Trace:
 [ 237.335953]  [<c14151e2>] dump_stack+0x76/0xb4
 [ 237.335957]  [<c1081075>] __warn+0xe5/0x100
 [ 237.336002]  [<f8fbabad>] ? fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.336046]  [<f8fbabad>] ? fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.336053]  [<c10810ba>] warn_slowpath_null+0x2a/0x30
 [ 237.336095]  [<f8fbabad>] fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.336137]  [<f8fbc67a>] fq_flow_reset.constprop.56+0x2a/0x90 [mac80211]
 [ 237.336180]  [<f8fbc79a>] fq_reset.constprop.59+0x2a/0x50 [mac80211]
 [ 237.336222]  [<f8fc04e8>] ieee80211_txq_teardown_flows+0x38/0x40 [mac80211]
 [ 237.336258]  [<f8f7c1a4>] ieee80211_unregister_hw+0xe4/0x120 [mac80211]
 [ 237.336275]  [<f933f536>] ath10k_mac_unregister+0x16/0x50 [ath10k_core]
 [ 237.336292]  [<f934592d>] ath10k_core_unregister+0x3d/0x90 [ath10k_core]
 [ 237.336301]  [<f85f8836>] ath10k_pci_remove+0x36/0xa0 [ath10k_pci]
 [ 237.336307]  [<c1470388>] pci_device_remove+0x38/0xb0
 ...

Fixes: 5caa328e3811 ("mac80211: implement codel on fair queuing flows")
Fixes: fa962b92120b ("mac80211: implement fair queueing per txq")
Tested-by: Kalle Valo <kvalo at qca.qualcomm.com>
Reported-by: Kalle Valo <kvalo at qca.qualcomm.com>
Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---

Notes:
    v1:
     - added Tested-by [Kalle]
     - swapped first/last name in Reported-by to match Tested-by
     - improve commit log

 net/mac80211/tx.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index fa8d38eb9236..91461c415525 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1449,7 +1449,9 @@ int ieee80211_txq_setup_flows(struct ieee80211_local *local)
 	local->cvars = kcalloc(fq->flows_cnt, sizeof(local->cvars[0]),
 			       GFP_KERNEL);
 	if (!local->cvars) {
+		spin_lock_bh(&fq->lock);
 		fq_reset(fq, fq_skb_free_func);
+		spin_unlock_bh(&fq->lock);
 		return -ENOMEM;
 	}
 
@@ -1469,7 +1471,9 @@ void ieee80211_txq_teardown_flows(struct ieee80211_local *local)
 	kfree(local->cvars);
 	local->cvars = NULL;
 
+	spin_lock_bh(&fq->lock);
 	fq_reset(fq, fq_skb_free_func);
+	spin_unlock_bh(&fq->lock);
 }
 
 struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
-- 
2.1.4



From s.gottschall at dd-wrt.com  Wed Jun 29 07:04:43 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Wed, 29 Jun 2016 16:04:43 +0200
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
Message-ID: <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>

this fix will crash QCA9980 on QCA IPQ8064 cpu based systems.
so please rework it, or leave it out.
note:
maybe the limit of 256kb is too low for that card


    10.102047] ath10k_pci 0000:01:00.0: unable to read from the device
[   10.102075] ath10k_pci 0000:01:00.0: could not execute otp for board 
id check: -110
[   10.107116] ath10k_pci 0000:01:00.0: failed to get board id from otp: 
-110
[   10.126517] ath10k_pci 0000:01:00.0: failed to fetch board data for 
bus=pci,vendor=168c,device=0040,subsystem-vendor=168c,subsystem-device=0002 
from ath10k/QCA99X0/hw2.0/board-2.bin
[   10.126697] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A 
crc32 62700264
[   11.518268] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 
7173fc19-f807-4345-906a-9f3d17fb751b)
[   11.518307] ath10k_pci 0000:01:00.0: qca99x0 hw2.0 target 0x01000000 
chip_id 0x003b01ff sub 168c:0002
[   11.526123] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1 
tracing 0 dfs 0 testmode 0
[   11.536976] ath10k_pci 0000:01:00.0: firmware ver 10.4.1.00030-1 api 
5 features no-p2p crc32 d2901e01
[   11.543610] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A 
crc32 62700264
[   11.552770] ath10k_pci 0000:01:00.0: htt-ver 0.0 wmi-op 6 htt-op 4 
cal file max-sta 512 raw 0 hwcrypto 1
[   11.561910] ath10k_pci 0000:01:00.0: firmware register dump:
[   11.569606] ath10k_pci 0000:01:00.0: [00]: 0x01000000 0x000015B3 
0x000D89A5 0x00955B31
[   11.575252] ath10k_pci 0000:01:00.0: [04]: 0x000D89A5 0x00060730 
0x0000000C 0x00000000
[   11.582978] ath10k_pci 0000:01:00.0: [08]: 0x00000010 0x0000000D 
0x000E8A64 0xFFFFC000
[   11.590876] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000 
0x000D89BC 0x000D8A03
[   11.598846] ath10k_pci 0000:01:00.0: [16]: 0x00953438 0x000D89BE 
0x00000000 0x00000000
[   11.606676] ath10k_pci 0000:01:00.0: [20]: 0x400D89A5 0x0040655C 
0x00413A84 0x00000005
[   11.614574] ath10k_pci 0000:01:00.0: [24]: 0x809CDC6E 0x004065BC 
0x00417450 0xC00D89A5
[   11.622473] ath10k_pci 0000:01:00.0: [28]: 0x8098011C 0x0040660C 
0x004179D8 0x0000000D
[   11.630372] ath10k_pci 0000:01:00.0: [32]: 0x809CDE70 0x0040662C 
0x004179D8 0x0000000D
[   11.638272] ath10k_pci 0000:01:00.0: [36]: 0x80981786 0x0040665C 
0x004179D8 0x00000020
[   11.646171] ath10k_pci 0000:01:00.0: [40]: 0x809CE0F7 0x0040667C 
0x00000000 0x0000A000
[   11.654070] ath10k_pci 0000:01:00.0: [44]: 0x809B307A 0x004066AC 
0x00981768 0x0042028C
[   11.661970] ath10k_pci 0000:01:00.0: [48]: 0x809AF3DA 0x004066FC 
0x00000002 0x0042028C
[   11.669869] ath10k_pci 0000:01:00.0: [52]: 0x809AEB02 0x0040672C 
0x00406750 0x0041847C
[   11.677768] ath10k_pci 0000:01:00.0: [56]: 0x8094EAAA 0x0040674C 
0x000E89AC 0x00000001

Sebastian


Am 14.06.2016 um 08:17 schrieb Rajkumar Manoharan:
> commit b057886524be ("ath10k: do not use coherent memory for allocated
> device memory chunks") replaced coherent memory allocation for memory
> chunks to fix low memory platforms. Unfortunately this is causing system
> freeze on x86 platform while bringing up qca99x0 device. The system
> hangs while DMA mapping bigger memory chunks (689816/865444 bytes). Fix
> this by limiting maximum memory chunk size to 256 KiB per request.
>
> Cc: Felix Fietkau <nbd at nbd.name>
> Fixes: b057886524be ("ath10k: do not use coherent memory for allocated 
> device memory chunks")
> Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
> ---
>   drivers/net/wireless/ath/ath10k/wmi.c | 6 ++++++
>   drivers/net/wireless/ath/ath10k/wmi.h | 1 +
>   2 files changed, 7 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
> b/drivers/net/wireless/ath/ath10k/wmi.c
> index 6279ab4a760e..7c15f65fe5ed 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -4411,6 +4411,12 @@ static int ath10k_wmi_alloc_chunk(struct ath10k 
> *ar, u32 req_id,
>           if (!pool_size)
>               return -EINVAL;
>   +        if (pool_size > WMI_MAX_MEM_CHUNK_SIZE) {
> +            num_units = WMI_MAX_MEM_CHUNK_SIZE /
> +                    round_up(unit_len, 4);
> +            pool_size = num_units * round_up(unit_len, 4);
> +        }
> +
>           vaddr = kzalloc(pool_size, GFP_KERNEL | __GFP_NOWARN);
>           if (!vaddr)
>               num_units /= 2;
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
> b/drivers/net/wireless/ath/ath10k/wmi.h
> index 90f594e89f94..dea1f235a54d 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
> @@ -6184,6 +6184,7 @@ struct wmi_roam_ev {
>   #define ATH10K_DEFAULT_ATIM 0
>     #define WMI_MAX_MEM_REQS 16
> +#define WMI_MAX_MEM_CHUNK_SIZE (256 * 1024) /* 256 KB */
>     struct wmi_scan_ev_arg {
>       __le32 event_type; /* %WMI_SCAN_EVENT_ */


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From s.gottschall at dd-wrt.com  Wed Jun 29 07:10:34 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Wed, 29 Jun 2016 16:10:34 +0200
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
Message-ID: <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>

by the way. 512 works


Am 29.06.2016 um 16:04 schrieb Sebastian Gottschall:
> this fix will crash QCA9980 on QCA IPQ8064 cpu based systems.
> so please rework it, or leave it out.
> note:
> maybe the limit of 256kb is too low for that card
>
>
>    10.102047] ath10k_pci 0000:01:00.0: unable to read from the device
> [   10.102075] ath10k_pci 0000:01:00.0: could not execute otp for 
> board id check: -110
> [   10.107116] ath10k_pci 0000:01:00.0: failed to get board id from 
> otp: -110
> [   10.126517] ath10k_pci 0000:01:00.0: failed to fetch board data for 
> bus=pci,vendor=168c,device=0040,subsystem-vendor=168c,subsystem-device=0002 
> from ath10k/QCA99X0/hw2.0/board-2.bin
> [   10.126697] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A 
> crc32 62700264
> [   11.518268] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 
> 7173fc19-f807-4345-906a-9f3d17fb751b)
> [   11.518307] ath10k_pci 0000:01:00.0: qca99x0 hw2.0 target 
> 0x01000000 chip_id 0x003b01ff sub 168c:0002
> [   11.526123] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1 
> tracing 0 dfs 0 testmode 0
> [   11.536976] ath10k_pci 0000:01:00.0: firmware ver 10.4.1.00030-1 
> api 5 features no-p2p crc32 d2901e01
> [   11.543610] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A 
> crc32 62700264
> [   11.552770] ath10k_pci 0000:01:00.0: htt-ver 0.0 wmi-op 6 htt-op 4 
> cal file max-sta 512 raw 0 hwcrypto 1
> [   11.561910] ath10k_pci 0000:01:00.0: firmware register dump:
> [   11.569606] ath10k_pci 0000:01:00.0: [00]: 0x01000000 0x000015B3 
> 0x000D89A5 0x00955B31
> [   11.575252] ath10k_pci 0000:01:00.0: [04]: 0x000D89A5 0x00060730 
> 0x0000000C 0x00000000
> [   11.582978] ath10k_pci 0000:01:00.0: [08]: 0x00000010 0x0000000D 
> 0x000E8A64 0xFFFFC000
> [   11.590876] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000 
> 0x000D89BC 0x000D8A03
> [   11.598846] ath10k_pci 0000:01:00.0: [16]: 0x00953438 0x000D89BE 
> 0x00000000 0x00000000
> [   11.606676] ath10k_pci 0000:01:00.0: [20]: 0x400D89A5 0x0040655C 
> 0x00413A84 0x00000005
> [   11.614574] ath10k_pci 0000:01:00.0: [24]: 0x809CDC6E 0x004065BC 
> 0x00417450 0xC00D89A5
> [   11.622473] ath10k_pci 0000:01:00.0: [28]: 0x8098011C 0x0040660C 
> 0x004179D8 0x0000000D
> [   11.630372] ath10k_pci 0000:01:00.0: [32]: 0x809CDE70 0x0040662C 
> 0x004179D8 0x0000000D
> [   11.638272] ath10k_pci 0000:01:00.0: [36]: 0x80981786 0x0040665C 
> 0x004179D8 0x00000020
> [   11.646171] ath10k_pci 0000:01:00.0: [40]: 0x809CE0F7 0x0040667C 
> 0x00000000 0x0000A000
> [   11.654070] ath10k_pci 0000:01:00.0: [44]: 0x809B307A 0x004066AC 
> 0x00981768 0x0042028C
> [   11.661970] ath10k_pci 0000:01:00.0: [48]: 0x809AF3DA 0x004066FC 
> 0x00000002 0x0042028C
> [   11.669869] ath10k_pci 0000:01:00.0: [52]: 0x809AEB02 0x0040672C 
> 0x00406750 0x0041847C
> [   11.677768] ath10k_pci 0000:01:00.0: [56]: 0x8094EAAA 0x0040674C 
> 0x000E89AC 0x00000001
>
> Sebastian
>
>
> Am 14.06.2016 um 08:17 schrieb Rajkumar Manoharan:
>> commit b057886524be ("ath10k: do not use coherent memory for allocated
>> device memory chunks") replaced coherent memory allocation for memory
>> chunks to fix low memory platforms. Unfortunately this is causing system
>> freeze on x86 platform while bringing up qca99x0 device. The system
>> hangs while DMA mapping bigger memory chunks (689816/865444 bytes). Fix
>> this by limiting maximum memory chunk size to 256 KiB per request.
>>
>> Cc: Felix Fietkau <nbd at nbd.name>
>> Fixes: b057886524be ("ath10k: do not use coherent memory for 
>> allocated device memory chunks")
>> Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
>> ---
>>   drivers/net/wireless/ath/ath10k/wmi.c | 6 ++++++
>>   drivers/net/wireless/ath/ath10k/wmi.h | 1 +
>>   2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
>> b/drivers/net/wireless/ath/ath10k/wmi.c
>> index 6279ab4a760e..7c15f65fe5ed 100644
>> --- a/drivers/net/wireless/ath/ath10k/wmi.c
>> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
>> @@ -4411,6 +4411,12 @@ static int ath10k_wmi_alloc_chunk(struct 
>> ath10k *ar, u32 req_id,
>>           if (!pool_size)
>>               return -EINVAL;
>>   +        if (pool_size > WMI_MAX_MEM_CHUNK_SIZE) {
>> +            num_units = WMI_MAX_MEM_CHUNK_SIZE /
>> +                    round_up(unit_len, 4);
>> +            pool_size = num_units * round_up(unit_len, 4);
>> +        }
>> +
>>           vaddr = kzalloc(pool_size, GFP_KERNEL | __GFP_NOWARN);
>>           if (!vaddr)
>>               num_units /= 2;
>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
>> b/drivers/net/wireless/ath/ath10k/wmi.h
>> index 90f594e89f94..dea1f235a54d 100644
>> --- a/drivers/net/wireless/ath/ath10k/wmi.h
>> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
>> @@ -6184,6 +6184,7 @@ struct wmi_roam_ev {
>>   #define ATH10K_DEFAULT_ATIM 0
>>     #define WMI_MAX_MEM_REQS 16
>> +#define WMI_MAX_MEM_CHUNK_SIZE (256 * 1024) /* 256 KB */
>>     struct wmi_scan_ev_arg {
>>       __le32 event_type; /* %WMI_SCAN_EVENT_ */
>
>


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From s.gottschall at dd-wrt.com  Wed Jun 29 06:55:59 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Wed, 29 Jun 2016 15:55:59 +0200
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
Message-ID: <0b4949ae-9849-853f-4a14-bb8e4d36b84d@dd-wrt.com>

this fix will crash QCA9980 on QCA IPQ8064 cpu based systems.
so please rework it, or leave it out.
note:
maybe the limit of 256kb is too low for that card


    10.102047] ath10k_pci 0000:01:00.0: unable to read from the device
[   10.102075] ath10k_pci 0000:01:00.0: could not execute otp for board 
id check: -110
[   10.107116] ath10k_pci 0000:01:00.0: failed to get board id from otp: 
-110
[   10.126517] ath10k_pci 0000:01:00.0: failed to fetch board data for 
bus=pci,vendor=168c,device=0040,subsystem-vendor=168c,subsystem-device=0002 
from ath10k/QCA99X0/hw2.0/board-2.bin
[   10.126697] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A 
crc32 62700264
[   11.518268] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 
7173fc19-f807-4345-906a-9f3d17fb751b)
[   11.518307] ath10k_pci 0000:01:00.0: qca99x0 hw2.0 target 0x01000000 
chip_id 0x003b01ff sub 168c:0002
[   11.526123] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1 
tracing 0 dfs 0 testmode 0
[   11.536976] ath10k_pci 0000:01:00.0: firmware ver 10.4.1.00030-1 api 
5 features no-p2p crc32 d2901e01
[   11.543610] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A 
crc32 62700264
[   11.552770] ath10k_pci 0000:01:00.0: htt-ver 0.0 wmi-op 6 htt-op 4 
cal file max-sta 512 raw 0 hwcrypto 1
[   11.561910] ath10k_pci 0000:01:00.0: firmware register dump:
[   11.569606] ath10k_pci 0000:01:00.0: [00]: 0x01000000 0x000015B3 
0x000D89A5 0x00955B31
[   11.575252] ath10k_pci 0000:01:00.0: [04]: 0x000D89A5 0x00060730 
0x0000000C 0x00000000
[   11.582978] ath10k_pci 0000:01:00.0: [08]: 0x00000010 0x0000000D 
0x000E8A64 0xFFFFC000
[   11.590876] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000 
0x000D89BC 0x000D8A03
[   11.598846] ath10k_pci 0000:01:00.0: [16]: 0x00953438 0x000D89BE 
0x00000000 0x00000000
[   11.606676] ath10k_pci 0000:01:00.0: [20]: 0x400D89A5 0x0040655C 
0x00413A84 0x00000005
[   11.614574] ath10k_pci 0000:01:00.0: [24]: 0x809CDC6E 0x004065BC 
0x00417450 0xC00D89A5
[   11.622473] ath10k_pci 0000:01:00.0: [28]: 0x8098011C 0x0040660C 
0x004179D8 0x0000000D
[   11.630372] ath10k_pci 0000:01:00.0: [32]: 0x809CDE70 0x0040662C 
0x004179D8 0x0000000D
[   11.638272] ath10k_pci 0000:01:00.0: [36]: 0x80981786 0x0040665C 
0x004179D8 0x00000020
[   11.646171] ath10k_pci 0000:01:00.0: [40]: 0x809CE0F7 0x0040667C 
0x00000000 0x0000A000
[   11.654070] ath10k_pci 0000:01:00.0: [44]: 0x809B307A 0x004066AC 
0x00981768 0x0042028C
[   11.661970] ath10k_pci 0000:01:00.0: [48]: 0x809AF3DA 0x004066FC 
0x00000002 0x0042028C
[   11.669869] ath10k_pci 0000:01:00.0: [52]: 0x809AEB02 0x0040672C 
0x00406750 0x0041847C
[   11.677768] ath10k_pci 0000:01:00.0: [56]: 0x8094EAAA 0x0040674C 
0x000E89AC 0x00000001

Sebastian


Am 14.06.2016 um 08:17 schrieb Rajkumar Manoharan:
> commit b057886524be ("ath10k: do not use coherent memory for allocated
> device memory chunks") replaced coherent memory allocation for memory
> chunks to fix low memory platforms. Unfortunately this is causing system
> freeze on x86 platform while bringing up qca99x0 device. The system
> hangs while DMA mapping bigger memory chunks (689816/865444 bytes). Fix
> this by limiting maximum memory chunk size to 256 KiB per request.
>
> Cc: Felix Fietkau <nbd at nbd.name>
> Fixes: b057886524be ("ath10k: do not use coherent memory for allocated device memory chunks")
> Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
> ---
>   drivers/net/wireless/ath/ath10k/wmi.c | 6 ++++++
>   drivers/net/wireless/ath/ath10k/wmi.h | 1 +
>   2 files changed, 7 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> index 6279ab4a760e..7c15f65fe5ed 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -4411,6 +4411,12 @@ static int ath10k_wmi_alloc_chunk(struct ath10k *ar, u32 req_id,
>   		if (!pool_size)
>   			return -EINVAL;
>   
> +		if (pool_size > WMI_MAX_MEM_CHUNK_SIZE) {
> +			num_units = WMI_MAX_MEM_CHUNK_SIZE /
> +					round_up(unit_len, 4);
> +			pool_size = num_units * round_up(unit_len, 4);
> +		}
> +
>   		vaddr = kzalloc(pool_size, GFP_KERNEL | __GFP_NOWARN);
>   		if (!vaddr)
>   			num_units /= 2;
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
> index 90f594e89f94..dea1f235a54d 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
> @@ -6184,6 +6184,7 @@ struct wmi_roam_ev {
>   #define ATH10K_DEFAULT_ATIM 0
>   
>   #define WMI_MAX_MEM_REQS 16
> +#define WMI_MAX_MEM_CHUNK_SIZE (256 * 1024) /* 256 KB */
>   
>   struct wmi_scan_ev_arg {
>   	__le32 event_type; /* %WMI_SCAN_EVENT_ */


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From rmanohar at qti.qualcomm.com  Wed Jun 29 09:35:25 2016
From: rmanohar at qti.qualcomm.com (Manoharan, Rajkumar)
Date: Wed, 29 Jun 2016 16:35:25 +0000
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>,
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
Message-ID: <1467218124941.40575@qti.qualcomm.com>

>> Am 29.06.2016 um 16:04 schrieb Sebastian Gottschall:
>> this fix will crash QCA9980 on QCA IPQ8064 cpu based systems.
>> so please rework it, or leave it out.
>> note:
>> maybe the limit of 256kb is too low for that card
>>
> by the way. 512 works
>
Thanks a lot Sebastian. Let me confirm the same on x86 and will update the change.

-Rajkumar

From s.gottschall at dd-wrt.com  Wed Jun 29 09:58:12 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Wed, 29 Jun 2016 18:58:12 +0200
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <1467218124941.40575@qti.qualcomm.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
Message-ID: <9fd1d06e-cb8e-d032-c304-ac4c550461e9@dd-wrt.com>

Am 29.06.2016 um 18:35 schrieb Manoharan, Rajkumar:
>>> Am 29.06.2016 um 16:04 schrieb Sebastian Gottschall:
>>> this fix will crash QCA9980 on QCA IPQ8064 cpu based systems.
>>> so please rework it, or leave it out.
>>> note:
>>> maybe the limit of 256kb is too low for that card
>>>
>> by the way. 512 works
>>
> Thanks a lot Sebastian. Let me confirm the same on x86 and will update the change.
please check 9984 as well. i dont have this card right now but it seems 
it has something todo with the firmware size and the 9984 is bigger than 
9980
i'm still waiting for my sample cards
>
> -Rajkumar


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From FGervais at distech-controls.com  Wed Jun 29 11:10:12 2016
From: FGervais at distech-controls.com (Francois Gervais)
Date: Wed, 29 Jun 2016 18:10:12 +0000
Subject: ath10k usb support
Message-ID: <FA4BBBD0B3C45046B0665ADDC31528510FE798A2@DC-A-EXCH2010.DistechControls.local>

Hi,

We are evaluating the new WUSB6100M wireless adapter for use with our embedded platform. This is a wireless usb dongle based on the QCA9377 chipset.

At first glance it seems that the current ath10k driver does not support this adapter.

We'd like to know how far is the current driver from supporting this usb adapter? 

Fran?ois Gervais 
Firmware Programmer / Programmeur micrologiciel
Distech Controls, Inc.
Tel  : +1 (450) 444-9898 x 263
Fax : +1 (450) 444-0770
?
Innovative Solutions for Greener BuildingsT
www.distech-controls.com




From michal.kazior at tieto.com  Thu Jun 30 00:09:01 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 30 Jun 2016 09:09:01 +0200
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <1467218124941.40575@qti.qualcomm.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
Message-ID: <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>

On 29 June 2016 at 18:35, Manoharan, Rajkumar <rmanohar at qti.qualcomm.com> wrote:
>>> Am 29.06.2016 um 16:04 schrieb Sebastian Gottschall:
>>> this fix will crash QCA9980 on QCA IPQ8064 cpu based systems.
>>> so please rework it, or leave it out.
>>> note:
>>> maybe the limit of 256kb is too low for that card
>>>
>> by the way. 512 works

I think this suggests the problem isn't about memory chunk size limit
per se but some kind of bug in address/offset logic in fw or hw.

DMA coherent and single-map addresses use completely different ranges
in many cases. Perhaps some MSBs are not properly handled in fw or hw.
I recall there is a magic macro through which target device accesses
host memory so maybe that's a good place to look to better understand
the problem?

I recall Ben mentioned he worked around the problem by enabling
IOMMU/VT-d on his system. This could either prevent the device from
doing bad things or maybe changed DMA address ranges that are handed
out to the driver effectively or changed PCI controller behavior in
some way.


> Thanks a lot Sebastian. Let me confirm the same on x86 and will update the change.

Just changing the memory chunk size limit blindly is bad and
Sebastian's crash has proven it. 512 may seem to work now but it may
fail with a other 10.4 firmware revisions or make x86 hang in other
cases.


Micha?


From michal.kazior at tieto.com  Thu Jun 30 00:15:43 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 30 Jun 2016 09:15:43 +0200
Subject: ath10k usb support
In-Reply-To: <FA4BBBD0B3C45046B0665ADDC31528510FE798A2@DC-A-EXCH2010.DistechControls.local>
References: <FA4BBBD0B3C45046B0665ADDC31528510FE798A2@DC-A-EXCH2010.DistechControls.local>
Message-ID: <CA+BoTQm24e9U5reTRzYr2R9Gp5O2bXz6BEqTRO_0YFmv82HFKw@mail.gmail.com>

On 29 June 2016 at 20:10, Francois Gervais
<FGervais at distech-controls.com> wrote:
> Hi,
>
> We are evaluating the new WUSB6100M wireless adapter for use with our embedded platform. This is a wireless usb dongle based on the QCA9377 chipset.
>
> At first glance it seems that the current ath10k driver does not support this adapter.

Correct. ath10k supports PCI and AHB buses only.


> We'd like to know how far is the current driver from supporting this usb adapter?

Probably quite some work - extra HTT abstraction, new USB hif/bus
implementation, some HTC changes and probably some tx/rx path
readjustments.


Micha?


From johannes at sipsolutions.net  Thu Jun 30 03:07:40 2016
From: johannes at sipsolutions.net (Johannes Berg)
Date: Thu, 30 Jun 2016 12:07:40 +0200
Subject: [PATCH] mac80211: fix fq lockdep warnings
In-Reply-To: <1467201634-11060-1-git-send-email-michal.kazior@tieto.com>
 (sfid-20160629_135849_174305_00E9FE0A)
References: <1467026569-19329-1-git-send-email-michal.kazior@tieto.com>
 <1467201634-11060-1-git-send-email-michal.kazior@tieto.com>
 (sfid-20160629_135849_174305_00E9FE0A)
Message-ID: <1467281260.2499.4.camel@sipsolutions.net>

On Wed, 2016-06-29 at 14:00 +0200, Michal Kazior wrote:
> Some lockdep assertions were not fulfilled and
> resulted in a kernel warning/call trace if driver
> used intermediate software queues (e.g. ath10k).
> 
> Existing code sequences should've guranteed safety
> but it's always good to be extra careful.
> 
Applied.

johannes


From kvalo at qca.qualcomm.com  Thu Jun 30 03:25:16 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 30 Jun 2016 10:25:16 +0000
Subject: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for
 QCA99X0 and later
In-Reply-To: <576F2165.3010109@candelatech.com> (Ben Greear's message of "Sat, 
 25 Jun 2016 17:27:17 -0700")
References: <1466700001-4883-1-git-send-email-mohammed@qca.qualcomm.com>
 <1466700001-4883-2-git-send-email-mohammed@qca.qualcomm.com>
 <576C1861.7020402@candelatech.com>
 <20160625185350.GA25330@atheros-ThinkPad-T61>
 <576F2165.3010109@candelatech.com>
Message-ID: <8760sr6kj8.fsf@kamboji.qca.qualcomm.com>

Ben Greear <greearb at candelatech.com> writes:

> Is there a better way than posting to the ath10k mailing list?  There are quite
> a few more of my patches that are stuck in pending or ignored state.  If you
> could review some of them and add them to your testing trees then it might help
> them go upstream.

Yes, as you seem to test with your custom ath10k and custom firmware
review and testing feedback from others is more than welcome. That way I
can have more confidence that the patch really works with the mainline
version.

The problem with your patches is that you dump more responsibility on
me. I have no idea if they work with the mainline kernel, or if they
break something, so I need to personally test the patch and that takes
time. Basically I have a rule if that I need to use more than two
minutes on a patch it goes to the Deferred queue and I'll go through
that less often than the normal patch queue.

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Thu Jun 30 03:44:47 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 30 Jun 2016 10:44:47 +0000
Subject: [PATCH v3] ath10k: Fix 10.4 extended peer stats update
In-Reply-To: <1464851602-12969-1-git-send-email-mohammed@qca.qualcomm.com>
 (Mohammed Shafi Shajakhan's message of "Thu, 2 Jun 2016 12:43:22	+0530")
References: <1464851602-12969-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <87vb0r5529.fsf@kamboji.qca.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> writes:

> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
>
> 10.4 'extended peer stats' will be not be appended with normal peer stats
> data and they shall be coming in separate chunks. Fix this by maintaining
> a separate linked list 'extender peer stats' for 10.4 and update
> rx_duration for per station statistics. Also parse through beacon filter
> (if enabled), to make sure we parse the extended peer stats properly.
> This issue was exposed when more than one client is connected and
> extended peer stats for 10.4 is enabled
>
> The order for the stats is as below
> S - standard peer stats, E- extended peer stats, B - beacon filter stats
>
> {S1, S2, S3..} -> {B1, B2, B3..}(if available) -> {E1, E2, E3..}
>
> Fixes: f9575793d44c ("ath10k: enable parsing per station rx duration for 10.4")
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> ---
> [v1: addressed line wrap around comment from Kalle]
> [v2: fixed ; in dummy inline function definition - thanks Sven Eckelmann]
> [v3: removed wmi-op-version suggested by Kalle, introduced fw specifi hw param for extd_stats]

I was sure I replied to this, but I can't find my reply anywhere. So I
guess I didn't, sorry about that.

> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -181,6 +181,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
>  			.board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
>  			.board_size = QCA99X0_BOARD_DATA_SZ,
>  			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> +			.extd_peer_stats = true,
>  		},
>  	},
>  	{
> @@ -203,6 +204,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
>  			.board = QCA9984_HW_1_0_BOARD_DATA_FILE,
>  			.board_size = QCA99X0_BOARD_DATA_SZ,
>  			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> +			.extd_peer_stats = true,
>  		},
>  	},
>  	{
> @@ -261,6 +263,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
>  			.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
>  			.board_size = QCA4019_BOARD_DATA_SZ,
>  			.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
> +			.extd_peer_stats = true,
>  		},
>  	},
>  };

This is not a hardware feature so hw_params is not really the right
place to handle this. In the pending branch I tried to solve this a bit
differently:

https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=ecf4daadc7677518ec7185dbddab959ac6e2db96

I added a bool "extended" to struct ath10k_fw_stats which is used to
detect if extended stats are used. Would that work? Please note that I
have only compile tested the patch.

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Thu Jun 30 03:49:02 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 30 Jun 2016 10:49:02 +0000
Subject: [PATCH v3] ath10k: Fix 10.4 extended peer stats update
In-Reply-To: <87vb0r5529.fsf@kamboji.qca.qualcomm.com> (Kalle Valo's message
 of "Thu, 30 Jun 2016 13:44:46 +0300")
References: <1464851602-12969-1-git-send-email-mohammed@qca.qualcomm.com>
 <87vb0r5529.fsf@kamboji.qca.qualcomm.com>
Message-ID: <87r3bf54v6.fsf@kamboji.qca.qualcomm.com>

Kalle Valo <kvalo at qca.qualcomm.com> writes:

>> @@ -261,6 +263,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
>>  			.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
>>  			.board_size = QCA4019_BOARD_DATA_SZ,
>>  			.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
>> +			.extd_peer_stats = true,
>>  		},
>>  	},
>>  };
>
> This is not a hardware feature so hw_params is not really the right
> place to handle this. In the pending branch I tried to solve this a bit
> differently:
>
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=ecf4daadc7677518ec7185dbddab959ac6e2db96
>
> I added a bool "extended" to struct ath10k_fw_stats which is used to
> detect if extended stats are used. Would that work? Please note that I
> have only compile tested the patch.

Here's a diff of what I did:

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 58932c09efc5..b734345ab598 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -180,7 +180,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
 			.board_size = QCA99X0_BOARD_DATA_SZ,
 			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
-			.extd_peer_stats = true,
 		},
 	},
 	{
@@ -203,7 +202,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board = QCA9984_HW_1_0_BOARD_DATA_FILE,
 			.board_size = QCA99X0_BOARD_DATA_SZ,
 			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
-			.extd_peer_stats = true,
 		},
 	},
 	{
@@ -261,7 +259,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
 			.board_size = QCA4019_BOARD_DATA_SZ,
 			.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
-			.extd_peer_stats = true,
 		},
 	},
 };
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 73a0b1ae1559..3707d8a707a2 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -263,6 +263,7 @@ struct ath10k_fw_stats_pdev {
 };
 
 struct ath10k_fw_stats {
+	bool extended;
 	struct list_head pdevs;
 	struct list_head vdevs;
 	struct list_head peers;
@@ -754,7 +755,6 @@ struct ath10k {
 			const char *board;
 			size_t board_size;
 			size_t board_ext_size;
-			bool extd_peer_stats;
 		} fw;
 	} hw_params;
 
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 001c0a144614..355e1ae665f9 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -327,6 +327,7 @@ static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
 {
 	spin_lock_bh(&ar->data_lock);
 	ar->debug.fw_stats_done = false;
+	ar->debug.fw_stats.extended = false;
 	ath10k_fw_stats_pdevs_free(&ar->debug.fw_stats.pdevs);
 	ath10k_fw_stats_vdevs_free(&ar->debug.fw_stats.vdevs);
 	ath10k_fw_stats_peers_free(&ar->debug.fw_stats.peers);
diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
index af3d49af9eab..0da8a57e0ba7 100644
--- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
+++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
@@ -19,14 +19,14 @@
 #include "debug.h"
 
 static void ath10k_sta_update_extd_stats_rx_duration(struct ath10k *ar,
-						     struct list_head *head)
+						     struct ath10k_fw_stats *stats)
 {
-	struct ieee80211_sta *sta;
 	struct ath10k_fw_extd_stats_peer *peer;
+	struct ieee80211_sta *sta;
 	struct ath10k_sta *arsta;
 
 	rcu_read_lock();
-	list_for_each_entry(peer, head, list) {
+	list_for_each_entry(peer, &stats->peers_extd, list) {
 		sta = ieee80211_find_sta_by_ifaddr(ar->hw, peer->peer_macaddr,
 						   NULL);
 		if (!sta)
@@ -38,13 +38,14 @@ static void ath10k_sta_update_extd_stats_rx_duration(struct ath10k *ar,
 }
 
 static void ath10k_sta_update_stats_rx_duration(struct ath10k *ar,
-						struct list_head *head)
-{	struct ieee80211_sta *sta;
+						struct ath10k_fw_stats *stats)
+{
 	struct ath10k_fw_stats_peer *peer;
+	struct ieee80211_sta *sta;
 	struct ath10k_sta *arsta;
 
 	rcu_read_lock();
-	list_for_each_entry(peer, head, list) {
+	list_for_each_entry(peer, &stats->peers, list) {
 		sta = ieee80211_find_sta_by_ifaddr(ar->hw, peer->peer_macaddr,
 						   NULL);
 		if (!sta)
@@ -58,11 +59,10 @@ static void ath10k_sta_update_stats_rx_duration(struct ath10k *ar,
 void ath10k_sta_update_rx_duration(struct ath10k *ar,
 				   struct ath10k_fw_stats *stats)
 {
-	if (ar->hw_params.fw.extd_peer_stats)
-		ath10k_sta_update_stats_rx_duration(ar, &stats->peers);
+	if (stats->extended)
+		ath10k_sta_update_extd_stats_rx_duration(ar, stats);
 	else
-		ath10k_sta_update_extd_stats_rx_duration(ar,
-							 &stats->peers_extd);
+		ath10k_sta_update_stats_rx_duration(ar, stats);
 }
 
 static ssize_t ath10k_dbg_sta_read_aggr_mode(struct file *file,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 5f2d423b1c33..16bd79716a6c 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3008,6 +3008,8 @@ static int ath10k_wmi_10_4_op_pull_fw_stats(struct ath10k *ar,
 	if ((stats_id & WMI_10_4_STAT_PEER_EXTD) == 0)
 		return 0;
 
+	stats->extended = true;
+
 	for (i = 0; i < num_peer_stats; i++) {
 		const struct wmi_10_4_peer_extd_stats *src;
 		struct ath10k_fw_extd_stats_peer *dst;


-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Thu Jun 30 03:51:13 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 30 Jun 2016 12:51:13 +0200
Subject: [v2] ath10k: Fix crash during card removal
In-Reply-To: <1465478927-21401-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <d95e54d0554c4c55aae695d5be61d9ed@euamsexm01a.eu.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> Usually when the firmware crashes we check for the value
> 'FW_IND_EVENT_PENDING' in 'FW_INDICATOR_ADDRESS' and proceed with
> disabling the irq and dumping firmware 'crash dump'. Now
> when the PCI card is unplugged from the device the PCI controller
> seems to generate a spurious interrupt after some time which
> was as treated a firmware crash and resulting in the below race
> condition (and eventually crashing the system)
> 
> 	ath10k_core_unregister -> ath10k_core_free_board_files
> 
> 	...... device unplug spurious interrupt .........
> 
> 	ath10k_pci_taklet -> ath10k_pci_fw_crashed_dump  ...etc
> 
> Clearly even after the firmware board files related data structure
> is freed up we are getting a spurious interrupt from PCI with 0xfffffff
> in the 'FW_INDICATOR_ADDRESS' resulting in scheduling of the pci tasklet
> and doing a crash dump, printing f/w board related info resulting in the
> below crash. Fix this by detecting this spurious interrupt in ath10k PCI
> irq handler itself and return IRQ_NONE. Thanks to Michal Kazior for
> helping us conclude the most appropriate fix.
> 
> Call trace:
> 
>  EIP is at ath10k_debug_print_board_info+0x39/0xb0
> [ath10k_core]
> EAX: 00000000 EBX: d4de15a0 ECX: 00000000 EDX: 00000064
> ESI: f615ddd0 EDI: f8530000 EBP: f615de3c ESP: f615ddbc
>  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> CR0: 80050033 CR2: 00000004 CR3: 01c0a000 CR4: 000006f0
> Stack:
>  f615ddd0 00000064 f8b4ecdd 00000000 00000000 00412f4e
> 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000
>  00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000
> Call Trace:
>   [<f8b1f517>] ath10k_print_driver_info+0x17/0x30
> [ath10k_core]
> [<f875463a>] ath10k_pci_fw_crashed_dump+0x7a/0xe0
> [ath10k_pci]
> [<f87549d0>] ath10k_pci_tasklet+0x70/0x90 [ath10k_pci]
> [<c106151e>] tasklet_action+0x9e/0xb0
> 
> Cc: Michal Kazior <michal.kazior at tieto.com>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Thanks, 1 patch applied to ath-next branch of ath.git:

fb7caababc02 ath10k: fix crash during card removal

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9167045/



From kvalo at qca.qualcomm.com  Thu Jun 30 03:52:51 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 30 Jun 2016 12:52:51 +0200
Subject: ath10k: Remove unneccessary WARN_ON_ONCE in rx during ACS
In-Reply-To: <1465478991-21449-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <0a498de131ae439883db7f1e239c5272@euamsexm01a.eu.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> The below warning message seems to hit occasionally with the following
> combination (IPQ4019 + ACS scan) where we receive packets as a self peer
> when hostapd does ACS when we bring up AP mode . ath10k has the below
> fall back mechanism to fetch current operating channel in rx (it will
> check for the next channel tracking variable if the current one is NULL)
> 
> 	[scan channel] --> [rx channel] --> [peer channel] -->
> 	[vdev channel] -->  [any vdev channel] --> [target oper channel]
> 
> 'scan channel' and 'target operating channel' are directly fetched from
> firmware events. All the others should be updated by mac80211.
> 
> During ACS scan we wouldn't have a valid channel context
> assigned from mac80211 ('ar->rx_channel'), and also relying on
> ('ar->scan_channel') is not helpful (it becomes NULL when it goes to
> BSS channel and also when the scan event is completed). In short we
> cannot always rely on these two channel tracking variables.
> 
> 'Target Operating Channel' (ar->tgt_oper_chan) seems to keep track of
> the current operating even while we are doing ACS scan and etc. Hence
> remove this un-necessary warning message and continue with
> target_operating channel. At the worst case scenario when the target
> operating channel is invalid (NULL) we already have an ath10k warning
> message to notify we really don't have a proper channel configured in
> rx to update the rx status("no channel configured; ignoring frame(s)!")
> 
>     WARNING: CPU: 0 PID: 0 at ath/ath10k/htt_rx.c:803
>     [<c0318838>] (warn_slowpath_null) from [<bf4a0104>]
>     (ath10k_htt_rx_h_channel+0xe0/0x1b8 [ath10k_core])
>     [<bf4a0104>] (ath10k_htt_rx_h_channel [ath10k_core]) from
>     [<bf4a025c>] (ath10k_htt_rx_h_ppdu+0x80/0x288 [ath10k_core])
>     [<bf4a025c>] (ath10k_htt_rx_h_ppdu [ath10k_core]) from
>     [<bf4a1a9c>] (ath10k_htt_txrx_compl_task+0x724/0x9d4 [ath10k_core])
>     [<bf4a1a9c>] (ath10k_htt_txrx_compl_task [ath10k_core])
> 
> Fixes:3b0499e9ce42 ("ath10k: reduce warning messages during rx without proper channel context")
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Thanks, 1 patch applied to ath-next branch of ath.git:

569fba2cbb6d ath10k: remove unneccessary WARN_ON_ONCE in rx during ACS

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9167049/



From kvalo at qca.qualcomm.com  Thu Jun 30 03:54:40 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 30 Jun 2016 12:54:40 +0200
Subject: ath10k: fix potential null dereference bugs
In-Reply-To: <1465563164-783-1-git-send-email-me@bobcopeland.com>
Message-ID: <fa78b1942cf2454898cc33b31a253b81@euamsexm01a.eu.qualcomm.com>

Bob Copeland <me at bobcopeland.com> wrote:
> Smatch warns about a number of cases in ath10k where a pointer is
> null-checked after it has already been dereferenced, in code involving
> ath10k private virtual interface pointers.
> 
> Fix these by making the dereference happen later.
> 
> Addresses the following smatch warnings:
> 
> drivers/net/wireless/ath/ath10k/mac.c:3651 ath10k_mac_txq_init() warn: variable dereferenced before check 'txq' (see line 3649)
> drivers/net/wireless/ath/ath10k/mac.c:3664 ath10k_mac_txq_unref() warn: variable dereferenced before check 'txq' (see line 3659)
> drivers/net/wireless/ath/ath10k/htt_tx.c:70 __ath10k_htt_tx_txq_recalc() warn: variable dereferenced before check 'txq->sta' (see line 52)
> drivers/net/wireless/ath/ath10k/htt_tx.c:740 ath10k_htt_tx_get_vdev_id() warn: variable dereferenced before check 'cb->vif' (see line 736)
> drivers/net/wireless/ath/ath10k/txrx.c:86 ath10k_txrx_tx_unref() warn: variable dereferenced before check 'txq' (see line 84)
> drivers/net/wireless/ath/ath10k/wmi.c:1837 ath10k_wmi_op_gen_mgmt_tx() warn: variable dereferenced before check 'cb->vif' (see line 1825)
> 
> Signed-off-by: Bob Copeland <me at bobcopeland.com>

Thanks, 1 patch applied to ath-next branch of ath.git:

a66cd733a729 ath10k: fix potential null dereference bugs

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9169669/



From mohammed at codeaurora.org  Thu Jun 30 03:59:51 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Thu, 30 Jun 2016 16:29:51 +0530
Subject: [PATCH v3] ath10k: Fix 10.4 extended peer stats update
In-Reply-To: <87r3bf54v6.fsf@kamboji.qca.qualcomm.com>
References: <1464851602-12969-1-git-send-email-mohammed@qca.qualcomm.com>
 <87vb0r5529.fsf@kamboji.qca.qualcomm.com>
 <87r3bf54v6.fsf@kamboji.qca.qualcomm.com>
Message-ID: <20160630105951.GA10001@atheros-ThinkPad-T61>

Hi Kalle,

On Thu, Jun 30, 2016 at 10:49:02AM +0000, Valo, Kalle wrote:
> Kalle Valo <kvalo at qca.qualcomm.com> writes:
> 
> >> @@ -261,6 +263,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
> >>  			.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
> >>  			.board_size = QCA4019_BOARD_DATA_SZ,
> >>  			.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
> >> +			.extd_peer_stats = true,
> >>  		},
> >>  	},
> >>  };
> >
> > This is not a hardware feature so hw_params is not really the right
> > place to handle this. In the pending branch I tried to solve this a bit
> > differently:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=ecf4daadc7677518ec7185dbddab959ac6e2db96
> >
> > I added a bool "extended" to struct ath10k_fw_stats which is used to
> > detect if extended stats are used. Would that work? Please note that I
> > have only compile tested the patch.

[shafi] thanks for taking time to do this, the change looks fine to me !
since 'ath10k_sta_update_rx_duration' is called right after 'ath10k_wmi_pull_fw_stats'
this should properly update the rx_duration based on the current data

> 
> Here's a diff of what I did:
> 
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> index 58932c09efc5..b734345ab598 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -180,7 +180,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
>  			.board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
>  			.board_size = QCA99X0_BOARD_DATA_SZ,
>  			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> -			.extd_peer_stats = true,
>  		},
>  	},
>  	{
> @@ -203,7 +202,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
>  			.board = QCA9984_HW_1_0_BOARD_DATA_FILE,
>  			.board_size = QCA99X0_BOARD_DATA_SZ,
>  			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> -			.extd_peer_stats = true,
>  		},
>  	},
>  	{
> @@ -261,7 +259,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
>  			.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
>  			.board_size = QCA4019_BOARD_DATA_SZ,
>  			.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
> -			.extd_peer_stats = true,
>  		},
>  	},
>  };
> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> index 73a0b1ae1559..3707d8a707a2 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -263,6 +263,7 @@ struct ath10k_fw_stats_pdev {
>  };
>  
>  struct ath10k_fw_stats {
> +	bool extended;
>  	struct list_head pdevs;
>  	struct list_head vdevs;
>  	struct list_head peers;
> @@ -754,7 +755,6 @@ struct ath10k {
>  			const char *board;
>  			size_t board_size;
>  			size_t board_ext_size;
> -			bool extd_peer_stats;
>  		} fw;
>  	} hw_params;
>  
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> index 001c0a144614..355e1ae665f9 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -327,6 +327,7 @@ static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
>  {
>  	spin_lock_bh(&ar->data_lock);
>  	ar->debug.fw_stats_done = false;
> +	ar->debug.fw_stats.extended = false;
>  	ath10k_fw_stats_pdevs_free(&ar->debug.fw_stats.pdevs);
>  	ath10k_fw_stats_vdevs_free(&ar->debug.fw_stats.vdevs);
>  	ath10k_fw_stats_peers_free(&ar->debug.fw_stats.peers);
> diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> index af3d49af9eab..0da8a57e0ba7 100644
> --- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> +++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> @@ -19,14 +19,14 @@
>  #include "debug.h"
>  
>  static void ath10k_sta_update_extd_stats_rx_duration(struct ath10k *ar,
> -						     struct list_head *head)
> +						     struct ath10k_fw_stats *stats)
>  {
> -	struct ieee80211_sta *sta;
>  	struct ath10k_fw_extd_stats_peer *peer;
> +	struct ieee80211_sta *sta;
>  	struct ath10k_sta *arsta;
>  
>  	rcu_read_lock();
> -	list_for_each_entry(peer, head, list) {
> +	list_for_each_entry(peer, &stats->peers_extd, list) {
>  		sta = ieee80211_find_sta_by_ifaddr(ar->hw, peer->peer_macaddr,
>  						   NULL);
>  		if (!sta)
> @@ -38,13 +38,14 @@ static void ath10k_sta_update_extd_stats_rx_duration(struct ath10k *ar,
>  }
>  
>  static void ath10k_sta_update_stats_rx_duration(struct ath10k *ar,
> -						struct list_head *head)
> -{	struct ieee80211_sta *sta;
> +						struct ath10k_fw_stats *stats)
> +{
>  	struct ath10k_fw_stats_peer *peer;
> +	struct ieee80211_sta *sta;
>  	struct ath10k_sta *arsta;
>  
>  	rcu_read_lock();
> -	list_for_each_entry(peer, head, list) {
> +	list_for_each_entry(peer, &stats->peers, list) {
>  		sta = ieee80211_find_sta_by_ifaddr(ar->hw, peer->peer_macaddr,
>  						   NULL);
>  		if (!sta)
> @@ -58,11 +59,10 @@ static void ath10k_sta_update_stats_rx_duration(struct ath10k *ar,
>  void ath10k_sta_update_rx_duration(struct ath10k *ar,
>  				   struct ath10k_fw_stats *stats)
>  {
> -	if (ar->hw_params.fw.extd_peer_stats)
> -		ath10k_sta_update_stats_rx_duration(ar, &stats->peers);
> +	if (stats->extended)
> +		ath10k_sta_update_extd_stats_rx_duration(ar, stats);
>  	else
> -		ath10k_sta_update_extd_stats_rx_duration(ar,
> -							 &stats->peers_extd);
> +		ath10k_sta_update_stats_rx_duration(ar, stats);
>  }
>  
>  static ssize_t ath10k_dbg_sta_read_aggr_mode(struct file *file,
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> index 5f2d423b1c33..16bd79716a6c 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -3008,6 +3008,8 @@ static int ath10k_wmi_10_4_op_pull_fw_stats(struct ath10k *ar,
>  	if ((stats_id & WMI_10_4_STAT_PEER_EXTD) == 0)
>  		return 0;
>  
> +	stats->extended = true;
> +
>  	for (i = 0; i < num_peer_stats; i++) {
>  		const struct wmi_10_4_peer_extd_stats *src;
>  		struct ath10k_fw_extd_stats_peer *dst;
> 
> 
> -- 
> Kalle Valo


From kvalo at qca.qualcomm.com  Thu Jun 30 04:00:05 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 30 Jun 2016 13:00:05 +0200
Subject: ath10k: Enable beacon loss detection support for 10.4
In-Reply-To: <1466081684-8074-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <f1028a60ba004c749ae647ad38c7382a@euamsexm01a.eu.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> Enable beacon loss detection support for 10.4 by handling
> roam event. With this change QCA99X0 station is able to
> detect beacon loss when the AP is powered off
> 
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Thanks, 1 patch applied to ath-next branch of ath.git:

343bf960f03c ath10k: enable beacon loss detection support for 10.4

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9180777/



From kvalo at qca.qualcomm.com  Thu Jun 30 04:01:03 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 30 Jun 2016 13:01:03 +0200
Subject: ath10k: Disable TX_STBC for tx chainmask of 1
In-Reply-To: <1466081713-8122-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <acc7cf0119594113851574777077856c@euamsexm01a.eu.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> Disable TX_STBC for both HT and VHT if the devices tx chainmask is '1'
> TX_STBC is required only for devices with tx_chainmask > 1. This fixes
> a ping failure for QCA9887 (1x1) in HT/VHT mode
> 
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Thanks, 1 patch applied to ath-next branch of ath.git:

34663241d81f ath10k: disable TX_STBC for tx chainmask of 1

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9180781/



From kvalo at qca.qualcomm.com  Thu Jun 30 04:05:12 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 30 Jun 2016 13:05:12 +0200
Subject: [v2] ath10k: Fix some typo in spectral code commments
In-Reply-To: <1466093628-10653-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <0ec846ef6718438d8d5a73f34b87f572@euamsexm01a.eu.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> Found this obvious typo while going through the spectral
> code design in ath10k
> 
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Thanks, 1 patch applied to ath-next branch of ath.git:

3fa35bacc16a ath10k: fix some typo in spectral code commments

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9181333/



From kvalo at qca.qualcomm.com  Thu Jun 30 04:09:31 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 30 Jun 2016 11:09:31 +0000
Subject: [PATCH v3] ath10k: Fix 10.4 extended peer stats update
In-Reply-To: <20160630105951.GA10001@atheros-ThinkPad-T61> (Mohammed Shafi
 Shajakhan's message of "Thu, 30 Jun 2016 16:29:51 +0530")
References: <1464851602-12969-1-git-send-email-mohammed@qca.qualcomm.com>
 <87vb0r5529.fsf@kamboji.qca.qualcomm.com>
 <87r3bf54v6.fsf@kamboji.qca.qualcomm.com>
 <20160630105951.GA10001@atheros-ThinkPad-T61>
Message-ID: <87mvm353x1.fsf@kamboji.qca.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at codeaurora.org> writes:

> Hi Kalle,
>
> On Thu, Jun 30, 2016 at 10:49:02AM +0000, Valo, Kalle wrote:
>> Kalle Valo <kvalo at qca.qualcomm.com> writes:
>> 
>> >> @@ -261,6 +263,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
>> >>  			.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
>> >>  			.board_size = QCA4019_BOARD_DATA_SZ,
>> >>  			.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
>> >> +			.extd_peer_stats = true,
>> >>  		},
>> >>  	},
>> >>  };
>> >
>> > This is not a hardware feature so hw_params is not really the right
>> > place to handle this. In the pending branch I tried to solve this a bit
>> > differently:
>> >
>> > https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=ecf4daadc7677518ec7185dbddab959ac6e2db96
>> >
>> > I added a bool "extended" to struct ath10k_fw_stats which is used to
>> > detect if extended stats are used. Would that work? Please note that I
>> > have only compile tested the patch.
>
> [shafi] thanks for taking time to do this, the change looks fine to me !
> since 'ath10k_sta_update_rx_duration' is called right after 'ath10k_wmi_pull_fw_stats'
> this should properly update the rx_duration based on the current data

Could you also run some tests to make sure? I don't trust my own code :)

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Thu Jun 30 04:26:22 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 30 Jun 2016 11:26:22 +0000
Subject: [PATCH 1/2] ath10k: remove unused <linux/semaphore.h>
In-Reply-To: <bf7b2008-b333-2d79-a952-fda895da8479@cogentembedded.com> (Sergei
 Shtylyov's message of "Tue, 21 Jun 2016 16:46:00 +0300")
References: <20160621114539.15313-1-chaehyun.lim@gmail.com>
 <bf7b2008-b333-2d79-a952-fda895da8479@cogentembedded.com>
Message-ID: <87inwq6hpe.fsf@kamboji.qca.qualcomm.com>

Sergei Shtylyov <sergei.shtylyov at cogentembedded.com> writes:

> On 6/21/2016 2:45 PM, Chaehyun Lim wrote:
>
>> <linux/semaphore.h> is not used anymore, so just remove it.
>
>    s/it/#include/?

Fixed that in the pending branch.

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Thu Jun 30 04:36:26 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 30 Jun 2016 11:36:26 +0000
Subject: [PATCHV2 3/3] ath10k: add testmode support for 10.4 firmware
In-Reply-To: <1467018454-24530-1-git-send-email-c_traja@qti.qualcomm.com> (c.
 traja's message of "Mon, 27 Jun 2016 14:37:34 +0530")
References: <1467018454-24530-1-git-send-email-c_traja@qti.qualcomm.com>
Message-ID: <87eg7e6h8n.fsf@kamboji.qca.qualcomm.com>

<c_traja at qti.qualcomm.com> writes:

> From: Tamizh chelvam <c_traja at qti.qualcomm.com>
>
> This patch adds testmode support for QCA99X0 chipsets which uses
> 10.4 firmware and added code swap support for UTF binary.
>
> Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>

There were few checkpatch warnings, I fixed them in the pending branch:

$ ath10k-check 
drivers/net/wireless/ath/ath10k/testmode.c:247: Alignment should match open parenthesis
drivers/net/wireless/ath/ath10k/testmode.c:250: Alignment should match open parenthesis
drivers/net/wireless/ath/ath10k/testmode.c:298: Alignment should match open parenthesis
drivers/net/wireless/ath/ath10k/testmode.c:325: Alignment should match open parenthesis

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Thu Jun 30 05:40:16 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 30 Jun 2016 12:40:16 +0000
Subject: [PATCHV2 1/3] ath10k: move firmware_swap_code_seg_info to
 ath10k_fw_file
In-Reply-To: <1467018404-24460-1-git-send-email-c_traja@qti.qualcomm.com> (c.
 traja's message of "Mon, 27 Jun 2016 14:36:44 +0530")
References: <1467018404-24460-1-git-send-email-c_traja@qti.qualcomm.com>
Message-ID: <8760sq6ea9.fsf@kamboji.qca.qualcomm.com>

<c_traja at qti.qualcomm.com> writes:

> From: Tamizh chelvam <c_traja at qti.qualcomm.com>
>
> Preparation to make use of firmware_swap_code_seg_info for
> UTF binary.
>
> Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>

This patchset crashes my x86 laptop once I start hostapd. Unfortunately
I can't provide any logs as I don't have netconsole set up yet, but this
is the board I'm using:

[   58.481559] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[   58.633122] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
[   58.633126] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 0 testmode 1
[   58.633318] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.52 api 5 features no-p2p,raw-mode,mfp crc32 67c4d25c
[   58.690098] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
[   59.950554] ath10k_pci 0000:02:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1

-- 
Kalle Valo

From FGervais at distech-controls.com  Thu Jun 30 07:13:20 2016
From: FGervais at distech-controls.com (Francois Gervais)
Date: Thu, 30 Jun 2016 14:13:20 +0000
Subject: ath10k usb support
In-Reply-To: <CA+BoTQm24e9U5reTRzYr2R9Gp5O2bXz6BEqTRO_0YFmv82HFKw@mail.gmail.com>
References: <FA4BBBD0B3C45046B0665ADDC31528510FE798A2@DC-A-EXCH2010.DistechControls.local>
 <CA+BoTQm24e9U5reTRzYr2R9Gp5O2bXz6BEqTRO_0YFmv82HFKw@mail.gmail.com>
Message-ID: <FA4BBBD0B3C45046B0665ADDC31528510FE7AAFB@DC-A-EXCH2010.DistechControls.local>

Is there any plans for this implementation? We would be willing to offer resources to help this development if possible.

Fran?ois Gervais 
Firmware Programmer / Programmeur micrologiciel
Distech Controls, Inc.
Tel  : +1 (450) 444-9898 x 263
Fax : +1 (450) 444-0770

Innovative Solutions for Greener Buildings?
www.distech-controls.com

-----Original Message-----
From: Michal Kazior [mailto:michal.kazior at tieto.com] 
Sent: June 30, 2016 3:16 AM
To: Francois Gervais
Cc: ath10k at lists.infradead.org
Subject: Re: ath10k usb support

On 29 June 2016 at 20:10, Francois Gervais <FGervais at distech-controls.com> wrote:
> Hi,
>
> We are evaluating the new WUSB6100M wireless adapter for use with our embedded platform. This is a wireless usb dongle based on the QCA9377 chipset.
>
> At first glance it seems that the current ath10k driver does not support this adapter.

Correct. ath10k supports PCI and AHB buses only.


> We'd like to know how far is the current driver from supporting this usb adapter?

Probably quite some work - extra HTT abstraction, new USB hif/bus implementation, some HTC changes and probably some tx/rx path readjustments.


Micha?

From mohammed at codeaurora.org  Thu Jun 30 12:49:49 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Fri, 1 Jul 2016 01:19:49 +0530
Subject: [PATCH v3] ath10k: Fix 10.4 extended peer stats update
In-Reply-To: <87mvm353x1.fsf@kamboji.qca.qualcomm.com>
References: <1464851602-12969-1-git-send-email-mohammed@qca.qualcomm.com>
 <87vb0r5529.fsf@kamboji.qca.qualcomm.com>
 <87r3bf54v6.fsf@kamboji.qca.qualcomm.com>
 <20160630105951.GA10001@atheros-ThinkPad-T61>
 <87mvm353x1.fsf@kamboji.qca.qualcomm.com>
Message-ID: <20160630194949.GA13923@atheros-ThinkPad-T61>

On Thu, Jun 30, 2016 at 11:09:31AM +0000, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan <mohammed at codeaurora.org> writes:
> 
> > Hi Kalle,
> >
> > On Thu, Jun 30, 2016 at 10:49:02AM +0000, Valo, Kalle wrote:
> >> Kalle Valo <kvalo at qca.qualcomm.com> writes:
> >> 
> >> >> @@ -261,6 +263,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
> >> >>  			.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
> >> >>  			.board_size = QCA4019_BOARD_DATA_SZ,
> >> >>  			.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
> >> >> +			.extd_peer_stats = true,
> >> >>  		},
> >> >>  	},
> >> >>  };
> >> >
> >> > This is not a hardware feature so hw_params is not really the right
> >> > place to handle this. In the pending branch I tried to solve this a bit
> >> > differently:
> >> >
> >> > https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=ecf4daadc7677518ec7185dbddab959ac6e2db96
> >> >
> >> > I added a bool "extended" to struct ath10k_fw_stats which is used to
> >> > detect if extended stats are used. Would that work? Please note that I
> >> > have only compile tested the patch.
> >
> > [shafi] thanks for taking time to do this, the change looks fine to me !
> > since 'ath10k_sta_update_rx_duration' is called right after 'ath10k_wmi_pull_fw_stats'
> > this should properly update the rx_duration based on the current data
> 
> Could you also run some tests to make sure? I don't trust my own code :)
>
[shafi] sure no problem, will do that, thanks for fixing this properly

regards,
shafi


