From jp.tosoni at acksys.fr  Thu Dec  1 01:13:30 2016
From: jp.tosoni at acksys.fr (Jean-Pierre Tosoni)
Date: Thu, 1 Dec 2016 10:13:30 +0100
Subject: Client station sends probes on DFS channels
In-Reply-To: <CAJ-Vmom1EDyHH8Pcuxq83ptsYEGj0LWeDCNvx7gDAUKQmbWZ6g@mail.gmail.com>
References: <006401d24b34$191d7830$4b586890$@acksys.fr>
 <CAJ-Vmom1EDyHH8Pcuxq83ptsYEGj0LWeDCNvx7gDAUKQmbWZ6g@mail.gmail.com>
Message-ID: <008001d24bb3$2f1e4db0$8d5ae910$@acksys.fr>

Hi Adrian,

> What's the etsi spec say about once a station hears beacons?

What ETSI EN301893 v1.8.1 [1] says is:

1) ETSI distinguishes "master" devices and "slave" devices
   (section 4.7.1.3)

2) "Slaves shall only operate in a network controlled by (...) a master"
   (section 4.7.1.3)

3) "A slave device shall stop its transmissions on a channel whenever
   instructed by a master device" (section 4.7.1.4)
   => In my understanding, from a 802.11 point of view, this implies that
      The slave obeys the master, hence it is associated with it "somehow".
      Otherwise, the station must be considered as being a master.

4) Channel move time: the slave must stop transmission within *10 seconds*
   After being instructed so (section 4.7.2.5.1 and table D.1)

5) During these 10 seconds, the airtime used must not exceed 1 second.


So,
- either any unrelated AP is considered a master, and when beacons
  cease this should be considered a hint to stop within 10 seconds,
- or the unassociated client is considered a master itself, and
  must obey CAC, NOP and so on.

Hence I think the relevant duration is the "channel move time" in table D.1
which is limited to 10 seconds -- instead of 10 minutes.

Jean-Pierre

De : Adrian Chadd [mailto:adrian.chadd at gmail.com] 
Envoy? : mercredi 30 novembre 2016 21:41
? : Jean-Pierre Tosoni
Cc : ath10k at lists.infradead.org
Objet : Re: Client station sends probes on DFS channels

Hi,
I thought that seeing beacons meant the sea could treat it as non passive for a while. Ten minutes sounds about right.
What's the etsi spec say about once a station hears beacons?
A

On Nov 30, 2016 12:36 PM, "Jean-Pierre Tosoni" <jp.tosoni at acksys.fr> wrote:
Hello list,

There is a case where I can see probes on a DFS channel, from a
non-associated station using ath10k. (note that the problem does
not arise when using ath9k).

*The setup*

I am using Openwrt, wpa_supplicant and compat-wireless 2016-10-08,
Card firmware is ath10k_pci: qca988x hw2.0 (0x4100016c, 0x043202ff)
                fw 10.2.4.70-2 api 5 htt-ver 2.1 wmi-op 5 htt-op 2
                cal otp max-sta 128 features no-p2p
        ath10k_pci: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1

I am using channel 116, regdom US or FR, where I see no traffic at all
using wireshark+Airpcap.
I set wpa_supplicant to scan this channel only for a specific SSID "ssid1".

At initial startup of the client device, no probes are going out, which is
OK.

Then, on another device, I start a hostapd set to channel 116, with a
different SSID "otherssid" so that the supplicant will not associate.

Shortly (1-2s) after the beacons appear in the air, the client begins to
Send probe request in the air, which is unexpected, but acceptable since
the client can infer absence of radars from the presence of beacons.

*The problem*

If I power down the AP, the client continues to send probes for around
10 minutes, which is unacceptable since it cannot handle radar detection,
as it is a slave device in the meaning of ETSI/EN 301-893[1].


Some tests I made:
- I tried to investigate the "beacon hint" mechanism but it appears that it
  is not used on DFS channels.

- I tried to force the IEEE80211_NO_IR flag when IEEE80211_CHAN_DFS is set.

- When I reload the reg. domain using "iw reg set", the probes cease, but
  will reappear if I cycle my AP again On then Off.

- When I let the client associate, then disassociate and stop the AP, the
  same problem arises. It disappears if I add a call to ath10k_regd_update()
  in mac.c after a disconnection (This is not a fix, since in my case the
  client never associates).

- Since at startup, the client does not send probes, I infer that the
  problem is *not* caused by a hidden AP that the card could see but
  not airpcap.

- I tried with channels 52 and 100, with regdom FR or US: same problem.

Any ideas?


[1]
http://www.etsi.org/deliver/etsi_en/301800_301899/301893/01.08.01_60/en_3018
93v010801p.pdf

J.P. Tosoni - ACKSYS




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



From kvalo at qca.qualcomm.com  Thu Dec  1 02:34:50 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 1 Dec 2016 10:34:50 +0000
Subject: ath10k: Fix soft lockup during firmware crash/hw-restart
In-Reply-To: <20161201060612.GA8611@atheros-ThinkPad-T61> (Mohammed Shafi
 Shajakhan's message of "Thu, 1 Dec 2016 11:36:31 +0530")
References: <1480430762-15995-1-git-send-email-mohammed@qca.qualcomm.com>
 <1a44a3e9-3d67-30a5-0325-a65003ebe1fc@candelatech.com>
 <20161201060612.GA8611@atheros-ThinkPad-T61>
Message-ID: <87mvggrl87.fsf@kamboji.qca.qualcomm.com>

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

> On Tue, Nov 29, 2016 at 10:16:50AM -0800, Ben Greear wrote:
>> Is this something for stable?  And if so, how far back should it be applied?
>
> @Kalle,
>
> [shafi] kindly suggest. If i am not wrong this is only needed for 4.9

Correct, commit 3c97f5de1f28 went to 4.9-rc1, it was not in 4.8. I'll
add CC stable to the commit log.

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Thu Dec  1 02:35:38 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 1 Dec 2016 10:35:38 +0000
Subject: [PATCH v2] ath10k: Fix soft lockup during firmware
 crash/hw-restart
In-Reply-To: <1480483769-17693-1-git-send-email-mohammed@qca.qualcomm.com>
 (Mohammed Shafi Shajakhan's message of "Wed, 30 Nov 2016 10:59:29	+0530")
References: <1480483769-17693-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <87inr4rl6t.fsf@kamboji.qca.qualcomm.com>

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

> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
>
> During firmware crash (or) user requested manual restart
> the system gets into a soft lock up state because of the
> below root cause.
>
> During user requested hardware restart / firmware crash
> the system goes into a soft lockup state as 'napi_synchronize'
> is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
> bit) and it sleeps into infinite loop as it waits for
> 'NAPI_STATE_SCHED' to be cleared. This condition is hit because
> 'ath10k_hif_stop' is called twice as below (resulting in calling
> 'napi_synchronize' after 'napi_disable')
>
> 'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
> -> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
> 'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)
>
> Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
> as it makes more sense before informing mac80211 to restart h/w
> Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'
>
> Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> ---
> [v2 Added Fixes ]

I'll also add:

Cc: <stable at vger.kernel.org> # v4.9

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Thu Dec  1 03:09:26 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 1 Dec 2016 12:09:26 +0100
Subject: ath10k: fix TLV set regdomain command
In-Reply-To: <1480275440-9919-1-git-send-email-erik.stromdahl@gmail.com>
References: <1480275440-9919-1-git-send-email-erik.stromdahl@gmail.com>
Message-ID: <d72fc1b1dafe443f93e103ae02d8a0a5@euamsexm01a.eu.qualcomm.com>

Erik Stromdahl <erik.stromdahl at gmail.com> wrote:
> There is a typo bug in the current implementation of
> ath10k_wmi_tlv_op_gen_pdev_set_rd.
> The conformance test limits are not set up properly.
> 
> The two arguments ctl2g and ctl5g were not used at all.
> Instead, the regdomain arguments rd2g and rd5g were used
> for the ctl settings as well.
> 
> Signed-off-by: Erik Stromdahl <erik.stromdahl at gmail.com>

Patch applied to ath-next branch of ath.git, thanks.

4e322f7db51a ath10k: fix TLV set regdomain command

-- 
https://patchwork.kernel.org/patch/9448885/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From mohammed at codeaurora.org  Thu Dec  1 03:12:38 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Thu, 1 Dec 2016 16:42:38 +0530
Subject: [PATCH v2] ath10k: Fix soft lockup during firmware
 crash/hw-restart
In-Reply-To: <87inr4rl6t.fsf@kamboji.qca.qualcomm.com>
References: <1480483769-17693-1-git-send-email-mohammed@qca.qualcomm.com>
 <87inr4rl6t.fsf@kamboji.qca.qualcomm.com>
Message-ID: <20161201111238.GA12384@atheros-ThinkPad-T61>

On Thu, Dec 01, 2016 at 10:35:38AM +0000, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> writes:
> 
> > From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> >
> > During firmware crash (or) user requested manual restart
> > the system gets into a soft lock up state because of the
> > below root cause.
> >
> > During user requested hardware restart / firmware crash
> > the system goes into a soft lockup state as 'napi_synchronize'
> > is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
> > bit) and it sleeps into infinite loop as it waits for
> > 'NAPI_STATE_SCHED' to be cleared. This condition is hit because
> > 'ath10k_hif_stop' is called twice as below (resulting in calling
> > 'napi_synchronize' after 'napi_disable')
> >
> > 'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
> > -> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
> > 'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)
> >
> > Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
> > as it makes more sense before informing mac80211 to restart h/w
> > Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'
> >
> > Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
> > Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> > ---
> > [v2 Added Fixes ]
> 
> I'll also add:
> 
> Cc: <stable at vger.kernel.org> # v4.9
>
thank you Kalle.

regards,
shafi


From kvalo at qca.qualcomm.com  Thu Dec  1 03:13:36 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 1 Dec 2016 12:13:36 +0100
Subject: [v2] ath10k: Fix soft lockup during firmware crash/hw-restart
In-Reply-To: <1480483769-17693-1-git-send-email-mohammed@qca.qualcomm.com>
References: <1480483769-17693-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <f957e5d085a347b59d9eae0d2c794d1e@euamsexm01a.eu.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> During firmware crash (or) user requested manual restart
> the system gets into a soft lock up state because of the
> below root cause.
> 
> During user requested hardware restart / firmware crash
> the system goes into a soft lockup state as 'napi_synchronize'
> is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
> bit) and it sleeps into infinite loop as it waits for
> 'NAPI_STATE_SCHED' to be cleared. This condition is hit because
> 'ath10k_hif_stop' is called twice as below (resulting in calling
> 'napi_synchronize' after 'napi_disable')
> 
> 'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
> -> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
> 'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)
> 
> Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
> as it makes more sense before informing mac80211 to restart h/w
> Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'
> 
> Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Patch applied to ath-next branch of ath.git, thanks.

c2cac2f74ab4 ath10k: fix soft lockup during firmware crash/hw-restart

-- 
https://patchwork.kernel.org/patch/9453609/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From kvalo at qca.qualcomm.com  Thu Dec  1 03:14:23 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 1 Dec 2016 12:14:23 +0100
Subject: ath10k: Fix Tx DMA alloc failure during continuous wifi down/up
In-Reply-To: <1480499414-19543-1-git-send-email-mohammed@qca.qualcomm.com>
References: <1480499414-19543-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <f867487151bf4e82a210dd1755cf4e43@euamsexm01a.eu.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> With maximum number of vap's configured in a two radio supported
> systems of ~256 Mb RAM, doing a continuous wifi down/up and
> intermittent traffic streaming from the connected stations results
> in failure to allocate contiguous memory for tx buffers. This results
> in the disappearance of all VAP's and a manual reboot is needed as
> this is not a crash (or) OOM(for OOM killer to be invoked). To address
> this allocate contiguous memory for tx buffers one time and re-use them
> until the modules are unloaded but this results in a slight increase in
> memory footprint of ath10k when the wifi is down, but the modules are
> still loaded. Also as of now we use a separate bool 'tx_mem_allocated'
> to keep track of the one time memory allocation, as we cannot come up
> with something like 'ath10k_tx_{register,unregister}' before
> 'ath10k_probe_fw' is called as 'ath10k_htt_tx_alloc_cont_frag_desc'
> memory allocation is dependent on the hw_param 'continuous_frag_desc'
> 
> a) memory footprint of ath10k without the change
> 
> lsmod | grep ath10k
> ath10k_core           414498  1 ath10k_pci
> ath10k_pci             38236  0
> 
> b) memory footprint of ath10k with the change
> 
> ath10k_core           414980  1 ath10k_pci
> ath10k_pci             38236  0
> 
> Memory Failure Call trace:
> 
> hostapd: page allocation failure: order:6, mode:0xd0
>  [<c021f150>] (__dma_alloc_buffer.isra.23) from
> [<c021f23c>] (__alloc_remap_buffer.isra.26+0x14/0xb8)
> [<c021f23c>] (__alloc_remap_buffer.isra.26) from
> [<c021f664>] (__dma_alloc+0x224/0x2b8)
> [<c021f664>] (__dma_alloc) from [<c021f810>]
> (arm_dma_alloc+0x84/0x90)
> [<c021f810>] (arm_dma_alloc) from [<bf954764>]
> (ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core])
> [<bf954764>] (ath10k_htt_tx_alloc [ath10k_core]) from
> [<bf94e6ac>] (ath10k_core_start+0x538/0xcf8 [ath10k_core])
> [<bf94e6ac>] (ath10k_core_start [ath10k_core]) from
> [<bf947eec>] (ath10k_start+0xbc/0x56c [ath10k_core])
> [<bf947eec>] (ath10k_start [ath10k_core]) from
> [<bf8a7a04>] (drv_start+0x40/0x5c [mac80211])
> [<bf8a7a04>] (drv_start [mac80211]) from [<bf8b7cf8>]
> (ieee80211_do_open+0x170/0x82c [mac80211])
> [<bf8b7cf8>] (ieee80211_do_open [mac80211]) from
> [<c056afc8>] (__dev_open+0xa0/0xf4)
> [21053.491752] Normal: 641*4kB (UEMR) 505*8kB (UEMR) 330*16kB (UEMR)
> 126*32kB (UEMR) 762*64kB (UEMR) 237*128kB (UEMR) 1*256kB (M) 0*512kB
> 0*1024kB 0*2048kB 0*4096kB = 95276kB
> 
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Patch applied to ath-next branch of ath.git, thanks.

9ec34a86195a ath10k: fix Tx DMA alloc failure during continuous wifi down/up

-- 
https://patchwork.kernel.org/patch/9453947/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From kvalo at qca.qualcomm.com  Thu Dec  1 03:16:49 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 1 Dec 2016 12:16:49 +0100
Subject: ath10k: wmi-alloc-chunk should use DMA_BIDIRECTIONAL.
In-Reply-To: <1480456828-13735-1-git-send-email-greearb@candelatech.com>
References: <1480456828-13735-1-git-send-email-greearb@candelatech.com>
Message-ID: <4391889d7b9f4329a2edfdc29ae42ecc@euamsexm01a.eu.qualcomm.com>

Ben Greear <greearb at candelatech.com> wrote:
> From: Ben Greear <greearb at candelatech.com>
> 
> These memory chunks are often used as 'swap' by the NIC,
> so it will be both reading and writing to these areas.
> 
> This seems to fix errors like this on my x86-64 machine:
> 
> kernel: DMAR: DMAR:[DMA Write] Request device [05:00.0] fault addr ff5de000
>         DMAR:[fault reason 05] PTE Write access is not set
> 
> Tested-by: Marek Behun <kabel at blackhole.sk>
> Signed-off-by: Ben Greear <greearb at candelatech.com>
> 
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> index 9fcb249..c68278a 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -4558,7 +4558,7 @@ static int ath10k_wmi_alloc_chunk(struct ath10k *ar, u32 req_id,
>  	if (!num_units)
>  		return -ENOMEM;
>  
> -	paddr = dma_map_single(ar->dev, vaddr, pool_size, DMA_TO_DEVICE);
> +	paddr = dma_map_single(ar->dev, vaddr, pool_size, DMA_BIDIRECTIONAL);
>  	if (dma_mapping_error(ar->dev, paddr)) {
>  		kfree(vaddr);
>  		return -ENOMEM;

Patch applied to ath-next branch of ath.git, thanks.

43ca92d380a8 ath10k: wmi-alloc-chunk should use DMA_BIDIRECTIONAL

-- 
https://patchwork.kernel.org/patch/9453173/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From adrian.chadd at gmail.com  Thu Dec  1 08:53:21 2016
From: adrian.chadd at gmail.com (Adrian Chadd)
Date: Thu, 1 Dec 2016 08:53:21 -0800
Subject: Client station sends probes on DFS channels
In-Reply-To: <008001d24bb3$2f1e4db0$8d5ae910$@acksys.fr>
References: <006401d24b34$191d7830$4b586890$@acksys.fr>
 <CAJ-Vmom1EDyHH8Pcuxq83ptsYEGj0LWeDCNvx7gDAUKQmbWZ6g@mail.gmail.com>
 <008001d24bb3$2f1e4db0$8d5ae910$@acksys.fr>
Message-ID: <CAJ-VmokWUF=TkQcYdzSZ9z4Ozb3Ci-XGY_DP6-tp2rQD2sh5iQ@mail.gmail.com>

Hi,

So to be clear:

* if you get a CSA, the STA should move and not use the air
* if you just start another AP And then kill the APs, there's nothing
above that says when the STA should stop talking?

Thanks,



-adrian


From greearb at candelatech.com  Thu Dec  1 14:52:59 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 1 Dec 2016 14:52:59 -0800
Subject: [PATCH 1/3] ath10k: Ensure there are no stale ar->txqs entries.
In-Reply-To: <57B70AED.2010200@candelatech.com>
References: <1471569995-10028-1-git-send-email-greearb@candelatech.com>
 <CA+BoTQn0d1bEB662r-Yivmdk_21LhjCQjJP_GoPaj-WT2wA=1g@mail.gmail.com>
 <57B70AED.2010200@candelatech.com>
Message-ID: <ba1cc818-6194-11d6-7cc3-1db28036a519@candelatech.com>

On 08/19/2016 06:34 AM, Ben Greear wrote:
>
>
> On 08/18/2016 11:59 PM, Michal Kazior wrote:
>> On 19 August 2016 at 03:26,  <greearb at candelatech.com> wrote:
>>> From: Ben Greear <greearb at candelatech.com>
>>>
>>> I was seeing kernel crashes due to accessing freed memory
>>> while debugging a 9984 firmware that was crashing often.
>>>
>>> This patch fixes the crashes.  I am not certain if there
>>> is a better way or not.


I did some more hacking on this today.  I think I found some better clue on this.

I added this code:

static void ath10k_mac_txq_init(struct ath10k *ar, struct ieee80211_txq *txq)
{
	struct ath10k_txq *artxq = (void *)txq->drv_priv;
	struct ath10k_txq *tmp, *walker;
	struct ieee80211_txq *txq_tmp;
	int i = 0;

	if (!txq)
		return;

	spin_lock_bh(&ar->txqs_lock);
	ar->txqs_lock.rlock.dbg1 = 104;

	/* Remove from ar->txqs in case it still exists there. */
	list_for_each_entry_safe(walker, tmp, &ar->txqs, list) {
		txq_tmp = container_of((void *)walker, struct ieee80211_txq,
				       drv_priv);
		if ((++i % 10000) == 0) {
			ath10k_err(ar, "txq-init: Checking txq_tmp: %p i: %d\n", txq_tmp, i);
			ath10k_err(ar, "txq-init: txqs: %p walker->list: %p w->next: %p  w->prev: %p ar->txqs: %p\n",
				   &ar->txqs, &(walker->list), walker->list.next, walker->list.prev, &ar->txqs);
		}

		if (txq_tmp == txq) {
			WARN_ON_ONCE(1);
			ath10k_err(ar, "txq-init: Found txq when it should be deleted, txq_tmp: %p  txq: %p\n",
				   txq_tmp, txq);
			list_del(&walker->list);
		}
	}
	spin_unlock_bh(&ar->txqs_lock);

	INIT_LIST_HEAD(&artxq->list);
}


[firmware has just crashed]

Dec 01 14:43:06 wave2 kernel: ------------[ cut here ]------------
Dec 01 14:43:06 wave2 kernel: WARNING: CPU: 0 PID: 193 at /home/greearb/git/linux-4.7.dev.y/drivers/net/wireless/ath/ath10k/mac.c:4217 
ath10k_mac_txq_init+0x1a7/0x1b0 [ath10k_core]
Dec 01 14:43:06 wave2 kernel: Modules linked in: nf_conntrack_netlink nf_conntrack nfnetlink nf_defrag_ipv4 bridge 8021q garp mrp stp llc bnep bluetooth fuse 
macvlan pktgen rpcsec_gss_krb5 nfsv4 nfs fscache coretemp hwmon intel_rapl x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic kvm iTCO_wdt irqbypass iTCO_vendor_support ath10k_pci ath10k_core joydev ath snd_hda_intel mac80211 snd_hda_codec snd_hda_core snd_hwdep 
snd_seq snd_seq_device pcspkr cfg80211 snd_pcm snd_timer snd i2c_i801 lpc_ich shpchp soundcore tpm_tis tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc serio_raw 
i915 i2c_algo_bit ata_generic drm_kms_helper pata_acpi e1000e ptp drm pps_core i2c_core fjes video ipv6 [last unloaded: nf_conntrack]
Dec 01 14:43:06 wave2 kernel: CPU: 0 PID: 193 Comm: kworker/0:1 Not tainted 4.7.10+ #14
Dec 01 14:43:06 wave2 kernel: Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.5 06/07/2013
Dec 01 14:43:06 wave2 kernel: Workqueue: events_freezable ieee80211_restart_work [mac80211]
Dec 01 14:43:06 wave2 kernel:  ffffffffa0e29507 ffff8801d14f7920 ffffffff8169ed08 0000000000000000
Dec 01 14:43:06 wave2 kernel:  0000000000000000 ffff8801d14f7968 ffffffff811569bc ffff8801d14e4f00
Dec 01 14:43:06 wave2 kernel:  0000107900000001 ffff8800c43ec9a0 0000000000000027 ffff8800c43ec988
Dec 01 14:43:06 wave2 kernel: Call Trace:
Dec 01 14:43:06 wave2 kernel:  [<ffffffffa0e29507>] ? ath10k_mac_txq_init+0x1a7/0x1b0 [ath10k_core]
Dec 01 14:43:06 wave2 kernel:  [<ffffffff8169ed08>] dump_stack+0x85/0xcd
Dec 01 14:43:06 wave2 kernel:  [<ffffffff811569bc>] __warn+0x10c/0x130
Dec 01 14:43:06 wave2 kernel:  [<ffffffff81156b58>] warn_slowpath_null+0x18/0x20
Dec 01 14:43:06 wave2 kernel:  [<ffffffffa0e29507>] ath10k_mac_txq_init+0x1a7/0x1b0 [ath10k_core]
Dec 01 14:43:06 wave2 kernel:  [<ffffffffa0e3766f>] ath10k_sta_state+0x4ef/0x1350 [ath10k_core]
Dec 01 14:43:06 wave2 kernel:  [<ffffffff811e10ed>] ? mark_lock+0x6d/0x8a0
Dec 01 14:43:06 wave2 kernel:  [<ffffffffa0e37180>] ? ath10k_station_assoc+0x920/0x920 [ath10k_core]
Dec 01 14:43:06 wave2 kernel:  [<ffffffff811ddd14>] ? __lock_is_held+0x84/0xc0
Dec 01 14:43:06 wave2 kernel:  [<ffffffffa0c0095f>] drv_sta_state+0xef/0xc50 [mac80211]
Dec 01 14:43:06 wave2 kernel:  [<ffffffffa0c6b1b0>] ieee80211_reconfig+0x10a0/0x2890 [mac80211]
Dec 01 14:43:06 wave2 kernel:  [<ffffffffa0bf8361>] ieee80211_restart_work+0xb1/0xf0 [mac80211]
Dec 01 14:43:06 wave2 kernel:  [<ffffffff81184dad>] process_one_work+0x42d/0xac0
Dec 01 14:43:06 wave2 kernel:  [<ffffffff81184cf4>] ? process_one_work+0x374/0xac0
Dec 01 14:43:06 wave2 kernel:  [<ffffffff81184980>] ? pwq_dec_nr_in_flight+0x110/0x110
Dec 01 14:43:06 wave2 kernel:  [<ffffffff811854c6>] worker_thread+0x86/0x730
Dec 01 14:43:06 wave2 kernel:  [<ffffffff81df25aa>] ? _raw_spin_unlock_irqrestore+0x5a/0x70
Dec 01 14:43:06 wave2 kernel:  [<ffffffff81185440>] ? process_one_work+0xac0/0xac0
Dec 01 14:43:06 wave2 kernel:  [<ffffffff8118f381>] kthread+0x191/0x1b0
Dec 01 14:43:06 wave2 kernel:  [<ffffffff8118f1f0>] ? kthread_create_on_node+0x320/0x320
Dec 01 14:43:06 wave2 kernel:  [<ffffffff8119baa3>] ? preempt_count_sub+0x13/0xd0
Dec 01 14:43:06 wave2 kernel:  [<ffffffff81df2f8f>] ret_from_fork+0x1f/0x40
Dec 01 14:43:06 wave2 kernel:  [<ffffffff8118f1f0>] ? kthread_create_on_node+0x320/0x320
Dec 01 14:43:06 wave2 kernel: ---[ end trace e64bc8f0c1a2531b ]---
Dec 01 14:43:06 wave2 kernel: ath10k_pci 0000:05:00.0: txq-init: Found txq when it should be deleted, txq_tmp: ffff8800c43ec988  txq: ffff8800c43ec988
Dec 01 14:43:07 wave2 kernel: ath10k_pci 0000:05:00.0: dropping dbg buffer due to crash since read


Thanks,
Ben

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



From greearb at candelatech.com  Thu Dec  1 16:24:59 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 1 Dec 2016 16:24:59 -0800
Subject: [PATCH 1/3] ath10k: Ensure there are no stale ar->txqs entries.
In-Reply-To: <ba1cc818-6194-11d6-7cc3-1db28036a519@candelatech.com>
References: <1471569995-10028-1-git-send-email-greearb@candelatech.com>
 <CA+BoTQn0d1bEB662r-Yivmdk_21LhjCQjJP_GoPaj-WT2wA=1g@mail.gmail.com>
 <57B70AED.2010200@candelatech.com>
 <ba1cc818-6194-11d6-7cc3-1db28036a519@candelatech.com>
Message-ID: <ef7e16a6-9353-0f63-ac70-fc8e234d6c25@candelatech.com>

On 12/01/2016 02:52 PM, Ben Greear wrote:
> On 08/19/2016 06:34 AM, Ben Greear wrote:
>>
>>
>> On 08/18/2016 11:59 PM, Michal Kazior wrote:
>>> On 19 August 2016 at 03:26,  <greearb at candelatech.com> wrote:
>>>> From: Ben Greear <greearb at candelatech.com>
>>>>
>>>> I was seeing kernel crashes due to accessing freed memory
>>>> while debugging a 9984 firmware that was crashing often.
>>>>
>>>> This patch fixes the crashes.  I am not certain if there
>>>> is a better way or not.

Michal, thanks for the help on IRC.  I added this logic:

static void ieee80211_drv_tx(struct ieee80211_local *local,
			     struct ieee80211_vif *vif,
			     struct ieee80211_sta *pubsta,
			     struct sk_buff *skb)
{
	struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
	struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
	struct ieee80211_tx_control control = {
		.sta = pubsta,
	};
	struct ieee80211_txq *txq = NULL;
	struct txq_info *txqi;
	u8 ac;

	if ((info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM) ||
	    (info->control.flags & IEEE80211_TX_CTRL_PS_RESPONSE))
		goto tx_normal;

	if (!ieee80211_is_data(hdr->frame_control))
		goto tx_normal;

	if (unlikely(!ieee80211_sdata_running(sdata))) {
		WARN_ON_ONCE(1);
		goto delete_and_return;
	}

...

	if (atomic_read(&sdata->txqs_len[ac]) >=
	    (local->hw.txq_ac_max_pending * 2)) {
		/* Must be that something is not paying attention to
		 * max-pending, like pktgen, so just drop this frame.
		 */
delete_and_return:
		ieee80211_free_txskb(&local->hw, skb);
		return;
	}


But, I still see the txq entries on the ar->txqs list in the ath10k_mac_txq_init
after firmware crash in my test case.  Is this the test you were suggesting?


Thanks,
Ben

>
>
> I did some more hacking on this today.  I think I found some better clue on this.
>
> I added this code:
>
> static void ath10k_mac_txq_init(struct ath10k *ar, struct ieee80211_txq *txq)
> {
>     struct ath10k_txq *artxq = (void *)txq->drv_priv;
>     struct ath10k_txq *tmp, *walker;
>     struct ieee80211_txq *txq_tmp;
>     int i = 0;
>
>     if (!txq)
>         return;
>
>     spin_lock_bh(&ar->txqs_lock);
>     ar->txqs_lock.rlock.dbg1 = 104;
>
>     /* Remove from ar->txqs in case it still exists there. */
>     list_for_each_entry_safe(walker, tmp, &ar->txqs, list) {
>         txq_tmp = container_of((void *)walker, struct ieee80211_txq,
>                        drv_priv);
>         if ((++i % 10000) == 0) {
>             ath10k_err(ar, "txq-init: Checking txq_tmp: %p i: %d\n", txq_tmp, i);
>             ath10k_err(ar, "txq-init: txqs: %p walker->list: %p w->next: %p  w->prev: %p ar->txqs: %p\n",
>                    &ar->txqs, &(walker->list), walker->list.next, walker->list.prev, &ar->txqs);
>         }
>
>         if (txq_tmp == txq) {
>             WARN_ON_ONCE(1);
>             ath10k_err(ar, "txq-init: Found txq when it should be deleted, txq_tmp: %p  txq: %p\n",
>                    txq_tmp, txq);
>             list_del(&walker->list);
>         }
>     }
>     spin_unlock_bh(&ar->txqs_lock);
>
>     INIT_LIST_HEAD(&artxq->list);
> }
>
>
> [firmware has just crashed]
>
> Dec 01 14:43:06 wave2 kernel: ------------[ cut here ]------------
> Dec 01 14:43:06 wave2 kernel: WARNING: CPU: 0 PID: 193 at /home/greearb/git/linux-4.7.dev.y/drivers/net/wireless/ath/ath10k/mac.c:4217
> ath10k_mac_txq_init+0x1a7/0x1b0 [ath10k_core]
> Dec 01 14:43:06 wave2 kernel: Modules linked in: nf_conntrack_netlink nf_conntrack nfnetlink nf_defrag_ipv4 bridge 8021q garp mrp stp llc bnep bluetooth fuse
> macvlan pktgen rpcsec_gss_krb5 nfsv4 nfs fscache coretemp hwmon intel_rapl x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_hdmi snd_hda_codec_realtek
> snd_hda_codec_generic kvm iTCO_wdt irqbypass iTCO_vendor_support ath10k_pci ath10k_core joydev ath snd_hda_intel mac80211 snd_hda_codec snd_hda_core snd_hwdep
> snd_seq snd_seq_device pcspkr cfg80211 snd_pcm snd_timer snd i2c_i801 lpc_ich shpchp soundcore tpm_tis tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc serio_raw
> i915 i2c_algo_bit ata_generic drm_kms_helper pata_acpi e1000e ptp drm pps_core i2c_core fjes video ipv6 [last unloaded: nf_conntrack]
> Dec 01 14:43:06 wave2 kernel: CPU: 0 PID: 193 Comm: kworker/0:1 Not tainted 4.7.10+ #14
> Dec 01 14:43:06 wave2 kernel: Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.5 06/07/2013
> Dec 01 14:43:06 wave2 kernel: Workqueue: events_freezable ieee80211_restart_work [mac80211]
> Dec 01 14:43:06 wave2 kernel:  ffffffffa0e29507 ffff8801d14f7920 ffffffff8169ed08 0000000000000000
> Dec 01 14:43:06 wave2 kernel:  0000000000000000 ffff8801d14f7968 ffffffff811569bc ffff8801d14e4f00
> Dec 01 14:43:06 wave2 kernel:  0000107900000001 ffff8800c43ec9a0 0000000000000027 ffff8800c43ec988
> Dec 01 14:43:06 wave2 kernel: Call Trace:
> Dec 01 14:43:06 wave2 kernel:  [<ffffffffa0e29507>] ? ath10k_mac_txq_init+0x1a7/0x1b0 [ath10k_core]
> Dec 01 14:43:06 wave2 kernel:  [<ffffffff8169ed08>] dump_stack+0x85/0xcd
> Dec 01 14:43:06 wave2 kernel:  [<ffffffff811569bc>] __warn+0x10c/0x130
> Dec 01 14:43:06 wave2 kernel:  [<ffffffff81156b58>] warn_slowpath_null+0x18/0x20
> Dec 01 14:43:06 wave2 kernel:  [<ffffffffa0e29507>] ath10k_mac_txq_init+0x1a7/0x1b0 [ath10k_core]
> Dec 01 14:43:06 wave2 kernel:  [<ffffffffa0e3766f>] ath10k_sta_state+0x4ef/0x1350 [ath10k_core]
> Dec 01 14:43:06 wave2 kernel:  [<ffffffff811e10ed>] ? mark_lock+0x6d/0x8a0
> Dec 01 14:43:06 wave2 kernel:  [<ffffffffa0e37180>] ? ath10k_station_assoc+0x920/0x920 [ath10k_core]
> Dec 01 14:43:06 wave2 kernel:  [<ffffffff811ddd14>] ? __lock_is_held+0x84/0xc0
> Dec 01 14:43:06 wave2 kernel:  [<ffffffffa0c0095f>] drv_sta_state+0xef/0xc50 [mac80211]
> Dec 01 14:43:06 wave2 kernel:  [<ffffffffa0c6b1b0>] ieee80211_reconfig+0x10a0/0x2890 [mac80211]
> Dec 01 14:43:06 wave2 kernel:  [<ffffffffa0bf8361>] ieee80211_restart_work+0xb1/0xf0 [mac80211]
> Dec 01 14:43:06 wave2 kernel:  [<ffffffff81184dad>] process_one_work+0x42d/0xac0
> Dec 01 14:43:06 wave2 kernel:  [<ffffffff81184cf4>] ? process_one_work+0x374/0xac0
> Dec 01 14:43:06 wave2 kernel:  [<ffffffff81184980>] ? pwq_dec_nr_in_flight+0x110/0x110
> Dec 01 14:43:06 wave2 kernel:  [<ffffffff811854c6>] worker_thread+0x86/0x730
> Dec 01 14:43:06 wave2 kernel:  [<ffffffff81df25aa>] ? _raw_spin_unlock_irqrestore+0x5a/0x70
> Dec 01 14:43:06 wave2 kernel:  [<ffffffff81185440>] ? process_one_work+0xac0/0xac0
> Dec 01 14:43:06 wave2 kernel:  [<ffffffff8118f381>] kthread+0x191/0x1b0
> Dec 01 14:43:06 wave2 kernel:  [<ffffffff8118f1f0>] ? kthread_create_on_node+0x320/0x320
> Dec 01 14:43:06 wave2 kernel:  [<ffffffff8119baa3>] ? preempt_count_sub+0x13/0xd0
> Dec 01 14:43:06 wave2 kernel:  [<ffffffff81df2f8f>] ret_from_fork+0x1f/0x40
> Dec 01 14:43:06 wave2 kernel:  [<ffffffff8118f1f0>] ? kthread_create_on_node+0x320/0x320
> Dec 01 14:43:06 wave2 kernel: ---[ end trace e64bc8f0c1a2531b ]---
> Dec 01 14:43:06 wave2 kernel: ath10k_pci 0000:05:00.0: txq-init: Found txq when it should be deleted, txq_tmp: ffff8800c43ec988  txq: ffff8800c43ec988
> Dec 01 14:43:07 wave2 kernel: ath10k_pci 0000:05:00.0: dropping dbg buffer due to crash since read
>
>
> Thanks,
> Ben
>


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



From greearb at candelatech.com  Thu Dec  1 17:56:04 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 1 Dec 2016 17:56:04 -0800
Subject: ath10k crash due to funky-ness in mac80211 restart logic.
Message-ID: <39f7970a-de68-7ffe-e6a0-53f044ad4488@candelatech.com>

I spent the day looking at strange issues related to ath10k firmware crashing
in my hacked 3.7 kernel.

Here is one of the things I noticed.

When firmware crashes, soon after mac80211 tries to restart things, and after a bit of work,
it starts adding interfaces again.

In the ath10k_add_interface method, we first memzero the arvif, and then a bit later
assign arvif->ar

Between that memzero and assigning arvif->ar, I was seeing ath10k_wmi_tx_beacon_nowait called,
with the half-built arvif.

This promptly crashed since it needs arvif->ar to be properly assigned.

Maybe we need to remove the SDATA_IN_DRIVER flag very early in the mac80211 code
that deals with the driver restarting it's firmware so that the active iterator
does not use those devices?


I added some debugging code:

ath10k_pci 0000:05:00.0: Initializing arvif: ffff8801ce97e320 on vif: ffff8801ce97e1d8

[the print that happens after arvif->ar is assigned is not shown, so code did not make it that far before
  the tx-beacon-nowait method was called]

tx-beacon-nowait:  arvif: ffff8801ce97e320  ar:           (null)
arvif->magic: 0x87560001
------------[ cut here ]------------
kernel BUG at /home/greearb/git/linux-4.7.dev.y/drivers/net/wireless/ath/ath10k/wmi.c:1781!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
Modules linked in: nf_conntrack_netlink nf_conntrack nfnetlink nf_defrag_ipv4 bridge carl9170 mac80211_hwsim ath10k_pci ath10k_core ath5k ath9k ath9k_common 
ath9k_hw ath mac80211 cfg80211 8021q garp mrp stp llc bnep bluetooth fuse macvlan pktgen rpcsec_gss_krb5 nfsv4 nfs fscache snd_hda_codec_hdmi coretemp hwmon 
intel_rapl x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek snd_hda_codec_generic kvm iTCO_wdt irqbypass iTCO_vendor_support joydev snd_hda_intel 
snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device pcspkr snd_pcm snd_timer shpchp snd i2c_i801 lpc_ich soundcore tpm_tis tpm nfsd auth_rpcgss nfs_acl 
lockd grace sunrpc i915 serio_raw i2c_algo_bit drm_kms_helper ata_generic e1000e pata_acpi drm ptp pps_core i2c_core fjes video ipv6 [last unloaded: nf_conntrack]
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.7.10+ #15
Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.5 06/07/2013
task: ffff8801d4f20000 ti: ffff8801d4f28000 task.ti: ffff8801d4f28000
RIP: 0010:[<ffffffffa0efbcfb>]  [<ffffffffa0efbcfb>] ath10k_wmi_tx_beacons_iter+0x28b/0x290 [ath10k_core]
RSP: 0018:ffff8801d6447a98  EFLAGS: 00010293
RAX: 0000000000000018 RBX: ffff8801ce97e1d8 RCX: 0000000000000000
RDX: 0000000000000018 RSI: 0000000000000003 RDI: ffffed003ac88f49
RBP: ffff8801d6447af0 R08: 0000000000000003 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000
R13: ffff8801ce97e320 R14: ffff8801ce97e378 R15: ffff8801ce97ca40
FS:  0000000000000000(0000) GS:ffff8801d6440000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007eff191ef1ab CR3: 000000000260a000 CR4: 00000000001406e0
Stack:
  1ffff1003ac88f59 0000000041b58ab3 ffffffffa0f4d52a ffff8801d4f20000
  0000000000000246 0000000000000002 ffff8801ce97e1d8 ffff8801bd5d39b8
  0000000000000002 0000000000000001 ffff8801ce97ca40 ffff8801d6447b48
Call Trace:
  <IRQ>
  [<ffffffffa0d03e5c>] __iterate_interfaces+0xfc/0x1d0 [mac80211]
  [<ffffffffa0efba70>] ? ath10k_wmi_cmd_send_nowait+0x260/0x260 [ath10k_core]
  [<ffffffffa0efba70>] ? ath10k_wmi_cmd_send_nowait+0x260/0x260 [ath10k_core]
  [<ffffffffa0d04477>] ieee80211_iterate_active_interfaces_atomic+0x67/0x100 [mac80211]
  [<ffffffffa0d04410>] ? ieee80211_handle_reconfig_failure+0x140/0x140 [mac80211]
  [<ffffffffa0ef4060>] ? ath10k_tpc_config_disp_tables+0x620/0x620 [ath10k_core]
  [<ffffffffa0ef408b>] ath10k_wmi_op_ep_tx_credits+0x2b/0x50 [ath10k_core]
  [<ffffffffa0ee2fd2>] ath10k_htc_rx_completion_handler+0x422/0x5c0 [ath10k_core]
  [<ffffffffa0b4301e>] ath10k_pci_process_rx_cb+0x37e/0x430 [ath10k_pci]
  [<ffffffffa0ee2bb0>] ? ath10k_htc_build_tx_ctrl_skb+0xc0/0xc0 [ath10k_core]
  [<ffffffffa0b42ca0>] ? ath10k_pci_rx_post_pipe+0x550/0x550 [ath10k_pci]
  [<ffffffff8120cbe5>] ? debug_lockdep_rcu_enabled+0x35/0x40
  [<ffffffff811e1893>] ? mark_held_locks+0x23/0xc0
  [<ffffffff8116019a>] ? __local_bh_enable_ip+0x6a/0xd0
  [<ffffffff811e1abb>] ? trace_hardirqs_on_caller+0x18b/0x290
  [<ffffffff811e1bcd>] ? trace_hardirqs_on+0xd/0x10
  [<ffffffff8116019a>] ? __local_bh_enable_ip+0x6a/0xd0
  [<ffffffff81df11d0>] ? _raw_spin_unlock_bh+0x30/0x40
  [<ffffffffa0b4902e>] ? ath10k_ce_per_engine_service+0xee/0x100 [ath10k_pci]
  [<ffffffffa0b43139>] ath10k_pci_htt_htc_rx_cb+0x29/0x30 [ath10k_pci]
  [<ffffffffa0b48fe6>] ath10k_ce_per_engine_service+0xa6/0x100 [ath10k_pci]
  [<ffffffffa0b49116>] ath10k_ce_per_engine_service_any+0xd6/0xf0 [ath10k_pci]
  [<ffffffffa0b45800>] ? ath10k_pci_enable_legacy_irq+0xe0/0xe0 [ath10k_pci]
  [<ffffffffa0b4585f>] ath10k_pci_tasklet+0x5f/0xb0 [ath10k_pci]
  [<ffffffff81160445>] tasklet_action+0x245/0x2b0
  [<ffffffff81df4831>] __do_softirq+0x181/0x595
  [<ffffffff8116137c>] irq_exit+0xbc/0xc0
  [<ffffffff81df423c>] do_IRQ+0x7c/0x150
  [<ffffffff81df23cc>] common_interrupt+0x8c/0x8c
  <EOI>
  [<ffffffff811e1abb>] ? trace_hardirqs_on_caller+0x18b/0x290
  [<ffffffff81b722ae>] ? cpuidle_enter_state+0x1ae/0x4b0
  [<ffffffff81b722a7>] ? cpuidle_enter_state+0x1a7/0x4b0
  [<ffffffff81b72602>] cpuidle_enter+0x12/0x20
  [<ffffffff811d0b6e>] call_cpuidle+0x4e/0x90
  [<ffffffff811d10e7>] cpu_startup_entry+0x3f7/0x540
  [<ffffffff811d0cf0>] ? default_idle_call+0x50/0x50
  [<ffffffff81234bdf>] ? clockevents_config_and_register+0x5f/0x70
  [<ffffffff81085a9a>] ? setup_APIC_timer+0xfa/0x110
  [<ffffffff81083b63>] start_secondary+0x253/0x2b0
  [<ffffffff81083910>] ? set_cpu_sibling_map+0x920/0x920
Code: 4d 49 e0 8b b3 48 01 00 00 48 c7 c7 a0 ee f3 a0 e8 d9 c2 3f e0 49 81 fd 3f 1f 00 00 76 0f 49 81 fc 3f 1f 00 00 0f 87 c0 fd ff ff <0f> 0b 0f 0b 90 55 48 89 
e5 41 57 41 56 48 8d 85 58 ff ff ff 41
RIP  [<ffffffffa0efbcfb>] ath10k_wmi_tx_beacons_iter+0x28b/0x290 [ath10k_core]
  RSP <ffff8801d6447a98>
---[ end trace 6588464714e5163a ]---

Thanks,
Ben

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



From greearb at candelatech.com  Thu Dec  1 18:29:59 2016
From: greearb at candelatech.com (greearb at candelatech.com)
Date: Thu,  1 Dec 2016 18:29:59 -0800
Subject: [PATCH 1/2] mac80211: do not iterate active interfaces when in
 re-configure
Message-ID: <1480645800-2148-1-git-send-email-greearb@candelatech.com>

From: Ben Greear <greearb at candelatech.com>

This appears to fix a problem where ath10k firmware would crash,
mac80211 would start re-adding interfaces to the driver, but the
iterate-active-interfaces logic would then try to use the half-built
interfaces.  With a bit of extra debug to catch the problem, the
ath10k crash looks like this:

ath10k_pci 0000:05:00.0: Initializing arvif: ffff8801ce97e320 on vif: ffff8801ce97e1d8

[the print that happens after arvif->ar is assigned is not shown, so code did not make it that far before
 the tx-beacon-nowait method was called]

tx-beacon-nowait:  arvif: ffff8801ce97e320  ar:           (null)
arvif->magic: 0x87560001
------------[ cut here ]------------
kernel BUG at /home/greearb/git/linux-4.7.dev.y/drivers/net/wireless/ath/ath10k/wmi.c:1781!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
Modules linked in: nf_conntrack_netlink nf_conntrack nfnetlink nf_defrag_ipv4 bridge carl9170 mac80211_hwsim ath10k_pci ath10k_core ath5k ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 8021q garp mrp stp llc bnep bluetooth fuse macvlan pktgen rpcsec_gss_krb5 nfsv4 nfs fscache snd_hda_codec_hdmi coretemp hwmon intel_rapl x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek snd_hda_codec_generic kvm iTCO_wdt irqbypass iTCO_vendor_support joydev snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device pcspkr snd_pcm snd_timer shpchp snd i2c_i801 lpc_ich soundcore tpm_tis tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc i915 serio_raw i2c_algo_bit drm_kms_helper ata_generic e1000e pata_acpi drm ptp pps_core i2c_core fjes video ipv6 [last unloaded: nf_conntrack]
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.7.10+ #15
Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.5 06/07/2013
task: ffff8801d4f20000 ti: ffff8801d4f28000 task.ti: ffff8801d4f28000
RIP: 0010:[<ffffffffa0efbcfb>]  [<ffffffffa0efbcfb>] ath10k_wmi_tx_beacons_iter+0x28b/0x290 [ath10k_core]
RSP: 0018:ffff8801d6447a98  EFLAGS: 00010293
RAX: 0000000000000018 RBX: ffff8801ce97e1d8 RCX: 0000000000000000
RDX: 0000000000000018 RSI: 0000000000000003 RDI: ffffed003ac88f49
RBP: ffff8801d6447af0 R08: 0000000000000003 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000
R13: ffff8801ce97e320 R14: ffff8801ce97e378 R15: ffff8801ce97ca40
FS:  0000000000000000(0000) GS:ffff8801d6440000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007eff191ef1ab CR3: 000000000260a000 CR4: 00000000001406e0
Stack:
 1ffff1003ac88f59 0000000041b58ab3 ffffffffa0f4d52a ffff8801d4f20000
 0000000000000246 0000000000000002 ffff8801ce97e1d8 ffff8801bd5d39b8
 0000000000000002 0000000000000001 ffff8801ce97ca40 ffff8801d6447b48
Call Trace:
 <IRQ>
 [<ffffffffa0d03e5c>] __iterate_interfaces+0xfc/0x1d0 [mac80211]
 [<ffffffffa0efba70>] ? ath10k_wmi_cmd_send_nowait+0x260/0x260 [ath10k_core]
 [<ffffffffa0efba70>] ? ath10k_wmi_cmd_send_nowait+0x260/0x260 [ath10k_core]
 [<ffffffffa0d04477>] ieee80211_iterate_active_interfaces_atomic+0x67/0x100 [mac80211]
 [<ffffffffa0d04410>] ? ieee80211_handle_reconfig_failure+0x140/0x140 [mac80211]
 [<ffffffffa0ef4060>] ? ath10k_tpc_config_disp_tables+0x620/0x620 [ath10k_core]
 [<ffffffffa0ef408b>] ath10k_wmi_op_ep_tx_credits+0x2b/0x50 [ath10k_core]
 [<ffffffffa0ee2fd2>] ath10k_htc_rx_completion_handler+0x422/0x5c0 [ath10k_core]
 [<ffffffffa0b4301e>] ath10k_pci_process_rx_cb+0x37e/0x430 [ath10k_pci]
 [<ffffffffa0ee2bb0>] ? ath10k_htc_build_tx_ctrl_skb+0xc0/0xc0 [ath10k_core]
 [<ffffffffa0b42ca0>] ? ath10k_pci_rx_post_pipe+0x550/0x550 [ath10k_pci]
 [<ffffffff8120cbe5>] ? debug_lockdep_rcu_enabled+0x35/0x40
 [<ffffffff811e1893>] ? mark_held_locks+0x23/0xc0
 [<ffffffff8116019a>] ? __local_bh_enable_ip+0x6a/0xd0
 [<ffffffff811e1abb>] ? trace_hardirqs_on_caller+0x18b/0x290
 [<ffffffff811e1bcd>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff8116019a>] ? __local_bh_enable_ip+0x6a/0xd0
 [<ffffffff81df11d0>] ? _raw_spin_unlock_bh+0x30/0x40
 [<ffffffffa0b4902e>] ? ath10k_ce_per_engine_service+0xee/0x100 [ath10k_pci]
 [<ffffffffa0b43139>] ath10k_pci_htt_htc_rx_cb+0x29/0x30 [ath10k_pci]
 [<ffffffffa0b48fe6>] ath10k_ce_per_engine_service+0xa6/0x100 [ath10k_pci]
 [<ffffffffa0b49116>] ath10k_ce_per_engine_service_any+0xd6/0xf0 [ath10k_pci]
 [<ffffffffa0b45800>] ? ath10k_pci_enable_legacy_irq+0xe0/0xe0 [ath10k_pci]
 [<ffffffffa0b4585f>] ath10k_pci_tasklet+0x5f/0xb0 [ath10k_pci]
 [<ffffffff81160445>] tasklet_action+0x245/0x2b0
 [<ffffffff81df4831>] __do_softirq+0x181/0x595
 [<ffffffff8116137c>] irq_exit+0xbc/0xc0
 [<ffffffff81df423c>] do_IRQ+0x7c/0x150
 [<ffffffff81df23cc>] common_interrupt+0x8c/0x8c
 <EOI>
 [<ffffffff811e1abb>] ? trace_hardirqs_on_caller+0x18b/0x290
 [<ffffffff81b722ae>] ? cpuidle_enter_state+0x1ae/0x4b0
 [<ffffffff81b722a7>] ? cpuidle_enter_state+0x1a7/0x4b0
 [<ffffffff81b72602>] cpuidle_enter+0x12/0x20
 [<ffffffff811d0b6e>] call_cpuidle+0x4e/0x90
 [<ffffffff811d10e7>] cpu_startup_entry+0x3f7/0x540
 [<ffffffff811d0cf0>] ? default_idle_call+0x50/0x50
 [<ffffffff81234bdf>] ? clockevents_config_and_register+0x5f/0x70
 [<ffffffff81085a9a>] ? setup_APIC_timer+0xfa/0x110
 [<ffffffff81083b63>] start_secondary+0x253/0x2b0
 [<ffffffff81083910>] ? set_cpu_sibling_map+0x920/0x920
Code: 4d 49 e0 8b b3 48 01 00 00 48 c7 c7 a0 ee f3 a0 e8 d9 c2 3f e0 49 81 fd 3f 1f 00 00 76 0f 49 81 fc 3f 1f 00 00 0f 87 c0 fd ff ff <0f> 0b 0f 0b 90 55 48 89 e5 41 57 41 56 48 8d 85 58 ff ff ff 41
RIP  [<ffffffffa0efbcfb>] ath10k_wmi_tx_beacons_iter+0x28b/0x290 [ath10k_core]
 RSP <ffff8801d6447a98>
---[ end trace 6588464714e5163a ]---

Signed-off-by: Ben Greear <greearb at candelatech.com>
---
 net/mac80211/util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 863f2c1..abe1f64 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -705,7 +705,7 @@ static void __iterate_interfaces(struct ieee80211_local *local,
 			break;
 		}
 		if (!(iter_flags & IEEE80211_IFACE_ITER_RESUME_ALL) &&
-		    active_only && !(sdata->flags & IEEE80211_SDATA_IN_DRIVER))
+		    (active_only && (local->in_reconfig || !(sdata->flags & IEEE80211_SDATA_IN_DRIVER))))
 			continue;
 		if (ieee80211_sdata_running(sdata) || !active_only)
 			iterator(data, sdata->vif.addr,
-- 
2.4.11



From greearb at candelatech.com  Thu Dec  1 18:30:00 2016
From: greearb at candelatech.com (greearb at candelatech.com)
Date: Thu,  1 Dec 2016 18:30:00 -0800
Subject: [PATCH 2/2] ath10k:  work-around for stale txq in ar->txqs
In-Reply-To: <1480645800-2148-1-git-send-email-greearb@candelatech.com>
References: <1480645800-2148-1-git-send-email-greearb@candelatech.com>
Message-ID: <1480645800-2148-2-git-send-email-greearb@candelatech.com>

From: Ben Greear <greearb at candelatech.com>

Due to reasons I do not fully understand, when ath10k firmware
crashes when trying to bring up lots of vdevs, the ar->txqs
may still have references to the txq struct when mac80211 re-adds
the network devices.

The device add logic was re-initializing the list members, but
if they were already in the ar->txqs, then that meant the list
was broken and trying to walk the list would end up in an infinite
loop.

So, check for this particular isue, and remove the reference from
ar->txqs before re-initializing the list-head.  There must be
a cleaner way to do this, but I am not sure exactly what that would
be.

Signed-off-by: Ben Greear <greearb at candelatech.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 48 ++++++++++++++++++++++++++++++-----
 drivers/net/wireless/ath/ath10k/wmi.c |  9 +++++++
 2 files changed, 51 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 784cf2b..2f50915 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4190,13 +4190,37 @@ void ath10k_mgmt_over_wmi_tx_work(struct work_struct *work)
 	}
 }
 
-static void ath10k_mac_txq_init(struct ieee80211_txq *txq)
+static void ath10k_mac_txq_init(struct ath10k *ar, struct ieee80211_txq *txq)
 {
 	struct ath10k_txq *artxq = (void *)txq->drv_priv;
+	struct ath10k_txq *tmp, *walker;
+	struct ieee80211_txq *txq_tmp;
+	int i = 0;
 
 	if (!txq)
 		return;
 
+	spin_lock_bh(&ar->txqs_lock);
+
+	/* Remove from ar->txqs in case it still exists there. */
+	list_for_each_entry_safe(walker, tmp, &ar->txqs, list) {
+		txq_tmp = container_of((void *)walker, struct ieee80211_txq,
+				       drv_priv);
+		if ((++i % 10000) == 0) {
+			ath10k_err(ar, "txq-init: Checking txq_tmp: %p i: %d\n", txq_tmp, i);
+			ath10k_err(ar, "txq-init: txqs: %p walker->list: %p w->next: %p  w->prev: %p ar->txqs: %p\n",
+				   &ar->txqs, &(walker->list), walker->list.next, walker->list.prev, &ar->txqs);
+		}
+
+		if (txq_tmp == txq) {
+			WARN_ON_ONCE(1);
+			ath10k_err(ar, "txq-init: Found txq when it should be deleted, txq_tmp: %p  txq: %p\n",
+				   txq_tmp, txq);
+			list_del(&walker->list);
+		}
+	}
+	spin_unlock_bh(&ar->txqs_lock);
+
 	INIT_LIST_HEAD(&artxq->list);
 }
 
@@ -4208,6 +4232,7 @@ static void ath10k_mac_txq_unref(struct ath10k *ar, struct ieee80211_txq *txq)
 	struct sk_buff *msdu;
 	struct ieee80211_txq *txq_tmp;
 	int msdu_id;
+	int i = 0;
 
 	if (!txq)
 		return;
@@ -4220,8 +4245,18 @@ static void ath10k_mac_txq_unref(struct ath10k *ar, struct ieee80211_txq *txq)
 	list_for_each_entry_safe(walker, tmp, &ar->txqs, list) {
 		txq_tmp = container_of((void *)walker, struct ieee80211_txq,
 				       drv_priv);
-		if (txq_tmp == txq)
+		if ((++i % 10000) == 0) {
+			ath10k_err(ar, "Checking txq_tmp: %p i: %d\n", txq_tmp, i);
+			ath10k_err(ar, "txqs: %p walker->list: %p w->next: %p  w->prev: %p ar->txqs: %p\n",
+				   &ar->txqs, &(walker->list), walker->list.next, walker->list.prev, &ar->txqs);
+		}
+
+		if (txq_tmp == txq) {
+			WARN_ON_ONCE(1);
+			ath10k_err(ar, "Found txq when it should be deleted, txq_tmp: %p  txq: %p\n",
+				   txq_tmp, txq);
 			list_del(&walker->list);
+		}
 	}
 	spin_unlock_bh(&ar->txqs_lock);
 
@@ -5255,7 +5290,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
 	mutex_lock(&ar->conf_mutex);
 
 	memset(arvif, 0, sizeof(*arvif));
-	ath10k_mac_txq_init(vif->txq);
+	ath10k_mac_txq_init(ar, vif->txq);
 
 	memset(&arvif->bcast_rate, WMI_FIXED_RATE_NONE, sizeof(arvif->bcast_rate));
 	memset(&arvif->mcast_rate, WMI_FIXED_RATE_NONE, sizeof(arvif->mcast_rate));
@@ -5620,8 +5655,9 @@ static void ath10k_remove_interface(struct ieee80211_hw *hw,
 		kfree(arvif->u.ap.noa_data);
 	}
 
-	ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %i delete (remove interface)\n",
-		   arvif->vdev_id);
+	ath10k_dbg(ar, ATH10K_DBG_MAC,
+		   "mac vdev %i delete (remove interface), vif: %p  arvif: %p\n",
+		   arvif->vdev_id, vif, arvif);
 
 	ret = ath10k_wmi_vdev_delete(ar, arvif->vdev_id);
 	if (ret)
@@ -6437,7 +6473,7 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
 		INIT_WORK(&arsta->update_wk, ath10k_sta_rc_update_wk);
 
 		for (i = 0; i < ARRAY_SIZE(sta->txq); i++)
-			ath10k_mac_txq_init(sta->txq[i]);
+			ath10k_mac_txq_init(ar, sta->txq[i]);
 	}
 
 	/* cancel must be done outside the mutex to avoid deadlock */
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index fd685c4..1c8ceb2 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1771,6 +1771,15 @@ static void ath10k_wmi_tx_beacon_nowait(struct ath10k_vif *arvif)
 	bool deliver_cab;
 	int ret;
 
+	/* I saw a kasan warning here, looks like arvif and/or ar might have been
+	 * NULL, add something to catch this if it happens again.
+	 */
+	if ((((unsigned long)(arvif)) < 8000) || (((unsigned long)(ar)) < 8000)) {
+		pr_err("tx-beacon-nowait:  arvif: %p  ar: %p\n", arvif, ar);
+		BUG_ON(((unsigned long)(arvif)) < 8000);
+		BUG_ON(((unsigned long)(ar)) < 8000);
+	}
+
 	spin_lock_bh(&ar->data_lock);
 
 	bcn = arvif->beacon;
-- 
2.4.11



From bmorgan at cococorp.com  Fri Dec  2 17:28:02 2016
From: bmorgan at cococorp.com (Benjamin Morgan)
Date: Fri, 2 Dec 2016 17:28:02 -0800
Subject: ath10k firmware crashes in mesh mode on QCA9880
In-Reply-To: <20161201070908.GB11953@atheros-ThinkPad-T61>
References: <583DD564.8040704@cococorp.com>
 <20161201070908.GB11953@atheros-ThinkPad-T61>
Message-ID: <58421FA2.2020004@cococorp.com>

Just tried 10.2.4.70.58 firmware that you linked to and it still crashes:

[  131.568989] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 
1838347e-9380-4a26-ac9d-2963ee95968b)
[  131.578124] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c 
chip_id 0x043202ff sub 0000:0000
[  131.587491] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 
tracing 0 dfs 1 testmode 1
[  131.600521] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.58 api 5 
features no-p2p,raw-mode,mfp crc32 e1af076f
[  131.610899] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A 
crc32 bebc7c08
[  131.618325] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 
cal file max-sta 128 raw 0 hwcrypto 1
[  131.629965] ath10k_pci 0000:01:00.0: firmware register dump:
[  131.635728] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 
0x009A45AF 0x00955B31
[  131.643761] ath10k_pci 0000:01:00.0: [04]: 0x009A45AF 0x00060130 
0x00000002 0x00439E98
[  131.651806] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074 
0x00407120 0x004436CC
[  131.659852] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000 
0x009A3550 0x009A355E
[  131.667892] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x009A31D6 
0x00000000 0x00000000
[  131.675936] ath10k_pci 0000:01:00.0: [20]: 0x409A45AF 0x0040AAC4 
0x0040AC60 0x0040AC09
[  131.683968] ath10k_pci 0000:01:00.0: [24]: 0x809A44F2 0x0040AB24 
0x00400000 0xC09A45AF
[  131.692013] ath10k_pci 0000:01:00.0: [28]: 0x809A3A16 0x0040AB84 
0x0044110C 0x00442074
[  131.700056] ath10k_pci 0000:01:00.0: [32]: 0x809A601A 0x0040ABB4 
0x0044110C 0x00407120
[  131.708100] ath10k_pci 0000:01:00.0: [36]: 0x809A2EA4 0x0040ABF4 
0x0040AC14 0x00001580
[  131.716143] ath10k_pci 0000:01:00.0: [40]: 0x80990F63 0x0040AD04 
0x009C6458 0x004436CC
[  131.724175] ath10k_pci 0000:01:00.0: [44]: 0x80998520 0x0040AD64 
0x004208FC 0x00439E4C
[  131.732220] ath10k_pci 0000:01:00.0: [48]: 0x8099AEA5 0x0040AD84 
0x004208FC 0x00425874
[  131.740263] ath10k_pci 0000:01:00.0: [52]: 0x809BFC39 0x0040AEE4 
0x00424FE8 0x00000002
[  131.748306] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14 
0x00000004 0x004039D0
[  131.857076] ieee80211 phy0: Hardware restart was requested
[  131.862705] ath10k_pci 0000:01:00.0: failed to synchronize monitor 
vdev 1 stop: -143
[  131.870594] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143

~Benjamin

On 11/30/2016 11:09 PM, Mohammed Shafi Shajakhan wrote:
> Hi,
>
> On Tue, Nov 29, 2016 at 11:22:12AM -0800, Benjamin Morgan wrote:
>> When we try to transmit traffic (ping) between two meshed ath10k
>> devices running latest lede we keep experiencing ath10k firmware
>> crashes. This seems to only happen when running in 802.11n/ac mode
>> but not in 802.11a/g mode. Also, from the station dumps it appears
>> that management traffic is flowing between the devices, however when
>> we try to send unicast data traffic the firmware crashes
>> immediately.
> [shafi] Did you get a chance to try with the below firmware as well
> https://github.com/kvalo/ath10k-firmware/blob/master/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.58
>
>> Platform: Archer C7 AC1750 v2
>> Software Image: LEDE (HEAD, r2299) Commit: https://github.com/lede-project/source/commit/d596c21ebd5a3e6ce933eff3e51989031e4b1d58
>>
>> Crypto: wpa_supplicant
>> wpa_supplicant-wlan0.conf
>> network={
>> ssid="bmorgan_lede_mesh"
>> key_mgmt=SAE
>> mode=5
>> frequency=5180
>> psk="meshpassword"
>> }
>>
>> Backports Verstion:
>> [    9.818007] Loading modules backported from Linux version
>> wt-2016-10-03-1-g6fcb1a6
>> [    9.825736] Backport generated by backports.git
>> backports-20160324-9-g0e38f5c
>>
>> ??Ath10k Initialization on Station A (dmesg)
>> [    9.896715] PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
>> [    9.902622] ath10k_pci 0000:01:00.0: pci irq legacy oper_irq_mode
>> 1 irq_mode 0 reset_mode 0
>> [   10.123734] ath10k_pci 0000:01:00.0: Direct firmware load for
>> ath10k/pre-cal-pci-0000:01:00.0.bin failed with error -2
>> [   10.134620] ath10k_pci 0000:01:00.0: Falling back to user helper
>> [   10.287680] firmware ath10k!pre-cal-pci-0000:01:00.0.bin:
>> firmware_loading_store: map pages failed
>> [   10.622789] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
>> 0x4100016c chip_id 0x043202ff sub 0000:0000
>> [   10.632184] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
>> tracing 0 dfs 1 testmode 1
>> [   10.645231] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54
>> api 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
>> [   10.655660] ath10k_pci 0000:01:00.0: Direct firmware load for
>> ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
>> [   10.666264] ath10k_pci 0000:01:00.0: Falling back to user helper
>> [   10.747925] firmware ath10k!QCA988X!hw2.0!board-2.bin:
>> firmware_loading_store: map pages failed
>> [   11.011123] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
>> crc32 bebc7c08
>> [   12.155224] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op
>> 2 cal file max-sta 128 raw 0 hwcrypto 1
>>
>> Station A (wlan0):
>> 18:A6:F7:23:6E:66
>> 10.230.5.41
>>
>> Station B (wlan0):
>> 18:a6:f7:26:0f:21
>> 10.230.5.42
>>
>> Station Dump on Station A before ping:
>> Station 18:a6:f7:26:0f:21 (on wlan0)
>> inactive time:340 ms
>> rx bytes:2472
>> rx packets:28
>> tx bytes:1204
>> tx packets:9
>> tx retries:0
>> tx failed:0
>> rx drop misc:1
>> signal: -14 dBm
>> signal avg:-14 dBm
>> Toffset:18142530 us
>> tx bitrate:6.0 MBit/s
>> rx bitrate:6.0 MBit/s
>> rx duration:1524 us
>> mesh llid:0
>> mesh plid:0
>> mesh plink:ESTAB
>> mesh local PS mode:ACTIVE
>> mesh peer PS mode:UNKNOWN
>> mesh non-peer PS mode:ACTIVE
>> authorized:yes
>> authenticated:yes
>> associated:yes
>> preamble:long
>> WMM/WME:yes
>> MFP:yes
>> TDLS peer:no
>> DTIM period:2
>> beacon interval:1000
>> connected time:10 seconds
>>
>> ?Crash Log on Station B (10.230.5.42)
>> [245.483888] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
>> 2bab5ee9-08ff-4a17-95b1-636d212acebc)
>> [245.493020] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
>> 0x4100016c chip_id 0x043202ff sub 0000:0000
>> [245.502384] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
>> tracing 0 dfs 1 testmode 1
>> [245.515436] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api
>> 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
>> [245.525812] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
>> crc32 bebc7c08
>> [245.533232] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
>> cal file max-sta 128 raw 0 hwcrypto 1
>> [245.544876] ath10k_pci 0000:01:00.0: firmware register dump:
>> [245.550633] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
>> 0x009A4577 0x00955B31
>> [245.558676] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
>> 0x00000002 0x00439E98
>> [245.566715] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
>> 0x00407120 0x004436CC
>> [245.574749] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
>> 0x009A3518 0x009A3526
>> [245.582793] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
>> 0x00000000 0x00000000
>> [245.590836] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
>> 0x0040AC60 0x0040AC09
>> [245.598882] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
>> 0x00400000 0xC09A4577
>> [245.606923] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
>> 0x0044110C 0x00442074
>> [245.614955] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
>> 0x0044110C 0x00407120
>> [245.623000] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
>> 0x0040AC14 0x00001580
>> [245.631043] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
>> 0x009C643C 0x004436CC
>> [245.639086] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
>> 0x004208FC 0x00439E4C
>> [245.647129] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
>> 0x004208FC 0x00425404
>> [245.655170] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
>> 0x00424FE8 0x00000002
>> [245.663198] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
>> 0x00000004 0x004039D0
>> [245.767023] ieee80211 phy0: Hardware restart was requested
>> [245.772655] ath10k_pci 0000:01:00.0: failed to synchronize monitor
>> vdev 1 stop: -143
>> [245.780542] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
>> ?
>> With wpa_supplicant turned off:
>>
>> Station Dump on Station A before ping:
>> Station 18:a6:f7:26:0f:21 (on wlan0)
>> inactive time:60 ms
>> rx bytes:3874
>> rx packets:67
>> tx bytes:707
>> tx packets:7
>> tx retries:0
>> tx failed:1
>> rx drop misc:3
>> signal: -14 dBm
>> signal avg:-14 dBm
>> Toffset:18446744073684250999 us
>> tx bitrate:6.0 MBit/s
>> rx bitrate:6.0 MBit/s
>> rx duration:1312 us
>> mesh llid:24953
>> mesh plid:59412
>> mesh plink:ESTAB
>> mesh local PS mode:ACTIVE
>> mesh peer PS mode:UNKNOWN
>> mesh non-peer PS mode:ACTIVE
>> authorized:yes
>> authenticated:yes
>> associated:yes
>> preamble:long
>> WMM/WME:yes
>> MFP:no
>> TDLS peer:no
>> DTIM period:2
>> beacon interval:1000
>> short slot time:yes
>> connected time:33 seconds
>>
>> Firmware crash on Station A (10.230.5.41)
>> [ 1040.984599] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
>> 42d4f6dc-0e89-4505-aefb-58cbb70d0dce)
>> [ 1040.993732] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
>> 0x4100016c chip_id 0x043202ff sub 0000:0000
>> [ 1041.003100] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
>> tracing 0 dfs 1 testmode 1
>> [ 1041.016144] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54
>> api 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
>> [ 1041.026523] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
>> crc32 bebc7c08
>> [ 1041.033940] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op
>> 2 cal file max-sta 128 raw 0 hwcrypto 1
>> [ 1041.045593] ath10k_pci 0000:01:00.0: firmware register dump:
>> [ 1041.051336] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
>> 0x009A4577 0x00955B31
>> [ 1041.059383] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
>> 0x00000001 0x00435354
>> [ 1041.067424] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
>> 0x00407120 0x004436CC
>> [ 1041.075463] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
>> 0x009A43A0 0x009A43DE
>> [ 1041.083490] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
>> 0x00000000 0x00000000
>> [ 1041.091535] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
>> 0x0040AC60 0x0040AC09
>> [ 1041.099579] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
>> 0x00955A00 0xC09A4577
>> [ 1041.107622] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
>> 0x0044110C 0x00442074
>> [ 1041.115661] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
>> 0x0044110C 0x00407120
>> [ 1041.123689] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
>> 0x0040AC10 0x00001580
>> [ 1041.131733] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
>> 0x009C643C 0x004436CC
>> [ 1041.139777] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
>> 0x004208FC 0x00439E4C
>> [ 1041.147820] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
>> 0x004208FC 0x00425758
>> [ 1041.155860] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
>> 0x00424FE8 0x00000002
>> [ 1041.163888] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
>> 0x00000004 0x004039D0
>> [ 1041.267025] ieee80211 phy0: Hardware restart was requested
>> [ 1041.272656] ath10k_pci 0000:01:00.0: failed to synchronize
>> monitor vdev 1 stop: -143
>> [ 1041.280545] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
>>
>> ?
>> Thanks in advance for your time and help,
>>
>> ~Benjamin
>>



From public_timo.s at silentcreek.de  Sat Dec  3 03:33:52 2016
From: public_timo.s at silentcreek.de (Timo Sigurdsson)
Date: Sat,  3 Dec 2016 12:33:52 +0100 (CET)
Subject: [BUG] Kernel crashes with ath10k radio and Nexus 5X clients
In-Reply-To: <20161121124752.GA5475@atheros-ThinkPad-T61>
References: <20161118093041.961686C80A76@dd34104.kasserver.com>
 <CAJ-VmokbM8s0CzwZNTXigt9e+MTng7-UOEMMtqDyLf0_D9_Pwg@mail.gmail.com>
 <20161120013527.30A6F6C80437@dd34104.kasserver.com><20161121124752.GA5475@atheros-ThinkPad-T61>
Message-ID: <20161203113352.6B6786C80496@dd34104.kasserver.com>

Hi Mohammed,

so, I provoked the crash again on a newer build with debugging enabled
(LEDE r2321, Linux 4.4.32, ath10k firmware 10.2.4.70.54).

The relevant dmesg output is pasted below (with mac addresses
pseudo-anonymized). I hope this includes the information you were
looking for. If not, please let me know what other useful information I
can provide. I haven't rebooted the access point yet.

Regards,

Timo

[283232.075393] ath10k_pci 0000:01:00.0: failed to delete peer 78:f8:82:00:00:00 for vdev 0: -145
[283232.084140] ath10k_pci 0000:01:00.0: found sta peer 78:f8:82:00:00:00 (ptr 86df2800 id 62) entry on vdev 0 after it was supposedly removed
[283232.096976] ------------[ cut here ]------------
[283232.101904] WARNING: CPU: 0 PID: 1841 at compat-wireless-2016-10-08/net/mac80211/sta_info.c:964 sta_set_sinfo+0x92c/0x9e0 [mac80211]()
[283232.114279] Modules linked in: pppoe ppp_async iptable_nat ath9k pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE ax88179_178a ath9k_common xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_id xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY usbnet slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt ath9k_hw em_nbyte sch_tbf sch_pie sch_gred sch_htb sch_teql cls_basic act_ipt sch_red sch_prio em_meta em_text sch_codel sch_sfq act_police sch_dsmark em_cmp sch_fq act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress ath10k_pci ath10k_core ath mac80211 cfg80211 compat ledt
 rig_usbport ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables ifb ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common mii
[283232.221696] CPU: 0 PID: 1841 Comm: hostapd Not tainted 4.4.32 #0
[283232.227884] Stack : 803c74e4 00000000 00000001 80420000 87d65b80 8040ed83 803a8bac 00000731
[283232.227884] 	  8048379c 8740e800 00000000 7782fe94 00000000 800a7238 803ae218 80410000
[283232.227884] 	  00000003 8740e800 803ac624 86e1db2c 00000000 800a51b4 01afb952 00000000
[283232.227884] 	  00000001 801f3200 00000000 00000000 00000000 00000000 00000000 00000000
[283232.227884] 	  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[283232.227884] 	  ...
[283232.264341] Call Trace:
[283232.266934] [<80071b80>] show_stack+0x50/0x84
[283232.271445] [<80081900>] warn_slowpath_common+0xa0/0xd0
[283232.276847] [<800819b8>] warn_slowpath_null+0x18/0x24
[283232.282164] [<875870a4>] sta_set_sinfo+0x92c/0x9e0 [mac80211]
[283232.288224] [<87587188>] __sta_info_destroy+0x30/0x48 [mac80211]
[283232.294519] [<87587238>] sta_info_destroy_addr_bss+0x38/0x60 [mac80211]
[283232.301475] [<874cc144>] cfg80211_check_station_change+0xed8/0x1390 [cfg80211]
[283232.308942] 
[283232.310543] ---[ end trace 1e173b5175dabd85 ]---
[283547.702654] ath10k_pci 0000:01:00.0: failed to install key for vdev 0 peer a0:02:dc:00:00:00: -145
[283547.711846] wlan0: failed to remove key (0, a0:02:dc:00:00:00) from hardware (-145)
[283547.720952] ath10k_pci 0000:01:00.0: cipher 0 is not supported
[283547.727006] ath10k_pci 0000:01:00.0: failed to remove peer wep key 0: -122
[283547.734106] ath10k_pci 0000:01:00.0: failed to clear all peer wep keys for vdev 0: -122
[283547.742313] ath10k_pci 0000:01:00.0: failed to disassociate station: a0:02:dc:00:00:00 vdev 0: -122
[283547.751590] ------------[ cut here ]------------
[283547.756521] WARNING: CPU: 0 PID: 1841 at compat-wireless-2016-10-08/net/mac80211/sta_info.c:956 sta_set_sinfo+0x8d8/0x9e0 [mac80211]()
[283547.768872] Modules linked in: pppoe ppp_async iptable_nat ath9k pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE ax88179_178a ath9k_common xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_id xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY usbnet slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt ath9k_hw em_nbyte sch_tbf sch_pie sch_gred sch_htb sch_teql cls_basic act_ipt sch_red sch_prio em_meta em_text sch_codel sch_sfq act_police sch_dsmark em_cmp sch_fq act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress ath10k_pci ath10k_core ath mac80211 cfg80211 compat ledt
 rig_usbport ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables ifb ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common mii
[283547.876293] CPU: 0 PID: 1841 Comm: hostapd Tainted: G        W       4.4.32 #0
[283547.883714] Stack : 803c74e4 00000000 00000001 80420000 87d65b80 8040ed83 803a8bac 00000731
[283547.883714] 	  8048379c 8740e800 00000000 7782fe94 00000000 800a7238 803ae218 80410000
[283547.883714] 	  00000003 8740e800 803ac624 86e1db2c 00000000 800a51b4 00000000 00000000
[283547.883714] 	  8040de90 801f3200 00000000 00000000 00000000 00000000 00000000 00000000
[283547.883714] 	  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[283547.883714] 	  ...
[283547.920171] Call Trace:
[283547.922762] [<80071b80>] show_stack+0x50/0x84
[283547.927274] [<80081900>] warn_slowpath_common+0xa0/0xd0
[283547.932676] [<800819b8>] warn_slowpath_null+0x18/0x24
[283547.937995] [<87587050>] sta_set_sinfo+0x8d8/0x9e0 [mac80211]
[283547.944054] [<87587188>] __sta_info_destroy+0x30/0x48 [mac80211]
[283547.950349] [<87587238>] sta_info_destroy_addr_bss+0x38/0x60 [mac80211]
[283547.957314] [<874cc144>] cfg80211_check_station_change+0xed8/0x1390 [cfg80211]
[283547.964779] 
[283547.966381] ---[ end trace 1e173b5175dabd86 ]---
[283550.962647] ath10k_pci 0000:01:00.0: failed to delete peer a0:02:dc:00:00:00 for vdev 0: -11
[283550.971316] ath10k_pci 0000:01:00.0: found sta peer a0:02:dc:00:00:00 (ptr 86df6400 id 196) entry on vdev 0 after it was supposedly removed
[283553.982619] ath10k_pci 0000:01:00.0: failed to install key for vdev 0 peer 64:bc:0c:00:00:00: -11
[283553.991720] wlan0: failed to remove key (0, 64:bc:0c:00:00:00) from hardware (-11)
[283554.017647] ath10k_pci 0000:01:00.0: cipher 0 is not supported
[283554.023706] ath10k_pci 0000:01:00.0: failed to remove peer wep key 0: -122
[283554.030778] ath10k_pci 0000:01:00.0: failed to clear all peer wep keys for vdev 0: -122
[283554.039005] ath10k_pci 0000:01:00.0: failed to disassociate station: 64:bc:0c:00:00:00 vdev 0: -122
[283557.042589] ath10k_pci 0000:01:00.0: failed to delete peer 64:bc:0c:00:00:00 for vdev 0: -11
[283557.051248] ath10k_pci 0000:01:00.0: found sta peer 64:bc:0c:00:00:00 (ptr 86e31800 id 43) entry on vdev 0 after it was supposedly removed
[283560.062553] ath10k_pci 0000:01:00.0: failed to set beacon mode for vdev 0: -11
[283563.062522] ath10k_pci 0000:01:00.0: failed to set dtim period for vdev 0: -11
[283566.077407] ath10k_pci 0000:01:00.0: failed to recalculate rts/cts prot for vdev 0: -11
[283569.082474] ath10k_pci 0000:01:00.0: failed to set protection mode 0 on vdev 0: -11
[283572.082447] ath10k_pci 0000:01:00.0: failed to set preamble for vdev 0: -11
[283826.570252] ath10k_pci 0000:01:00.0: failed to install key for vdev 0 peer 30:b5:c2:00:00:00: -11
[283826.579348] wlan0: failed to remove key (1, ff:ff:ff:ff:ff:ff) from hardware (-11)
[283829.580227] ath10k_pci 0000:01:00.0: failed to install key for vdev 0 peer 30:b5:c2:00:00:00: -11
[283829.589379] wlan0: failed to set key (1, ff:ff:ff:ff:ff:ff) to hardware (-11)


Mohammed Shafi Shajakhan schrieb am 21.11.2016 13:47:

> Hi Timo,
> 
> sorry had I missed the exact kernel crash call trace ?
> I could see only the warnings, can you please post the call
> trace of the kernel crash please ?
> 
> regards,
> shafi
> 
> On Sun, Nov 20, 2016 at 02:35:27AM +0100, Timo Sigurdsson wrote:
>> Hi Adrian,
>> 
>> sure - here's the bug report on kernel.org:
>> https://bugzilla.kernel.org/show_bug.cgi?id=188201
>> 
>> Regards,
>> 
>> Timo
>> 
>> 
>> Adrian Chadd schrieb am 18.11.2016 22:22:
>> 
>> > hiya!
>> > 
>> > Can you file a kernel.org bug mentioning this?
>> > 
>> > thanks!
>> > 
>> > 
>> > -a
>> > 
>> > 
>> > On 18 November 2016 at 01:30, Timo Sigurdsson
>> > <public_timo.s at silentcreek.de> wrote:
>> >> Hi again,
>> >>
>> >> in the meantime, I have some more information to add to the issue mentioned
>> in
>> >> my email quoted further down below.
>> >>
>> >> Ben Greear approached me off-list and suggested to try the Candela Tech
>> ath10k
>> >> driver and firmware and see if the issue occurs with that as well. So, for
>> the
>> >> last 3 weeks I've been testing the CT driver and firmware and I can happily
>> >> report that the issue with the driver crashing after a while when a Nexus
>> 5X
>> >> device is connected is not occuring with the current BETA 18
>> >> firmware-2-ct-full-community.bin. So, this really seems like a regression
>> in
>> >> the official API level 5 ath10k firmware blobs.
>> >>
>> >> The CT firmware is not perfect either, since it seems to suffer from a
>> >> different
>> >> bug that has been resolved in the official firmwares, and that is that
>> after a
>> >> reboot of my TP-Link Archer C7 v2, the ath10k driver won't load. Only after
>> a
>> >> hard reset or "cold boot" it will come up. That's an issue I had with older
>> >> official firmwares as well, but it has been resolved with the recent API
>> level
>> >> 5 firmwares.
>> >>
>> >> Nevertheless, for the time being, I will stick to the CT firmware because I
>> >> can
>> >> work around the reboot issue and having the 5GHz wifi working for my Nexus
>> 5X
>> >> clients is more important.
>> >>
>> >> Over the next weeks, I will test different combinations of ath10k(-ct)
>> driver
>> >> and firmware to see if there's a combination that resolves all issues. This
>> >> morning I flashed a LEDE build with the official ath10k driver and the CT
>> >> firmware binary.
>> >>
>> >> But of course, if someone has more suggestions on what I could try or what
>> >> information I could collect to help resolve the issue related to the Nexus
>> 5X
>> >> clients in the official firmware binaries, I think that would be beneficial
>> >> for a larger audience.
>> >>
>> >> Regards,
>> >>
>> >> Timo
>> >>
>> >> P.S.: Please include my email address in any reply, since I'm not
>> subscribed
>> >> to the mailing list. Thank you.
>> >>
>> >>
>> >> Timo Sigurdsson schrieb am 29.10.2016 22:19:
>> >>
>> >>> Hi everybody,
>> >>>
>> >>> I have a TP-Link Archer C7 v2 running a fairly recent build of LEDE
>> (r1952,
>> >>> Linux 4.4.26, compat-wireless-2016-10-08). It all works well except for
>> the
>> >>> fact that when I connect a Nexus 5X device to the 5GHz radio, the kernel
>> or
>> >>> ath10k driver will crash after a while. 5Ghz wifi will be dead after that
>> >>> until I reboot the system.
>> >>>
>> >>> This issue has been reported before [1] and it also has been declared as
>> >>> solved with newer firmwares [2] (but reopened by other users). However,
>> even
>> >>> with the latest firmware 10.2.4.70.58 from Kalle Valo's Github repository
>> the
>> >>> issue is far from resolved. I have tried many different firmware revisions
>> >>> over the time (more recently 10.2.4.70.56 and 10.2.4.70.54), and I can
>> could
>> >>> only find that the issue sometimes takes longer to trigger with some
>> >>> firmwares
>> >>> (which might just be random), but it would always occur at some point with
>> >>> API
>> >>> level 5 firmwares. With API level 2 firmwares (which I testesd when I was
>> >>> still using OpenWrt 15.05) I never saw these crashes, but the Nexus 5X had
>> >>> other connectivity issues with these older firmwares that made this
>> >>> combination no fun to use either. But this shows that the firmware itself
>> >>> makes the difference here.
>> >>>
>> >>> I actually have two Nexus 5X on my network (my wife's and my own). I can
>> >>> trigger the crash with either one of them. And if both Nexus 5X are
>> connected
>> >>> to the 5Ghz radio, then the issue triggers much faster (can be as low as
>> 15
>> >>> minutes). My workaround is to let the Nexus 5X devices only connect to the
>> >>> 2.4GHz radio. This way, the device can runs for weeks without any issue or
>> >>> crash, but of course I would prefer the actual bug being fixed rather than
>> to
>> >>> circumvent it.
>> >>>
>> >>> I'm appending a syslog from my access point with a crash happening while
>> one
>> >>> Nexus 5X was connected to the 5GHz radio starting from the time the system
>> >>> booted. I randomized the MAC addresses. but left the first two characters
>> >>> unique so different clients can be distinguished.
>> >>>
>> >>> If there is more info I could collect to help identify the cause of this
>> >>> issue, please let me know (and possibly how to do that as well).
>> >>>
>> >>> Thank you and regards,
>> >>>
>> >>> Timo
>> >>>
>> >>> [1] http://lists.infradead.org/pipermail/ath10k/2015-November/006413.html
>> >>> [2] https://dev.openwrt.org/ticket/20854
>> >>>
>> >>> And here's the log:
>> >>> Fri Oct 28 02:01:35 2016 kern.notice kernel: [    0.000000] Linux version
>> >>> 4.4.26 (user at buildsystem) (gcc version 5.4.0 (LEDE GCC 5.4.0 r1952) ) #0
>> Fri
>> >>> Oct 21 15:52:28 2016
>> >>> [...]
>> >>> Fri Oct 28 02:01:35 2016 kern.info kernel: [    9.468751] Loading modules
>> >>> backported from Linux version wt-2016-10-03-1-g6fcb1a6
>> >>> Fri Oct 28 02:01:35 2016 kern.info kernel: [    9.476481] Backport
>> generated
>> >>> by
>> >>> backports.git backports-20160324-9-g0e38f5c
>> >>> Fri Oct 28 02:01:35 2016 kern.warn kernel: [    9.576570] PCI: Enabling
>> >>> device
>> >>> 0000:01:00.0 (0000 -> 0002)
>> >>> Fri Oct 28 02:01:35 2016 kern.info kernel: [    9.582475] ath10k_pci
>> >>> 0000:01:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0
>> >>> Fri Oct 28 02:01:35 2016 kern.warn kernel: [   10.087609] ath10k_pci
>> >>> 0000:01:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:01:00.0.bin
>> >>> failed with error -2
>> >>> Fri Oct 28 02:01:35 2016 kern.warn kernel: [   10.098492] ath10k_pci
>> >>> 0000:01:00.0: Falling back to user helper
>> >>> Fri Oct 28 02:01:35 2016 kern.err kernel: [   10.176500] firmware
>> >>> ath10k!pre-cal-pci-0000:01:00.0.bin: firmware_loading_store: map pages
>> failed
>> >>> Fri Oct 28 02:01:35 2016 kern.info kernel: [   10.677026] ath10k_pci
>> >>> 0000:01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub
>> >>> 0000:0000
>> >>> Fri Oct 28 02:01:35 2016 kern.info kernel: [   10.686424] ath10k_pci
>> >>> 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
>> >>> Fri Oct 28 02:01:35 2016 kern.info kernel: [   10.699498] ath10k_pci
>> >>> 0000:01:00.0: firmware ver 10.2.4.70.58 api 5 features no-p2p,raw-mode,mfp
>> >>> crc32 e1af076f
>> >>> Fri Oct 28 02:01:35 2016 kern.warn kernel: [   10.709932] ath10k_pci
>> >>> 0000:01:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin
>> >>> failed
>> >>> with error -2
>> >>> Fri Oct 28 02:01:35 2016 kern.warn kernel: [   10.720531] ath10k_pci
>> >>> 0000:01:00.0: Falling back to user helper
>> >>> Fri Oct 28 02:01:35 2016 kern.err kernel: [   10.798719] firmware
>> >>> ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
>> >>> Fri Oct 28 02:01:35 2016 kern.info kernel: [   10.823845] ath10k_pci
>> >>> 0000:01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
>> >>> Fri Oct 28 02:01:35 2016 kern.info kernel: [   11.954723] ath10k_pci
>> >>> 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal file max-sta 128 raw 0
>> >>> hwcrypto
>> >>> 1
>> >>> [...]
>> >>> // Evertyhing runs fine for a bit more than a day, but then this happens
>> ...
>> >>> //
>> >>> // Note: The ath10k radio in question is wlan0 //
>> >>> Sat Oct 29 10:38:21 2016 daemon.info hostapd: wlan1: STA 9c:12:34:56:78:9a
>> >>> IEEE
>> >>> 802.11: disassociated
>> >>> Sat Oct 29 10:38:22 2016 daemon.info hostapd: wlan1: STA 9c:12:34:56:78:9a
>> >>> IEEE
>> >>> 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
>> >>> Sat Oct 29 10:42:57 2016 daemon.info hostapd: wlan1: STA 00:12:34:56:78:9a
>> >>> WPA:
>> >>> group key handshake completed (RSN)
>> >>> Sat Oct 29 10:42:57 2016 daemon.info hostapd: wlan0: STA a0:12:34:56:78:9a
>> >>> WPA:
>> >>> group key handshake completed (RSN)
>> >>> Sat Oct 29 10:42:57 2016 daemon.info hostapd: wlan0: STA 70:12:34:56:78:9a
>> >>> WPA:
>> >>> group key handshake completed (RSN)
>> >>> Sat Oct 29 10:43:05 2016 kern.warn kernel: [117635.147861] ath10k_pci
>> >>> 0000:01:00.0: failed to delete peer 7f:12:34:56:78:9a for vdev 0: -145
>> >>> Sat Oct 29 10:43:05 2016 kern.warn kernel: [117635.156679] ath10k_pci
>> >>> 0000:01:00.0: found sta peer 7f:12:34:56:78:9a (ptr 86ebf200 id 62) entry
>> on
>> >>> vdev 0 after it was supposedly removed
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.169489] ------------[
>> cut
>> >>> here ]------------
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.174314] WARNING: CPU: 0
>> >>> PID:
>> >>> 1885 at compat-wireless-2016-10-08/net/mac80211/sta_info.c:964 0x875870a4
>> >>> [mac80211 at 87580000+0x5f500]()
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.186854] Modules linked
>> in:
>> >>> pppoe ppp_async iptable_nat ath9k pppox ppp_generic nf_nat_ipv4
>> >>> nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE ax88179_178a
>> >>> ath9k_common xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent
>> >>> xt_nat
>> >>> xt_multiport xt_mark xt_mac xt_limit xt_length xt_id xt_hl xt_helper
>> xt_ecn
>> >>> xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment
>> >>> xt_TCPMSS
>> >>> xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY usbnet Sat Oct 29
>> 10:43:06
>> >>> 2016 kern.warn kernel: [117635.294282] CPU: 0 PID: 1885 Comm: hostapd Not
>> >>> tainted 4.4.26 #0
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.300471] Stack :
>> 8036cff4
>> >>> 00000000 00000001 803c0000 00000000 00000000 00000000 00000000
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.300471]      00000000
>> >>> 00000000
>> >>> 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.300471]      00000000
>> >>> 00000000
>> >>> 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.300471]      00000000
>> >>> 00000000
>> >>> 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.300471]      00000000
>> >>> 00000000
>> >>> 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.300471]      ...
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.336918] Call
>> >>> Trace:[<800716f0>] 0x800716f0
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.341551] [<800716f0>]
>> >>> 0x800716f0
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.345176] [<8008144c>]
>> >>> 0x8008144c
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.348832] [<875870a4>]
>> >>> 0x875870a4 [mac80211 at 87580000+0x5f500]
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.354943] [<80081504>]
>> >>> 0x80081504
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.358611] [<875870a4>]
>> >>> 0x875870a4 [mac80211 at 87580000+0x5f500]
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.364742] [<87587188>]
>> >>> 0x87587188 [mac80211 at 87580000+0x5f500]
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.370861] [<875849b4>]
>> >>> 0x875849b4 [mac80211 at 87580000+0x5f500]
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.376951] [<80115770>]
>> >>> 0x80115770
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.380613] [<87587238>]
>> >>> 0x87587238 [mac80211 at 87580000+0x5f500]
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.386727] [<874cc114>]
>> >>> 0x874cc114 [cfg80211 at 874c0000+0x35b60]
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.392854] [<80293074>]
>> >>> 0x80293074
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.396485] [<80291900>]
>> >>> 0x80291900
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.400176] [<80292df8>]
>> >>> 0x80292df8
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.403801] [<80292238>]
>> >>> 0x80292238
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.407439] [<80292de0>]
>> >>> 0x80292de0
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.411079] [<80257794>]
>> >>> 0x80257794
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.414711] [<80291aa0>]
>> >>> 0x80291aa0
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.418345] [<80256c90>]
>> >>> 0x80256c90
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.421991] [<80292004>]
>> >>> 0x80292004
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.425616] [<801b5304>]
>> >>> 0x801b5304
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.429260] [<8025b478>]
>> >>> 0x8025b478
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.432902] [<8024d0e4>]
>> >>> 0x8024d0e4
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.436540] [<8024e4f8>]
>> >>> 0x8024e4f8
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.440195] [<801b5304>]
>> >>> 0x801b5304
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.443835] [<8027e338>]
>> >>> 0x8027e338
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.447464] [<802e8244>]
>> >>> 0x802e8244
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.451136] [<8011aa58>]
>> >>> 0x8011aa58
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.454762] [<8011ae3c>]
>> >>> 0x8011ae3c
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.458402] [<8011acd4>]
>> >>> 0x8011acd4
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.462057] [<80117a10>]
>> >>> 0x80117a10
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.465700] [<8024f424>]
>> >>> 0x8024f424
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.469344] [<800b1dd0>]
>> >>> 0x800b1dd0
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.472986] [<8006295c>]
>> >>> 0x8006295c
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.476615]
>> >>> Sat Oct 29 10:43:06 2016 kern.warn kernel: [117635.478223] ---[ end trace
>> >>> 2c07f06df2595aa5 ]---
>> >>> Sat Oct 29 10:43:06 2016 daemon.info hostapd: wlan0: STA 7f:12:34:56:78:9a
>> >>> IEEE
>> >>> 802.11: deauthenticated due to local deauth request
>> >>> Sat Oct 29 10:43:15 2016 daemon.info hostapd: wlan1: STA 70:12:34:56:78:9a
>> >>> IEEE
>> >>> 802.11: authenticated
>> >>> Sat Oct 29 10:43:15 2016 daemon.info hostapd: wlan1: STA 70:12:34:56:78:9a
>> >>> IEEE
>> >>> 802.11: associated (aid 2)
>> >>> Sat Oct 29 10:43:15 2016 daemon.info hostapd: wlan1: STA 70:12:34:56:78:9a
>> >>> RADIUS: starting accounting session D1227001A194DA09
>> >>> Sat Oct 29 10:43:15 2016 daemon.info hostapd: wlan1: STA 70:12:34:56:78:9a
>> >>> WPA:
>> >>> pairwise key handshake completed (RSN)
>> >>> Sat Oct 29 10:43:31 2016 daemon.info hostapd: wlan1: STA a0:12:34:56:78:9a
>> >>> IEEE
>> >>> 802.11: authenticated
>> >>> Sat Oct 29 10:43:31 2016 daemon.info hostapd: wlan1: STA a0:12:34:56:78:9a
>> >>> IEEE
>> >>> 802.11: associated (aid 3)
>> >>> Sat Oct 29 10:43:31 2016 daemon.info hostapd: wlan1: STA a0:12:34:56:78:9a
>> >>> RADIUS: starting accounting session 92084E55AFE512B3
>> >>> Sat Oct 29 10:43:31 2016 daemon.info hostapd: wlan1: STA a0:12:34:56:78:9a
>> >>> WPA:
>> >>> pairwise key handshake completed (RSN)
>> >>> Sat Oct 29 10:48:02 2016 daemon.info hostapd: wlan0: STA a0:12:34:56:78:9a
>> >>> IEEE
>> >>> 802.11: disassociated due to inactivity
>> >>> Sat Oct 29 10:48:05 2016 kern.warn kernel: [117935.165013] ath10k_pci
>> >>> 0000:01:00.0: failed to install key for vdev 0 peer a0:12:34:56:78:9a:
>> -145
>> >>> Sat Oct 29 10:48:05 2016 kern.err kernel: [117935.174193] wlan0: failed to
>> >>> remove key (0, a0:12:34:56:78:9a) from hardware (-145)
>> >>> Sat Oct 29 10:48:05 2016 daemon.info hostapd: wlan0: STA 70:12:34:56:78:9a
>> >>> IEEE
>> >>> 802.11: disassociated due to inactivity
>> >>> Sat Oct 29 10:48:08 2016 kern.warn kernel: [117938.174996] ath10k_pci
>> >>> 0000:01:00.0: failed to install key for vdev 0 peer 70:12:34:56:78:9a: -11
>> >>> Sat Oct 29 10:48:08 2016 kern.err kernel: [117938.184092] wlan0: failed to
>> >>> remove key (0, 70:12:34:56:78:9a) from hardware (-11)
>> >>> Sat Oct 29 10:48:08 2016 daemon.info hostapd: wlan0: STA a0:12:34:56:78:9a
>> >>> IEEE
>> >>> 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.193251] ath10k_pci
>> >>> 0000:01:00.0: cipher 0 is not supported
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.199320] ath10k_pci
>> >>> 0000:01:00.0: failed to remove peer wep key 0: -122
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.206409] ath10k_pci
>> >>> 0000:01:00.0: failed to clear all peer wep keys for vdev 0: -122
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.214621] ath10k_pci
>> >>> 0000:01:00.0: failed to disassociate station: a0:12:34:56:78:9a vdev 0:
>> -122
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.223892] ------------[
>> cut
>> >>> here ]------------
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.228706] WARNING: CPU: 0
>> >>> PID:
>> >>> 1885 at compat-wireless-2016-10-08/net/mac80211/sta_info.c:956 0x87587050
>> >>> [mac80211 at 87580000+0x5f500]()
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.241226] Modules linked
>> in:
>> >>> pppoe ppp_async iptable_nat ath9k pppox ppp_generic nf_nat_ipv4
>> >>> nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE ax88179_178a
>> >>> ath9k_common xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent
>> >>> xt_nat
>> >>> xt_multiport xt_mark xt_mac xt_limit xt_length xt_id xt_hl xt_helper
>> xt_ecn
>> >>> xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment
>> >>> xt_TCPMSS
>> >>> xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY usbnet Sat Oct 29
>> 10:48:09
>> >>> 2016 kern.warn kernel: [117938.348645] CPU: 0 PID: 1885 Comm: hostapd
>> >>> Tainted:
>> >>> G        W       4.4.26 #0
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.356067] Stack :
>> 8036cff4
>> >>> 00000000 00000001 803c0000 00000000 00000000 00000000 00000000
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.356067]      00000000
>> >>> 00000000
>> >>> 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.356067]      00000000
>> >>> 00000000
>> >>> 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.356067]      00000000
>> >>> 00000000
>> >>> 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.356067]      00000000
>> >>> 00000000
>> >>> 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.356067]      ...
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.392511] Call
>> >>> Trace:[<800716f0>] 0x800716f0
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.397147] [<800716f0>]
>> >>> 0x800716f0
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.400770] [<8008144c>]
>> >>> 0x8008144c
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.404414] [<87587050>]
>> >>> 0x87587050 [mac80211 at 87580000+0x5f500]
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.410531] [<80081504>]
>> >>> 0x80081504
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.414184] [<87587050>]
>> >>> 0x87587050 [mac80211 at 87580000+0x5f500]
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.420297] [<8759cb40>]
>> >>> 0x8759cb40 [mac80211 at 87580000+0x5f500]
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.426431] [<87587188>]
>> >>> 0x87587188 [mac80211 at 87580000+0x5f500]
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.432531] [<875849b4>]
>> >>> 0x875849b4 [mac80211 at 87580000+0x5f500]
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.438629] [<801018e4>]
>> >>> 0x801018e4
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.442276] [<87587238>]
>> >>> 0x87587238 [mac80211 at 87580000+0x5f500]
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.448406] [<874cc114>]
>> >>> 0x874cc114 [cfg80211 at 874c0000+0x35b60]
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.454516] [<80293074>]
>> >>> 0x80293074
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.458147] [<80291900>]
>> >>> 0x80291900
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.461822] [<80292df8>]
>> >>> 0x80292df8
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.465461] [<80292238>]
>> >>> 0x80292238
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.469092] [<800a15d0>]
>> >>> 0x800a15d0
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.472726] [<80292de0>]
>> >>> 0x80292de0
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.476371] [<80257794>]
>> >>> 0x80257794
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.480002] [<80291aa0>]
>> >>> 0x80291aa0
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.483630] [<80256c90>]
>> >>> 0x80256c90
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.487280] [<80292004>]
>> >>> 0x80292004
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.490908] [<801b5304>]
>> >>> 0x801b5304
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.494541] [<8025b478>]
>> >>> 0x8025b478
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.498198] [<8024d0e4>]
>> >>> 0x8024d0e4
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.501840] [<8024e4f8>]
>> >>> 0x8024e4f8
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.505492] [<8027e338>]
>> >>> 0x8027e338
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.509121] [<802e8244>]
>> >>> 0x802e8244
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.512780] [<8011aa58>]
>> >>> 0x8011aa58
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.516413] [<8011ae3c>]
>> >>> 0x8011ae3c
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.520043] [<8011acd4>]
>> >>> 0x8011acd4
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.523697] [<80117a10>]
>> >>> 0x80117a10
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.527352] [<8024f424>]
>> >>> 0x8024f424
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.530981] [<801059e8>]
>> >>> 0x801059e8
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.534625] [<8006295c>]
>> >>> 0x8006295c
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.538265]
>> >>> Sat Oct 29 10:48:09 2016 kern.warn kernel: [117938.539870] ---[ end trace
>> >>> 2c07f06df2595aa6 ]---
>> >>> Sat Oct 29 10:48:12 2016 kern.warn kernel: [117941.534956] ath10k_pci
>> >>> 0000:01:00.0: failed to delete peer a0:12:34:56:78:9a for vdev 0: -11
>> >>> Sat Oct 29 10:48:12 2016 kern.warn kernel: [117941.543716] ath10k_pci
>> >>> 0000:01:00.0: found sta peer a0:12:34:56:78:9a (ptr 86ebf400 id 196) entry
>> on
>> >>> vdev 0 after it was supposedly removed
>> >>> Sat Oct 29 10:48:12 2016 daemon.info hostapd: wlan0: STA 70:12:34:56:78:9a
>> >>> IEEE
>> >>> 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
>> >>> Sat Oct 29 10:48:12 2016 kern.warn kernel: [117941.558962] ath10k_pci
>> >>> 0000:01:00.0: cipher 0 is not supported
>> >>> Sat Oct 29 10:48:12 2016 kern.warn kernel: [117941.565049] ath10k_pci
>> >>> 0000:01:00.0: failed to remove peer wep key 0: -122
>> >>> Sat Oct 29 10:48:15 2016 kern.warn kernel: [117944.564917] ath10k_warn: 2
>> >>> callbacks suppressed
>> >>> Sat Oct 29 10:48:15 2016 kern.warn kernel: [117944.569617] ath10k_pci
>> >>> 0000:01:00.0: failed to delete peer 70:12:34:56:78:9a for vdev 0: -11
>> >>> Sat Oct 29 10:48:15 2016 kern.warn kernel: [117944.578309] ath10k_pci
>> >>> 0000:01:00.0: found sta peer 70:12:34:56:78:9a (ptr 86320c00 id 251) entry
>> on
>> >>> vdev 0 after it was supposedly removed
>> >>> Sat Oct 29 10:48:18 2016 kern.warn kernel: [117947.584908] ath10k_pci
>> >>> 0000:01:00.0: failed to set beacon mode for vdev 0: -11
>> >>> Sat Oct 29 10:48:21 2016 kern.warn kernel: [117950.584876] ath10k_pci
>> >>> 0000:01:00.0: failed to set dtim period for vdev 0: -11
>> >>> Sat Oct 29 10:48:24 2016 kern.warn kernel: [117953.594843] ath10k_pci
>> >>> 0000:01:00.0: failed to recalculate rts/cts prot for vdev 0: -11
>> >>> Sat Oct 29 10:48:27 2016 kern.warn kernel: [117956.594833] ath10k_pci
>> >>> 0000:01:00.0: failed to set protection mode 0 on vdev 0: -11
>> >>> Sat Oct 29 10:48:30 2016 kern.warn kernel: [117959.594805] ath10k_pci
>> >>> 0000:01:00.0: failed to set preamble for vdev 0: -11
>> >>> Sat Oct 29 10:52:57 2016 daemon.info hostapd: wlan1: STA 00:12:34:56:78:9a
>> >>> WPA:
>> >>> group key handshake completed (RSN)
>> >>> Sat Oct 29 10:52:57 2016 daemon.info hostapd: wlan1: STA a0:12:34:56:78:9a
>> >>> WPA:
>> >>> group key handshake completed (RSN)
>> >>> Sat Oct 29 10:53:00 2016 kern.warn kernel: [118229.632250] ath10k_pci
>> >>> 0000:01:00.0: failed to install key for vdev 0 peer 30:12:34:56:78:9a: -11
>> >>> Sat Oct 29 10:53:00 2016 kern.err kernel: [118229.641421] wlan0: failed to
>> >>> remove key (2, ff:ff:ff:ff:ff:ff) from hardware (-11)
>> >>> Sat Oct 29 10:53:03 2016 kern.warn kernel: [118232.642204] ath10k_pci
>> >>> 0000:01:00.0: failed to install key for vdev 0 peer 30:12:34:56:78:9a: -11
>> >>> Sat Oct 29 10:53:03 2016 kern.err kernel: [118232.651309] wlan0: failed to
>> >>> set
>> >>> key (2, ff:ff:ff:ff:ff:ff) to hardware (-11)
>> >>> Sat Oct 29 10:53:08 2016 daemon.info hostapd: wlan1: STA 70:12:34:56:78:9a
>> >>> IEEE
>> >>> 802.11: deauthenticated due to local deauth request
>> >>> Sat Oct 29 10:53:11 2016 daemon.info hostapd: wlan1: STA 70:12:34:56:78:9a
>> >>> IEEE
>> >>> 802.11: authenticated
>> >>> Sat Oct 29 10:53:11 2016 daemon.info hostapd: wlan1: STA 70:12:34:56:78:9a
>> >>> IEEE
>> >>> 802.11: associated (aid 2)
>> >>> Sat Oct 29 10:53:11 2016 daemon.info hostapd: wlan1: STA 70:12:34:56:78:9a
>> >>> RADIUS: starting accounting session 56977F3FD253EA9C
>> >>> Sat Oct 29 10:53:11 2016 daemon.info hostapd: wlan1: STA 70:12:34:56:78:9a
>> >>> WPA:
>> >>> pairwise key handshake completed (RSN)
>> >>>
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
> 



From mohammed at codeaurora.org  Sat Dec  3 04:43:58 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Sat, 3 Dec 2016 18:13:58 +0530
Subject: ath10k firmware crashes in mesh mode on QCA9880
In-Reply-To: <58421FA2.2020004@cococorp.com>
References: <583DD564.8040704@cococorp.com>
 <20161201070908.GB11953@atheros-ThinkPad-T61>
 <58421FA2.2020004@cococorp.com>
Message-ID: <20161203124358.GB31861@atheros-ThinkPad-T61>

Hi Benjamin,

On Fri, Dec 02, 2016 at 05:28:02PM -0800, Benjamin Morgan wrote:
> Just tried 10.2.4.70.58 firmware that you linked to and it still crashes:
> 
> [  131.568989] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> 1838347e-9380-4a26-ac9d-2963ee95968b)
> [  131.578124] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043202ff sub 0000:0000
> [  131.587491] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
> tracing 0 dfs 1 testmode 1
> [  131.600521] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.58
> api 5 features no-p2p,raw-mode,mfp crc32 e1af076f
> [  131.610899] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [  131.618325] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op
> 2 cal file max-sta 128 raw 0 hwcrypto 1
> [  131.629965] ath10k_pci 0000:01:00.0: firmware register dump:
> [  131.635728] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> 0x009A45AF 0x00955B31
> [  131.643761] ath10k_pci 0000:01:00.0: [04]: 0x009A45AF 0x00060130
> 0x00000002 0x00439E98
> [  131.651806] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
> 0x00407120 0x004436CC
> [  131.659852] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
> 0x009A3550 0x009A355E
> [  131.667892] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x009A31D6
> 0x00000000 0x00000000
> [  131.675936] ath10k_pci 0000:01:00.0: [20]: 0x409A45AF 0x0040AAC4
> 0x0040AC60 0x0040AC09
> [  131.683968] ath10k_pci 0000:01:00.0: [24]: 0x809A44F2 0x0040AB24
> 0x00400000 0xC09A45AF
> [  131.692013] ath10k_pci 0000:01:00.0: [28]: 0x809A3A16 0x0040AB84
> 0x0044110C 0x00442074
> [  131.700056] ath10k_pci 0000:01:00.0: [32]: 0x809A601A 0x0040ABB4
> 0x0044110C 0x00407120
> [  131.708100] ath10k_pci 0000:01:00.0: [36]: 0x809A2EA4 0x0040ABF4
> 0x0040AC14 0x00001580
> [  131.716143] ath10k_pci 0000:01:00.0: [40]: 0x80990F63 0x0040AD04
> 0x009C6458 0x004436CC
> [  131.724175] ath10k_pci 0000:01:00.0: [44]: 0x80998520 0x0040AD64
> 0x004208FC 0x00439E4C
> [  131.732220] ath10k_pci 0000:01:00.0: [48]: 0x8099AEA5 0x0040AD84
> 0x004208FC 0x00425874
> [  131.740263] ath10k_pci 0000:01:00.0: [52]: 0x809BFC39 0x0040AEE4
> 0x00424FE8 0x00000002
> [  131.748306] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
> 0x00000004 0x004039D0
> [  131.857076] ieee80211 phy0: Hardware restart was requested
> [  131.862705] ath10k_pci 0000:01:00.0: failed to synchronize
> monitor vdev 1 stop: -143
> [  131.870594] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143

[shafi] request to try with the latest backports and ath.git
Also worth trying this fix in ath10k (once the next firmware version)
is available. I will keep you posted. thank you !

> 
> ~Benjamin
> 
> On 11/30/2016 11:09 PM, Mohammed Shafi Shajakhan wrote:
> >Hi,
> >
> >On Tue, Nov 29, 2016 at 11:22:12AM -0800, Benjamin Morgan wrote:
> >>When we try to transmit traffic (ping) between two meshed ath10k
> >>devices running latest lede we keep experiencing ath10k firmware
> >>crashes. This seems to only happen when running in 802.11n/ac mode
> >>but not in 802.11a/g mode. Also, from the station dumps it appears
> >>that management traffic is flowing between the devices, however when
> >>we try to send unicast data traffic the firmware crashes
> >>immediately.
> >[shafi] Did you get a chance to try with the below firmware as well
> >https://github.com/kvalo/ath10k-firmware/blob/master/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.58
> >
> >>Platform: Archer C7 AC1750 v2
> >>Software Image: LEDE (HEAD, r2299) Commit: https://github.com/lede-project/source/commit/d596c21ebd5a3e6ce933eff3e51989031e4b1d58
> >>
> >>Crypto: wpa_supplicant
> >>wpa_supplicant-wlan0.conf
> >>network={
> >>ssid="bmorgan_lede_mesh"
> >>key_mgmt=SAE
> >>mode=5
> >>frequency=5180
> >>psk="meshpassword"
> >>}
> >>
> >>Backports Verstion:
> >>[    9.818007] Loading modules backported from Linux version
> >>wt-2016-10-03-1-g6fcb1a6
> >>[    9.825736] Backport generated by backports.git
> >>backports-20160324-9-g0e38f5c
> >>
> >>??Ath10k Initialization on Station A (dmesg)
> >>[    9.896715] PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
> >>[    9.902622] ath10k_pci 0000:01:00.0: pci irq legacy oper_irq_mode
> >>1 irq_mode 0 reset_mode 0
> >>[   10.123734] ath10k_pci 0000:01:00.0: Direct firmware load for
> >>ath10k/pre-cal-pci-0000:01:00.0.bin failed with error -2
> >>[   10.134620] ath10k_pci 0000:01:00.0: Falling back to user helper
> >>[   10.287680] firmware ath10k!pre-cal-pci-0000:01:00.0.bin:
> >>firmware_loading_store: map pages failed
> >>[   10.622789] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> >>0x4100016c chip_id 0x043202ff sub 0000:0000
> >>[   10.632184] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
> >>tracing 0 dfs 1 testmode 1
> >>[   10.645231] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54
> >>api 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> >>[   10.655660] ath10k_pci 0000:01:00.0: Direct firmware load for
> >>ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
> >>[   10.666264] ath10k_pci 0000:01:00.0: Falling back to user helper
> >>[   10.747925] firmware ath10k!QCA988X!hw2.0!board-2.bin:
> >>firmware_loading_store: map pages failed
> >>[   11.011123] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> >>crc32 bebc7c08
> >>[   12.155224] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op
> >>2 cal file max-sta 128 raw 0 hwcrypto 1
> >>
> >>Station A (wlan0):
> >>18:A6:F7:23:6E:66
> >>10.230.5.41
> >>
> >>Station B (wlan0):
> >>18:a6:f7:26:0f:21
> >>10.230.5.42
> >>
> >>Station Dump on Station A before ping:
> >>Station 18:a6:f7:26:0f:21 (on wlan0)
> >>inactive time:340 ms
> >>rx bytes:2472
> >>rx packets:28
> >>tx bytes:1204
> >>tx packets:9
> >>tx retries:0
> >>tx failed:0
> >>rx drop misc:1
> >>signal: -14 dBm
> >>signal avg:-14 dBm
> >>Toffset:18142530 us
> >>tx bitrate:6.0 MBit/s
> >>rx bitrate:6.0 MBit/s
> >>rx duration:1524 us
> >>mesh llid:0
> >>mesh plid:0
> >>mesh plink:ESTAB
> >>mesh local PS mode:ACTIVE
> >>mesh peer PS mode:UNKNOWN
> >>mesh non-peer PS mode:ACTIVE
> >>authorized:yes
> >>authenticated:yes
> >>associated:yes
> >>preamble:long
> >>WMM/WME:yes
> >>MFP:yes
> >>TDLS peer:no
> >>DTIM period:2
> >>beacon interval:1000
> >>connected time:10 seconds
> >>
> >>?Crash Log on Station B (10.230.5.42)
> >>[245.483888] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> >>2bab5ee9-08ff-4a17-95b1-636d212acebc)
> >>[245.493020] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> >>0x4100016c chip_id 0x043202ff sub 0000:0000
> >>[245.502384] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
> >>tracing 0 dfs 1 testmode 1
> >>[245.515436] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api
> >>5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> >>[245.525812] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> >>crc32 bebc7c08
> >>[245.533232] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
> >>cal file max-sta 128 raw 0 hwcrypto 1
> >>[245.544876] ath10k_pci 0000:01:00.0: firmware register dump:
> >>[245.550633] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> >>0x009A4577 0x00955B31
> >>[245.558676] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
> >>0x00000002 0x00439E98
> >>[245.566715] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
> >>0x00407120 0x004436CC
> >>[245.574749] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
> >>0x009A3518 0x009A3526
> >>[245.582793] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> >>0x00000000 0x00000000
> >>[245.590836] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
> >>0x0040AC60 0x0040AC09
> >>[245.598882] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
> >>0x00400000 0xC09A4577
> >>[245.606923] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
> >>0x0044110C 0x00442074
> >>[245.614955] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
> >>0x0044110C 0x00407120
> >>[245.623000] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
> >>0x0040AC14 0x00001580
> >>[245.631043] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
> >>0x009C643C 0x004436CC
> >>[245.639086] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
> >>0x004208FC 0x00439E4C
> >>[245.647129] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
> >>0x004208FC 0x00425404
> >>[245.655170] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
> >>0x00424FE8 0x00000002
> >>[245.663198] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
> >>0x00000004 0x004039D0
> >>[245.767023] ieee80211 phy0: Hardware restart was requested
> >>[245.772655] ath10k_pci 0000:01:00.0: failed to synchronize monitor
> >>vdev 1 stop: -143
> >>[245.780542] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
> >>?
> >>With wpa_supplicant turned off:
> >>
> >>Station Dump on Station A before ping:
> >>Station 18:a6:f7:26:0f:21 (on wlan0)
> >>inactive time:60 ms
> >>rx bytes:3874
> >>rx packets:67
> >>tx bytes:707
> >>tx packets:7
> >>tx retries:0
> >>tx failed:1
> >>rx drop misc:3
> >>signal: -14 dBm
> >>signal avg:-14 dBm
> >>Toffset:18446744073684250999 us
> >>tx bitrate:6.0 MBit/s
> >>rx bitrate:6.0 MBit/s
> >>rx duration:1312 us
> >>mesh llid:24953
> >>mesh plid:59412
> >>mesh plink:ESTAB
> >>mesh local PS mode:ACTIVE
> >>mesh peer PS mode:UNKNOWN
> >>mesh non-peer PS mode:ACTIVE
> >>authorized:yes
> >>authenticated:yes
> >>associated:yes
> >>preamble:long
> >>WMM/WME:yes
> >>MFP:no
> >>TDLS peer:no
> >>DTIM period:2
> >>beacon interval:1000
> >>short slot time:yes
> >>connected time:33 seconds
> >>
> >>Firmware crash on Station A (10.230.5.41)
> >>[ 1040.984599] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> >>42d4f6dc-0e89-4505-aefb-58cbb70d0dce)
> >>[ 1040.993732] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> >>0x4100016c chip_id 0x043202ff sub 0000:0000
> >>[ 1041.003100] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
> >>tracing 0 dfs 1 testmode 1
> >>[ 1041.016144] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54
> >>api 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> >>[ 1041.026523] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> >>crc32 bebc7c08
> >>[ 1041.033940] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op
> >>2 cal file max-sta 128 raw 0 hwcrypto 1
> >>[ 1041.045593] ath10k_pci 0000:01:00.0: firmware register dump:
> >>[ 1041.051336] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> >>0x009A4577 0x00955B31
> >>[ 1041.059383] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
> >>0x00000001 0x00435354
> >>[ 1041.067424] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
> >>0x00407120 0x004436CC
> >>[ 1041.075463] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
> >>0x009A43A0 0x009A43DE
> >>[ 1041.083490] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> >>0x00000000 0x00000000
> >>[ 1041.091535] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
> >>0x0040AC60 0x0040AC09
> >>[ 1041.099579] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
> >>0x00955A00 0xC09A4577
> >>[ 1041.107622] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
> >>0x0044110C 0x00442074
> >>[ 1041.115661] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
> >>0x0044110C 0x00407120
> >>[ 1041.123689] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
> >>0x0040AC10 0x00001580
> >>[ 1041.131733] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
> >>0x009C643C 0x004436CC
> >>[ 1041.139777] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
> >>0x004208FC 0x00439E4C
> >>[ 1041.147820] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
> >>0x004208FC 0x00425758
> >>[ 1041.155860] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
> >>0x00424FE8 0x00000002
> >>[ 1041.163888] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
> >>0x00000004 0x004039D0
> >>[ 1041.267025] ieee80211 phy0: Hardware restart was requested
> >>[ 1041.272656] ath10k_pci 0000:01:00.0: failed to synchronize
> >>monitor vdev 1 stop: -143
> >>[ 1041.280545] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
> >>
> >>?
> >>Thanks in advance for your time and help,
> >>
> >>~Benjamin
> >>
> 


From mohammed at codeaurora.org  Sat Dec  3 04:46:00 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Sat, 3 Dec 2016 18:16:00 +0530
Subject: ath10k firmware crashes in mesh mode on QCA9880
In-Reply-To: <20161203124358.GB31861@atheros-ThinkPad-T61>
References: <583DD564.8040704@cococorp.com>
 <20161201070908.GB11953@atheros-ThinkPad-T61>
 <58421FA2.2020004@cococorp.com>
 <20161203124358.GB31861@atheros-ThinkPad-T61>
Message-ID: <20161203124600.GC31861@atheros-ThinkPad-T61>

https://patchwork.kernel.org/patch/9437519/
(sorry missed this in the previous thread)

On Sat, Dec 03, 2016 at 06:13:58PM +0530, Mohammed Shafi Shajakhan wrote:
> Hi Benjamin,
> 
> On Fri, Dec 02, 2016 at 05:28:02PM -0800, Benjamin Morgan wrote:
> > Just tried 10.2.4.70.58 firmware that you linked to and it still crashes:
> > 
> > [  131.568989] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> > 1838347e-9380-4a26-ac9d-2963ee95968b)
> > [  131.578124] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> > 0x4100016c chip_id 0x043202ff sub 0000:0000
> > [  131.587491] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
> > tracing 0 dfs 1 testmode 1
> > [  131.600521] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.58
> > api 5 features no-p2p,raw-mode,mfp crc32 e1af076f
> > [  131.610899] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> > crc32 bebc7c08
> > [  131.618325] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op
> > 2 cal file max-sta 128 raw 0 hwcrypto 1
> > [  131.629965] ath10k_pci 0000:01:00.0: firmware register dump:
> > [  131.635728] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> > 0x009A45AF 0x00955B31
> > [  131.643761] ath10k_pci 0000:01:00.0: [04]: 0x009A45AF 0x00060130
> > 0x00000002 0x00439E98
> > [  131.651806] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
> > 0x00407120 0x004436CC
> > [  131.659852] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
> > 0x009A3550 0x009A355E
> > [  131.667892] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x009A31D6
> > 0x00000000 0x00000000
> > [  131.675936] ath10k_pci 0000:01:00.0: [20]: 0x409A45AF 0x0040AAC4
> > 0x0040AC60 0x0040AC09
> > [  131.683968] ath10k_pci 0000:01:00.0: [24]: 0x809A44F2 0x0040AB24
> > 0x00400000 0xC09A45AF
> > [  131.692013] ath10k_pci 0000:01:00.0: [28]: 0x809A3A16 0x0040AB84
> > 0x0044110C 0x00442074
> > [  131.700056] ath10k_pci 0000:01:00.0: [32]: 0x809A601A 0x0040ABB4
> > 0x0044110C 0x00407120
> > [  131.708100] ath10k_pci 0000:01:00.0: [36]: 0x809A2EA4 0x0040ABF4
> > 0x0040AC14 0x00001580
> > [  131.716143] ath10k_pci 0000:01:00.0: [40]: 0x80990F63 0x0040AD04
> > 0x009C6458 0x004436CC
> > [  131.724175] ath10k_pci 0000:01:00.0: [44]: 0x80998520 0x0040AD64
> > 0x004208FC 0x00439E4C
> > [  131.732220] ath10k_pci 0000:01:00.0: [48]: 0x8099AEA5 0x0040AD84
> > 0x004208FC 0x00425874
> > [  131.740263] ath10k_pci 0000:01:00.0: [52]: 0x809BFC39 0x0040AEE4
> > 0x00424FE8 0x00000002
> > [  131.748306] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
> > 0x00000004 0x004039D0
> > [  131.857076] ieee80211 phy0: Hardware restart was requested
> > [  131.862705] ath10k_pci 0000:01:00.0: failed to synchronize
> > monitor vdev 1 stop: -143
> > [  131.870594] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
> 
> [shafi] request to try with the latest backports and ath.git
> Also worth trying this fix in ath10k (once the next firmware version)
> is available. I will keep you posted. thank you !
> 
> > 
> > ~Benjamin
> > 
> > On 11/30/2016 11:09 PM, Mohammed Shafi Shajakhan wrote:
> > >Hi,
> > >
> > >On Tue, Nov 29, 2016 at 11:22:12AM -0800, Benjamin Morgan wrote:
> > >>When we try to transmit traffic (ping) between two meshed ath10k
> > >>devices running latest lede we keep experiencing ath10k firmware
> > >>crashes. This seems to only happen when running in 802.11n/ac mode
> > >>but not in 802.11a/g mode. Also, from the station dumps it appears
> > >>that management traffic is flowing between the devices, however when
> > >>we try to send unicast data traffic the firmware crashes
> > >>immediately.
> > >[shafi] Did you get a chance to try with the below firmware as well
> > >https://github.com/kvalo/ath10k-firmware/blob/master/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.58
> > >
> > >>Platform: Archer C7 AC1750 v2
> > >>Software Image: LEDE (HEAD, r2299) Commit: https://github.com/lede-project/source/commit/d596c21ebd5a3e6ce933eff3e51989031e4b1d58
> > >>
> > >>Crypto: wpa_supplicant
> > >>wpa_supplicant-wlan0.conf
> > >>network={
> > >>ssid="bmorgan_lede_mesh"
> > >>key_mgmt=SAE
> > >>mode=5
> > >>frequency=5180
> > >>psk="meshpassword"
> > >>}
> > >>
> > >>Backports Verstion:
> > >>[    9.818007] Loading modules backported from Linux version
> > >>wt-2016-10-03-1-g6fcb1a6
> > >>[    9.825736] Backport generated by backports.git
> > >>backports-20160324-9-g0e38f5c
> > >>
> > >>??Ath10k Initialization on Station A (dmesg)
> > >>[    9.896715] PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
> > >>[    9.902622] ath10k_pci 0000:01:00.0: pci irq legacy oper_irq_mode
> > >>1 irq_mode 0 reset_mode 0
> > >>[   10.123734] ath10k_pci 0000:01:00.0: Direct firmware load for
> > >>ath10k/pre-cal-pci-0000:01:00.0.bin failed with error -2
> > >>[   10.134620] ath10k_pci 0000:01:00.0: Falling back to user helper
> > >>[   10.287680] firmware ath10k!pre-cal-pci-0000:01:00.0.bin:
> > >>firmware_loading_store: map pages failed
> > >>[   10.622789] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> > >>0x4100016c chip_id 0x043202ff sub 0000:0000
> > >>[   10.632184] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
> > >>tracing 0 dfs 1 testmode 1
> > >>[   10.645231] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54
> > >>api 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> > >>[   10.655660] ath10k_pci 0000:01:00.0: Direct firmware load for
> > >>ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
> > >>[   10.666264] ath10k_pci 0000:01:00.0: Falling back to user helper
> > >>[   10.747925] firmware ath10k!QCA988X!hw2.0!board-2.bin:
> > >>firmware_loading_store: map pages failed
> > >>[   11.011123] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> > >>crc32 bebc7c08
> > >>[   12.155224] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op
> > >>2 cal file max-sta 128 raw 0 hwcrypto 1
> > >>
> > >>Station A (wlan0):
> > >>18:A6:F7:23:6E:66
> > >>10.230.5.41
> > >>
> > >>Station B (wlan0):
> > >>18:a6:f7:26:0f:21
> > >>10.230.5.42
> > >>
> > >>Station Dump on Station A before ping:
> > >>Station 18:a6:f7:26:0f:21 (on wlan0)
> > >>inactive time:340 ms
> > >>rx bytes:2472
> > >>rx packets:28
> > >>tx bytes:1204
> > >>tx packets:9
> > >>tx retries:0
> > >>tx failed:0
> > >>rx drop misc:1
> > >>signal: -14 dBm
> > >>signal avg:-14 dBm
> > >>Toffset:18142530 us
> > >>tx bitrate:6.0 MBit/s
> > >>rx bitrate:6.0 MBit/s
> > >>rx duration:1524 us
> > >>mesh llid:0
> > >>mesh plid:0
> > >>mesh plink:ESTAB
> > >>mesh local PS mode:ACTIVE
> > >>mesh peer PS mode:UNKNOWN
> > >>mesh non-peer PS mode:ACTIVE
> > >>authorized:yes
> > >>authenticated:yes
> > >>associated:yes
> > >>preamble:long
> > >>WMM/WME:yes
> > >>MFP:yes
> > >>TDLS peer:no
> > >>DTIM period:2
> > >>beacon interval:1000
> > >>connected time:10 seconds
> > >>
> > >>?Crash Log on Station B (10.230.5.42)
> > >>[245.483888] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> > >>2bab5ee9-08ff-4a17-95b1-636d212acebc)
> > >>[245.493020] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> > >>0x4100016c chip_id 0x043202ff sub 0000:0000
> > >>[245.502384] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
> > >>tracing 0 dfs 1 testmode 1
> > >>[245.515436] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api
> > >>5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> > >>[245.525812] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> > >>crc32 bebc7c08
> > >>[245.533232] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
> > >>cal file max-sta 128 raw 0 hwcrypto 1
> > >>[245.544876] ath10k_pci 0000:01:00.0: firmware register dump:
> > >>[245.550633] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> > >>0x009A4577 0x00955B31
> > >>[245.558676] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
> > >>0x00000002 0x00439E98
> > >>[245.566715] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
> > >>0x00407120 0x004436CC
> > >>[245.574749] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
> > >>0x009A3518 0x009A3526
> > >>[245.582793] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> > >>0x00000000 0x00000000
> > >>[245.590836] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
> > >>0x0040AC60 0x0040AC09
> > >>[245.598882] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
> > >>0x00400000 0xC09A4577
> > >>[245.606923] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
> > >>0x0044110C 0x00442074
> > >>[245.614955] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
> > >>0x0044110C 0x00407120
> > >>[245.623000] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
> > >>0x0040AC14 0x00001580
> > >>[245.631043] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
> > >>0x009C643C 0x004436CC
> > >>[245.639086] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
> > >>0x004208FC 0x00439E4C
> > >>[245.647129] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
> > >>0x004208FC 0x00425404
> > >>[245.655170] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
> > >>0x00424FE8 0x00000002
> > >>[245.663198] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
> > >>0x00000004 0x004039D0
> > >>[245.767023] ieee80211 phy0: Hardware restart was requested
> > >>[245.772655] ath10k_pci 0000:01:00.0: failed to synchronize monitor
> > >>vdev 1 stop: -143
> > >>[245.780542] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
> > >>?
> > >>With wpa_supplicant turned off:
> > >>
> > >>Station Dump on Station A before ping:
> > >>Station 18:a6:f7:26:0f:21 (on wlan0)
> > >>inactive time:60 ms
> > >>rx bytes:3874
> > >>rx packets:67
> > >>tx bytes:707
> > >>tx packets:7
> > >>tx retries:0
> > >>tx failed:1
> > >>rx drop misc:3
> > >>signal: -14 dBm
> > >>signal avg:-14 dBm
> > >>Toffset:18446744073684250999 us
> > >>tx bitrate:6.0 MBit/s
> > >>rx bitrate:6.0 MBit/s
> > >>rx duration:1312 us
> > >>mesh llid:24953
> > >>mesh plid:59412
> > >>mesh plink:ESTAB
> > >>mesh local PS mode:ACTIVE
> > >>mesh peer PS mode:UNKNOWN
> > >>mesh non-peer PS mode:ACTIVE
> > >>authorized:yes
> > >>authenticated:yes
> > >>associated:yes
> > >>preamble:long
> > >>WMM/WME:yes
> > >>MFP:no
> > >>TDLS peer:no
> > >>DTIM period:2
> > >>beacon interval:1000
> > >>short slot time:yes
> > >>connected time:33 seconds
> > >>
> > >>Firmware crash on Station A (10.230.5.41)
> > >>[ 1040.984599] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> > >>42d4f6dc-0e89-4505-aefb-58cbb70d0dce)
> > >>[ 1040.993732] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> > >>0x4100016c chip_id 0x043202ff sub 0000:0000
> > >>[ 1041.003100] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
> > >>tracing 0 dfs 1 testmode 1
> > >>[ 1041.016144] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54
> > >>api 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> > >>[ 1041.026523] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> > >>crc32 bebc7c08
> > >>[ 1041.033940] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op
> > >>2 cal file max-sta 128 raw 0 hwcrypto 1
> > >>[ 1041.045593] ath10k_pci 0000:01:00.0: firmware register dump:
> > >>[ 1041.051336] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> > >>0x009A4577 0x00955B31
> > >>[ 1041.059383] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
> > >>0x00000001 0x00435354
> > >>[ 1041.067424] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
> > >>0x00407120 0x004436CC
> > >>[ 1041.075463] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
> > >>0x009A43A0 0x009A43DE
> > >>[ 1041.083490] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> > >>0x00000000 0x00000000
> > >>[ 1041.091535] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
> > >>0x0040AC60 0x0040AC09
> > >>[ 1041.099579] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
> > >>0x00955A00 0xC09A4577
> > >>[ 1041.107622] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
> > >>0x0044110C 0x00442074
> > >>[ 1041.115661] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
> > >>0x0044110C 0x00407120
> > >>[ 1041.123689] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
> > >>0x0040AC10 0x00001580
> > >>[ 1041.131733] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
> > >>0x009C643C 0x004436CC
> > >>[ 1041.139777] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
> > >>0x004208FC 0x00439E4C
> > >>[ 1041.147820] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
> > >>0x004208FC 0x00425758
> > >>[ 1041.155860] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
> > >>0x00424FE8 0x00000002
> > >>[ 1041.163888] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
> > >>0x00000004 0x004039D0
> > >>[ 1041.267025] ieee80211 phy0: Hardware restart was requested
> > >>[ 1041.272656] ath10k_pci 0000:01:00.0: failed to synchronize
> > >>monitor vdev 1 stop: -143
> > >>[ 1041.280545] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
> > >>
> > >>?
> > >>Thanks in advance for your time and help,
> > >>
> > >>~Benjamin
> > >>
> > 


From michal.kazior at tieto.com  Mon Dec  5 00:13:21 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 5 Dec 2016 09:13:21 +0100
Subject: [PATCH 1/2] mac80211: do not iterate active interfaces when in
 re-configure
In-Reply-To: <1480645800-2148-1-git-send-email-greearb@candelatech.com>
References: <1480645800-2148-1-git-send-email-greearb@candelatech.com>
Message-ID: <CA+BoTQkEaC-ZSbeK=JB=q+ucF1PWcEQXkJEp6JYv4pfOf35cHg@mail.gmail.com>

On 2 December 2016 at 03:29,  <greearb at candelatech.com> wrote:
> From: Ben Greear <greearb at candelatech.com>
>
> This appears to fix a problem where ath10k firmware would crash,
> mac80211 would start re-adding interfaces to the driver, but the
> iterate-active-interfaces logic would then try to use the half-built
> interfaces.  With a bit of extra debug to catch the problem, the
> ath10k crash looks like this:
>
> ath10k_pci 0000:05:00.0: Initializing arvif: ffff8801ce97e320 on vif: ffff8801ce97e1d8
>
> [the print that happens after arvif->ar is assigned is not shown, so code did not make it that far before
>  the tx-beacon-nowait method was called]
>
> tx-beacon-nowait:  arvif: ffff8801ce97e320  ar:           (null)
[...]
>
> Signed-off-by: Ben Greear <greearb at candelatech.com>
> ---
>  net/mac80211/util.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> index 863f2c1..abe1f64 100644
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@ -705,7 +705,7 @@ static void __iterate_interfaces(struct ieee80211_local *local,
>                         break;
>                 }
>                 if (!(iter_flags & IEEE80211_IFACE_ITER_RESUME_ALL) &&
> -                   active_only && !(sdata->flags & IEEE80211_SDATA_IN_DRIVER))
> +                   (active_only && (local->in_reconfig || !(sdata->flags & IEEE80211_SDATA_IN_DRIVER))))
>                         continue;

Doesn't this effectivelly prevent you from iterating over interfaces
completely during reconfig? As you bring up interfaces you might
need/want to iterate over others to re-adjust your own state.

I'd argue there should be another flag, IEEE80211_SDATA_RESUMING, used
with sdata->flags for resuming so that once it is re-added to the
driver it can be cleared (and therefore properly iterated over).


Micha?


From michal.kazior at tieto.com  Mon Dec  5 00:50:55 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 5 Dec 2016 09:50:55 +0100
Subject: [PATCH 1/3] ath10k: Ensure there are no stale ar->txqs entries.
In-Reply-To: <ef7e16a6-9353-0f63-ac70-fc8e234d6c25@candelatech.com>
References: <1471569995-10028-1-git-send-email-greearb@candelatech.com>
 <CA+BoTQn0d1bEB662r-Yivmdk_21LhjCQjJP_GoPaj-WT2wA=1g@mail.gmail.com>
 <57B70AED.2010200@candelatech.com>
 <ba1cc818-6194-11d6-7cc3-1db28036a519@candelatech.com>
 <ef7e16a6-9353-0f63-ac70-fc8e234d6c25@candelatech.com>
Message-ID: <CA+BoTQnuLbVzuEVvf9+wOGhj7i3DV2LaMqGBfGhQHEgOSXei4g@mail.gmail.com>

On 2 December 2016 at 01:24, Ben Greear <greearb at candelatech.com> wrote:
> On 12/01/2016 02:52 PM, Ben Greear wrote:
>>
>> On 08/19/2016 06:34 AM, Ben Greear wrote:
>>>
>>>
>>>
>>> On 08/18/2016 11:59 PM, Michal Kazior wrote:
>>>>
>>>> On 19 August 2016 at 03:26,  <greearb at candelatech.com> wrote:
>>>>>
>>>>> From: Ben Greear <greearb at candelatech.com>
>>>>>
>>>>> I was seeing kernel crashes due to accessing freed memory
>>>>> while debugging a 9984 firmware that was crashing often.
>>>>>
>>>>> This patch fixes the crashes.  I am not certain if there
>>>>> is a better way or not.
>
>
> Michal, thanks for the help on IRC.  I added this logic:
>
> static void ieee80211_drv_tx(struct ieee80211_local *local,
>                              struct ieee80211_vif *vif,
>                              struct ieee80211_sta *pubsta,
>                              struct sk_buff *skb)
> {
>         struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
>         struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
>         struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
>         struct ieee80211_tx_control control = {
>                 .sta = pubsta,
>         };
>         struct ieee80211_txq *txq = NULL;
>         struct txq_info *txqi;
>         u8 ac;
>
>         if ((info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM) ||
>             (info->control.flags & IEEE80211_TX_CTRL_PS_RESPONSE))
>                 goto tx_normal;
>
>         if (!ieee80211_is_data(hdr->frame_control))
>                 goto tx_normal;
>
>         if (unlikely(!ieee80211_sdata_running(sdata))) {
>                 WARN_ON_ONCE(1);
>                 goto delete_and_return;
>         }
>
> ...
>
>         if (atomic_read(&sdata->txqs_len[ac]) >=
>             (local->hw.txq_ac_max_pending * 2)) {
>                 /* Must be that something is not paying attention to
>                  * max-pending, like pktgen, so just drop this frame.
>                  */
> delete_and_return:
>                 ieee80211_free_txskb(&local->hw, skb);
>                 return;
>         }
>
>
> But, I still see the txq entries on the ar->txqs list in the
> ath10k_mac_txq_init
> after firmware crash in my test case.  Is this the test you were suggesting?

Yes.

Now that I think about it mac80211 doesn't call anything in driver
during hw_restart that would unref txqs. This means you'll have them
still linked when add_interface/sta_state is called, no?

This means that either:
 (a) txq (re-)init should be smarter in ath10k
 (b) txqs should be purged during hw_restart in ath10k


Micha?


From kvalo at qca.qualcomm.com  Mon Dec  5 02:29:13 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Mon, 5 Dec 2016 10:29:13 +0000
Subject: ath10k: wmi-alloc-chunk should use DMA_BIDIRECTIONAL.
In-Reply-To: <1480456828-13735-1-git-send-email-greearb@candelatech.com>
 (greearb@candelatech.com's message of "Tue, 29 Nov 2016 14:00:28	-0800")
References: <1480456828-13735-1-git-send-email-greearb@candelatech.com>
Message-ID: <87k2beoeiv.fsf@kamboji.qca.qualcomm.com>

greearb at candelatech.com writes:

> From: Ben Greear <greearb at candelatech.com>
>
> These memory chunks are often used as 'swap' by the NIC,
> so it will be both reading and writing to these areas.
>
> This seems to fix errors like this on my x86-64 machine:
>
> kernel: DMAR: DMAR:[DMA Write] Request device [05:00.0] fault addr ff5de000
>         DMAR:[fault reason 05] PTE Write access is not set

Noticed this in my log, but I don't have time to investigate this in
detail right now:

[  413.795346] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  414.158755] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  477.439659] ath10k_pci 0000:02:00.0: could not get mac80211 beacon
[  481.666630] ------------[ cut here ]------------
[  481.666669] WARNING: CPU: 0 PID: 1978 at lib/dma-debug.c:1155 check_unmap+0x320/0x8e0
[  481.666688] ath10k_pci 0000:02:00.0: DMA-API: device driver frees DMA memory with different direction [device address=0x000000002d130000] [size=63800 bytes] [mapped with DMA_BIDIRECTIONAL] [unmapped with DMA_TO_DEVICE]
[  481.666703] Modules linked in: ctr ccm ath10k_pci(E-) ath10k_core(E) ath(E) mac80211(E) cfg80211(E) snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi arc4 snd_rawmidi snd_seq_midi_event snd_seq btusb btintel snd_seq_device joydev coret
[  481.671468] CPU: 0 PID: 1978 Comm: rmmod Tainted: G            E   4.9.0-rc7-wt+ #54
[  481.671478] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD Ver. F.04 01/27/2010
[  481.671489]  ef49dcec c842ee92 c8b5830e ef49dd34 ef49dd20 c80850f5 c8b5a13c ef49dd50
[  481.671560]  000007ba c8b5830e 00000483 c8461830 c8461830 00000483 ef49ddcc f34e64b8
[  481.671641]  c8b58360 ef49dd3c c80851bb 00000009 00000000 ef49dd34 c8b5a13c ef49dd50
[  481.671716] Call Trace:
[  481.671731]  [<c842ee92>] dump_stack+0x76/0xb4
[  481.671745]  [<c80850f5>] __warn+0xe5/0x100
[  481.671757]  [<c8461830>] ? check_unmap+0x320/0x8e0
[  481.671769]  [<c8461830>] ? check_unmap+0x320/0x8e0
[  481.671780]  [<c80851bb>] warn_slowpath_fmt+0x3b/0x40
[  481.671791]  [<c8461830>] check_unmap+0x320/0x8e0
[  481.671804]  [<c8462054>] debug_dma_unmap_page+0x84/0xa0
[  481.671835]  [<f937cd7a>] ath10k_wmi_free_host_mem+0x9a/0xe0 [ath10k_core]
[  481.671861]  [<f9363400>] ath10k_core_destroy+0x50/0x60 [ath10k_core]
[  481.671875]  [<f8e13969>] ath10k_pci_remove+0x79/0xa0 [ath10k_pci]
[  481.671889]  [<c848d8d8>] pci_device_remove+0x38/0xb0
[  481.671901]  [<c859fe4b>] __device_release_driver+0x7b/0x110
[  481.671913]  [<c85a00e7>] driver_detach+0x97/0xa0
[  481.671923]  [<c859ef8b>] bus_remove_driver+0x4b/0xb0
[  481.671934]  [<c85a0cda>] driver_unregister+0x2a/0x60
[  481.671949]  [<c848c888>] pci_unregister_driver+0x18/0x70
[  481.671965]  [<f8e14dae>] ath10k_pci_exit+0xd/0x25f [ath10k_pci]
[  481.671979]  [<c812bb84>] SyS_delete_module+0xf4/0x180
[  481.671995]  [<c81f801b>] ? __might_fault+0x8b/0xa0
[  481.672009]  [<c80037d0>] do_fast_syscall_32+0xa0/0x1e0
[  481.672025]  [<c88d4c88>] sysenter_past_esp+0x45/0x74
[  481.672037] ---[ end trace 3fd23759e17e1622 ]---
[  481.672049] Mapped at:
[  481.672060]  [  481.672072] [<c846062c>] debug_dma_map_page.part.25+0x1c/0xf0
[  481.672083]  [  481.672095] [<c8460799>] debug_dma_map_page+0x99/0xc0
[  481.672106]  [  481.672132] [<f93745ec>] ath10k_wmi_alloc_chunk+0x12c/0x1f0 [ath10k_core]
[  481.672142]  [  481.672168] [<f937d0c4>] ath10k_wmi_event_service_ready_work+0x304/0x540 [ath10k_core]
[  481.672178]  [  481.672190] [<c80a3643>] process_one_work+0x1c3/0x670
[  482.137134] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[  482.313144] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:02:00.0.bin failed with error -2
[  482.313274] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/cal-pci-0000:02:00.0.bin failed with error -2
[  482.313768] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
[  482.313777] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 0 testmode 1
[  482.313974] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
[  482.369858] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
[  482.370011] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
[  483.596770] 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
[  483.701686] ath: EEPROM regdomain: 0x0
[  483.701706] ath: EEPROM indicates default country code should be used
[  483.701713] ath: doing EEPROM country->regdmn map search
[  483.701721] ath: country maps to regdmn code: 0x3a
[  483.701730] ath: Country alpha2 being used: US
[  483.701737] ath: Regpair used: 0x3a

-- 
Kalle Valo

From jp.tosoni at acksys.fr  Mon Dec  5 00:43:55 2016
From: jp.tosoni at acksys.fr (Jean-Pierre Tosoni)
Date: Mon, 5 Dec 2016 09:43:55 +0100
Subject: TR: Client station sends probes on DFS channels
In-Reply-To: <CAJ-VmonyohH8qEGMYT5fVAgQ9BskZYj9djYU6mZ1Zp_HEsgdVw@mail.gmail.com>
References: <006401d24b34$191d7830$4b586890$@acksys.fr>
 <CAJ-Vmom1EDyHH8Pcuxq83ptsYEGj0LWeDCNvx7gDAUKQmbWZ6g@mail.gmail.com>
 <008001d24bb3$2f1e4db0$8d5ae910$@acksys.fr>
 <CAJ-VmokWUF=TkQcYdzSZ9z4Ozb3Ci-XGY_DP6-tp2rQD2sh5iQ@mail.gmail.com>
 <000001d24bf5$b0c9c690$125d53b0$@acksys.fr>
 <CAJ-VmokpLMHL3ND34C4FAW3tVtxHKKOcgSHR9Vs+GsxPwMVE8A@mail.gmail.com>
 <000201d24bfb$e0248550$a06d8ff0$@acksys.fr>
 <CAJ-Vmo=DabqVwVpBui7gu9p9EBQ_o+o7JGSaKriHvA-OMWBb0A@mail.gmail.com>
 <000301d24bff$61d07200$25715600$@acksys.fr>
 <CAJ-VmonyohH8qEGMYT5fVAgQ9BskZYj9djYU6mZ1Zp_HEsgdVw@mail.gmail.com>
Message-ID: <001c01d24ed3$b6c5ad80$24510880$@acksys.fr>

Just keeping the list informed... At some point the discussion turned private.

Jean-Pierre Tosoni

-----Message d'origine-----
De : Adrian Chadd [mailto:adrian.chadd at gmail.com] 
Envoy? : jeudi 1 d?cembre 2016 19:20
? : Jean-Pierre Tosoni
Objet : Re: Client station sends probes on DFS channels

well, if it fails ETSI certification then you can file a complain with QCA. :) they're passing certification tests with it atm, so...


-a


On 1 December 2016 at 10:18, Jean-Pierre Tosoni <jp.tosoni at acksys.fr> wrote:
> :(
> Can we expect a fix someday?
>
> JP
>
>
>
>> -----Message d'origine-----
>> De : Adrian Chadd [mailto:adrian.chadd at gmail.com] Envoy? : jeudi 1 
>> d?cembre 2016 19:00 ? : Jean-Pierre Tosoni Objet : Re: Client station 
>> sends probes on DFS channels
>>
>> firmware
>>
>>
>> -a
>>
>>
>> On 1 December 2016 at 09:53, Jean-Pierre Tosoni <jp.tosoni at acksys.fr>
>> wrote:
>> > Hi again,
>> >
>> > That being said, is this 10-minutes delay implemented in ath10k or 
>> > in the firmware of the card? Or is it configurable maybe?
>> >
>> > Jean-Pierre
>> >
>> >> -----Message d'origine-----
>> >> De : Adrian Chadd [mailto:adrian.chadd at gmail.com] Envoy? : jeudi 1 
>> >> d?cembre 2016 18:21 ? : Jean-Pierre Tosoni Objet : Re: Client 
>> >> station sends probes on DFS channels
>> >>
>> >> Hi,
>> >>
>> >> So the implementations I've seen all treat "I see beacons" as "the 
>> >> channel is blessed"; there's no logic for doing it for an AP that 
>> >> you're associated to.
>> >>
>> >> That's likely what we need clarification around.
>> >>
>> >> The "controlled by a master" doesn't necessarily imply that the 
>> >> STA is controlled by the AP, just that the AP has gone through the 
>> >> CAC and is doing DFS checking. Otherwise the STA couldn't actually 
>> >> send assoc req/response frames, because the station hasn't yet 
>> >> associated to an AP to be considered "in control" by it.
>> >>
>> >>
>> >> -adrian
>> >>
>> >>
>> >> On 1 December 2016 at 09:09, Jean-Pierre Tosoni 
>> >> <jp.tosoni at acksys.fr>
>> >> wrote:
>> >> > Not quite so.
>> >> >
>> >> >> * if you get a CSA, the STA should move and not use the air
>> >> >
>> >> > No, because the STA is not associated: it is currently searching 
>> >> > for an
>> >> AP.
>> >> > So, it cannot receive a CSA, and should do a passive scan.
>> >> >
>> >> >> * if you just start another AP And then kill the APs, there's 
>> >> >> nothing above that says when the STA should stop talking?
>> >> >
>> >> > Wrong, the norm says that the STA should *not begin* talking 
>> >> > (since it is not associated with a master AP)
>> >> >
>> >> >> -----Message d'origine-----
>> >> >> De : Adrian Chadd [mailto:adrian.chadd at gmail.com] Envoy? : 
>> >> >> jeudi 1 d?cembre 2016 17:53 ? : Jean-Pierre Tosoni Cc :
>> >> >> ath10k at lists.infradead.org Objet : Re: Client station sends 
>> >> >> probes on DFS channels
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> So to be clear:
>> >> >>
>> >> >> * if you get a CSA, the STA should move and not use the air
>> >> >> * if you just start another AP And then kill the APs, there's 
>> >> >> nothing above that says when the STA should stop talking?
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >>
>> >> >>
>> >> >> -adrian
>> >> >
>> >
>



From johannes at sipsolutions.net  Mon Dec  5 05:52:30 2016
From: johannes at sipsolutions.net (Johannes Berg)
Date: Mon, 05 Dec 2016 14:52:30 +0100
Subject: [PATCH 1/2] mac80211: do not iterate active interfaces when in
 re-configure
In-Reply-To: <CA+BoTQkEaC-ZSbeK=JB=q+ucF1PWcEQXkJEp6JYv4pfOf35cHg@mail.gmail.com>
 (sfid-20161205_092619_855272_0854B225)
References: <1480645800-2148-1-git-send-email-greearb@candelatech.com>
 <CA+BoTQkEaC-ZSbeK=JB=q+ucF1PWcEQXkJEp6JYv4pfOf35cHg@mail.gmail.com>
 (sfid-20161205_092619_855272_0854B225)
Message-ID: <1480945950.31788.4.camel@sipsolutions.net>

On Mon, 2016-12-05 at 09:13 +0100, Michal Kazior wrote:
> On 2 December 2016 at 03:29,??<greearb at candelatech.com> wrote:
> > 
> > From: Ben Greear <greearb at candelatech.com>
> > 
> > This appears to fix a problem where ath10k firmware would crash,
> > mac80211 would start re-adding interfaces to the driver, but the
> > iterate-active-interfaces logic would then try to use the half-
> > built
> > interfaces.??With a bit of extra debug to catch the problem, the
> > ath10k crash looks like this:
> > 
> > ath10k_pci 0000:05:00.0: Initializing arvif: ffff8801ce97e320 on
> > vif: ffff8801ce97e1d8
> > 
> > [the print that happens after arvif->ar is assigned is not shown,
> > so code did not make it that far before
> > ?the tx-beacon-nowait method was called]
> > 
> > tx-beacon-nowait:??arvif: ffff8801ce97e320??ar:???????????(null)
> [...]
> > 
> > 
> > Signed-off-by: Ben Greear <greearb at candelatech.com>
> > ---
> > ?net/mac80211/util.c | 2 +-
> > ?1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> > index 863f2c1..abe1f64 100644
> > --- a/net/mac80211/util.c
> > +++ b/net/mac80211/util.c
> > @@ -705,7 +705,7 @@ static void __iterate_interfaces(struct
> > ieee80211_local *local,
> > ????????????????????????break;
> > ????????????????}
> > ????????????????if (!(iter_flags & IEEE80211_IFACE_ITER_RESUME_ALL)
> > &&
> > -???????????????????active_only && !(sdata->flags &
> > IEEE80211_SDATA_IN_DRIVER))
> > +???????????????????(active_only && (local->in_reconfig || !(sdata-
> > >flags & IEEE80211_SDATA_IN_DRIVER))))
> > ????????????????????????continue;
> 
> Doesn't this effectivelly prevent you from iterating over interfaces
> completely during reconfig? As you bring up interfaces you might
> need/want to iterate over others to re-adjust your own state.

Agree, that doesn't really make sense.

> I'd argue there should be another flag, IEEE80211_SDATA_RESUMING,
> used with sdata->flags for resuming so that once it is re-added to
> the driver it can be cleared (and therefore properly iterated over).

That would make some sense, or perhaps the sdata_in_driver should be
cleared (and remembered elsewhere) at some point during the restart.

johannes


From johannes at sipsolutions.net  Mon Dec  5 06:46:01 2016
From: johannes at sipsolutions.net (Johannes Berg)
Date: Mon, 05 Dec 2016 15:46:01 +0100
Subject: [PATCH 1/4] cfg80211: Add support to enable or disable btcoex
In-Reply-To: <1478610932-21954-2-git-send-email-c_traja@qti.qualcomm.com>
References: <1478610932-21954-1-git-send-email-c_traja@qti.qualcomm.com>
 <1478610932-21954-2-git-send-email-c_traja@qti.qualcomm.com>
Message-ID: <1480949161.31788.23.camel@sipsolutions.net>

On Tue, 2016-11-08 at 18:45 +0530, c_traja at qti.qualcomm.com wrote:
> From: Tamizh chelvam <c_traja at qti.qualcomm.com>
> 
> This patch adds support to enable or disable btcoex by
> adding NL80211_ATTR_WIPHY_BTCOEX_ENABLE attribute in
> NL80211_CMD_SET_WIPHY command. By default BTCOEX disabled in driver.

I think overloading SET_WIPHY even more is a mistake - why not group
this with the new command you're introducing in the second patch?

Also, can have a flag attribute to enable/disable, or better even
disable when you're not setting any other parameters.

johannes


From johannes at sipsolutions.net  Mon Dec  5 06:49:13 2016
From: johannes at sipsolutions.net (Johannes Berg)
Date: Mon, 05 Dec 2016 15:49:13 +0100
Subject: [PATCH 2/4] cfg80211: Add new NL80211_CMD_SET_BTCOEX_PRIORITY
 to support BTCOEX
In-Reply-To: <1478610932-21954-3-git-send-email-c_traja@qti.qualcomm.com>
References: <1478610932-21954-1-git-send-email-c_traja@qti.qualcomm.com>
 <1478610932-21954-3-git-send-email-c_traja@qti.qualcomm.com>
Message-ID: <1480949353.31788.27.camel@sipsolutions.net>

On Tue, 2016-11-08 at 18:45 +0530, c_traja at qti.qualcomm.com wrote:
>?
> + * struct cfg80211_btcoex_priority - BTCOEX support frame type
> + *
> + * This structure defines the driver supporting frame types for
> BTCOEX
> + *
> + * @wlan_be_preferred: best effort frames preferred over bt traffic
> + * @wlan_bk_preferred: background frames preferred over bt traffic
> + * @wlan_vi_preferred: video frames preferred over bt traffic
> + * @wlan_vo_preferred: voice frames preferred over bt traffic
> + * @wlan_beacon_preferred: beacon preferred over bt traffic
> + * @wlan_mgmt_preferred: management frames preferred ovet bt traffic

typo: over

> ?
> ?/**
> + * wiphy_btcoex_support_flags
> + *	This enum has the driver supported frame types for BTCOEX.
> + * @WIPHY_WLAN_BE_PREFERRED - Supports Best Effort frame for BTCOEX
> + * @WIPHY_WLAN_BK_PREFERRED - supports Background frame for BTCOEX
> + * @WIPHY_WLAN_VI_PREFERRED - supports Video frame for BTCOEX
> + * @WIPHY_WLAN_VO_PREFERRED - supports Voice frame for BTCOEX
> + * @WIPHY_WLAN_BEACON_PREFERRED - supports Beacon frame for BTCOEX
> + * @WIPHY_WLAN_MGMT_PREFERRED - supports Management frames for
> BTCOEX.
> + */

That's not making much sense to me?

> +/**
> + * enum wiphy_btcoex_priority - BTCOEX priority level
> + *	This enum defines priority level for BTCOEX
> + * WIPHY_WLAN_PREFERRED_LOW - low priority frames over BT traffic
> + * WIPHY_WLAN_PREFERRED_HIGH - high priority frames over BT traffic
> + */
> +
> +enum wiphy_btcoex_priority {
> +	WIPHY_WLAN_PREFERRED_LOW = false,
> +	WIPHY_WLAN_PREFERRED_HIGH = true,
> +};

That false/true seems just strange.

> + * @btcoex_support_flags: This will have the driver supported
> + *	frame types for BTCOEX. This value filled by using
> + *	%enum wiphy_btcoex_support_flags while driver
> + *	initialization.

The whole "will have" isn't really clear.

> + * @NL80211_ATTR_SET_BTCOEX_PRIORITY: nested attribute for driver
> supporting
> + *	the BTCOEX. When used with
> %NL80211_CMD_SET_BTCOEX_PRIORITY it contains
> + *	attributes according &enum nl80211_btcoex_priority to
> indicate
> + *	which frame has high priority over BT.

There should be no "SET" in there.

> ?/**
> + * enum nl80211_btcoex_priority - BTCOEX parameter attributes
> + *	This strcuture has enum values for driver supported wlan
> + *	frame type for BTCOEX.
> + * @NL80211_WLAN_BE_PREFERRED - Best Effort frame
> + * @NL80211_WLAN_BK_PREFERRED - Background frame
> + * @NL80211_WLAN_VI_PREFERRED - Video frame
> + * @NL80211_WLAN_VO_PREFERRED - Voice frame
> + * @NL80211_WLAN_BEACON_PREFERRED - BEACON frame
> + * @NL80211_WLAN_MGMT_PREFERRED - MGMT frame
> + */
> +
> +enum nl80211_btcoex_priority {
> +	__NL80211_WLAN_PREFERRED_INVALID,
> +	NL80211_WLAN_BE_PREFERRED,
> +	NL80211_WLAN_BK_PREFERRED,
> +	NL80211_WLAN_VI_PREFERRED,
> +	NL80211_WLAN_VO_PREFERRED,
> +	NL80211_WLAN_BEACON_PREFERRED,
> +	NL80211_WLAN_MGMT_PREFERRED,
> +	__NL80211_WLAN_PREFERRED_LAST,
> +	NL80211_WLAN_PREFERRED_MAX =
> +			__NL80211_WLAN_PREFERRED_LAST - 1,
> +};

Wouldn't a bitmap be easier?

johannes


From johannes at sipsolutions.net  Mon Dec  5 07:00:54 2016
From: johannes at sipsolutions.net (Johannes Berg)
Date: Mon, 05 Dec 2016 16:00:54 +0100
Subject: [PATCH 1/2] mac80211: do not iterate active interfaces when in
 re-configure
In-Reply-To: <58458058.5020008@candelatech.com>
References: <1480645800-2148-1-git-send-email-greearb@candelatech.com>
 <CA+BoTQkEaC-ZSbeK=JB=q+ucF1PWcEQXkJEp6JYv4pfOf35cHg@mail.gmail.com>
 (sfid-20161205_092619_855272_0854B225)
 <1480945950.31788.4.camel@sipsolutions.net>
 <58458058.5020008@candelatech.com>
Message-ID: <1480950054.31788.36.camel@sipsolutions.net>

On Mon, 2016-12-05 at 06:57 -0800, Ben Greear wrote:

> I think clearing sdata-in-driver would fix the ath10k problem, at
> least, but I was afraid it would break something else in mac80211 or
> maybe in other thick firmware drivers.

It's pretty much an internal thing - not sure what it'd break. OTOH,
some drivers might actually assume that iterating finds them all, if
they never clear the data even across a restart?

> One way or another, we cannot be iterating over interfaces while
> the interfaces are at the same time being (re)added.

Well, we obviously *can* be, and we do in fact do that - it's just that
ath10k specifically has issues with the data it's putting there, no?

> Maybe mac80211 should explicitly remove all interfaces from the
> driver during crash recovery???

I don't think that'll work. Removing them would interact with the
firmware, which is dead, etc. That'd just cause trouble.

> And the behaviour needs to be clearly documented somewhere
> easy to find so that we can think about and program to the correct
> API behaviour.

We assume that the driver resets all its internal state - this whole
interface iteration is a corner case we hadn't considered, I suppose.

johannes


From greearb at candelatech.com  Mon Dec  5 07:06:35 2016
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 05 Dec 2016 07:06:35 -0800
Subject: [PATCH 1/2] mac80211: do not iterate active interfaces when in
 re-configure
In-Reply-To: <1480950054.31788.36.camel@sipsolutions.net>
References: <1480645800-2148-1-git-send-email-greearb@candelatech.com>	
 <CA+BoTQkEaC-ZSbeK=JB=q+ucF1PWcEQXkJEp6JYv4pfOf35cHg@mail.gmail.com>	
 (sfid-20161205_092619_855272_0854B225)
 <1480945950.31788.4.camel@sipsolutions.net>	
 <58458058.5020008@candelatech.com>
 <1480950054.31788.36.camel@sipsolutions.net>
Message-ID: <5845827B.2000000@candelatech.com>



On 12/05/2016 07:00 AM, Johannes Berg wrote:
> On Mon, 2016-12-05 at 06:57 -0800, Ben Greear wrote:
>
>> I think clearing sdata-in-driver would fix the ath10k problem, at
>> least, but I was afraid it would break something else in mac80211 or
>> maybe in other thick firmware drivers.
>
> It's pretty much an internal thing - not sure what it'd break. OTOH,
> some drivers might actually assume that iterating finds them all, if
> they never clear the data even across a restart?
>
>> One way or another, we cannot be iterating over interfaces while
>> the interfaces are at the same time being (re)added.
>
> Well, we obviously *can* be, and we do in fact do that - it's just that
> ath10k specifically has issues with the data it's putting there, no?

It causes races that appear to be very difficult to resolve in the
driver alone.  On normal bringup of an interface, the sdata-in-driver
flag is only set at the bottom of the add-interface.  In case of re-config,
the flag is already set, and never cleared, so behaviour is different
w/regard to the iterate.

>
>> Maybe mac80211 should explicitly remove all interfaces from the
>> driver during crash recovery?
>
> I don't think that'll work. Removing them would interact with the
> firmware, which is dead, etc. That'd just cause trouble.

That issue already causes trouble and is dealt with in ath10k, I think,
but clearing the flag in mac80211 would probably be enough to fix the
iterate logic.

>> And the behaviour needs to be clearly documented somewhere
>> easy to find so that we can think about and program to the correct
>> API behaviour.
>
> We assume that the driver resets all its internal state - this whole
> interface iteration is a corner case we hadn't considered, I suppose.

Yeah, tricky beastie.  I think the txq issue is also part of this since there
are references up in mac80211 and also down in ath10k.  Part of my hack
to clean up that crash might be resolved by mac80211 doing better cleanup
API when firmware crashes.

Thanks,
Ben

>
> johannes
>

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


From greearb at candelatech.com  Mon Dec  5 06:57:28 2016
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 05 Dec 2016 06:57:28 -0800
Subject: [PATCH 1/2] mac80211: do not iterate active interfaces when in
 re-configure
In-Reply-To: <1480945950.31788.4.camel@sipsolutions.net>
References: <1480645800-2148-1-git-send-email-greearb@candelatech.com>
 <CA+BoTQkEaC-ZSbeK=JB=q+ucF1PWcEQXkJEp6JYv4pfOf35cHg@mail.gmail.com>
 (sfid-20161205_092619_855272_0854B225)
 <1480945950.31788.4.camel@sipsolutions.net>
Message-ID: <58458058.5020008@candelatech.com>



On 12/05/2016 05:52 AM, Johannes Berg wrote:
> On Mon, 2016-12-05 at 09:13 +0100, Michal Kazior wrote:
>> On 2 December 2016 at 03:29,  <greearb at candelatech.com> wrote:
>>>
>>> From: Ben Greear <greearb at candelatech.com>
>>>
>>> This appears to fix a problem where ath10k firmware would crash,
>>> mac80211 would start re-adding interfaces to the driver, but the
>>> iterate-active-interfaces logic would then try to use the half-
>>> built
>>> interfaces.  With a bit of extra debug to catch the problem, the
>>> ath10k crash looks like this:
>>>
>>> ath10k_pci 0000:05:00.0: Initializing arvif: ffff8801ce97e320 on
>>> vif: ffff8801ce97e1d8
>>>
>>> [the print that happens after arvif->ar is assigned is not shown,
>>> so code did not make it that far before
>>>   the tx-beacon-nowait method was called]
>>>
>>> tx-beacon-nowait:  arvif: ffff8801ce97e320  ar:           (null)
>> [...]
>>>
>>>
>>> Signed-off-by: Ben Greear <greearb at candelatech.com>
>>> ---
>>>   net/mac80211/util.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
>>> index 863f2c1..abe1f64 100644
>>> --- a/net/mac80211/util.c
>>> +++ b/net/mac80211/util.c
>>> @@ -705,7 +705,7 @@ static void __iterate_interfaces(struct
>>> ieee80211_local *local,
>>>                          break;
>>>                  }
>>>                  if (!(iter_flags & IEEE80211_IFACE_ITER_RESUME_ALL)
>>> &&
>>> -                   active_only && !(sdata->flags &
>>> IEEE80211_SDATA_IN_DRIVER))
>>> +                   (active_only && (local->in_reconfig || !(sdata-
>>>> flags & IEEE80211_SDATA_IN_DRIVER))))
>>>                          continue;
>>
>> Doesn't this effectivelly prevent you from iterating over interfaces
>> completely during reconfig? As you bring up interfaces you might
>> need/want to iterate over others to re-adjust your own state.
>
> Agree, that doesn't really make sense.
>
>> I'd argue there should be another flag, IEEE80211_SDATA_RESUMING,
>> used with sdata->flags for resuming so that once it is re-added to
>> the driver it can be cleared (and therefore properly iterated over).
>
> That would make some sense, or perhaps the sdata_in_driver should be
> cleared (and remembered elsewhere) at some point during the restart.

I think clearing sdata-in-driver would fix the ath10k problem, at least,
but I was afraid it would break something else in mac80211 or maybe in
other thick firmware drivers.

One way or another, we cannot be iterating over interfaces while
the interfaces are at the same time being (re)added.

Maybe mac80211 should explicitly remove all interfaces from the driver
during crash recovery?  And the behaviour needs to be clearly documented somewhere
easy to find so that we can think about and program to the correct API
behaviour.

Thanks,
Bne


>
> johannes
>
> _______________________________________________
> 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  Mon Dec  5 09:23:56 2016
From: adrian at freebsd.org (Adrian Chadd)
Date: Mon, 5 Dec 2016 09:23:56 -0800
Subject: [PATCH 1/2] mac80211: do not iterate active interfaces when in
 re-configure
In-Reply-To: <5845827B.2000000@candelatech.com>
References: <1480645800-2148-1-git-send-email-greearb@candelatech.com>
 <CA+BoTQkEaC-ZSbeK=JB=q+ucF1PWcEQXkJEp6JYv4pfOf35cHg@mail.gmail.com>
 <1480945950.31788.4.camel@sipsolutions.net> <58458058.5020008@candelatech.com>
 <1480950054.31788.36.camel@sipsolutions.net>
 <5845827B.2000000@candelatech.com>
Message-ID: <CAJ-VmokNztn7Rj4jTxYo2QR0vL0-t6h7M5qLKUSMn2-VtAN2bA@mail.gmail.com>

fwiw, I'm facing the same kinds of cleanup problems with my port of
(oct 2015) ath10k to freebsd.

The oct 2015 ath10k tree doesn't have the firmware per-txq/tid/peer
feedback stuff in it, so this hasn't yet bitten me, but there rest of
the races have - mostly surrounding handling pending TX frames when a
VAP is deleted (vdev/interface in ath10k/mac80211 language) and if any
TX frames were stuck. Stuck TX frames happens more often than I'd like
because of how earlier firmware required peer entries to first appear
in the hardware.

Maybe we need some kind of lifecycle checkpoint for things like peer
addition/removal (for the txq issues ben had before) and the ability
to ask the firmware to stop/flush HTT TX and re-start it. That way we
can cleanly add/remove interfaces at any point without worrying about
any dangling frames in the transmit queue waiting for completion.



-adrian


From greearb at candelatech.com  Mon Dec  5 10:28:39 2016
From: greearb at candelatech.com (greearb at candelatech.com)
Date: Mon,  5 Dec 2016 10:28:39 -0800
Subject: [PATCH] ath10k:  free host-mem with DMA_BIRECTIONAL flag.
Message-ID: <1480962519-13027-1-git-send-email-greearb@candelatech.com>

From: Ben Greear <greearb at candelatech.com>

Hopefully this fixes the problem reported by Kalle:

Noticed this in my log, but I don't have time to investigate this in
detail right now:

[  413.795346] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  414.158755] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  477.439659] ath10k_pci 0000:02:00.0: could not get mac80211 beacon
[  481.666630] ------------[ cut here ]------------
[  481.666669] WARNING: CPU: 0 PID: 1978 at lib/dma-debug.c:1155 check_unmap+0x320/0x8e0
[  481.666688] ath10k_pci 0000:02:00.0: DMA-API: device driver frees DMA memory with different direction [device address=0x000000002d130000] [size=63800 bytes] [mapped with DMA_BIDIRECTIONAL] [unmapped with DMA_TO_DEVICE]
[  481.666703] Modules linked in: ctr ccm ath10k_pci(E-) ath10k_core(E) ath(E) mac80211(E) cfg80211(E) snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi arc4 snd_rawmidi snd_seq_midi_event snd_seq btusb btintel snd_seq_device joydev coret
[  481.671468] CPU: 0 PID: 1978 Comm: rmmod Tainted: G            E   4.9.0-rc7-wt+ #54
[  481.671478] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD Ver. F.04 01/27/2010
[  481.671489]  ef49dcec c842ee92 c8b5830e ef49dd34 ef49dd20 c80850f5 c8b5a13c ef49dd50
[  481.671560]  000007ba c8b5830e 00000483 c8461830 c8461830 00000483 ef49ddcc f34e64b8
[  481.671641]  c8b58360 ef49dd3c c80851bb 00000009 00000000 ef49dd34 c8b5a13c ef49dd50
[  481.671716] Call Trace:
[  481.671731]  [<c842ee92>] dump_stack+0x76/0xb4
[  481.671745]  [<c80850f5>] __warn+0xe5/0x100
[  481.671757]  [<c8461830>] ? check_unmap+0x320/0x8e0
[  481.671769]  [<c8461830>] ? check_unmap+0x320/0x8e0
[  481.671780]  [<c80851bb>] warn_slowpath_fmt+0x3b/0x40
[  481.671791]  [<c8461830>] check_unmap+0x320/0x8e0
[  481.671804]  [<c8462054>] debug_dma_unmap_page+0x84/0xa0
[  481.671835]  [<f937cd7a>] ath10k_wmi_free_host_mem+0x9a/0xe0 [ath10k_core]
[  481.671861]  [<f9363400>] ath10k_core_destroy+0x50/0x60 [ath10k_core]
[  481.671875]  [<f8e13969>] ath10k_pci_remove+0x79/0xa0 [ath10k_pci]
[  481.671889]  [<c848d8d8>] pci_device_remove+0x38/0xb0
[  481.671901]  [<c859fe4b>] __device_release_driver+0x7b/0x110
[  481.671913]  [<c85a00e7>] driver_detach+0x97/0xa0
[  481.671923]  [<c859ef8b>] bus_remove_driver+0x4b/0xb0
[  481.671934]  [<c85a0cda>] driver_unregister+0x2a/0x60
[  481.671949]  [<c848c888>] pci_unregister_driver+0x18/0x70
[  481.671965]  [<f8e14dae>] ath10k_pci_exit+0xd/0x25f [ath10k_pci]
[  481.671979]  [<c812bb84>] SyS_delete_module+0xf4/0x180
[  481.671995]  [<c81f801b>] ? __might_fault+0x8b/0xa0
[  481.672009]  [<c80037d0>] do_fast_syscall_32+0xa0/0x1e0
[  481.672025]  [<c88d4c88>] sysenter_past_esp+0x45/0x74
[  481.672037] ---[ end trace 3fd23759e17e1622 ]---
[  481.672049] Mapped at:
[  481.672060]  [  481.672072] [<c846062c>] debug_dma_map_page.part.25+0x1c/0xf0
[  481.672083]  [  481.672095] [<c8460799>] debug_dma_map_page+0x99/0xc0
[  481.672106]  [  481.672132] [<f93745ec>] ath10k_wmi_alloc_chunk+0x12c/0x1f0 [ath10k_core]
[  481.672142]  [  481.672168] [<f937d0c4>] ath10k_wmi_event_service_ready_work+0x304/0x540 [ath10k_core]
[  481.672178]  [  481.672190] [<c80a3643>] process_one_work+0x1c3/0x670
[  482.137134] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[  482.313144] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:02:00.0.bin failed with error -2
[  482.313274] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/cal-pci-0000:02:00.0.bin failed with error -2
[  482.313768] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
[  482.313777] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 0 testmode 1
[  482.313974] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
[  482.369858] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
[  482.370011] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
[  483.596770] 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
[  483.701686] ath: EEPROM regdomain: 0x0
[  483.701706] ath: EEPROM indicates default country code should be used
[  483.701713] ath: doing EEPROM country->regdmn map search
[  483.701721] ath: country maps to regdmn code: 0x3a
[  483.701730] ath: Country alpha2 being used: US
[  483.701737] ath: Regpair used: 0x3a

Reported-by: Kalle Valo <kvalo at qca.qualcomm.com>
Signed-off-by: Ben Greear <greearb at candelatech.com>
---
 drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index c748923..0be76e4 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -8473,7 +8473,7 @@ void ath10k_wmi_free_host_mem(struct ath10k *ar)
 		dma_unmap_single(ar->dev,
 				 ar->wmi.mem_chunks[i].paddr,
 				 ar->wmi.mem_chunks[i].len,
-				 DMA_TO_DEVICE);
+				 DMA_BIDIRECTIONAL);
 		kfree(ar->wmi.mem_chunks[i].vaddr);
 	}
 
-- 
2.4.11



From bmorgan at cococorp.com  Mon Dec  5 10:34:13 2016
From: bmorgan at cococorp.com (Benjamin Morgan)
Date: Mon, 5 Dec 2016 10:34:13 -0800
Subject: ath10k firmware crashes in mesh mode on QCA9880
In-Reply-To: <20161203124600.GC31861@atheros-ThinkPad-T61>
References: <583DD564.8040704@cococorp.com>
 <20161201070908.GB11953@atheros-ThinkPad-T61> <58421FA2.2020004@cococorp.com>
 <20161203124358.GB31861@atheros-ThinkPad-T61>
 <20161203124600.GC31861@atheros-ThinkPad-T61>
Message-ID: <5845B325.6060002@cococorp.com>

Applied the patch and tried with 10.2.4.70.54 firmware and it still crashes:

[  142.438377] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 
a5499582-e220-46d2-9359-0b44219f69ea)
[  142.447512] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c 
chip_id 0x043202ff sub 0000:0000
[  142.456879] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 
tracing 0 dfs 1 testmode 1
[  142.469916] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api 5 
features no-p2p,raw-mode,mfp crc32 9d340dd9
[  142.480295] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A 
crc32 bebc7c08
[  142.487717] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 
cal file max-sta 128 raw 0 hwcrypto 1
[  142.499361] ath10k_pci 0000:01:00.0: firmware register dump:
[  142.505124] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 
0x009A4577 0x00955B31
[  142.513157] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130 
0x00000002 0x00439E98
[  142.521203] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074 
0x00407120 0x004436CC
[  142.529246] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000 
0x009A3518 0x009A3526
[  142.537285] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x009A3EA6 
0x00000000 0x00000000
[  142.545324] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4 
0x0040AC60 0x0040AC09
[  142.553356] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24 
0x00400000 0xC09A4577
[  142.561400] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84 
0x0044110C 0x00442074
[  142.569444] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4 
0x0044110C 0x00407120
[  142.577483] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4 
0x0040AC14 0x00001580
[  142.585522] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04 
0x009C643C 0x004436CC
[  142.593554] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64 
0x004208FC 0x00439E4C
[  142.601600] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84 
0x004208FC 0x0042638C
[  142.609642] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4 
0x00424FE8 0x00000002
[  142.617681] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14 
0x00000004 0x004039D0
[  142.727220] ieee80211 phy0: Hardware restart was requested
[  142.732850] ath10k_pci 0000:01:00.0: failed to synchronize monitor 
vdev 1 stop: -143
[  142.740739] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143


~Benjamin

On 12/03/2016 04:46 AM, Mohammed Shafi Shajakhan wrote:
> https://patchwork.kernel.org/patch/9437519/
> (sorry missed this in the previous thread)
>
> On Sat, Dec 03, 2016 at 06:13:58PM +0530, Mohammed Shafi Shajakhan wrote:
>> Hi Benjamin,
>>
>> On Fri, Dec 02, 2016 at 05:28:02PM -0800, Benjamin Morgan wrote:
>>> Just tried 10.2.4.70.58 firmware that you linked to and it still crashes:
>>>
>>> [  131.568989] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
>>> 1838347e-9380-4a26-ac9d-2963ee95968b)
>>> [  131.578124] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
>>> 0x4100016c chip_id 0x043202ff sub 0000:0000
>>> [  131.587491] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
>>> tracing 0 dfs 1 testmode 1
>>> [  131.600521] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.58
>>> api 5 features no-p2p,raw-mode,mfp crc32 e1af076f
>>> [  131.610899] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
>>> crc32 bebc7c08
>>> [  131.618325] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op
>>> 2 cal file max-sta 128 raw 0 hwcrypto 1
>>> [  131.629965] ath10k_pci 0000:01:00.0: firmware register dump:
>>> [  131.635728] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
>>> 0x009A45AF 0x00955B31
>>> [  131.643761] ath10k_pci 0000:01:00.0: [04]: 0x009A45AF 0x00060130
>>> 0x00000002 0x00439E98
>>> [  131.651806] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
>>> 0x00407120 0x004436CC
>>> [  131.659852] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
>>> 0x009A3550 0x009A355E
>>> [  131.667892] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x009A31D6
>>> 0x00000000 0x00000000
>>> [  131.675936] ath10k_pci 0000:01:00.0: [20]: 0x409A45AF 0x0040AAC4
>>> 0x0040AC60 0x0040AC09
>>> [  131.683968] ath10k_pci 0000:01:00.0: [24]: 0x809A44F2 0x0040AB24
>>> 0x00400000 0xC09A45AF
>>> [  131.692013] ath10k_pci 0000:01:00.0: [28]: 0x809A3A16 0x0040AB84
>>> 0x0044110C 0x00442074
>>> [  131.700056] ath10k_pci 0000:01:00.0: [32]: 0x809A601A 0x0040ABB4
>>> 0x0044110C 0x00407120
>>> [  131.708100] ath10k_pci 0000:01:00.0: [36]: 0x809A2EA4 0x0040ABF4
>>> 0x0040AC14 0x00001580
>>> [  131.716143] ath10k_pci 0000:01:00.0: [40]: 0x80990F63 0x0040AD04
>>> 0x009C6458 0x004436CC
>>> [  131.724175] ath10k_pci 0000:01:00.0: [44]: 0x80998520 0x0040AD64
>>> 0x004208FC 0x00439E4C
>>> [  131.732220] ath10k_pci 0000:01:00.0: [48]: 0x8099AEA5 0x0040AD84
>>> 0x004208FC 0x00425874
>>> [  131.740263] ath10k_pci 0000:01:00.0: [52]: 0x809BFC39 0x0040AEE4
>>> 0x00424FE8 0x00000002
>>> [  131.748306] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
>>> 0x00000004 0x004039D0
>>> [  131.857076] ieee80211 phy0: Hardware restart was requested
>>> [  131.862705] ath10k_pci 0000:01:00.0: failed to synchronize
>>> monitor vdev 1 stop: -143
>>> [  131.870594] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
>> [shafi] request to try with the latest backports and ath.git
>> Also worth trying this fix in ath10k (once the next firmware version)
>> is available. I will keep you posted. thank you !
>>
>>> ~Benjamin
>>>
>>> On 11/30/2016 11:09 PM, Mohammed Shafi Shajakhan wrote:
>>>> Hi,
>>>>
>>>> On Tue, Nov 29, 2016 at 11:22:12AM -0800, Benjamin Morgan wrote:
>>>>> When we try to transmit traffic (ping) between two meshed ath10k
>>>>> devices running latest lede we keep experiencing ath10k firmware
>>>>> crashes. This seems to only happen when running in 802.11n/ac mode
>>>>> but not in 802.11a/g mode. Also, from the station dumps it appears
>>>>> that management traffic is flowing between the devices, however when
>>>>> we try to send unicast data traffic the firmware crashes
>>>>> immediately.
>>>> [shafi] Did you get a chance to try with the below firmware as well
>>>> https://github.com/kvalo/ath10k-firmware/blob/master/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.58
>>>>
>>>>> Platform: Archer C7 AC1750 v2
>>>>> Software Image: LEDE (HEAD, r2299) Commit: https://github.com/lede-project/source/commit/d596c21ebd5a3e6ce933eff3e51989031e4b1d58
>>>>>
>>>>> Crypto: wpa_supplicant
>>>>> wpa_supplicant-wlan0.conf
>>>>> network={
>>>>> ssid="bmorgan_lede_mesh"
>>>>> key_mgmt=SAE
>>>>> mode=5
>>>>> frequency=5180
>>>>> psk="meshpassword"
>>>>> }
>>>>>
>>>>> Backports Verstion:
>>>>> [    9.818007] Loading modules backported from Linux version
>>>>> wt-2016-10-03-1-g6fcb1a6
>>>>> [    9.825736] Backport generated by backports.git
>>>>> backports-20160324-9-g0e38f5c
>>>>>
>>>>> ??Ath10k Initialization on Station A (dmesg)
>>>>> [    9.896715] PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
>>>>> [    9.902622] ath10k_pci 0000:01:00.0: pci irq legacy oper_irq_mode
>>>>> 1 irq_mode 0 reset_mode 0
>>>>> [   10.123734] ath10k_pci 0000:01:00.0: Direct firmware load for
>>>>> ath10k/pre-cal-pci-0000:01:00.0.bin failed with error -2
>>>>> [   10.134620] ath10k_pci 0000:01:00.0: Falling back to user helper
>>>>> [   10.287680] firmware ath10k!pre-cal-pci-0000:01:00.0.bin:
>>>>> firmware_loading_store: map pages failed
>>>>> [   10.622789] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
>>>>> 0x4100016c chip_id 0x043202ff sub 0000:0000
>>>>> [   10.632184] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
>>>>> tracing 0 dfs 1 testmode 1
>>>>> [   10.645231] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54
>>>>> api 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
>>>>> [   10.655660] ath10k_pci 0000:01:00.0: Direct firmware load for
>>>>> ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
>>>>> [   10.666264] ath10k_pci 0000:01:00.0: Falling back to user helper
>>>>> [   10.747925] firmware ath10k!QCA988X!hw2.0!board-2.bin:
>>>>> firmware_loading_store: map pages failed
>>>>> [   11.011123] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
>>>>> crc32 bebc7c08
>>>>> [   12.155224] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op
>>>>> 2 cal file max-sta 128 raw 0 hwcrypto 1
>>>>>
>>>>> Station A (wlan0):
>>>>> 18:A6:F7:23:6E:66
>>>>> 10.230.5.41
>>>>>
>>>>> Station B (wlan0):
>>>>> 18:a6:f7:26:0f:21
>>>>> 10.230.5.42
>>>>>
>>>>> Station Dump on Station A before ping:
>>>>> Station 18:a6:f7:26:0f:21 (on wlan0)
>>>>> inactive time:340 ms
>>>>> rx bytes:2472
>>>>> rx packets:28
>>>>> tx bytes:1204
>>>>> tx packets:9
>>>>> tx retries:0
>>>>> tx failed:0
>>>>> rx drop misc:1
>>>>> signal: -14 dBm
>>>>> signal avg:-14 dBm
>>>>> Toffset:18142530 us
>>>>> tx bitrate:6.0 MBit/s
>>>>> rx bitrate:6.0 MBit/s
>>>>> rx duration:1524 us
>>>>> mesh llid:0
>>>>> mesh plid:0
>>>>> mesh plink:ESTAB
>>>>> mesh local PS mode:ACTIVE
>>>>> mesh peer PS mode:UNKNOWN
>>>>> mesh non-peer PS mode:ACTIVE
>>>>> authorized:yes
>>>>> authenticated:yes
>>>>> associated:yes
>>>>> preamble:long
>>>>> WMM/WME:yes
>>>>> MFP:yes
>>>>> TDLS peer:no
>>>>> DTIM period:2
>>>>> beacon interval:1000
>>>>> connected time:10 seconds
>>>>>
>>>>> ?Crash Log on Station B (10.230.5.42)
>>>>> [245.483888] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
>>>>> 2bab5ee9-08ff-4a17-95b1-636d212acebc)
>>>>> [245.493020] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
>>>>> 0x4100016c chip_id 0x043202ff sub 0000:0000
>>>>> [245.502384] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
>>>>> tracing 0 dfs 1 testmode 1
>>>>> [245.515436] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api
>>>>> 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
>>>>> [245.525812] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
>>>>> crc32 bebc7c08
>>>>> [245.533232] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
>>>>> cal file max-sta 128 raw 0 hwcrypto 1
>>>>> [245.544876] ath10k_pci 0000:01:00.0: firmware register dump:
>>>>> [245.550633] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
>>>>> 0x009A4577 0x00955B31
>>>>> [245.558676] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
>>>>> 0x00000002 0x00439E98
>>>>> [245.566715] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
>>>>> 0x00407120 0x004436CC
>>>>> [245.574749] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
>>>>> 0x009A3518 0x009A3526
>>>>> [245.582793] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
>>>>> 0x00000000 0x00000000
>>>>> [245.590836] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
>>>>> 0x0040AC60 0x0040AC09
>>>>> [245.598882] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
>>>>> 0x00400000 0xC09A4577
>>>>> [245.606923] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
>>>>> 0x0044110C 0x00442074
>>>>> [245.614955] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
>>>>> 0x0044110C 0x00407120
>>>>> [245.623000] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
>>>>> 0x0040AC14 0x00001580
>>>>> [245.631043] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
>>>>> 0x009C643C 0x004436CC
>>>>> [245.639086] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
>>>>> 0x004208FC 0x00439E4C
>>>>> [245.647129] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
>>>>> 0x004208FC 0x00425404
>>>>> [245.655170] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
>>>>> 0x00424FE8 0x00000002
>>>>> [245.663198] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
>>>>> 0x00000004 0x004039D0
>>>>> [245.767023] ieee80211 phy0: Hardware restart was requested
>>>>> [245.772655] ath10k_pci 0000:01:00.0: failed to synchronize monitor
>>>>> vdev 1 stop: -143
>>>>> [245.780542] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
>>>>> ?
>>>>> With wpa_supplicant turned off:
>>>>>
>>>>> Station Dump on Station A before ping:
>>>>> Station 18:a6:f7:26:0f:21 (on wlan0)
>>>>> inactive time:60 ms
>>>>> rx bytes:3874
>>>>> rx packets:67
>>>>> tx bytes:707
>>>>> tx packets:7
>>>>> tx retries:0
>>>>> tx failed:1
>>>>> rx drop misc:3
>>>>> signal: -14 dBm
>>>>> signal avg:-14 dBm
>>>>> Toffset:18446744073684250999 us
>>>>> tx bitrate:6.0 MBit/s
>>>>> rx bitrate:6.0 MBit/s
>>>>> rx duration:1312 us
>>>>> mesh llid:24953
>>>>> mesh plid:59412
>>>>> mesh plink:ESTAB
>>>>> mesh local PS mode:ACTIVE
>>>>> mesh peer PS mode:UNKNOWN
>>>>> mesh non-peer PS mode:ACTIVE
>>>>> authorized:yes
>>>>> authenticated:yes
>>>>> associated:yes
>>>>> preamble:long
>>>>> WMM/WME:yes
>>>>> MFP:no
>>>>> TDLS peer:no
>>>>> DTIM period:2
>>>>> beacon interval:1000
>>>>> short slot time:yes
>>>>> connected time:33 seconds
>>>>>
>>>>> Firmware crash on Station A (10.230.5.41)
>>>>> [ 1040.984599] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
>>>>> 42d4f6dc-0e89-4505-aefb-58cbb70d0dce)
>>>>> [ 1040.993732] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
>>>>> 0x4100016c chip_id 0x043202ff sub 0000:0000
>>>>> [ 1041.003100] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
>>>>> tracing 0 dfs 1 testmode 1
>>>>> [ 1041.016144] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54
>>>>> api 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
>>>>> [ 1041.026523] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
>>>>> crc32 bebc7c08
>>>>> [ 1041.033940] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op
>>>>> 2 cal file max-sta 128 raw 0 hwcrypto 1
>>>>> [ 1041.045593] ath10k_pci 0000:01:00.0: firmware register dump:
>>>>> [ 1041.051336] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
>>>>> 0x009A4577 0x00955B31
>>>>> [ 1041.059383] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
>>>>> 0x00000001 0x00435354
>>>>> [ 1041.067424] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
>>>>> 0x00407120 0x004436CC
>>>>> [ 1041.075463] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
>>>>> 0x009A43A0 0x009A43DE
>>>>> [ 1041.083490] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
>>>>> 0x00000000 0x00000000
>>>>> [ 1041.091535] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
>>>>> 0x0040AC60 0x0040AC09
>>>>> [ 1041.099579] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
>>>>> 0x00955A00 0xC09A4577
>>>>> [ 1041.107622] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
>>>>> 0x0044110C 0x00442074
>>>>> [ 1041.115661] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
>>>>> 0x0044110C 0x00407120
>>>>> [ 1041.123689] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
>>>>> 0x0040AC10 0x00001580
>>>>> [ 1041.131733] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
>>>>> 0x009C643C 0x004436CC
>>>>> [ 1041.139777] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
>>>>> 0x004208FC 0x00439E4C
>>>>> [ 1041.147820] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
>>>>> 0x004208FC 0x00425758
>>>>> [ 1041.155860] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
>>>>> 0x00424FE8 0x00000002
>>>>> [ 1041.163888] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
>>>>> 0x00000004 0x004039D0
>>>>> [ 1041.267025] ieee80211 phy0: Hardware restart was requested
>>>>> [ 1041.272656] ath10k_pci 0000:01:00.0: failed to synchronize
>>>>> monitor vdev 1 stop: -143
>>>>> [ 1041.280545] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
>>>>>
>>>>> ?
>>>>> Thanks in advance for your time and help,
>>>>>
>>>>> ~Benjamin
>>>>>



From greearb at candelatech.com  Mon Dec  5 10:19:08 2016
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 5 Dec 2016 10:19:08 -0800
Subject: [PATCH 1/3] ath10k: Ensure there are no stale ar->txqs entries.
In-Reply-To: <CA+BoTQnuLbVzuEVvf9+wOGhj7i3DV2LaMqGBfGhQHEgOSXei4g@mail.gmail.com>
References: <1471569995-10028-1-git-send-email-greearb@candelatech.com>
 <CA+BoTQn0d1bEB662r-Yivmdk_21LhjCQjJP_GoPaj-WT2wA=1g@mail.gmail.com>
 <57B70AED.2010200@candelatech.com>
 <ba1cc818-6194-11d6-7cc3-1db28036a519@candelatech.com>
 <ef7e16a6-9353-0f63-ac70-fc8e234d6c25@candelatech.com>
 <CA+BoTQnuLbVzuEVvf9+wOGhj7i3DV2LaMqGBfGhQHEgOSXei4g@mail.gmail.com>
Message-ID: <4c1d2822-05cd-c0cb-7c57-a3f6c7ced709@candelatech.com>

On 12/05/2016 12:50 AM, Michal Kazior wrote:
> On 2 December 2016 at 01:24, Ben Greear <greearb at candelatech.com> wrote:
>> On 12/01/2016 02:52 PM, Ben Greear wrote:
>>>
>>> On 08/19/2016 06:34 AM, Ben Greear wrote:
>>>>
>>>>
>>>>
>>>> On 08/18/2016 11:59 PM, Michal Kazior wrote:
>>>>>
>>>>> On 19 August 2016 at 03:26,  <greearb at candelatech.com> wrote:
>>>>>>
>>>>>> From: Ben Greear <greearb at candelatech.com>
>>>>>>
>>>>>> I was seeing kernel crashes due to accessing freed memory
>>>>>> while debugging a 9984 firmware that was crashing often.
>>>>>>
>>>>>> This patch fixes the crashes.  I am not certain if there
>>>>>> is a better way or not.
>>
>>
>> Michal, thanks for the help on IRC.  I added this logic:
>>
>> static void ieee80211_drv_tx(struct ieee80211_local *local,
>>                              struct ieee80211_vif *vif,
>>                              struct ieee80211_sta *pubsta,
>>                              struct sk_buff *skb)
>> {
>>         struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
>>         struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
>>         struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
>>         struct ieee80211_tx_control control = {
>>                 .sta = pubsta,
>>         };
>>         struct ieee80211_txq *txq = NULL;
>>         struct txq_info *txqi;
>>         u8 ac;
>>
>>         if ((info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM) ||
>>             (info->control.flags & IEEE80211_TX_CTRL_PS_RESPONSE))
>>                 goto tx_normal;
>>
>>         if (!ieee80211_is_data(hdr->frame_control))
>>                 goto tx_normal;
>>
>>         if (unlikely(!ieee80211_sdata_running(sdata))) {
>>                 WARN_ON_ONCE(1);
>>                 goto delete_and_return;
>>         }
>>
>> ...
>>
>>         if (atomic_read(&sdata->txqs_len[ac]) >=
>>             (local->hw.txq_ac_max_pending * 2)) {
>>                 /* Must be that something is not paying attention to
>>                  * max-pending, like pktgen, so just drop this frame.
>>                  */
>> delete_and_return:
>>                 ieee80211_free_txskb(&local->hw, skb);
>>                 return;
>>         }
>>
>>
>> But, I still see the txq entries on the ar->txqs list in the
>> ath10k_mac_txq_init
>> after firmware crash in my test case.  Is this the test you were suggesting?
>
> Yes.
>
> Now that I think about it mac80211 doesn't call anything in driver
> during hw_restart that would unref txqs. This means you'll have them
> still linked when add_interface/sta_state is called, no?
>
> This means that either:
>  (a) txq (re-)init should be smarter in ath10k
>  (b) txqs should be purged during hw_restart in ath10k

I posted a patch that does (a) last Friday:

"ath10k:  work-around for stale txq in ar->txqs"

I realized it will not apply upstream because it is also patching the previous
work-around I had in the patch that originated this email thread.

With these patches and the iterate hack to mac80211, then I no longer
see crashes in my test case that previously crashed very readily.

Thanks,
Ben


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



From arnagara at qti.qualcomm.com  Mon Dec  5 11:24:08 2016
From: arnagara at qti.qualcomm.com (Nagarajan, Ashok Raj)
Date: Mon, 5 Dec 2016 19:24:08 +0000
Subject: ath10k firmware crashes in mesh mode on QCA9880
In-Reply-To: <5845B325.6060002@cococorp.com>
References: <583DD564.8040704@cococorp.com>
 <20161201070908.GB11953@atheros-ThinkPad-T61> <58421FA2.2020004@cococorp.com>
 <20161203124358.GB31861@atheros-ThinkPad-T61>
 <20161203124600.GC31861@atheros-ThinkPad-T61> <5845B325.6060002@cococorp.com>
Message-ID: <d8eb0ba5828d43dd83030247ba443b88@aphydexm01f.ap.qualcomm.com>

>> Applied the patch and tried with 10.2.4.70.54 firmware and it still crashes:

>> [  142.438377] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 
>> a5499582-e220-46d2-9359-0b44219f69ea)
>> [  142.447512] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c 
>> chip_id 0x043202ff sub 0000:0000
>> [  142.456879] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 
>> tracing 0 dfs 1 testmode 1
>> [  142.469916] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api 5 
features no-p2p,raw-mode,mfp crc32 9d340dd9
>> [  142.480295] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A 
>> crc32 bebc7c08
>> [  142.487717] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 
>> cal file max-sta 128 raw 0 hwcrypto 1
>> [  142.499361] ath10k_pci 0000:01:00.0: firmware register dump:
>> [  142.505124] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 
0x009A4577 0x00955B31

Benjamin, Thanks for the logs.
Quick questions to further debug the issue here,

1. Is this issue seen every time you start sending data traffic?
2. Issue seen with older firmwares? (FYR, http://linuxwireless.org/en/users/Drivers/ath10k/firmware/ )
3. Could you please share the dmesg from your device after enabling MAC and WMI logs in ath10k driver
	To enable debug logs please see http://linuxwireless.org/en/users/Drivers/ath10k/debug/	
4. Do you know what is the Number of Spatial Streams seen in mesh beacons and in mesh data packet?

Thanks,
Ashok

From chunkeey at googlemail.com  Mon Dec  5 13:52:46 2016
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Mon,  5 Dec 2016 22:52:46 +0100
Subject: [PATCH 2/2] ath10k: fix potential memory leak in
 ath10k_wmi_tlv_op_pull_fw_stats()
In-Reply-To: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
References: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
Message-ID: <e0909741dfae742197d5f5d60709d225cc179b42.1480974623.git.chunkeey@googlemail.com>

ath10k_wmi_tlv_op_pull_fw_stats() uses tb = ath10k_wmi_tlv_parse_alloc(...)
function, which allocates memory. If any of the three error-paths are
taken, this tb needs to be freed.

Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>
---
 drivers/net/wireless/ath/ath10k/wmi-tlv.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index f304f6632c4f..1f6bb9e8bb01 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -1105,8 +1105,10 @@ static int ath10k_wmi_tlv_op_pull_fw_stats(struct ath10k *ar,
 		struct ath10k_fw_stats_pdev *dst;
 
 		src = data;
-		if (data_len < sizeof(*src))
+		if (data_len < sizeof(*src)) {
+			kfree(tb);
 			return -EPROTO;
+		}
 
 		data += sizeof(*src);
 		data_len -= sizeof(*src);
@@ -1126,8 +1128,10 @@ static int ath10k_wmi_tlv_op_pull_fw_stats(struct ath10k *ar,
 		struct ath10k_fw_stats_vdev *dst;
 
 		src = data;
-		if (data_len < sizeof(*src))
+		if (data_len < sizeof(*src)) {
+			kfree(tb);
 			return -EPROTO;
+		}
 
 		data += sizeof(*src);
 		data_len -= sizeof(*src);
@@ -1145,8 +1149,10 @@ static int ath10k_wmi_tlv_op_pull_fw_stats(struct ath10k *ar,
 		struct ath10k_fw_stats_peer *dst;
 
 		src = data;
-		if (data_len < sizeof(*src))
+		if (data_len < sizeof(*src)) {
+			kfree(tb);
 			return -EPROTO;
+		}
 
 		data += sizeof(*src);
 		data_len -= sizeof(*src);
-- 
2.11.0



From chunkeey at googlemail.com  Mon Dec  5 13:52:45 2016
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Mon,  5 Dec 2016 22:52:45 +0100
Subject: [PATCH 1/2] ath10k: add accounting for the extended peer statistics
Message-ID: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>

The 10.4 firmware adds extended peer information to the
firmware's statistics payload. This additional info is
stored as a separate data field and the elements are
stored in their own "peers_extd" list.

These elements can pile up in the same way as the peer
information elements. This is because the
ath10k_wmi_10_4_op_pull_fw_stats() function tries to
pull the same amount (num_peer_stats) for every statistic
data unit.

Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>
---
 drivers/net/wireless/ath/ath10k/debug.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 82a4c67f3672..4acd9eb65910 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -399,6 +399,7 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
 			 * prevent firmware from DoS-ing the host.
 			 */
 			ath10k_fw_stats_peers_free(&ar->debug.fw_stats.peers);
+			ath10k_fw_extd_stats_peers_free(&ar->debug.fw_stats.peers_extd);
 			ath10k_warn(ar, "dropping fw peer stats\n");
 			goto free;
 		}
@@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
 			goto free;
 		}
 
+		if (!list_empty(&stats.peers))
+			list_splice_tail_init(&stats.peers_extd,
+					      &ar->debug.fw_stats.peers_extd);
+
 		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);
-- 
2.11.0



From jp.tosoni at acksys.fr  Tue Dec  6 09:02:52 2016
From: jp.tosoni at acksys.fr (Jean-Pierre Tosoni)
Date: Tue, 6 Dec 2016 18:02:52 +0100
Subject: ath10k firmware sends probes on DFS channels without radar detection 
Message-ID: <004a01d24fe2$94da8dc0$be8fa940$@acksys.fr>

This follows on the previous discussion
	"Client station sends probes on DFS channels"

Problem:
The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
wpa_supplicant do not comply with the norm ETSI/EN 301-893
section 4.7; because they can send probes for 600s when no
AP is around.

Analysis:
The problem seems to lie in the firmware, which regards the presence
of *any* beacon as a proof that the channel is radar-clean for 600s.

This is a wrong hypothesis, since a rogue AP sending fraudulent
beacons should not induce a scrupulous STA in sending illegal probes.

Moreover, the norm (table D.1) sets a time limit of 10s to
shutdown when no AP positively allows the STA to transmit on
the DFS channel.

Status:
- there is no known plan at QCA to fix the issue.
- ath10k firmware is not publicly available for fixes.
- there is no obvious fix working in ath10k.
- the issue does not show up with other mac80211 devices like ath9k.
- wpa_supplicant considers this is a kernel issue [2]

Jean-Pierre Tosoni



> -----Message d'origine-----
> De?: ath10k [mailto:ath10k-bounces at lists.infradead.org] De la part de
> Jean-Pierre Tosoni
> Envoy??: mercredi 30 novembre 2016 19:04
> ??: ath10k at lists.infradead.org
> Objet?: Client station sends probes on DFS channels
> 
> Hello list,
> 
> There is a case where I can see probes on a DFS channel, from a non-
> associated station using ath10k. (note that the problem does not arise
> when using ath9k).
> 
> *The setup*
> 
> I am using Openwrt, wpa_supplicant and compat-wireless 2016-10-08,
> Card firmware is	ath10k_pci: qca988x hw2.0 (0x4100016c, 0x043202ff)
> 		fw 10.2.4.70-2 api 5 htt-ver 2.1 wmi-op 5 htt-op 2
> 		cal otp max-sta 128 features no-p2p
> 	ath10k_pci: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
> 
> I am using channel 116, regdom US or FR, where I see no traffic at all
> using wireshark+Airpcap.
> I set wpa_supplicant to scan this channel only for a specific SSID
> "ssid1".
> 
> At initial startup of the client device, no probes are going out, which
> is OK.
> 
> Then, on another device, I start a hostapd set to channel 116, with a
> different SSID "otherssid" so that the supplicant will not associate.
> 
> Shortly (1-2s) after the beacons appear in the air, the client begins to
> Send probe request in the air, which is unexpected, but acceptable since
> the client can infer absence of radars from the presence of beacons.
> 
> *The problem*
> 
> If I power down the AP, the client continues to send probes for around
> 10 minutes, which is unacceptable since it cannot handle radar detection,
> as it is a slave device in the meaning of ETSI/EN 301-893[1].
> 
> 
> Some tests I made:
> - I tried to investigate the "beacon hint" mechanism but it appears
>   that it is not used on DFS channels.
> 
> - I tried to force the IEEE80211_NO_IR flag when IEEE80211_CHAN_DFS
>   is set.
> 
> - When I reload the reg. domain using "iw reg set", the probes cease,
>   but will reappear if I cycle my AP again On then Off.
> 
> - When I let the client associate, then disassociate and stop the AP,
>   the same problem arises. It disappears if I add a call to
>   ath10k_regd_update() in mac.c after a disconnection (This is not a
>   fix, since in my case the client never associates).
> 
> - Since at startup, the client does not send probes, I infer that the
>   problem is *not* caused by a hidden AP that the card could see but
>   not airpcap.
> 
> - I tried with channels 52 and 100, with regdom FR or US: same problem.
> 
> Any ideas?
> 
> 
> [1] http://www.etsi.org/deliver/etsi_en/301800_301899/301893/ 
> 01.08.01_60/en_301893v010801p.pdf
[2] http://lists.shmoo.com/pipermail/hostap/2015-January/031906.html 
> 
> J.P. Tosoni - ACKSYS
> 
> 
> 
> 
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k



From greearb at candelatech.com  Tue Dec  6 11:36:01 2016
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 6 Dec 2016 11:36:01 -0800
Subject: ath10k firmware sends probes on DFS channels without radar
 detection
In-Reply-To: <004a01d24fe2$94da8dc0$be8fa940$@acksys.fr>
References: <004a01d24fe2$94da8dc0$be8fa940$@acksys.fr>
Message-ID: <63c731f2-ee21-6450-2ae4-2808e7130eb5@candelatech.com>

On 12/06/2016 09:02 AM, Jean-Pierre Tosoni wrote:
> This follows on the previous discussion
> 	"Client station sends probes on DFS channels"
>
> Problem:
> The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
> wpa_supplicant do not comply with the norm ETSI/EN 301-893
> section 4.7; because they can send probes for 600s when no
> AP is around.
>
> Analysis:
> The problem seems to lie in the firmware, which regards the presence
> of *any* beacon as a proof that the channel is radar-clean for 600s.
>
> This is a wrong hypothesis, since a rogue AP sending fraudulent
> beacons should not induce a scrupulous STA in sending illegal probes.
>
> Moreover, the norm (table D.1) sets a time limit of 10s to
> shutdown when no AP positively allows the STA to transmit on
> the DFS channel.
>
> Status:
> - there is no known plan at QCA to fix the issue.
> - ath10k firmware is not publicly available for fixes.
> - there is no obvious fix working in ath10k.
> - the issue does not show up with other mac80211 devices like ath9k.
> - wpa_supplicant considers this is a kernel issue [2]

Have you confirmed that there are no probe requests being sent by
ath10k driver?

You could also try disabling the station keep-alive and roaming logic in the firmware by
tweaking the wmi initial setup logic.  I disable that in my firmware,
for instance, because mac80211 can do a better job and then I can
save resources in the firmware.

Finally, if that doesn't work, then I could probably fix that in CT firmware
in case that is of interest.

Thanks,
Ben

>
> Jean-Pierre Tosoni
>
>
>
>> -----Message d'origine-----
>> De : ath10k [mailto:ath10k-bounces at lists.infradead.org] De la part de
>> Jean-Pierre Tosoni
>> Envoy? : mercredi 30 novembre 2016 19:04
>> ? : ath10k at lists.infradead.org
>> Objet : Client station sends probes on DFS channels
>>
>> Hello list,
>>
>> There is a case where I can see probes on a DFS channel, from a non-
>> associated station using ath10k. (note that the problem does not arise
>> when using ath9k).
>>
>> *The setup*
>>
>> I am using Openwrt, wpa_supplicant and compat-wireless 2016-10-08,
>> Card firmware is	ath10k_pci: qca988x hw2.0 (0x4100016c, 0x043202ff)
>> 		fw 10.2.4.70-2 api 5 htt-ver 2.1 wmi-op 5 htt-op 2
>> 		cal otp max-sta 128 features no-p2p
>> 	ath10k_pci: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
>>
>> I am using channel 116, regdom US or FR, where I see no traffic at all
>> using wireshark+Airpcap.
>> I set wpa_supplicant to scan this channel only for a specific SSID
>> "ssid1".
>>
>> At initial startup of the client device, no probes are going out, which
>> is OK.
>>
>> Then, on another device, I start a hostapd set to channel 116, with a
>> different SSID "otherssid" so that the supplicant will not associate.
>>
>> Shortly (1-2s) after the beacons appear in the air, the client begins to
>> Send probe request in the air, which is unexpected, but acceptable since
>> the client can infer absence of radars from the presence of beacons.
>>
>> *The problem*
>>
>> If I power down the AP, the client continues to send probes for around
>> 10 minutes, which is unacceptable since it cannot handle radar detection,
>> as it is a slave device in the meaning of ETSI/EN 301-893[1].
>>
>>
>> Some tests I made:
>> - I tried to investigate the "beacon hint" mechanism but it appears
>>   that it is not used on DFS channels.
>>
>> - I tried to force the IEEE80211_NO_IR flag when IEEE80211_CHAN_DFS
>>   is set.
>>
>> - When I reload the reg. domain using "iw reg set", the probes cease,
>>   but will reappear if I cycle my AP again On then Off.
>>
>> - When I let the client associate, then disassociate and stop the AP,
>>   the same problem arises. It disappears if I add a call to
>>   ath10k_regd_update() in mac.c after a disconnection (This is not a
>>   fix, since in my case the client never associates).
>>
>> - Since at startup, the client does not send probes, I infer that the
>>   problem is *not* caused by a hidden AP that the card could see but
>>   not airpcap.
>>
>> - I tried with channels 52 and 100, with regdom FR or US: same problem.
>>
>> Any ideas?
>>
>>
>> [1] http://www.etsi.org/deliver/etsi_en/301800_301899/301893/
>> 01.08.01_60/en_301893v010801p.pdf
> [2] http://lists.shmoo.com/pipermail/hostap/2015-January/031906.html
>>
>> J.P. Tosoni - ACKSYS
>>
>>
>>
>>
>> _______________________________________________
>> 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 bmorgan at cococorp.com  Tue Dec  6 13:32:43 2016
From: bmorgan at cococorp.com (Benjamin Morgan)
Date: Tue, 6 Dec 2016 13:32:43 -0800
Subject: ath10k firmware crashes in mesh mode on QCA9880
In-Reply-To: <d8eb0ba5828d43dd83030247ba443b88@aphydexm01f.ap.qualcomm.com>
References: <583DD564.8040704@cococorp.com>
 <20161201070908.GB11953@atheros-ThinkPad-T61> <58421FA2.2020004@cococorp.com>
 <20161203124358.GB31861@atheros-ThinkPad-T61>
 <20161203124600.GC31861@atheros-ThinkPad-T61> <5845B325.6060002@cococorp.com>
 <d8eb0ba5828d43dd83030247ba443b88@aphydexm01f.ap.qualcomm.com>
Message-ID: <58472E7B.7090603@cococorp.com>

1. Yes, this appears to happens every time a unicast packet with 
wpa_supplicant encryption in VHT80 mode is received. I haven't seen a 
successful ping-pong pair.
2. We tried with 10.2.4.70.42-2 firmware and still saw crashes.
3. We ran our experiment again with extra debugging turned on.
     Node A: 18:A6:F7:23:6E:66 | 10.230.5.41
     Node B: 18:A6:F7:26:0F:21 | 10.230.5.42
     The ping command we used was run on Node A was 'ping -s 1500 -i 0.1 
10.230.5.42'
     Here is the dmesg log from Node B.

[ 5413.478170] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5413.503954] ath10k_pci 0000:01:00.0: scan event bss channel type 4 
reason 3 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running (2)
[ 5413.503985] ath10k_pci 0000:01:00.0: chan info err_code 0 freq 5825 
cmd_flags 1 noise_floor -105 rx_clear_count 7692807 cycle_count 312271423
[ 5413.504029] ath10k_pci 0000:01:00.0: scan event completed type 2 
reason 0 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running (2)
[ 5413.525868] ath10k_pci 0000:01:00.0: wmi vdev install key idx 1 
cipher 4 len 16
[ 5413.526014] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31 value 1
[ 5413.526193] ath10k_pci 0000:01:00.0: mac vdev 0 set keyidx 1
[ 5413.526216] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31 value 1
[ 5413.526532] ath10k_pci 0000:01:00.0: mac chanctx add freq 5180 width 
3 ptr 86db29b0
[ 5413.526556] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0 
needed? 0 allowed? 1
[ 5413.526574] ath10k_pci 0000:01:00.0: mac chanctx assign ptr 86db29b0 
vdev_id 0
[ 5413.526592] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq 
5180 phymode 11ac-vht80
[ 5413.526616] ath10k_pci 0000:01:00.0: wmi vdev start id 0x0 flags: 
0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
[ 5413.533099] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
[ 5413.533148] ath10k_pci 0000:01:00.0: mac vdev_id 0 txpower 23
[ 5413.533163] ath10k_pci 0000:01:00.0: mac txpower 23
[ 5413.533180] ath10k_pci 0000:01:00.0: wmi pdev set param 3 value 46
[ 5413.533247] ath10k_pci 0000:01:00.0: wmi pdev set param 4 value 46
[ 5413.533295] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180 
width 3 ptr 86db29b0 changed 10
[ 5413.533318] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180 
width 3 ptr 86db29b0 changed 2
[ 5413.533337] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0 
needed? 1 allowed? 1
[ 5413.533357] ath10k_pci 0000:01:00.0: WMI vdev create: id 1 type 4 
subtype 0 macaddr 18:a6:f7:26:0f:21
[ 5413.533412] ath10k_pci 0000:01:00.0: mac monitor vdev 1 created
[ 5413.533463] ath10k_pci 0000:01:00.0: wmi vdev start id 0x1 flags: 
0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
[ 5413.937652] ath10k_pci 0000:01:00.0: wmi event debug mesg len 152
[ 5413.978273] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5414.478363] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5414.527015] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
[ 5414.527067] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x1 assoc id 
0 bssid 18:a6:f7:26:0f:21
[ 5414.527121] ath10k_pci 0000:01:00.0: mac monitor vdev 1 started
[ 5414.527165] ath10k_pci 0000:01:00.0: mac monitor started
[ 5414.527216] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 3 
value 1000
[ 5414.527262] ath10k_pci 0000:01:00.0: mac vdev 0 beacon_interval 1000
[ 5414.527278] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
staggered
[ 5414.527294] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[ 5414.527314] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[ 5414.527330] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[ 5414.527457] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x0 assoc id 
0 bssid 00:00:00:00:00:00
[ 5414.527501] ath10k_pci 0000:01:00.0: mac vdev 0 up
[ 5414.527564] ath10k_pci 0000:01:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
[ 5414.541090] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1 
needed? 1 allowed? 1
[ 5414.978454] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5415.478548] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5415.978649] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5416.445280] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1 
needed? 1 allowed? 1
[ 5416.478761] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5416.978879] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5417.478985] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5417.979081] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5418.479190] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5418.979301] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5419.479403] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5419.979551] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5420.479643] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5420.979746] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5421.479841] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5421.979940] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5422.480288] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5422.980386] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5423.480490] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5423.980600] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5424.480702] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5424.971969] ath10k_pci 0000:01:00.0: mac vdev 0 peer create 
18:a6:f7:23:6e:66 (new sta) sta 1 / 128 peer 2 / 144
[ 5424.972000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0 
peer_addr 18:a6:f7:23:6e:66
[ 5424.975107] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
staggered
[ 5424.975134] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[ 5424.975219] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[ 5424.975238] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[ 5424.980787] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5425.204468] ath10k_pci 0000:01:00.0: mac sta 18:a6:f7:23:6e:66 associated
[ 5425.204531] ath10k_pci 0000:01:00.0: mac ht peer 18:a6:f7:23:6e:66 
mcs cnt 24 nss 3
[ 5425.204548] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66 qos 1
[ 5425.204563] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66 
phymode 11na-ht40
[ 5425.204585] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr 
18:a6:f7:23:6e:66 (new)
[ 5425.204614] ath10k_pci 0000:01:00.0: wmi vdev 0 peer 
0x18:a6:f7:23:6e:66 set param 1 value 0
[ 5425.205376] ath10k_pci 0000:01:00.0: received event id 36891 not 
implemented
[ 5425.209240] ath10k_pci 0000:01:00.0: wmi vdev install key idx 0 
cipher 4 len 16
[ 5425.209655] ath10k_pci 0000:01:00.0: wmi vdev install key idx 1 
cipher 4 len 16
[ 5425.209848] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31 value 1
[ 5425.210196] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
staggered
[ 5425.210221] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[ 5425.210296] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[ 5425.210315] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[ 5425.480863] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5425.938619] ath10k_pci 0000:01:00.0: wmi event debug mesg len 100
[ 5425.980946] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5425.995007] ath10k_pci 0000:01:00.0: mac sta rc update for 
18:a6:f7:23:6e:66 changed 00000001 bw 2 nss 3 smps 1
[ 5425.995060] ath10k_pci 0000:01:00.0: mac update sta 18:a6:f7:23:6e:66 
peer bw 2
[ 5425.995081] ath10k_pci 0000:01:00.0: wmi vdev 0 peer 
0x18:a6:f7:23:6e:66 set param 4 value 2
[ 5426.481030] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5426.981117] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5427.481206] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5427.981294] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5428.481628] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5428.981718] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5429.481812] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5429.981894] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5430.481985] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5430.982073] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5431.482174] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5431.982505] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5432.482597] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5432.982679] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5433.482765] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5433.982857] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5434.482946] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5434.983008] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5435.483100] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5435.983181] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5436.483276] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5436.983366] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5437.483445] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5437.983516] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5438.483607] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5438.983692] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5439.439875] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 
db76b67c-ca98-4519-a762-4ff4edb45526)
[ 5439.449007] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c 
chip_id 0x043202ff sub 0000:0000
[ 5439.458378] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1 
tracing 0 dfs 1 testmode 1
[ 5439.471460] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api 5 
features no-p2p,raw-mode,mfp crc32 9d340dd9
[ 5439.481844] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A 
crc32 bebc7c08
[ 5439.489267] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 
cal file max-sta 128 raw 0 hwcrypto 1
[ 5439.500918] ath10k_pci 0000:01:00.0: firmware register dump:
[ 5439.506678] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 
0x009A4577 0x00955B31
[ 5439.514706] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130 
0x00000002 0x00439E98
[ 5439.522751] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074 
0x00407120 0x004436CC
[ 5439.530794] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000 
0x009A3518 0x009A3526
[ 5439.538834] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D 
0x00000000 0x00000000
[ 5439.546871] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4 
0x0040AC60 0x0040AC09
[ 5439.554915] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24 
0x00400000 0xC09A4577
[ 5439.562948] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84 
0x0044110C 0x00442074
[ 5439.570992] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4 
0x0044110C 0x00407120
[ 5439.579032] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4 
0x0040AC14 0x00001580
[ 5439.587070] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04 
0x009C643C 0x004436CC
[ 5439.595113] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64 
0x004208FC 0x00439E4C
[ 5439.603146] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84 
0x004208FC 0x00425E00
[ 5439.611191] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4 
0x00424FE8 0x00000002
[ 5439.619230] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14 
0x00000004 0x004039D0
[ 5439.726818] ieee80211 phy0: Hardware restart was requested
[ 5439.732433] ath10k_pci 0000:01:00.0: wmi mgmt vdev down id 0x1
[ 5439.732461] ath10k_pci 0000:01:00.0: wmi vdev stop id 0x1
[ 5439.732482] ath10k_pci 0000:01:00.0: failed to synchronize monitor 
vdev 1 stop: -143
[ 5439.740370] ath10k_pci 0000:01:00.0: mac monitor vdev 1 stopped
[ 5439.740386] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
[ 5439.747042] ath10k_pci 0000:01:00.0: wmi disable pktlog

We noticed in this log that when the radio starts up it says that it is 
in VHT80 mode:
[ 5413.526592] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq 
5180 phymode 11ac-vht80

But when a peer connects it seems to think the peer is in HT40 mode:
[ 5425.204563] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66 
phymode 11na-ht40

Compared to no encryption case - this log was taken from Node A:

[   24.874253] ath10k_pci 0000:01:00.0: mac chanctx add freq 5180 width 
3 ptr 86d26db0
[   24.874278] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0 
needed? 0 allowed? 1
[   24.874296] ath10k_pci 0000:01:00.0: mac chanctx assign ptr 86d26db0 
vdev_id 0
[   24.874312] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq 
5180 phymode 11ac-vht80
[   24.874337] ath10k_pci 0000:01:00.0: wmi vdev start id 0x0 flags: 
0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
[   24.881335] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
[   24.881423] ath10k_pci 0000:01:00.0: mac vdev_id 0 txpower 23
[   24.881438] ath10k_pci 0000:01:00.0: mac txpower 23
[   24.881454] ath10k_pci 0000:01:00.0: wmi pdev set param 3 value 46
[   24.881491] ath10k_pci 0000:01:00.0: wmi pdev set param 4 value 46
[   24.881515] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180 
width 3 ptr 86d26db0 changed 10
[   24.881535] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180 
width 3 ptr 86d26db0 changed 2
[   24.881554] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0 
needed? 1 allowed? 1
[   24.881574] ath10k_pci 0000:01:00.0: WMI vdev create: id 1 type 4 
subtype 0 macaddr 18:a6:f7:23:6e:66
[   24.881689] ath10k_pci 0000:01:00.0: mac monitor vdev 1 created
[   24.881745] ath10k_pci 0000:01:00.0: wmi vdev start id 0x1 flags: 
0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
[   25.273460] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[   25.730570] ath10k_pci 0000:01:00.0: wmi event debug mesg len 300
[   25.773566] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[   25.874556] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
[   25.879992] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x1 assoc id 
0 bssid 18:a6:f7:23:6e:66
[   25.880077] ath10k_pci 0000:01:00.0: mac monitor vdev 1 started
[   25.880093] ath10k_pci 0000:01:00.0: mac monitor started
[   25.880139] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 3 
value 1000
[   25.880184] ath10k_pci 0000:01:00.0: mac vdev 0 beacon_interval 1000
[   25.880199] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
staggered
[   25.880215] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[   25.880235] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[   25.880250] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[   25.880988] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x0 assoc id 
0 bssid 00:00:00:00:00:00
[   25.881035] ath10k_pci 0000:01:00.0: mac vdev 0 up
[   25.881097] ath10k_pci 0000:01:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
[   25.882968] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   25.928796] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
staggered
[   25.928821] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[   25.928866] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[   25.928883] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[   25.929020] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1 
needed? 1 allowed? 1
[   25.941886] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
staggered
[   25.941911] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[   25.941955] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[   25.941972] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[   25.953727] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
staggered
[   25.953753] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[   25.953798] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[   25.953817] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[   25.970588] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
staggered
[   25.970614] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[   25.970659] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[   25.970676] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[   25.989056] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
staggered
[   25.989081] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[   25.989126] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[   25.989143] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[   26.071686] ath10k_pci 0000:01:00.0: mac vdev 0 peer create 
18:a6:f7:26:0f:21 (new sta) sta 1 / 128 peer 2 / 144
[   26.071712] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0 
peer_addr 18:a6:f7:26:0f:21
[   26.071952] ath10k_pci 0000:01:00.0: mac sta 18:a6:f7:26:0f:21 associated
[   26.071981] ath10k_pci 0000:01:00.0: mac ht peer 18:a6:f7:26:0f:21 
mcs cnt 24 nss 3
[   26.071999] ath10k_pci 0000:01:00.0: mac vht peer 18:a6:f7:26:0f:21 
max_mpdu 1048575 flags 0x601b001
[   26.072013] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:26:0f:21 qos 1
[   26.072028] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:26:0f:21 
phymode 11ac-vht80
[   26.072047] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr 
18:a6:f7:26:0f:21 (new)
[   26.072071] ath10k_pci 0000:01:00.0: wmi vdev 0 peer 
0x18:a6:f7:26:0f:21 set param 1 value 0
[   26.072502] ath10k_pci 0000:01:00.0: received event id 36891 not 
implemented
[   26.074194] ath10k_pci 0000:01:00.0: mac sta rc update for 
18:a6:f7:26:0f:21 changed 00000000 bw 2 nss 3 smps 1
[   26.074586] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
staggered
[   26.074609] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[   26.074682] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[   26.074701] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[   26.074760] ath10k_pci 0000:01:00.0: mac vdev 0 slot_time 2
[   26.074779] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 7 value 2
[   26.273652] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[   26.730650] ath10k_pci 0000:01:00.0: wmi event debug mesg len 44
[   26.773733] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[   27.135445] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1 
needed? 1 allowed? 1
[   27.273810] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID

It seems to start up in VHT80 mode and when it peers with Node B it 
thinks Node B is also in VHT80 mode and ping works.

4. Beacons are sent at 6 Mb/s basic rate and unicast QoS Data is sent 
with three spatial streams. Attached is the full pcap of the experiment.

Thank you for looking into this!

~Benjamin

On 12/05/2016 11:24 AM, Nagarajan, Ashok Raj wrote:
> 0x009A4577 0x00955B31
>
> Benjamin, Thanks for the logs.
> Quick questions to further debug the issue here,
>
> 1. Is this issue seen every time you start sending data traffic?
> 2. Issue seen with older firmwares? (FYR, http://linuxwireless.org/en/users/Drivers/ath10k/firmware/ )
> 3. Could you please share the dmesg from your device after enabling MAC and WMI logs in ath10k driver
> 	To enable debug logs please see http://linuxwireless.org/en/users/Drivers/ath10k/debug/	
> 4. Do you know what is the Number of Spatial Streams seen in mesh beacons and in mesh data packet?
>
> Thanks,
> Ashok

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ath10k_crash_pcap.tgz
Type: application/x-compressed-tar
Size: 25083 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20161206/23b00df7/attachment-0001.bin>

From mohammed at qti.qualcomm.com  Tue Dec  6 21:00:32 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Wed, 7 Dec 2016 10:30:32 +0530
Subject: [PATCH] ath10k: Avoid potential page alloc BUG_ON in tx free path
Message-ID: <1481086832-17281-1-git-send-email-mohammed@qca.qualcomm.com>

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

'ath10k_htt_tx_free_cont_txbuf' and 'ath10k_htt_tx_free_cont_frag_desc'
have NULL pointer checks to avoid crash if they are called twice
but this is as of now not sufficient as these pointers are not assigned
to NULL once the contiguous DMA memory allocation is freed, fix this.
Though this may not be hit with the explicity check of state variable
'tx_mem_allocated' check, good to have this addressed as well.

Below BUG_ON is hit when the above scenario is simulated
with kernel debugging enabled

 page:f6d09a00 count:0 mapcount:-127 mapping:  (null)
index:0x0
 flags: 0x40000000()
 page dumped because: VM_BUG_ON_PAGE(page_ref_count(page)
== 0)
 ------------[ cut here ]------------
 kernel BUG at ./include/linux/mm.h:445!
 invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
 EIP is at put_page_testzero.part.88+0xd/0xf
 Call Trace:
  [<c118a2cc>] __free_pages+0x3c/0x40
  [<c118a30e>] free_pages+0x3e/0x50
  [<c10222b4>] dma_generic_free_coherent+0x24/0x30
  [<f8c1d9a8>] ath10k_htt_tx_free_cont_txbuf+0xf8/0x140

  [<f8c1e2a9>] ath10k_htt_tx_destroy+0x29/0xa0

  [<f8c143e0>] ath10k_core_destroy+0x60/0x80 [ath10k_core]
  [<f8acd7e9>] ath10k_pci_remove+0x79/0xa0 [ath10k_pci]
  [<c13ed7a8>] pci_device_remove+0x38/0xb0
  [<c14d3492>] __device_release_driver+0x72/0x100
  [<c14d36b7>] driver_detach+0x97/0xa0
  [<c14d29c0>] bus_remove_driver+0x40/0x80
  [<c14d427a>] driver_unregister+0x2a/0x60
  [<c13ec768>] pci_unregister_driver+0x18/0x70
  [<f8aced4f>] ath10k_pci_exit+0xd/0x2be [ath10k_pci]
  [<c1101e78>] SyS_delete_module+0x158/0x210
  [<c11b34f1>] ? __might_fault+0x41/0xa0
  [<c11b353b>] ? __might_fault+0x8b/0xa0
  [<c1001a4b>] do_fast_syscall_32+0x9b/0x1c0
  [<c178da34>] sysenter_past_esp+0x45/0x74

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

diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 27e49db..86b427f 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -239,6 +239,7 @@ static void ath10k_htt_tx_free_cont_txbuf(struct ath10k_htt *htt)
 
 	size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
 	dma_free_coherent(ar->dev, size, htt->txbuf.vaddr, htt->txbuf.paddr);
+	htt->txbuf.vaddr = NULL;
 }
 
 static int ath10k_htt_tx_alloc_cont_txbuf(struct ath10k_htt *htt)
@@ -268,6 +269,7 @@ static void ath10k_htt_tx_free_cont_frag_desc(struct ath10k_htt *htt)
 			  size,
 			  htt->frag_desc.vaddr,
 			  htt->frag_desc.paddr);
+	htt->frag_desc.vaddr = NULL;
 }
 
 static int ath10k_htt_tx_alloc_cont_frag_desc(struct ath10k_htt *htt)
-- 
1.9.1



From mohammed at codeaurora.org  Tue Dec  6 22:28:24 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Wed, 7 Dec 2016 11:58:24 +0530
Subject: [PATCH 1/2] ath10k: add accounting for the extended peer
 statistics
In-Reply-To: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
References: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
Message-ID: <20161207062824.GA3404@atheros-ThinkPad-T61>

Hi Christian,

On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote:
> The 10.4 firmware adds extended peer information to the
> firmware's statistics payload. This additional info is
> stored as a separate data field and the elements are
> stored in their own "peers_extd" list.
> 
> These elements can pile up in the same way as the peer
> information elements. This is because the
> ath10k_wmi_10_4_op_pull_fw_stats() function tries to
> pull the same amount (num_peer_stats) for every statistic
> data unit.
> 
> Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
> Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>
> ---
>  drivers/net/wireless/ath/ath10k/debug.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> index 82a4c67f3672..4acd9eb65910 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -399,6 +399,7 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
>  			 * prevent firmware from DoS-ing the host.
>  			 */
>  			ath10k_fw_stats_peers_free(&ar->debug.fw_stats.peers);
> +			ath10k_fw_extd_stats_peers_free(&ar->debug.fw_stats.peers_extd);

[shafi] thanks for fixing this !

>  			ath10k_warn(ar, "dropping fw peer stats\n");
>  			goto free;
>  		}
> @@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
>  			goto free;
>  		}
>  
> +		if (!list_empty(&stats.peers))

[shafi] sorry please correct me if i am wrong, for 'extended peer stats' we are checking
for normal 'peer stats' ? Is this the fix intended, i had started a build to
check your change and we will keep you posted, does this fix displaying
'rx_duration' in ath10k fw_stats.

> +			list_splice_tail_init(&stats.peers_extd,
> +					      &ar->debug.fw_stats.peers_extd);
> +
>  		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);

thanks,
shafi


From tamizhchelvam at codeaurora.org  Wed Dec  7 03:04:33 2016
From: tamizhchelvam at codeaurora.org (Tamizh chelvam)
Date: Wed, 07 Dec 2016 16:34:33 +0530
Subject: [PATCH 1/4] cfg80211: Add support to enable or disable btcoex
In-Reply-To: <1480949161.31788.23.camel@sipsolutions.net>
References: <1478610932-21954-1-git-send-email-c_traja@qti.qualcomm.com>
 <1478610932-21954-2-git-send-email-c_traja@qti.qualcomm.com>
 <1480949161.31788.23.camel@sipsolutions.net>
Message-ID: <576b59d939ecd1296b8550de2e63052d@codeaurora.org>

Hi Johannes,

Thanks for the comments.

On 2016-12-05 20:16, Johannes Berg wrote:
> On Tue, 2016-11-08 at 18:45 +0530, c_traja at qti.qualcomm.com wrote:
>> From: Tamizh chelvam <c_traja at qti.qualcomm.com>
>> 
>> This patch adds support to enable or disable btcoex by
>> adding NL80211_ATTR_WIPHY_BTCOEX_ENABLE attribute in
>> NL80211_CMD_SET_WIPHY command. By default BTCOEX disabled in driver.
> 
> I think overloading SET_WIPHY even more is a mistake - why not group
> this with the new command you're introducing in the second patch?
> 
Sure.

> Also, can have a flag attribute to enable/disable, or better even
> disable when you're not setting any other parameters.

BTCOEX will be disabled by default. I will use 
NL80211_ATTR_WIPHY_BTCOEX_ENABLE
attribute to enable/disable BTCOEX.



From alexandre at maloteaux.net  Wed Dec  7 00:40:29 2016
From: alexandre at maloteaux.net (Alexandre Maloteaux)
Date: Wed, 7 Dec 2016 09:40:29 +0100
Subject: boot kernel panic with QCA6174 and kernel 4.8
Message-ID: <c932ec30-7538-3229-e965-cfea18742e9c@maloteaux.net>

Hi
Since recent kernel upgrade on Arch linux ;  im facing  boot kernel
panics with the ath10k_pci and QCA6174 802.11ac Wireless Network Adapter
on an Eurocom P5 Pro laptop.

This is the main call stack dump :

ath10k_print_driver_info(ath10k_core)
ath10k_pcl_fw_crashed_dump (ath10k_pci)
ath10k_pcl.tasklet

So far i can circumvent the kernel panic by appending
modprobe.blacklist=ath10k_pci  to the kernel command line.
Once the Os is booted i can load the module with modprobe without
triggering the kernel panic.

I also unpacked the initrd and the firmware file are not located in
lib/firmware.

I could not setup kdump so early in the boot process so i have attached
a screenshot of the on screen dump.

lspci :
06:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless
Network Adapter (rev 20)

uname -r
4.8.11-1-ARCH

Best Regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sc panic.jpg
Type: image/jpeg
Size: 428995 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20161207/bed9df0e/attachment-0001.jpg>

From mohammed at codeaurora.org  Wed Dec  7 04:41:49 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Wed, 7 Dec 2016 18:11:49 +0530
Subject: boot kernel panic with QCA6174 and kernel 4.8
In-Reply-To: <c932ec30-7538-3229-e965-cfea18742e9c@maloteaux.net>
References: <c932ec30-7538-3229-e965-cfea18742e9c@maloteaux.net>
Message-ID: <20161207124149.GA4410@atheros-ThinkPad-T61>

Hi,

On Wed, Dec 07, 2016 at 09:40:29AM +0100, Alexandre Maloteaux wrote:
> Hi
> Since recent kernel upgrade on Arch linux ;  im facing  boot kernel
> panics with the ath10k_pci and QCA6174 802.11ac Wireless Network Adapter
> on an Eurocom P5 Pro laptop.
> 
> This is the main call stack dump :
> 
> ath10k_print_driver_info(ath10k_core)
> ath10k_pcl_fw_crashed_dump (ath10k_pci)
> ath10k_pcl.tasklet

[shafi] If you have the source of the same and with the help of gdb we
can get the exact line

> 
> So far i can circumvent the kernel panic by appending
> modprobe.blacklist=ath10k_pci  to the kernel command line.
> Once the Os is booted i can load the module with modprobe without
> triggering the kernel panic.
> 
> I also unpacked the initrd and the firmware file are not located in
> lib/firmware.

[shafi] interesting your log (image file) seems to show the firmware is crashed
? if the firmware is missing you can give a try with this
https://patchwork.kernel.org/patch/9412085/ but the call trace looks completely
different, if the f/w is not there

long time back we fixed a race https://patchwork.kernel.org/patch/9167045/ but
it should be available in 4.8.11

> 
> I could not setup kdump so early in the boot process so i have attached
> a screenshot of the on screen dump.
> 
> lspci :
> 06:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless
> Network Adapter (rev 20)
> 
> uname -r
> 4.8.11-1-ARCH
> 
> Best Regards


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



From mohammed at codeaurora.org  Wed Dec  7 04:52:45 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Wed, 7 Dec 2016 18:22:45 +0530
Subject: boot kernel panic with QCA6174 and kernel 4.8
In-Reply-To: <20161207124149.GA4410@atheros-ThinkPad-T61>
References: <c932ec30-7538-3229-e965-cfea18742e9c@maloteaux.net>
 <20161207124149.GA4410@atheros-ThinkPad-T61>
Message-ID: <20161207125245.GA4429@atheros-ThinkPad-T61>


Hi,

also worth putting a print in 'ath10k_debug_print_board_info'
debug.c

~/ath/drivers/net/wireless/ath/ath10k$ git diff

diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index bfc0215..89ab4af 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
	+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -169,6 +169,12 @@ void ath10k_debug_print_board_info(struct ath10k *ar)
	else
	scnprintf(boardinfo, sizeof(boardinfo), "N/A");

	+	       if (IS_ERR_OR_NULL(ar->normal_mode_fw.board)) {
		+               printk("\nAvoided oops ?\n");
		+               WARN_ON(1);
		+               return;
		+       }
		+
		ath10k_info(ar, "board_file api %d bmi_id %s
				crc32 %08x",
				ar->bd_api,
				boardinfo,

Let me know if it helps, or you need a patch format

regards,
shafi

On Wed, Dec 07, 2016 at 06:11:49PM +0530, Mohammed Shafi Shajakhan wrote:
> Hi,
> 
> On Wed, Dec 07, 2016 at 09:40:29AM +0100, Alexandre Maloteaux wrote:
> > Hi
> > Since recent kernel upgrade on Arch linux ;  im facing  boot kernel
> > panics with the ath10k_pci and QCA6174 802.11ac Wireless Network Adapter
> > on an Eurocom P5 Pro laptop.
> > 
> > This is the main call stack dump :
> > 
> > ath10k_print_driver_info(ath10k_core)
> > ath10k_pcl_fw_crashed_dump (ath10k_pci)
> > ath10k_pcl.tasklet
> 
> [shafi] If you have the source of the same and with the help of gdb we
> can get the exact line
> 
> > 
> > So far i can circumvent the kernel panic by appending
> > modprobe.blacklist=ath10k_pci  to the kernel command line.
> > Once the Os is booted i can load the module with modprobe without
> > triggering the kernel panic.
> > 
> > I also unpacked the initrd and the firmware file are not located in
> > lib/firmware.
> 
> [shafi] interesting your log (image file) seems to show the firmware is crashed
> ? if the firmware is missing you can give a try with this
> https://patchwork.kernel.org/patch/9412085/ but the call trace looks completely
> different, if the f/w is not there
> 
> long time back we fixed a race https://patchwork.kernel.org/patch/9167045/ but
> it should be available in 4.8.11
> 
> > 
> > I could not setup kdump so early in the boot process so i have attached
> > a screenshot of the on screen dump.
> > 
> > lspci :
> > 06:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless
> > Network Adapter (rev 20)
> > 
> > uname -r
> > 4.8.11-1-ARCH
> > 
> > Best Regards
> 
> 
> > _______________________________________________
> > 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


From zoilo214.gomez at gmail.com  Wed Dec  7 05:50:20 2016
From: zoilo214.gomez at gmail.com (Zoilo Gomez)
Date: Wed, 7 Dec 2016 14:50:20 +0100
Subject: ath10k qca988x: hostapd does not start properly
In-Reply-To: <CA+BoTQ=kXyjtNFmj_bvym2-OxOP84XKhxpTgX0PmeMd7y52=kw@mail.gmail.com>
References: <CAMfKPAXXtuwbn2nQC19NwN=XuF-B8XQEzuk0pMPS8tHRMUV3Yg@mail.gmail.com>
 <CA+BoTQ=kXyjtNFmj_bvym2-OxOP84XKhxpTgX0PmeMd7y52=kw@mail.gmail.com>
Message-ID: <CAMfKPAWq-RvnE2neYMTSQUdmOEwjk5wpy58kCtzab8ebqiywHQ@mail.gmail.com>

Thank you very much Michal, I have installed CRDA and wireless-regdb
now and got it to work!



On Thu, Nov 24, 2016 at 8:21 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 23 November 2016 at 23:02, Zoilo Gomez <zoilo214.gomez at gmail.com> wrote:
>> Hi guys,
>>
>> I am trying to build an AP using QCA988X. All seems to go well to the
>> point where I can load the ath10k drivers, and (after installing
>> firmware in /lib/firmware/QCA988X/HW2.0), firmware seems to be loaded
>> properly. I can run iw and get results (see below), however hostapd
>> does not start properly, throwing errors (a.o.):
>> => Channel list update timeout - try to continue anyway
>> => channel [0] (36) is disabled for use in AP mode, flags: 0x853 NO-IR
>> => wlan0: IEEE 802.11 Configured channel (36) not found from the
>> channel list of current mode (2) IEEE 802.11a
>>
>> This must be really easy, but I have just started working on this, so
>> your help to get me going is very much appreciated!
>>
>> Thank you in advance for your time and help,
>>
>> Zoilo.
>>
>>
>>
>> Kernel is 3.10.87 with backport-3.18.1-1.
>>
>> I use these firware versions:
>>
>> ~ # ls -l /root/firmware-*
>> -rwxr-xr-x    1 root     root        197244 Nov 16  2016
>> /root/firmware-2.bin_10.1.467.2-1
>> -rwxr-xr-x    1 root     root        235056 Nov 17  2016
>> /root/firmware-3.bin_10.2.2.39.6-1
>>
>>
>> ~ # iw list
>> Wiphy phy1
>>                 Frequencies:
>>                         * 5180 MHz [36] (30.0 dBm) (no IR)
>>                         * 5200 MHz [40] (30.0 dBm) (no IR)
>>                         * 5220 MHz [44] (30.0 dBm) (no IR)
>>                         * 5240 MHz [48] (30.0 dBm) (no IR)
>>                         * 5260 MHz [52] (30.0 dBm) (no IR, radar detection)
>>                           DFS state: usable (for 207721 sec)
>>                           DFS CAC time: 0 ms
>>                         * 5280 MHz [56] (30.0 dBm) (no IR, radar detection)
>>                           DFS state: usable (for 207721 sec)
>>                           DFS CAC time: 0 ms
>>                         * 5300 MHz [60] (30.0 dBm) (no IR, radar detection)
>>                           DFS state: usable (for 207721 sec)
>>                           DFS CAC time: 0 ms
>>                         * 5320 MHz [64] (30.0 dBm) (no IR, radar detection)
>>                           DFS state: usable (for 207721 sec)
>>                           DFS CAC time: 0 ms
>>                         * 5500 MHz [100] (disabled)
>>                         * 5520 MHz [104] (disabled)
>>                         * 5540 MHz [108] (disabled)
>>                         * 5560 MHz [112] (disabled)
>>                         * 5580 MHz [116] (disabled)
>>                         * 5600 MHz [120] (disabled)
>>                         * 5620 MHz [124] (disabled)
>>                         * 5640 MHz [128] (disabled)
>>                         * 5660 MHz [132] (disabled)
>>                         * 5680 MHz [136] (disabled)
>>                         * 5700 MHz [140] (disabled)
>>                         * 5745 MHz [149] (30.0 dBm) (no IR)
>>                         * 5765 MHz [153] (30.0 dBm) (no IR)
>>                         * 5785 MHz [157] (30.0 dBm) (no IR)
>>                         * 5805 MHz [161] (30.0 dBm) (no IR)
>>                         * 5825 MHz [165] (30.0 dBm) (no IR)
> [...]
>> Here is my configuration file for hostapd:
>>
>> /root # cat test.80211ac.conf
>> interface=wlan0
>> driver=nl80211
>>
>> ssid=ath10k-test
>>
>> country_code=US
>> hw_mode=a
>> channel=36
> [...]
>> Channel list update timeout - try to continue anyway
>> nl80211: Regulatory information - country=00
>> nl80211: 2402-2472 @ 40 MHz 20 mBm
>> nl80211: 2457-2482 @ 40 MHz 20 mBm (no IR)
>> nl80211: 2474-2494 @ 20 MHz 20 mBm (no OFDM) (no IR)
>> nl80211: 5170-5250 @ 160 MHz 20 mBm (no IR)
>> nl80211: 5250-5330 @ 160 MHz 20 mBm (DFS) (no IR)
>> nl80211: 5490-5730 @ 160 MHz 20 mBm (DFS) (no IR)
>> channel [0] (36) is disabled for use in AP mode, flags: 0x853 NO-IR
>> wlan0: IEEE 802.11 Configured channel (36) not found from the channel
>> list of current mode (2) IEEE 802.11a
>> wlan0: IEEE 802.11 Hardware does not support configured channel
>> Could not select hw_mode and channel. (-3)
>> wlan0: interface state COUNTRY_UPDATE->DISABLED
>> wlan0: AP-DISABLED
>
> Your regulatory domain doesn't seem to get updated and all 5GHz
> channels remain to be restricted by the (conservative) world
> regulatory which disallows initiating radiation (NO-IR).
>
> Your regulatory update seems to timeout suggesting you're missing CRDA.
>
>
> Michal


From bartosz.markowski at tieto.com  Wed Dec  7 09:07:30 2016
From: bartosz.markowski at tieto.com (Bartosz Markowski)
Date: Wed,  7 Dec 2016 18:07:30 +0100
Subject: [PATCH 1/5] ath10k: fix IRAM banks number for QCA9377
Message-ID: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>

QCA9377 firmware shall alloc 4 IRAM banks

Signed-off-by: Bartosz Markowski <bartosz.markowski at tieto.com>
---
 drivers/net/wireless/ath/ath10k/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 0457e315d336..983f65bbb7fb 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1973,7 +1973,7 @@ static int ath10k_pci_get_num_banks(struct ath10k *ar)
 		}
 		break;
 	case QCA9377_1_0_DEVICE_ID:
-		return 2;
+		return 4;
 	}
 
 	ath10k_warn(ar, "unknown number of banks, assuming 1\n");
-- 
2.1.2



From bartosz.markowski at tieto.com  Wed Dec  7 09:07:31 2016
From: bartosz.markowski at tieto.com (Bartosz Markowski)
Date: Wed,  7 Dec 2016 18:07:31 +0100
Subject: [PATCH 2/5] ath10k: override CE5 config for QCA9377
In-Reply-To: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
References: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
Message-ID: <1481130454-27244-2-git-send-email-bartosz.markowski@tieto.com>

Similarly to QCA6174, QCA9377 requires the CE5 configuration to be
available for other feature. Use the ath10k_pci_override_ce_config()
for it as well.

This is required for TF2.0 firmware. Previous FW revisions were
working fine without this patch.

Fixes: a70587b3389a ("ath10k: configure copy engine 5 for HTT messages")
Signed-off-by: Bartosz Markowski <bartosz.markowski at tieto.com>
---
 drivers/net/wireless/ath/ath10k/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 983f65bbb7fb..85367006a80a 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3132,7 +3132,7 @@ int ath10k_pci_setup_resource(struct ath10k *ar)
 	setup_timer(&ar_pci->rx_post_retry, ath10k_pci_rx_replenish_retry,
 		    (unsigned long)ar);
 
-	if (QCA_REV_6174(ar))
+	if (QCA_REV_6174(ar) || QCA_REV_9377(ar))
 		ath10k_pci_override_ce_config(ar);
 
 	ret = ath10k_pci_alloc_pipes(ar);
-- 
2.1.2



From bartosz.markowski at tieto.com  Wed Dec  7 09:07:33 2016
From: bartosz.markowski at tieto.com (Bartosz Markowski)
Date: Wed,  7 Dec 2016 18:07:33 +0100
Subject: [PATCH 4/5] ath10k: set CTS protection VDEV param only if VDEV is up
In-Reply-To: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
References: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
Message-ID: <1481130454-27244-4-git-send-email-bartosz.markowski@tieto.com>

The cts protection vdev parameter, in new QCA9377 TF2.0 firmware,
requires bss peer to be created for the STATION vdev type.
bss peer is being allocated by the firmware after vdev_start/_up commands.
mac80211 may call the cts protection setup at any time, so the
we needs to track the situation and defer the cts configuration
to prevent firmware asserts, like below:

[00]: 0x05020001 0x000015B3 0x0099ACE2 0x00955B31
[04]: 0x0099ACE2 0x00060730 0x00000004 0x00000000
[08]: 0x0044C754 0x00412C10 0x00000000 0x00409C54
[12]: 0x00000009 0x00000000 0x00952F6C 0x00952F77
[16]: 0x00952CC4 0x00910712 0x00000000 0x00000000
[20]: 0x4099ACE2 0x0040E858 0x00421254 0x004127F4
[24]: 0x8099B9B2 0x0040E8B8 0x00000000 0xC099ACE2
[28]: 0x800B75CB 0x0040E8F8 0x00000007 0x00005008
[32]: 0x809B048A 0x0040E958 0x00000010 0x00433B10
[36]: 0x809AFBBC 0x0040E9A8 0x0042BB74 0x0042BBBC
[40]: 0x8091D252 0x0040E9C8 0x0042BBBC 0x00000001
[44]: 0x809FFA45 0x0040EA78 0x0043D3E4 0x0042C2C8
[48]: 0x809FCEF4 0x0040EA98 0x0043D3E4 0x00000001
[52]: 0x80911210 0x0040EAE8 0x00000010 0x004041D0
[56]: 0x80911154 0x0040EB28 0x00400000 0x00000000

Signed-off-by: Bartosz Markowski <bartosz.markowski at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 51 +++++++++++++++++++++++++++++------
 1 file changed, 43 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d06a12d548fd..6f1825964177 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1227,6 +1227,36 @@ static int ath10k_monitor_recalc(struct ath10k *ar)
 		return ath10k_monitor_stop(ar);
 }
 
+static bool ath10k_mac_can_set_cts_prot(struct ath10k_vif *arvif)
+{
+	struct ath10k *ar = arvif->ar;
+
+	lockdep_assert_held(&ar->conf_mutex);
+
+	if (!arvif->is_started) {
+		ath10k_dbg(ar, ATH10K_DBG_MAC, "defer cts setup, vdev is not ready yet\n");
+		return false;
+	}
+
+	return true;
+}
+
+static int ath10k_mac_set_cts_prot(struct ath10k_vif *arvif)
+{
+	struct ath10k *ar = arvif->ar;
+	u32 vdev_param;
+
+	lockdep_assert_held(&ar->conf_mutex);
+
+	vdev_param = ar->wmi.vdev_param->protection_mode;
+
+	ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %d cts_protection %d\n",
+		   arvif->vdev_id, arvif->use_cts_prot);
+
+	return ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
+					 arvif->use_cts_prot ? 1 : 0);
+}
+
 static int ath10k_recalc_rtscts_prot(struct ath10k_vif *arvif)
 {
 	struct ath10k *ar = arvif->ar;
@@ -5329,20 +5359,18 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw,
 
 	if (changed & BSS_CHANGED_ERP_CTS_PROT) {
 		arvif->use_cts_prot = info->use_cts_prot;
-		ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %d cts_prot %d\n",
-			   arvif->vdev_id, info->use_cts_prot);
 
 		ret = ath10k_recalc_rtscts_prot(arvif);
 		if (ret)
 			ath10k_warn(ar, "failed to recalculate rts/cts prot for vdev %d: %d\n",
 				    arvif->vdev_id, ret);
 
-		vdev_param = ar->wmi.vdev_param->protection_mode;
-		ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
-						info->use_cts_prot ? 1 : 0);
-		if (ret)
-			ath10k_warn(ar, "failed to set protection mode %d on vdev %i: %d\n",
-				    info->use_cts_prot, arvif->vdev_id, ret);
+		if (ath10k_mac_can_set_cts_prot(arvif)) {
+			ret = ath10k_mac_set_cts_prot(arvif);
+			if (ret)
+				ath10k_warn(ar, "failed to set cts protection for vdev %d: %d\n",
+					    arvif->vdev_id, ret);
+		}
 	}
 
 	if (changed & BSS_CHANGED_ERP_SLOT) {
@@ -7365,6 +7393,13 @@ ath10k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
 		arvif->is_up = true;
 	}
 
+	if (ath10k_mac_can_set_cts_prot(arvif)) {
+		ret = ath10k_mac_set_cts_prot(arvif);
+		if (ret)
+			ath10k_warn(ar, "failed to set cts protection for vdev %d: %d\n",
+				    arvif->vdev_id, ret);
+	}
+
 	mutex_unlock(&ar->conf_mutex);
 	return 0;
 
-- 
2.1.2



From bartosz.markowski at tieto.com  Wed Dec  7 09:07:32 2016
From: bartosz.markowski at tieto.com (Bartosz Markowski)
Date: Wed,  7 Dec 2016 18:07:32 +0100
Subject: [PATCH 3/5] ath10k: decrease num of peers support
In-Reply-To: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
References: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
Message-ID: <1481130454-27244-3-git-send-email-bartosz.markowski@tieto.com>

The correct number for QCA9377 chip is 33 VDEVs.
This impacts also QCA6174 chip and it's max VDEV number.

Signed-off-by: Bartosz Markowski <bartosz.markowski at tieto.com>
---
 drivers/net/wireless/ath/ath10k/hw.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 883547f3347c..7feffec531cc 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -512,7 +512,7 @@ ath10k_rx_desc_get_l3_pad_bytes(struct ath10k_hw_params *hw,
 /* Target specific defines for WMI-TLV firmware */
 #define TARGET_TLV_NUM_VDEVS			4
 #define TARGET_TLV_NUM_STATIONS			32
-#define TARGET_TLV_NUM_PEERS			35
+#define TARGET_TLV_NUM_PEERS			33
 #define TARGET_TLV_NUM_TDLS_VDEVS		1
 #define TARGET_TLV_NUM_TIDS			((TARGET_TLV_NUM_PEERS) * 2)
 #define TARGET_TLV_NUM_MSDU_DESC		(1024 + 32)
-- 
2.1.2



From tamizhchelvam at codeaurora.org  Wed Dec  7 09:59:08 2016
From: tamizhchelvam at codeaurora.org (Tamizh chelvam)
Date: Wed, 07 Dec 2016 23:29:08 +0530
Subject: [PATCH 2/4] cfg80211: Add new NL80211_CMD_SET_BTCOEX_PRIORITY to
 support BTCOEX
In-Reply-To: <1480949353.31788.27.camel@sipsolutions.net>
References: <1478610932-21954-1-git-send-email-c_traja@qti.qualcomm.com>
 <1478610932-21954-3-git-send-email-c_traja@qti.qualcomm.com>
 <1480949353.31788.27.camel@sipsolutions.net>
Message-ID: <5e5e8971c96293a81e7cb37bcdfbd593@codeaurora.org>

Hi Johannes,

Thanks for the comments.

On 2016-12-05 20:19, Johannes Berg wrote:
> On Tue, 2016-11-08 at 18:45 +0530, c_traja at qti.qualcomm.com wrote:
>> ?
>> + * struct cfg80211_btcoex_priority - BTCOEX support frame type
>> + *
>> + * This structure defines the driver supporting frame types for
>> BTCOEX
>> + *
>> + * @wlan_be_preferred: best effort frames preferred over bt traffic
>> + * @wlan_bk_preferred: background frames preferred over bt traffic
>> + * @wlan_vi_preferred: video frames preferred over bt traffic
>> + * @wlan_vo_preferred: voice frames preferred over bt traffic
>> + * @wlan_beacon_preferred: beacon preferred over bt traffic
>> + * @wlan_mgmt_preferred: management frames preferred ovet bt traffic
> 
> typo: over
> 
Okay
>> ?
>> ?/**
>> + * wiphy_btcoex_support_flags
>> + *	This enum has the driver supported frame types for BTCOEX.
>> + * @WIPHY_WLAN_BE_PREFERRED - Supports Best Effort frame for BTCOEX
>> + * @WIPHY_WLAN_BK_PREFERRED - supports Background frame for BTCOEX
>> + * @WIPHY_WLAN_VI_PREFERRED - supports Video frame for BTCOEX
>> + * @WIPHY_WLAN_VO_PREFERRED - supports Voice frame for BTCOEX
>> + * @WIPHY_WLAN_BEACON_PREFERRED - supports Beacon frame for BTCOEX
>> + * @WIPHY_WLAN_MGMT_PREFERRED - supports Management frames for
>> BTCOEX.
>> + */
> 
> That's not making much sense to me?
> 

is it fine to have as WIPHY_BTCOEX_BE_PREFERRED ?

>> +/**
>> + * enum wiphy_btcoex_priority - BTCOEX priority level
>> + *	This enum defines priority level for BTCOEX
>> + * WIPHY_WLAN_PREFERRED_LOW - low priority frames over BT traffic
>> + * WIPHY_WLAN_PREFERRED_HIGH - high priority frames over BT traffic
>> + */
>> +
>> +enum wiphy_btcoex_priority {
>> +	WIPHY_WLAN_PREFERRED_LOW = false,
>> +	WIPHY_WLAN_PREFERRED_HIGH = true,
>> +};
> 
> That false/true seems just strange.
> 

I will just use as a enum without assigning false/true.

>> + * @btcoex_support_flags: This will have the driver supported
>> + *	frame types for BTCOEX. This value filled by using
>> + *	%enum wiphy_btcoex_support_flags while driver
>> + *	initialization.
> 
> The whole "will have" isn't really clear.
> 
>> + * @NL80211_ATTR_SET_BTCOEX_PRIORITY: nested attribute for driver
>> supporting
>> + *	the BTCOEX. When used with
>> %NL80211_CMD_SET_BTCOEX_PRIORITY it contains
>> + *	attributes according &enum nl80211_btcoex_priority to
>> indicate
>> + *	which frame has high priority over BT.
> 
> There should be no "SET" in there.
> 
Okay sure.

>> ?/**
>> + * enum nl80211_btcoex_priority - BTCOEX parameter attributes
>> + *	This strcuture has enum values for driver supported wlan
>> + *	frame type for BTCOEX.
>> + * @NL80211_WLAN_BE_PREFERRED - Best Effort frame
>> + * @NL80211_WLAN_BK_PREFERRED - Background frame
>> + * @NL80211_WLAN_VI_PREFERRED - Video frame
>> + * @NL80211_WLAN_VO_PREFERRED - Voice frame
>> + * @NL80211_WLAN_BEACON_PREFERRED - BEACON frame
>> + * @NL80211_WLAN_MGMT_PREFERRED - MGMT frame
>> + */
>> +
>> +enum nl80211_btcoex_priority {
>> +	__NL80211_WLAN_PREFERRED_INVALID,
>> +	NL80211_WLAN_BE_PREFERRED,
>> +	NL80211_WLAN_BK_PREFERRED,
>> +	NL80211_WLAN_VI_PREFERRED,
>> +	NL80211_WLAN_VO_PREFERRED,
>> +	NL80211_WLAN_BEACON_PREFERRED,
>> +	NL80211_WLAN_MGMT_PREFERRED,
>> +	__NL80211_WLAN_PREFERRED_LAST,
>> +	NL80211_WLAN_PREFERRED_MAX =
>> +			__NL80211_WLAN_PREFERRED_LAST - 1,
>> +};
> 
> Wouldn't a bitmap be easier?
> 
since this is to distinguish between different btcoex priorities and we 
are not going to do any manipulations on these parameters.
It is just used as flag attribute.


From bartosz.markowski at tieto.com  Wed Dec  7 09:07:34 2016
From: bartosz.markowski at tieto.com (Bartosz Markowski)
Date: Wed,  7 Dec 2016 18:07:34 +0100
Subject: [PATCH 5/5] ath10k: add debug trace to rts/cts set function
In-Reply-To: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
References: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
Message-ID: <1481130454-27244-5-git-send-email-bartosz.markowski@tieto.com>

Align it with the cts protection call.

Signed-off-by: Bartosz Markowski <bartosz.markowski at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 6f1825964177..508366f139f1 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1275,6 +1275,9 @@ static int ath10k_recalc_rtscts_prot(struct ath10k_vif *arvif)
 		rts_cts |= SM(WMI_RTSCTS_FOR_SECOND_RATESERIES,
 			      WMI_RTSCTS_PROFILE);
 
+	ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %d recalc rts/cts prot %d\n",
+		   arvif->vdev_id, rts_cts);
+
 	return ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
 					 rts_cts);
 }
-- 
2.1.2



From alexandre at maloteaux.net  Wed Dec  7 12:30:55 2016
From: alexandre at maloteaux.net (Alexandre Maloteaux)
Date: Wed, 7 Dec 2016 21:30:55 +0100
Subject: boot kernel panic with QCA6174 and kernel 4.8
In-Reply-To: <20161207125245.GA4429@atheros-ThinkPad-T61>
References: <c932ec30-7538-3229-e965-cfea18742e9c@maloteaux.net>
 <20161207124149.GA4410@atheros-ThinkPad-T61>
 <20161207125245.GA4429@atheros-ThinkPad-T61>
Message-ID: <50de5ee1-840e-ca54-6e23-821aa5f37774@maloteaux.net>

Hi would like to clarify that i have the bug since 1 week . However the
kernel panic is semi-Random.

If  i face the kernel panic ; then i can restart indefinitely and i
always face the crash.
Right now i came back home and the laptop starts correctly. I can
restart it multiple time and it will boot correctly as well.

I m facing this behavior since 1 week and can't find a pattern on how to
crash / success boot.

Best Regards


From ryanhsu at qca.qualcomm.com  Wed Dec  7 13:45:33 2016
From: ryanhsu at qca.qualcomm.com (ryanhsu at qca.qualcomm.com)
Date: Wed, 7 Dec 2016 13:45:33 -0800
Subject: [PATCH] ath10k: fix incorrect txpower set by P2P_DEVICE interface
Message-ID: <1481147133-3957-1-git-send-email-ryanhsu@qca.qualcomm.com>

From: Ryan Hsu <ryanhsu at qca.qualcomm.com>

Ath10k reports the phy capability that upports P2P_DEVICE interface.

When we use the P2P supported wpa_supplicant to start connection, it'll
create the two interfaces, one is wlan0 (vdev_id=0) and one is P2P_DEVICE
p2p-dev-wlan0 which is for p2p control channel (vdev_id=1).

	ath10k_pci mac vdev create 0 (add interface) type 2 subtype 0
	ath10k_add_interface: vdev_id: 0, txpower: 0, bss_power: 0
	...
	ath10k_pci mac vdev create 1 (add interface) type 2 subtype 1
	ath10k_add_interface: vdev_id: 1, txpower: 0, bss_power: 0

And the txpower in per vif bss_conf will only be set to valid tx power when
the interface is assigned with channel_ctx.

But this P2P_DEVICE interface will never be used for any connection, so
that the uninitialized bss_conf.txpower=0 is assinged to the
arvif->txpower when interface created.

Since the txpower configuration is per phy interface.
So the smallest txpower of all vifs will be the one limit the tx power
of the phyical device, that causing the low txpower issue on other
active interfaces.

	wlan0: Limiting TX power to 21 (24 - 3) dBm
	ath10k_pci mac vdev_id 0 txpower 21
	ath10k_mac_txpower_recalc: vdev_id: 1, txpower: 0
	ath10k_mac_txpower_recalc: vdev_id: 0, txpower: 21
	ath10k_pci mac txpower 0

This issue only happens when we use the wpa_supplicant that supports
P2P or if we use the iw tool to create the control P2P_DEVICE interface.

Signed-off-by: Ryan Hsu <ryanhsu at qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index fe42bf5..6e1550b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4671,7 +4671,8 @@ static int ath10k_mac_txpower_recalc(struct ath10k *ar)
 	lockdep_assert_held(&ar->conf_mutex);
 
 	list_for_each_entry(arvif, &ar->arvifs, list) {
-		WARN_ON(arvif->txpower < 0);
+		if (arvif->txpower <= 0)
+			continue;
 
 		if (txpower == -1)
 			txpower = arvif->txpower;
@@ -4679,8 +4680,8 @@ static int ath10k_mac_txpower_recalc(struct ath10k *ar)
 			txpower = min(txpower, arvif->txpower);
 	}
 
-	if (WARN_ON(txpower == -1))
-		return -EINVAL;
+	if (txpower == -1)
+		return 0;
 
 	ret = ath10k_mac_txpower_setup(ar, txpower);
 	if (ret) {
-- 
1.9.1



From andreaschristofo at gmail.com  Thu Dec  8 11:13:55 2016
From: andreaschristofo at gmail.com (Andreas Christoforou)
Date: Thu, 8 Dec 2016 21:13:55 +0200
Subject: ath10k raw mode
Message-ID: <20161208191355.GA6764@ac>

Dear All,

could you please someone send me or let me know where I can download a firmware with raw mode flag enabled for my QCA988X card.

Thanks,
Andreas


From michal.kazior at tieto.com  Fri Dec  9 00:40:52 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 9 Dec 2016 09:40:52 +0100
Subject: ath10k raw mode
In-Reply-To: <20161208191355.GA6764@ac>
References: <20161208191355.GA6764@ac>
Message-ID: <CA+BoTQm5u+QkbK54aG7fNrcLZyqC7ne0P93VnPGHSKJ-fdCBwg@mail.gmail.com>

On 8 December 2016 at 20:13, Andreas Christoforou
<andreaschristofo at gmail.com> wrote:
> Dear All,
>
> could you please someone send me or let me know where I can download a firmware with raw mode flag enabled for my QCA988X card.

You can check this:

  https://github.com/kvalo/ath10k-firmware/tree/master/QCA988X/hw2.0/10.2.4.70

At the very least 10.2.4.70.54 should support it (at least it does
advertise it). It probably makes sense to have this (list of raw-mode
supporting firmware revisions) listed somewhere on
https://wireless.wiki.kernel.org/en/users/drivers/ath10k - any
volunteers? :)


Micha?


From erik.stromdahl at gmail.com  Sat Dec 10 04:58:40 2016
From: erik.stromdahl at gmail.com (Erik Stromdahl)
Date: Sat, 10 Dec 2016 13:58:40 +0100
Subject: [PATCH 1/2] ath10k: htc: Removal of unused struct members
Message-ID: <1481374721-16354-1-git-send-email-erik.stromdahl@gmail.com>

Removed tx_credits_per_max_message and tx_credit_size
from struct ath10k_htc_ep since they are not used
anywhere in the code.

They are just written, never read.

Signed-off-by: Erik Stromdahl <erik.stromdahl at gmail.com>
---
 drivers/net/wireless/ath/ath10k/htc.c |    6 ------
 drivers/net/wireless/ath/ath10k/htc.h |    2 --
 2 files changed, 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index 175aae3..f2e0659 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -726,12 +726,6 @@ int ath10k_htc_connect_service(struct ath10k_htc *htc,
 	ep->max_tx_queue_depth = conn_req->max_send_queue_depth;
 	ep->max_ep_message_len = __le16_to_cpu(resp_msg->max_msg_size);
 	ep->tx_credits = tx_alloc;
-	ep->tx_credit_size = htc->target_credit_size;
-	ep->tx_credits_per_max_message = ep->max_ep_message_len /
-					 htc->target_credit_size;
-
-	if (ep->max_ep_message_len % htc->target_credit_size)
-		ep->tx_credits_per_max_message++;
 
 	/* copy all the callbacks */
 	ep->ep_ops = conn_req->ep_ops;
diff --git a/drivers/net/wireless/ath/ath10k/htc.h b/drivers/net/wireless/ath/ath10k/htc.h
index 0c55cd9..ca150c9 100644
--- a/drivers/net/wireless/ath/ath10k/htc.h
+++ b/drivers/net/wireless/ath/ath10k/htc.h
@@ -314,8 +314,6 @@ struct ath10k_htc_ep {
 
 	u8 seq_no; /* for debugging */
 	int tx_credits;
-	int tx_credit_size;
-	int tx_credits_per_max_message;
 	bool tx_credit_flow_enabled;
 };
 
-- 
1.7.9.5



From erik.stromdahl at gmail.com  Sat Dec 10 04:58:41 2016
From: erik.stromdahl at gmail.com (Erik Stromdahl)
Date: Sat, 10 Dec 2016 13:58:41 +0100
Subject: [PATCH 2/2] ath10k: htc: Simplified credit distribution.
In-Reply-To: <1481374721-16354-1-git-send-email-erik.stromdahl@gmail.com>
References: <1481374721-16354-1-git-send-email-erik.stromdahl@gmail.com>
Message-ID: <1481374721-16354-2-git-send-email-erik.stromdahl@gmail.com>

Simplified transmit credit distribution code somewhat.
Since the WMI control service will get assigned all credits
there is no need for having a credit_allocation array in
struct ath10k_htc.

Signed-off-by: Erik Stromdahl <erik.stromdahl at gmail.com>
---
 drivers/net/wireless/ath/ath10k/htc.c |   29 +++++------------------------
 drivers/net/wireless/ath/ath10k/htc.h |    1 -
 2 files changed, 5 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index f2e0659..9f6a915 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -474,33 +474,16 @@ static void ath10k_htc_reset_endpoint_states(struct ath10k_htc *htc)
 	}
 }
 
-static void ath10k_htc_setup_target_buffer_assignments(struct ath10k_htc *htc)
-{
-	struct ath10k_htc_svc_tx_credits *entry;
-
-	entry = &htc->service_tx_alloc[0];
-
-	/*
-	 * for PCIE allocate all credists/HTC buffers to WMI.
-	 * no buffers are used/required for data. data always
-	 * remains on host.
-	 */
-	entry++;
-	entry->service_id = ATH10K_HTC_SVC_ID_WMI_CONTROL;
-	entry->credit_allocation = htc->total_transmit_credits;
-}
-
 static u8 ath10k_htc_get_credit_allocation(struct ath10k_htc *htc,
 					   u16 service_id)
 {
 	u8 allocation = 0;
-	int i;
 
-	for (i = 0; i < ATH10K_HTC_EP_COUNT; i++) {
-		if (htc->service_tx_alloc[i].service_id == service_id)
-			allocation =
-			    htc->service_tx_alloc[i].credit_allocation;
-	}
+	/* The WMI control service is the only service with flow control.
+	 * Let it have all transmit credits.
+	 */
+	if (service_id == ATH10K_HTC_SVC_ID_WMI_CONTROL)
+		allocation = htc->total_transmit_credits;
 
 	return allocation;
 }
@@ -574,8 +557,6 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
 		return -ECOMM;
 	}
 
-	ath10k_htc_setup_target_buffer_assignments(htc);
-
 	/* setup our pseudo HTC control endpoint connection */
 	memset(&conn_req, 0, sizeof(conn_req));
 	memset(&conn_resp, 0, sizeof(conn_resp));
diff --git a/drivers/net/wireless/ath/ath10k/htc.h b/drivers/net/wireless/ath/ath10k/htc.h
index ca150c9..6ababa3 100644
--- a/drivers/net/wireless/ath/ath10k/htc.h
+++ b/drivers/net/wireless/ath/ath10k/htc.h
@@ -337,7 +337,6 @@ struct ath10k_htc {
 	struct completion ctl_resp;
 
 	int total_transmit_credits;
-	struct ath10k_htc_svc_tx_credits service_tx_alloc[ATH10K_HTC_EP_COUNT];
 	int target_credit_size;
 };
 
-- 
1.7.9.5



From michal.kazior at tieto.com  Mon Dec 12 05:33:59 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 12 Dec 2016 14:33:59 +0100
Subject: ath10k raw mode
In-Reply-To: <CAPd_300YffoiqezwWx82GuMiSHgC7kg6JCF8KNZ2_ytj=gnfzQ@mail.gmail.com>
References: <20161208191355.GA6764@ac>
 <CA+BoTQm5u+QkbK54aG7fNrcLZyqC7ne0P93VnPGHSKJ-fdCBwg@mail.gmail.com>
 <CAPd_300YffoiqezwWx82GuMiSHgC7kg6JCF8KNZ2_ytj=gnfzQ@mail.gmail.com>
Message-ID: <CA+BoTQnzfoHE6SwuM819iA2PwB7sjYmz10Pv9b1C-fBdqMdLjA@mail.gmail.com>

On 12 December 2016 at 14:23, Andreas Christoforou <aceoscy at gmail.com> wrote:
> Dear Michal,
>
> unfortunately I am getting the following error
>
>   [ 50.416483] ath10k_pci 0000:07:00.0: firmware crashed! (uuid
> bdf6b230-c8f5-4e61-b174-93b0980ee5dc)
> [   50.425506] ath10k_pci 0000:07:00.0: qca988x hw2.0 (0x4100016c,
> 0x043202ff sub 0000:0000) fw 10.2.4.70.59-2 fwapi 5 bdapi 1 htt-ver 2.1
> wmi-op 5 htt-op 2 cal otp max-sta 128 raw 1 hwcrypto 0 features
> no-p2p,raw-mode
> [   50.444686] ath10k_pci 0000:07:00.0: debug 1 debugfs 1 tracing 1 dfs 0
> testmode 1
> [   50.454283] ath10k_pci 0000:07:00.0: firmware register dump:
> [   50.460008] ath10k_pci 0000:07:00.0: [00]: 0x4100016C 0x00000000
> 0x0097F8D5 0x00000000
> [   50.467940] ath10k_pci 0000:07:00.0: [04]: 0x00000000 0x00000000
> 0x00000000 0x00000000
> [   50.475908] ath10k_pci 0000:07:00.0: [08]: 0x00000000 0x00000000
> 0x00000000 0x00000000
> [   50.483865] ath10k_pci 0000:07:00.0: [12]: 0x00000000 0x00000000
> 0x00000000 0x00000000
> [   50.491869] ath10k_pci 0000:07:00.0: [16]: 0x00000000 0x00000000
> 0x00000000 0x0097F8D5
> [   50.499851] ath10k_pci 0000:07:00.0: [20]: 0x00000000 0x00401930
> 0x00000000 0x00000000
> [   50.507784] ath10k_pci 0000:07:00.0: [24]: 0x00000000 0x00000000
> 0x00000000 0x00000000
> [   50.515756] ath10k_pci 0000:07:00.0: [28]: 0x00000000 0x00000000
> 0x00000000 0x00000000
> [   50.523721] ath10k_pci 0000:07:00.0: [32]: 0x00000000 0x00000000
> 0x00000000 0x00000000
> [   50.531692] ath10k_pci 0000:07:00.0: [36]: 0x00000000 0x00000000
> 0x00000000 0x00000000
> [   50.539649] ath10k_pci 0000:07:00.0: [40]: 0x00000000 0x00000000
> 0x00000000 0x00000000
> [   50.547592] ath10k_pci 0000:07:00.0: [44]: 0x00000000 0x00000000
> 0x00000000 0x00000000
> [   50.555547] ath10k_pci 0000:07:00.0: [48]: 0x00000000 0x00000000
> 0x00000000 0x00000000
> [   50.563519] ath10k_pci 0000:07:00.0: [52]: 0x00000000 0x00000000
> 0x00000000 0x00000000
> [   50.571478] ath10k_pci 0000:07:00.0: [56]: 0x00000000 0x00000000
> 0x00000000 0x00000000
> [   50.583360] ath10k_warn: 6 callbacks suppressed
> [   50.587916] ath10k_pci 0000:07:00.0: failed to start WMI vdev 0: -108
> [   50.594461] ath10k_pci 0000:07:00.0: failed to start vdev 0 addr
> 00:00:00:00:00:00 on freq 2412: -108
> [   50.705799] ieee80211 phy0: Hardware restart was requested
> [   50.712476] ath10k_pci 0000:07:00.0: failed to flush transmit queue (skip
> 1 ar-state 2): 500
> [   50.722235] ath10k_pci 0000:07:00.0: failed to delete WMI vdev 0: -108

All I can tell from this is seems to crash when you try to start an
interface. Is it a monitor interface? If you intend to inject frames -
it's not supported. I'm not sure if anyone tried monitor mode for
sniffing with raw-mode enabled.


Micha?


From kvalo at qca.qualcomm.com  Mon Dec 12 08:35:10 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Mon, 12 Dec 2016 16:35:10 +0000
Subject: [PATCH] ath10k:  free host-mem with DMA_BIRECTIONAL flag.
In-Reply-To: <1480962519-13027-1-git-send-email-greearb@candelatech.com>
 (greearb@candelatech.com's message of "Mon, 5 Dec 2016 10:28:39	-0800")
References: <1480962519-13027-1-git-send-email-greearb@candelatech.com>
Message-ID: <87eg1d14xt.fsf@kamboji.qca.qualcomm.com>

greearb at candelatech.com writes:

> From: Ben Greear <greearb at candelatech.com>
>
> Hopefully this fixes the problem reported by Kalle:
>
> Noticed this in my log, but I don't have time to investigate this in
> detail right now:
>
> [  413.795346] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [  414.158755] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [  477.439659] ath10k_pci 0000:02:00.0: could not get mac80211 beacon
> [  481.666630] ------------[ cut here ]------------
> [  481.666669] WARNING: CPU: 0 PID: 1978 at lib/dma-debug.c:1155 check_unmap+0x320/0x8e0
> [  481.666688] ath10k_pci 0000:02:00.0: DMA-API: device driver frees DMA memory with different direction [device address=0x000000002d130000] [size=63800 bytes] [mapped with DMA_BIDIRECTIONAL] [unmapped with DMA_TO_DEVICE]
> [  481.666703] Modules linked in: ctr ccm ath10k_pci(E-) ath10k_core(E) ath(E) mac80211(E) cfg80211(E) snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi arc4 snd_rawmidi snd_seq_midi_event snd_seq btusb btintel snd_seq_device joydev coret
> [  481.671468] CPU: 0 PID: 1978 Comm: rmmod Tainted: G            E   4.9.0-rc7-wt+ #54
> [  481.671478] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD Ver. F.04 01/27/2010
> [  481.671489]  ef49dcec c842ee92 c8b5830e ef49dd34 ef49dd20 c80850f5 c8b5a13c ef49dd50
> [  481.671560]  000007ba c8b5830e 00000483 c8461830 c8461830 00000483 ef49ddcc f34e64b8
> [  481.671641]  c8b58360 ef49dd3c c80851bb 00000009 00000000 ef49dd34 c8b5a13c ef49dd50
> [  481.671716] Call Trace:
> [  481.671731]  [<c842ee92>] dump_stack+0x76/0xb4
> [  481.671745]  [<c80850f5>] __warn+0xe5/0x100
> [  481.671757]  [<c8461830>] ? check_unmap+0x320/0x8e0
> [  481.671769]  [<c8461830>] ? check_unmap+0x320/0x8e0
> [  481.671780]  [<c80851bb>] warn_slowpath_fmt+0x3b/0x40
> [  481.671791]  [<c8461830>] check_unmap+0x320/0x8e0
> [  481.671804]  [<c8462054>] debug_dma_unmap_page+0x84/0xa0
> [  481.671835]  [<f937cd7a>] ath10k_wmi_free_host_mem+0x9a/0xe0 [ath10k_core]
> [  481.671861]  [<f9363400>] ath10k_core_destroy+0x50/0x60 [ath10k_core]
> [  481.671875]  [<f8e13969>] ath10k_pci_remove+0x79/0xa0 [ath10k_pci]
> [  481.671889]  [<c848d8d8>] pci_device_remove+0x38/0xb0
> [  481.671901]  [<c859fe4b>] __device_release_driver+0x7b/0x110
> [  481.671913]  [<c85a00e7>] driver_detach+0x97/0xa0
> [  481.671923]  [<c859ef8b>] bus_remove_driver+0x4b/0xb0
> [  481.671934]  [<c85a0cda>] driver_unregister+0x2a/0x60
> [  481.671949]  [<c848c888>] pci_unregister_driver+0x18/0x70
> [  481.671965]  [<f8e14dae>] ath10k_pci_exit+0xd/0x25f [ath10k_pci]
> [  481.671979]  [<c812bb84>] SyS_delete_module+0xf4/0x180
> [  481.671995]  [<c81f801b>] ? __might_fault+0x8b/0xa0
> [  481.672009]  [<c80037d0>] do_fast_syscall_32+0xa0/0x1e0
> [  481.672025]  [<c88d4c88>] sysenter_past_esp+0x45/0x74
> [  481.672037] ---[ end trace 3fd23759e17e1622 ]---
> [  481.672049] Mapped at:
> [  481.672060]  [  481.672072] [<c846062c>] debug_dma_map_page.part.25+0x1c/0xf0
> [  481.672083]  [  481.672095] [<c8460799>] debug_dma_map_page+0x99/0xc0
> [  481.672106]  [  481.672132] [<f93745ec>] ath10k_wmi_alloc_chunk+0x12c/0x1f0 [ath10k_core]
> [  481.672142]  [  481.672168] [<f937d0c4>] ath10k_wmi_event_service_ready_work+0x304/0x540 [ath10k_core]
> [  481.672178]  [  481.672190] [<c80a3643>] process_one_work+0x1c3/0x670
> [  482.137134] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
> [  482.313144] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:02:00.0.bin failed with error -2
> [  482.313274] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/cal-pci-0000:02:00.0.bin failed with error -2
> [  482.313768] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
> [  482.313777] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 0 testmode 1
> [  482.313974] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
> [  482.369858] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
> [  482.370011] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
> [  483.596770] 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
> [  483.701686] ath: EEPROM regdomain: 0x0
> [  483.701706] ath: EEPROM indicates default country code should be used
> [  483.701713] ath: doing EEPROM country->regdmn map search
> [  483.701721] ath: country maps to regdmn code: 0x3a
> [  483.701730] ath: Country alpha2 being used: US
> [  483.701737] ath: Regpair used: 0x3a
>
> Reported-by: Kalle Valo <kvalo at qca.qualcomm.com>
> Signed-off-by: Ben Greear <greearb at candelatech.com>

Thanks, I don't see the warning anymore so this seems to be fixed. I'll
push this to 4.10.

-- 
Kalle Valo

From chunkeey at googlemail.com  Tue Dec 13 04:41:33 2016
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Tue, 13 Dec 2016 13:41:33 +0100
Subject: [PATCH 1/2] ath10k: add accounting for the extended peer
 statistics
In-Reply-To: <20161207062824.GA3404@atheros-ThinkPad-T61>
References: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
 <20161207062824.GA3404@atheros-ThinkPad-T61>
Message-ID: <2870294.lMmxz9iPmq@debian64>

Hello,

It looks like google put your mail into the spam-can. 
I'm sorry for not answering sooner.

On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Shafi Shajakhan wrote:
> On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote:
> > The 10.4 firmware adds extended peer information to the
> > firmware's statistics payload. This additional info is
> > stored as a separate data field and the elements are
> > stored in their own "peers_extd" list.
> > 
> > These elements can pile up in the same way as the peer
> > information elements. This is because the
> > ath10k_wmi_10_4_op_pull_fw_stats() function tries to
> > pull the same amount (num_peer_stats) for every statistic
> > data unit.
> > 
> > Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
> > Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>
> > ---
> >  drivers/net/wireless/ath/ath10k/debug.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> > index 82a4c67f3672..4acd9eb65910 100644
> > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > @@ -399,6 +399,7 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> >  			 * prevent firmware from DoS-ing the host.
> >  			 */
> >  			ath10k_fw_stats_peers_free(&ar->debug.fw_stats.peers);
> > +			ath10k_fw_extd_stats_peers_free(&ar->debug.fw_stats.peers_extd);
> 
> [shafi] thanks for fixing this !
> 
> >  			ath10k_warn(ar, "dropping fw peer stats\n");
> >  			goto free;
> >  		}
> > @@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> >  			goto free;
> >  		}
> >  
> > +		if (!list_empty(&stats.peers))
> 
> [shafi] sorry please correct me if i am wrong, for 'extended peer stats' we are checking
> for normal 'peer stats' ? Is this the fix intended, i had started a build to
> check your change and we will keep you posted, does this fix displaying
> 'rx_duration' in ath10k fw_stats.
The idea is not to queue any "extended peer stats" when there where no "peer stats" to
begin with. Because otherwise, the function is still vulnerable to OOM since the 
extended peers stats will be queued unchecked (not that this is currently a problem).
 
> > +			list_splice_tail_init(&stats.peers_extd,
> > +					      &ar->debug.fw_stats.peers_extd);
> > +
> >  		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);

Regards,
Christian




From kvalo at qca.qualcomm.com  Tue Dec 13 05:10:53 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Tue, 13 Dec 2016 13:10:53 +0000
Subject: [RFC v2 11/11] ath10k: Added sdio support
In-Reply-To: <1479496971-19174-12-git-send-email-erik.stromdahl@gmail.com>
 (Erik Stromdahl's message of "Fri, 18 Nov 2016 20:22:51 +0100")
References: <1479496971-19174-1-git-send-email-erik.stromdahl@gmail.com>
 <1479496971-19174-12-git-send-email-erik.stromdahl@gmail.com>
Message-ID: <87pokwynxf.fsf@kamboji.qca.qualcomm.com>

Erik Stromdahl <erik.stromdahl at gmail.com> writes:

> Initial HIF sdio/mailbox implementation.
>
> Signed-off-by: Erik Stromdahl <erik.stromdahl at gmail.com>

While testing this I noticed few new warnings:

drivers/net/wireless/ath/ath10k/sdio.c: In function ath10k_sdio_probe:
drivers/net/wireless/ath/ath10k/sdio.c:1723:6: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
drivers/net/wireless/ath/ath10k/sdio.c:375:5: warning: symbol 'ath10k_sdio_mbox_rxmsg_pending_handler' was not declared. Should it be static?
drivers/net/wireless/ath/ath10k/sdio.c:1018:5: warning: symbol 'ath10k_sdio_hif_tx_sg' was not declared. Should it be static?
drivers/net/wireless/ath/ath10k/sdio.c:1415:5: warning: symbol 'ath10k_sdio_hif_exchange_bmi_msg' was not declared. Should it be static?
drivers/net/wireless/ath/ath10k/sdio.c:1555:5: warning: symbol 'ath10k_sdio_hif_map_service_to_pipe' was not declared. Should it be static?
drivers/net/wireless/ath/ath10k/sdio.c:1635:6: warning: symbol 'ath10k_sdio_hif_get_default_pipe' was not declared. Should it be static?
drivers/net/wireless/ath/ath10k/htc.c:265: line over 90 characters
drivers/net/wireless/ath/ath10k/htc.c:355: line over 90 characters

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Tue Dec 13 05:44:44 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Tue, 13 Dec 2016 13:44:44 +0000
Subject: [RFC v2 05/11] ath10k: htc: refactorization
In-Reply-To: <1479496971-19174-6-git-send-email-erik.stromdahl@gmail.com>
 (Erik Stromdahl's message of "Fri, 18 Nov 2016 20:22:45 +0100")
References: <1479496971-19174-1-git-send-email-erik.stromdahl@gmail.com>
 <1479496971-19174-6-git-send-email-erik.stromdahl@gmail.com>
Message-ID: <87inqoymd0.fsf@kamboji.qca.qualcomm.com>

Erik Stromdahl <erik.stromdahl at gmail.com> writes:

> Code refactorization:
>
> Moved the code for ep 0 in ath10k_htc_rx_completion_handler
> to ath10k_htc_control_rx_complete.
>
> This eases the implementation of SDIO/mbox significantly since
> the ep_rx_complete cb is invoked directly from the SDIO/mbox
> hif layer.
>
> Since the ath10k_htc_control_rx_complete already is present
> (only containing a warning message) there is no reason for not
> using it (instead of having a special case for ep 0 in
> ath10k_htc_rx_completion_handler).
>
> Signed-off-by: Erik Stromdahl <erik.stromdahl at gmail.com>

I tested this on QCA988X PCI board just to see if there are any
regressions. It crashes immediately during module load, every time, and
bisected that the crashing starts on this patch:

[ 1239.715325] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[ 1239.885125] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:02:00.0.bin failed with error -2
[ 1239.885260] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/cal-pci-0000:02:00.0.bin failed with error -2
[ 1239.885687] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
[ 1239.885699] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1
[ 1239.885899] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
[ 1239.941836] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
[ 1239.941993] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
[ 1241.136693] BUG: unable to handle kernel NULL pointer dereference at   (null)
[ 1241.136738] IP: [<  (null)>]   (null)
[ 1241.136759] *pdpt = 0000000000000000 *pde = f0002a55f0002a55 [ 1241.136781] 
[ 1241.136793] Oops: 0010 [#1] SMP

What's odd is that when I added some printks on my own and enabled both
boot and htc debug levels it doesn't crash anymore. After everything
works normally after that, I can start AP mode and connect to it. Is it
a race somewhere?

-- 
Kalle Valo

From michal.kazior at tieto.com  Tue Dec 13 05:52:41 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 13 Dec 2016 14:52:41 +0100
Subject: [RFC v2 05/11] ath10k: htc: refactorization
In-Reply-To: <87inqoymd0.fsf@kamboji.qca.qualcomm.com>
References: <1479496971-19174-1-git-send-email-erik.stromdahl@gmail.com>
 <1479496971-19174-6-git-send-email-erik.stromdahl@gmail.com>
 <87inqoymd0.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CA+BoTQkuUFxnra75B4LpF5+k9yE7hkNYDXbtUMBLq2LFuPSasg@mail.gmail.com>

On 13 December 2016 at 14:44, Valo, Kalle <kvalo at qca.qualcomm.com> wrote:
> Erik Stromdahl <erik.stromdahl at gmail.com> writes:
>
>> Code refactorization:
>>
>> Moved the code for ep 0 in ath10k_htc_rx_completion_handler
>> to ath10k_htc_control_rx_complete.
>>
>> This eases the implementation of SDIO/mbox significantly since
>> the ep_rx_complete cb is invoked directly from the SDIO/mbox
>> hif layer.
>>
>> Since the ath10k_htc_control_rx_complete already is present
>> (only containing a warning message) there is no reason for not
>> using it (instead of having a special case for ep 0 in
>> ath10k_htc_rx_completion_handler).
>>
>> Signed-off-by: Erik Stromdahl <erik.stromdahl at gmail.com>
>
> I tested this on QCA988X PCI board just to see if there are any
> regressions. It crashes immediately during module load, every time, and
> bisected that the crashing starts on this patch:
>
> [ 1239.715325] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
> [ 1239.885125] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:02:00.0.bin failed with error -2
> [ 1239.885260] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/cal-pci-0000:02:00.0.bin failed with error -2
> [ 1239.885687] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
> [ 1239.885699] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1
> [ 1239.885899] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
> [ 1239.941836] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
> [ 1239.941993] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
> [ 1241.136693] BUG: unable to handle kernel NULL pointer dereference at   (null)
> [ 1241.136738] IP: [<  (null)>]   (null)
> [ 1241.136759] *pdpt = 0000000000000000 *pde = f0002a55f0002a55 [ 1241.136781]
> [ 1241.136793] Oops: 0010 [#1] SMP
>
> What's odd is that when I added some printks on my own and enabled both
> boot and htc debug levels it doesn't crash anymore. After everything
> works normally after that, I can start AP mode and connect to it. Is it
> a race somewhere?

Yes. htc_wait_target() is called after hif_start(). The ep_rx_complete
is set in htc_wait_target() [changed patch 4, but still too late].

ep_rx_complete must be set prior to calling hif_start(). You probably
crash on end of ath10k_htc_rx_completion_handler() when trying to call
ep->ep_ops.ep_rx_complete(ar, skb).


Micha?


From johannes at sipsolutions.net  Tue Dec 13 08:09:11 2016
From: johannes at sipsolutions.net (Johannes Berg)
Date: Tue, 13 Dec 2016 17:09:11 +0100
Subject: [PATCH 2/4] cfg80211: Add new NL80211_CMD_SET_BTCOEX_PRIORITY
 to support BTCOEX
In-Reply-To: <5e5e8971c96293a81e7cb37bcdfbd593@codeaurora.org>
References: <1478610932-21954-1-git-send-email-c_traja@qti.qualcomm.com>
 <1478610932-21954-3-git-send-email-c_traja@qti.qualcomm.com>
 <1480949353.31788.27.camel@sipsolutions.net>
 <5e5e8971c96293a81e7cb37bcdfbd593@codeaurora.org>
Message-ID: <1481645351.20412.34.camel@sipsolutions.net>


> > > ?/**
> > > + * wiphy_btcoex_support_flags
> > > + *	This enum has the driver supported frame types for
> > > BTCOEX.
> > > + * @WIPHY_WLAN_BE_PREFERRED - Supports Best Effort frame for
> > > BTCOEX
> > > + * @WIPHY_WLAN_BK_PREFERRED - supports Background frame for
> > > BTCOEX
> > > + * @WIPHY_WLAN_VI_PREFERRED - supports Video frame for BTCOEX
> > > + * @WIPHY_WLAN_VO_PREFERRED - supports Voice frame for BTCOEX
> > > + * @WIPHY_WLAN_BEACON_PREFERRED - supports Beacon frame for
> > > BTCOEX
> > > + * @WIPHY_WLAN_MGMT_PREFERRED - supports Management frames for
> > > BTCOEX.
> > > + */
> > 
> > That's not making much sense to me?
> > 
> 
> is it fine to have as WIPHY_BTCOEX_BE_PREFERRED ?

It's not really clear to me what you intend to do this - if it's really
support flags then you really should name those better.

> > > +/**
> > > + * enum wiphy_btcoex_priority - BTCOEX priority level
> > > + *	This enum defines priority level for BTCOEX
> > > + * WIPHY_WLAN_PREFERRED_LOW - low priority frames over BT
> > > traffic
> > > + * WIPHY_WLAN_PREFERRED_HIGH - high priority frames over BT
> > > traffic
> > > + */
> > > +
> > > +enum wiphy_btcoex_priority {
> > > +	WIPHY_WLAN_PREFERRED_LOW = false,
> > > +	WIPHY_WLAN_PREFERRED_HIGH = true,
> > > +};
> > 
> > That false/true seems just strange.
> > 
> 
> I will just use as a enum without assigning false/true.

What do you even need this enum for though?

> > > +enum nl80211_btcoex_priority {
> > > +	__NL80211_WLAN_PREFERRED_INVALID,
> > > +	NL80211_WLAN_BE_PREFERRED,
> > > +	NL80211_WLAN_BK_PREFERRED,
> > > +	NL80211_WLAN_VI_PREFERRED,
> > > +	NL80211_WLAN_VO_PREFERRED,
> > > +	NL80211_WLAN_BEACON_PREFERRED,
> > > +	NL80211_WLAN_MGMT_PREFERRED,
> > > +	__NL80211_WLAN_PREFERRED_LAST,
> > > +	NL80211_WLAN_PREFERRED_MAX =
> > > +			__NL80211_WLAN_PREFERRED_LAST - 1,
> > > +};
> > 
> > Wouldn't a bitmap be easier?
> > 
> since this is to distinguish between different btcoex priorities and
> we?
> are not going to do any manipulations on these parameters.
> It is just used as flag attribute.

But why the (parsing) complexity, when a single bitmap would do?

johannes


From kvalo at qca.qualcomm.com  Tue Dec 13 09:26:18 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Tue, 13 Dec 2016 17:26:18 +0000
Subject: [RFC v2 05/11] ath10k: htc: refactorization
In-Reply-To: <CA+BoTQkuUFxnra75B4LpF5+k9yE7hkNYDXbtUMBLq2LFuPSasg@mail.gmail.com>	(Michal
 Kazior's message of "Tue, 13 Dec 2016 14:52:41 +0100")
References: <1479496971-19174-1-git-send-email-erik.stromdahl@gmail.com>
 <1479496971-19174-6-git-send-email-erik.stromdahl@gmail.com>
 <87inqoymd0.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQkuUFxnra75B4LpF5+k9yE7hkNYDXbtUMBLq2LFuPSasg@mail.gmail.com>
Message-ID: <871sxbzqo6.fsf@kamboji.qca.qualcomm.com>

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

> On 13 December 2016 at 14:44, Valo, Kalle <kvalo at qca.qualcomm.com> wrote:
>> Erik Stromdahl <erik.stromdahl at gmail.com> writes:
>>
>>> Code refactorization:
>>>
>>> Moved the code for ep 0 in ath10k_htc_rx_completion_handler
>>> to ath10k_htc_control_rx_complete.
>>>
>>> This eases the implementation of SDIO/mbox significantly since
>>> the ep_rx_complete cb is invoked directly from the SDIO/mbox
>>> hif layer.
>>>
>>> Since the ath10k_htc_control_rx_complete already is present
>>> (only containing a warning message) there is no reason for not
>>> using it (instead of having a special case for ep 0 in
>>> ath10k_htc_rx_completion_handler).
>>>
>>> Signed-off-by: Erik Stromdahl <erik.stromdahl at gmail.com>
>>
>> I tested this on QCA988X PCI board just to see if there are any
>> regressions. It crashes immediately during module load, every time, and
>> bisected that the crashing starts on this patch:
>>
>> [ 1239.715325] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
>> [ 1239.885125] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:02:00.0.bin failed with error -2
>> [ 1239.885260] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/cal-pci-0000:02:00.0.bin failed with error -2
>> [ 1239.885687] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
>> [ 1239.885699] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1
>> [ 1239.885899] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
>> [ 1239.941836] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
>> [ 1239.941993] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
>> [ 1241.136693] BUG: unable to handle kernel NULL pointer dereference at   (null)
>> [ 1241.136738] IP: [<  (null)>]   (null)
>> [ 1241.136759] *pdpt = 0000000000000000 *pde = f0002a55f0002a55 [ 1241.136781]
>> [ 1241.136793] Oops: 0010 [#1] SMP
>>
>> What's odd is that when I added some printks on my own and enabled both
>> boot and htc debug levels it doesn't crash anymore. After everything
>> works normally after that, I can start AP mode and connect to it. Is it
>> a race somewhere?
>
> Yes. htc_wait_target() is called after hif_start(). The ep_rx_complete
> is set in htc_wait_target() [changed patch 4, but still too late].
>
> ep_rx_complete must be set prior to calling hif_start(). You probably
> crash on end of ath10k_htc_rx_completion_handler() when trying to call
> ep->ep_ops.ep_rx_complete(ar, skb).

Yeah, just checked and ep->ep_ops.ep_rx_complete is NULL at the end of
ath10k_htc_rx_completion_handler().

-- 
Kalle Valo

From erik.stromdahl at gmail.com  Tue Dec 13 10:37:30 2016
From: erik.stromdahl at gmail.com (Erik Stromdahl)
Date: Tue, 13 Dec 2016 19:37:30 +0100
Subject: [RFC v2 05/11] ath10k: htc: refactorization
In-Reply-To: <871sxbzqo6.fsf@kamboji.qca.qualcomm.com>
References: <1479496971-19174-1-git-send-email-erik.stromdahl@gmail.com>
 <1479496971-19174-6-git-send-email-erik.stromdahl@gmail.com>
 <87inqoymd0.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQkuUFxnra75B4LpF5+k9yE7hkNYDXbtUMBLq2LFuPSasg@mail.gmail.com>
 <871sxbzqo6.fsf@kamboji.qca.qualcomm.com>
Message-ID: <70b8a055-e6ba-857d-8b03-06f50e3f10fe@gmail.com>



On 12/13/2016 06:26 PM, Valo, Kalle wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
> 
>> On 13 December 2016 at 14:44, Valo, Kalle <kvalo at qca.qualcomm.com> wrote:
>>> Erik Stromdahl <erik.stromdahl at gmail.com> writes:
>>>
>>>> Code refactorization:
>>>>
>>>> Moved the code for ep 0 in ath10k_htc_rx_completion_handler
>>>> to ath10k_htc_control_rx_complete.
>>>>
>>>> This eases the implementation of SDIO/mbox significantly since
>>>> the ep_rx_complete cb is invoked directly from the SDIO/mbox
>>>> hif layer.
>>>>
>>>> Since the ath10k_htc_control_rx_complete already is present
>>>> (only containing a warning message) there is no reason for not
>>>> using it (instead of having a special case for ep 0 in
>>>> ath10k_htc_rx_completion_handler).
>>>>
>>>> Signed-off-by: Erik Stromdahl <erik.stromdahl at gmail.com>
>>>
>>> I tested this on QCA988X PCI board just to see if there are any
>>> regressions. It crashes immediately during module load, every time, and
>>> bisected that the crashing starts on this patch:
>>>
>>> [ 1239.715325] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
>>> [ 1239.885125] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:02:00.0.bin failed with error -2
>>> [ 1239.885260] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/cal-pci-0000:02:00.0.bin failed with error -2
>>> [ 1239.885687] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
>>> [ 1239.885699] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1
>>> [ 1239.885899] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
>>> [ 1239.941836] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
>>> [ 1239.941993] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
>>> [ 1241.136693] BUG: unable to handle kernel NULL pointer dereference at   (null)
>>> [ 1241.136738] IP: [<  (null)>]   (null)
>>> [ 1241.136759] *pdpt = 0000000000000000 *pde = f0002a55f0002a55 [ 1241.136781]
>>> [ 1241.136793] Oops: 0010 [#1] SMP
>>>
>>> What's odd is that when I added some printks on my own and enabled both
>>> boot and htc debug levels it doesn't crash anymore. After everything
>>> works normally after that, I can start AP mode and connect to it. Is it
>>> a race somewhere?
>>
>> Yes. htc_wait_target() is called after hif_start(). The ep_rx_complete
>> is set in htc_wait_target() [changed patch 4, but still too late].
>>
>> ep_rx_complete must be set prior to calling hif_start(). You probably
>> crash on end of ath10k_htc_rx_completion_handler() when trying to call
>> ep->ep_ops.ep_rx_complete(ar, skb).
> 
> Yeah, just checked and ep->ep_ops.ep_rx_complete is NULL at the end of
> ath10k_htc_rx_completion_handler().
> 
It is indeed correct as Michal points out, there is a risk that the
first HTC control message (typically an HTC ready message) is received
before the HTC control endpoint is connected.

I have experienced a similar race with my SDIO implementation as well.
In this case I did solve the issue by enabling HIF target interrupts
after the HTC control endpoint was connected. I am not sure however if
this is the most elegant way to solve this problem.

My SDIO target won't send the HTC ready message before this is done.
The fix essentially consists of moving the ..._irg_enable call from
hif_start into another hif op.

I have made a few updates since I submitted the original RFC and created
a repo on github:

https://github.com/erstrom/linux-ath

I have a bunch of branches that are all based on the tags on the ath master.

As of this moment the latest version is:

ath-201612131156-ath10k-sdio

This branch contains the original RFC patches plus some addons/fixes.

In the above mentioned branch there are a few commits related to this
race condition. Perhaps you can have a look at them?

The commits are:
821672913328cf737c9616786dc28d2e4e8a4a90
dd7fcf0a1f78e68876d14f90c12bd37f3a700ad7
7434b7b40875bd08a3a48a437ba50afed7754931

Perhaps this approach can work with PCIe as well?

/Erik


From bmorgan at cococorp.com  Tue Dec 13 10:42:27 2016
From: bmorgan at cococorp.com (Benjamin Morgan)
Date: Tue, 13 Dec 2016 10:42:27 -0800
Subject: ath10k firmware crashes in mesh mode on QCA9880
In-Reply-To: <58472E7B.7090603@cococorp.com>
References: <583DD564.8040704@cococorp.com>
 <20161201070908.GB11953@atheros-ThinkPad-T61> <58421FA2.2020004@cococorp.com>
 <20161203124358.GB31861@atheros-ThinkPad-T61>
 <20161203124600.GC31861@atheros-ThinkPad-T61> <5845B325.6060002@cococorp.com>
 <d8eb0ba5828d43dd83030247ba443b88@aphydexm01f.ap.qualcomm.com>
 <58472E7B.7090603@cococorp.com>
Message-ID: <58504113.2080702@cococorp.com>

Just tested the latest 10.2.4.70.59-2 firmware and it still crashes with 
wpa_supplicant encrypted mesh =(

[   85.201440] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 
b7f44483-0488-46af-8dff-db88f4b56327)
[   85.210573] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c 
chip_id 0x043202ff sub 0000:0000
[   85.219940] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1 
tracing 0 dfs 1 testmode 1
[   85.233034] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.59-2 api 
5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
[   85.245177] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A 
crc32 bebc7c08
[   85.252592] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 
cal file max-sta 128 raw 0 hwcrypto 1
[   85.264235] ath10k_pci 0000:01:00.0: firmware register dump:
[   85.269992] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 
0x009A45AF 0x00955B31
[   85.278031] ath10k_pci 0000:01:00.0: [04]: 0x009A45AF 0x00060130 
0x00000002 0x00439E98
[   85.286078] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074 
0x00407120 0x004436CC
[   85.294107] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000 
0x009A3550 0x009A355E
[   85.302152] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D 
0x00000000 0x00000000
[   85.310195] ath10k_pci 0000:01:00.0: [20]: 0x409A45AF 0x0040AAC4 
0x0040AC60 0x0040AC09
[   85.318239] ath10k_pci 0000:01:00.0: [24]: 0x809A44F2 0x0040AB24 
0x00400000 0xC09A45AF
[   85.326282] ath10k_pci 0000:01:00.0: [28]: 0x809A3A16 0x0040AB84 
0x0044110C 0x00442074
[   85.334314] ath10k_pci 0000:01:00.0: [32]: 0x809A601A 0x0040ABB4 
0x0044110C 0x00407120
[   85.342350] ath10k_pci 0000:01:00.0: [36]: 0x809A2EA4 0x0040ABF4 
0x0040AC14 0x00001580
[   85.350393] ath10k_pci 0000:01:00.0: [40]: 0x80990F63 0x0040AD04 
0x009C6458 0x004436CC
[   85.358437] ath10k_pci 0000:01:00.0: [44]: 0x80998520 0x0040AD64 
0x004208FC 0x00439E4C
[   85.366479] ath10k_pci 0000:01:00.0: [48]: 0x8099AEA5 0x0040AD84 
0x004208FC 0x00425AAC
[   85.374512] ath10k_pci 0000:01:00.0: [52]: 0x809BFC39 0x0040AEE4 
0x00424FE8 0x00000002
[   85.382548] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14 
0x00000004 0x004039D0
[   85.487067] ieee80211 phy0: Hardware restart was requested
[   85.492701] ath10k_pci 0000:01:00.0: wmi disable pktlog

Any new leads on tracking down this issue?

~Benjamin


On 12/06/2016 01:32 PM, Benjamin Morgan wrote:
> 1. Yes, this appears to happens every time a unicast packet with 
> wpa_supplicant encryption in VHT80 mode is received. I haven't seen a 
> successful ping-pong pair.
> 2. We tried with 10.2.4.70.42-2 firmware and still saw crashes.
> 3. We ran our experiment again with extra debugging turned on.
>     Node A: 18:A6:F7:23:6E:66 | 10.230.5.41
>     Node B: 18:A6:F7:26:0F:21 | 10.230.5.42
>     The ping command we used was run on Node A was 'ping -s 1500 -i 
> 0.1 10.230.5.42'
>     Here is the dmesg log from Node B.
>
> [ 5413.478170] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5413.503954] ath10k_pci 0000:01:00.0: scan event bss channel type 4 
> reason 3 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running (2)
> [ 5413.503985] ath10k_pci 0000:01:00.0: chan info err_code 0 freq 5825 
> cmd_flags 1 noise_floor -105 rx_clear_count 7692807 cycle_count 312271423
> [ 5413.504029] ath10k_pci 0000:01:00.0: scan event completed type 2 
> reason 0 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running (2)
> [ 5413.525868] ath10k_pci 0000:01:00.0: wmi vdev install key idx 1 
> cipher 4 len 16
> [ 5413.526014] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31 
> value 1
> [ 5413.526193] ath10k_pci 0000:01:00.0: mac vdev 0 set keyidx 1
> [ 5413.526216] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31 
> value 1
> [ 5413.526532] ath10k_pci 0000:01:00.0: mac chanctx add freq 5180 
> width 3 ptr 86db29b0
> [ 5413.526556] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0 
> needed? 0 allowed? 1
> [ 5413.526574] ath10k_pci 0000:01:00.0: mac chanctx assign ptr 
> 86db29b0 vdev_id 0
> [ 5413.526592] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq 
> 5180 phymode 11ac-vht80
> [ 5413.526616] ath10k_pci 0000:01:00.0: wmi vdev start id 0x0 flags: 
> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
> [ 5413.533099] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
> [ 5413.533148] ath10k_pci 0000:01:00.0: mac vdev_id 0 txpower 23
> [ 5413.533163] ath10k_pci 0000:01:00.0: mac txpower 23
> [ 5413.533180] ath10k_pci 0000:01:00.0: wmi pdev set param 3 value 46
> [ 5413.533247] ath10k_pci 0000:01:00.0: wmi pdev set param 4 value 46
> [ 5413.533295] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180 
> width 3 ptr 86db29b0 changed 10
> [ 5413.533318] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180 
> width 3 ptr 86db29b0 changed 2
> [ 5413.533337] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0 
> needed? 1 allowed? 1
> [ 5413.533357] ath10k_pci 0000:01:00.0: WMI vdev create: id 1 type 4 
> subtype 0 macaddr 18:a6:f7:26:0f:21
> [ 5413.533412] ath10k_pci 0000:01:00.0: mac monitor vdev 1 created
> [ 5413.533463] ath10k_pci 0000:01:00.0: wmi vdev start id 0x1 flags: 
> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
> [ 5413.937652] ath10k_pci 0000:01:00.0: wmi event debug mesg len 152
> [ 5413.978273] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5414.478363] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5414.527015] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
> [ 5414.527067] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x1 assoc 
> id 0 bssid 18:a6:f7:26:0f:21
> [ 5414.527121] ath10k_pci 0000:01:00.0: mac monitor vdev 1 started
> [ 5414.527165] ath10k_pci 0000:01:00.0: mac monitor started
> [ 5414.527216] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 3 
> value 1000
> [ 5414.527262] ath10k_pci 0000:01:00.0: mac vdev 0 beacon_interval 1000
> [ 5414.527278] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
> staggered
> [ 5414.527294] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 5414.527314] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 5414.527330] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
> value 2
> [ 5414.527457] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x0 assoc 
> id 0 bssid 00:00:00:00:00:00
> [ 5414.527501] ath10k_pci 0000:01:00.0: mac vdev 0 up
> [ 5414.527564] ath10k_pci 0000:01:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
> [ 5414.541090] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1 
> needed? 1 allowed? 1
> [ 5414.978454] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5415.478548] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5415.978649] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5416.445280] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1 
> needed? 1 allowed? 1
> [ 5416.478761] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5416.978879] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5417.478985] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5417.979081] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5418.479190] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5418.979301] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5419.479403] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5419.979551] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5420.479643] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5420.979746] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5421.479841] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5421.979940] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5422.480288] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5422.980386] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5423.480490] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5423.980600] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5424.480702] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5424.971969] ath10k_pci 0000:01:00.0: mac vdev 0 peer create 
> 18:a6:f7:23:6e:66 (new sta) sta 1 / 128 peer 2 / 144
> [ 5424.972000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0 
> peer_addr 18:a6:f7:23:6e:66
> [ 5424.975107] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
> staggered
> [ 5424.975134] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 5424.975219] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 5424.975238] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
> value 2
> [ 5424.980787] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5425.204468] ath10k_pci 0000:01:00.0: mac sta 18:a6:f7:23:6e:66 
> associated
> [ 5425.204531] ath10k_pci 0000:01:00.0: mac ht peer 18:a6:f7:23:6e:66 
> mcs cnt 24 nss 3
> [ 5425.204548] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66 qos 1
> [ 5425.204563] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66 
> phymode 11na-ht40
> [ 5425.204585] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr 
> 18:a6:f7:23:6e:66 (new)
> [ 5425.204614] ath10k_pci 0000:01:00.0: wmi vdev 0 peer 
> 0x18:a6:f7:23:6e:66 set param 1 value 0
> [ 5425.205376] ath10k_pci 0000:01:00.0: received event id 36891 not 
> implemented
> [ 5425.209240] ath10k_pci 0000:01:00.0: wmi vdev install key idx 0 
> cipher 4 len 16
> [ 5425.209655] ath10k_pci 0000:01:00.0: wmi vdev install key idx 1 
> cipher 4 len 16
> [ 5425.209848] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31 
> value 1
> [ 5425.210196] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
> staggered
> [ 5425.210221] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 5425.210296] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 5425.210315] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
> value 2
> [ 5425.480863] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5425.938619] ath10k_pci 0000:01:00.0: wmi event debug mesg len 100
> [ 5425.980946] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5425.995007] ath10k_pci 0000:01:00.0: mac sta rc update for 
> 18:a6:f7:23:6e:66 changed 00000001 bw 2 nss 3 smps 1
> [ 5425.995060] ath10k_pci 0000:01:00.0: mac update sta 
> 18:a6:f7:23:6e:66 peer bw 2
> [ 5425.995081] ath10k_pci 0000:01:00.0: wmi vdev 0 peer 
> 0x18:a6:f7:23:6e:66 set param 4 value 2
> [ 5426.481030] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5426.981117] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5427.481206] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5427.981294] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5428.481628] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5428.981718] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5429.481812] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5429.981894] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5430.481985] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5430.982073] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5431.482174] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5431.982505] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5432.482597] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5432.982679] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5433.482765] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5433.982857] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5434.482946] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5434.983008] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5435.483100] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5435.983181] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5436.483276] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5436.983366] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5437.483445] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5437.983516] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5438.483607] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5438.983692] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5439.439875] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 
> db76b67c-ca98-4519-a762-4ff4edb45526)
> [ 5439.449007] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 
> 0x4100016c chip_id 0x043202ff sub 0000:0000
> [ 5439.458378] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1 
> tracing 0 dfs 1 testmode 1
> [ 5439.471460] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api 
> 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> [ 5439.481844] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A 
> crc32 bebc7c08
> [ 5439.489267] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 
> cal file max-sta 128 raw 0 hwcrypto 1
> [ 5439.500918] ath10k_pci 0000:01:00.0: firmware register dump:
> [ 5439.506678] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 
> 0x009A4577 0x00955B31
> [ 5439.514706] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130 
> 0x00000002 0x00439E98
> [ 5439.522751] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074 
> 0x00407120 0x004436CC
> [ 5439.530794] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000 
> 0x009A3518 0x009A3526
> [ 5439.538834] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D 
> 0x00000000 0x00000000
> [ 5439.546871] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4 
> 0x0040AC60 0x0040AC09
> [ 5439.554915] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24 
> 0x00400000 0xC09A4577
> [ 5439.562948] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84 
> 0x0044110C 0x00442074
> [ 5439.570992] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4 
> 0x0044110C 0x00407120
> [ 5439.579032] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4 
> 0x0040AC14 0x00001580
> [ 5439.587070] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04 
> 0x009C643C 0x004436CC
> [ 5439.595113] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64 
> 0x004208FC 0x00439E4C
> [ 5439.603146] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84 
> 0x004208FC 0x00425E00
> [ 5439.611191] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4 
> 0x00424FE8 0x00000002
> [ 5439.619230] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14 
> 0x00000004 0x004039D0
> [ 5439.726818] ieee80211 phy0: Hardware restart was requested
> [ 5439.732433] ath10k_pci 0000:01:00.0: wmi mgmt vdev down id 0x1
> [ 5439.732461] ath10k_pci 0000:01:00.0: wmi vdev stop id 0x1
> [ 5439.732482] ath10k_pci 0000:01:00.0: failed to synchronize monitor 
> vdev 1 stop: -143
> [ 5439.740370] ath10k_pci 0000:01:00.0: mac monitor vdev 1 stopped
> [ 5439.740386] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
> [ 5439.747042] ath10k_pci 0000:01:00.0: wmi disable pktlog
>
> We noticed in this log that when the radio starts up it says that it 
> is in VHT80 mode:
> [ 5413.526592] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq 
> 5180 phymode 11ac-vht80
>
> But when a peer connects it seems to think the peer is in HT40 mode:
> [ 5425.204563] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66 
> phymode 11na-ht40
>
> Compared to no encryption case - this log was taken from Node A:
>
> [   24.874253] ath10k_pci 0000:01:00.0: mac chanctx add freq 5180 
> width 3 ptr 86d26db0
> [   24.874278] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0 
> needed? 0 allowed? 1
> [   24.874296] ath10k_pci 0000:01:00.0: mac chanctx assign ptr 
> 86d26db0 vdev_id 0
> [   24.874312] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq 
> 5180 phymode 11ac-vht80
> [   24.874337] ath10k_pci 0000:01:00.0: wmi vdev start id 0x0 flags: 
> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
> [   24.881335] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
> [   24.881423] ath10k_pci 0000:01:00.0: mac vdev_id 0 txpower 23
> [   24.881438] ath10k_pci 0000:01:00.0: mac txpower 23
> [   24.881454] ath10k_pci 0000:01:00.0: wmi pdev set param 3 value 46
> [   24.881491] ath10k_pci 0000:01:00.0: wmi pdev set param 4 value 46
> [   24.881515] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180 
> width 3 ptr 86d26db0 changed 10
> [   24.881535] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180 
> width 3 ptr 86d26db0 changed 2
> [   24.881554] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0 
> needed? 1 allowed? 1
> [   24.881574] ath10k_pci 0000:01:00.0: WMI vdev create: id 1 type 4 
> subtype 0 macaddr 18:a6:f7:23:6e:66
> [   24.881689] ath10k_pci 0000:01:00.0: mac monitor vdev 1 created
> [   24.881745] ath10k_pci 0000:01:00.0: wmi vdev start id 0x1 flags: 
> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
> [   25.273460] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [   25.730570] ath10k_pci 0000:01:00.0: wmi event debug mesg len 300
> [   25.773566] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [   25.874556] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
> [   25.879992] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x1 assoc 
> id 0 bssid 18:a6:f7:23:6e:66
> [   25.880077] ath10k_pci 0000:01:00.0: mac monitor vdev 1 started
> [   25.880093] ath10k_pci 0000:01:00.0: mac monitor started
> [   25.880139] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 3 
> value 1000
> [   25.880184] ath10k_pci 0000:01:00.0: mac vdev 0 beacon_interval 1000
> [   25.880199] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
> staggered
> [   25.880215] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [   25.880235] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [   25.880250] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
> value 2
> [   25.880988] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x0 assoc 
> id 0 bssid 00:00:00:00:00:00
> [   25.881035] ath10k_pci 0000:01:00.0: mac vdev 0 up
> [   25.881097] ath10k_pci 0000:01:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
> [   25.882968] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [   25.928796] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
> staggered
> [   25.928821] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [   25.928866] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [   25.928883] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
> value 2
> [   25.929020] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1 
> needed? 1 allowed? 1
> [   25.941886] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
> staggered
> [   25.941911] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [   25.941955] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [   25.941972] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
> value 2
> [   25.953727] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
> staggered
> [   25.953753] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [   25.953798] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [   25.953817] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
> value 2
> [   25.970588] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
> staggered
> [   25.970614] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [   25.970659] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [   25.970676] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
> value 2
> [   25.989056] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
> staggered
> [   25.989081] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [   25.989126] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [   25.989143] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
> value 2
> [   26.071686] ath10k_pci 0000:01:00.0: mac vdev 0 peer create 
> 18:a6:f7:26:0f:21 (new sta) sta 1 / 128 peer 2 / 144
> [   26.071712] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0 
> peer_addr 18:a6:f7:26:0f:21
> [   26.071952] ath10k_pci 0000:01:00.0: mac sta 18:a6:f7:26:0f:21 
> associated
> [   26.071981] ath10k_pci 0000:01:00.0: mac ht peer 18:a6:f7:26:0f:21 
> mcs cnt 24 nss 3
> [   26.071999] ath10k_pci 0000:01:00.0: mac vht peer 18:a6:f7:26:0f:21 
> max_mpdu 1048575 flags 0x601b001
> [   26.072013] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:26:0f:21 qos 1
> [   26.072028] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:26:0f:21 
> phymode 11ac-vht80
> [   26.072047] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr 
> 18:a6:f7:26:0f:21 (new)
> [   26.072071] ath10k_pci 0000:01:00.0: wmi vdev 0 peer 
> 0x18:a6:f7:26:0f:21 set param 1 value 0
> [   26.072502] ath10k_pci 0000:01:00.0: received event id 36891 not 
> implemented
> [   26.074194] ath10k_pci 0000:01:00.0: mac sta rc update for 
> 18:a6:f7:26:0f:21 changed 00000000 bw 2 nss 3 smps 1
> [   26.074586] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
> staggered
> [   26.074609] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [   26.074682] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [   26.074701] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
> value 2
> [   26.074760] ath10k_pci 0000:01:00.0: mac vdev 0 slot_time 2
> [   26.074779] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 7 
> value 2
> [   26.273652] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [   26.730650] ath10k_pci 0000:01:00.0: wmi event debug mesg len 44
> [   26.773733] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [   27.135445] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1 
> needed? 1 allowed? 1
> [   27.273810] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>
> It seems to start up in VHT80 mode and when it peers with Node B it 
> thinks Node B is also in VHT80 mode and ping works.
>
> 4. Beacons are sent at 6 Mb/s basic rate and unicast QoS Data is sent 
> with three spatial streams. Attached is the full pcap of the experiment.
>
> Thank you for looking into this!
>
> ~Benjamin
>
> On 12/05/2016 11:24 AM, Nagarajan, Ashok Raj wrote:
>> 0x009A4577 0x00955B31
>>
>> Benjamin, Thanks for the logs.
>> Quick questions to further debug the issue here,
>>
>> 1. Is this issue seen every time you start sending data traffic?
>> 2. Issue seen with older firmwares? (FYR, 
>> http://linuxwireless.org/en/users/Drivers/ath10k/firmware/ )
>> 3. Could you please share the dmesg from your device after enabling 
>> MAC and WMI logs in ath10k driver
>>     To enable debug logs please see 
>> http://linuxwireless.org/en/users/Drivers/ath10k/debug/
>> 4. Do you know what is the Number of Spatial Streams seen in mesh 
>> beacons and in mesh data packet?
>>
>> Thanks,
>> Ashok
>



From michal.kazior at tieto.com  Tue Dec 13 11:21:53 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 13 Dec 2016 20:21:53 +0100
Subject: [RFC v2 05/11] ath10k: htc: refactorization
In-Reply-To: <70b8a055-e6ba-857d-8b03-06f50e3f10fe@gmail.com>
References: <1479496971-19174-1-git-send-email-erik.stromdahl@gmail.com>
 <1479496971-19174-6-git-send-email-erik.stromdahl@gmail.com>
 <87inqoymd0.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQkuUFxnra75B4LpF5+k9yE7hkNYDXbtUMBLq2LFuPSasg@mail.gmail.com>
 <871sxbzqo6.fsf@kamboji.qca.qualcomm.com>
 <70b8a055-e6ba-857d-8b03-06f50e3f10fe@gmail.com>
Message-ID: <CA+BoTQmRV59imnmSykjs=ym0qut9akUHzFKfAMioK=MT8my98A@mail.gmail.com>

On 13 December 2016 at 19:37, Erik Stromdahl <erik.stromdahl at gmail.com> wrote:
>
>
> On 12/13/2016 06:26 PM, Valo, Kalle wrote:
>> Michal Kazior <michal.kazior at tieto.com> writes:
>>
>>> On 13 December 2016 at 14:44, Valo, Kalle <kvalo at qca.qualcomm.com> wrote:
>>>> Erik Stromdahl <erik.stromdahl at gmail.com> writes:
>>>>
>>>>> Code refactorization:
>>>>>
>>>>> Moved the code for ep 0 in ath10k_htc_rx_completion_handler
>>>>> to ath10k_htc_control_rx_complete.
>>>>>
>>>>> This eases the implementation of SDIO/mbox significantly since
>>>>> the ep_rx_complete cb is invoked directly from the SDIO/mbox
>>>>> hif layer.
>>>>>
>>>>> Since the ath10k_htc_control_rx_complete already is present
>>>>> (only containing a warning message) there is no reason for not
>>>>> using it (instead of having a special case for ep 0 in
>>>>> ath10k_htc_rx_completion_handler).
>>>>>
>>>>> Signed-off-by: Erik Stromdahl <erik.stromdahl at gmail.com>
>>>>
>>>> I tested this on QCA988X PCI board just to see if there are any
>>>> regressions. It crashes immediately during module load, every time, and
>>>> bisected that the crashing starts on this patch:
>>>>
>>>> [ 1239.715325] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
>>>> [ 1239.885125] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:02:00.0.bin failed with error -2
>>>> [ 1239.885260] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/cal-pci-0000:02:00.0.bin failed with error -2
>>>> [ 1239.885687] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
>>>> [ 1239.885699] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1
>>>> [ 1239.885899] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
>>>> [ 1239.941836] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
>>>> [ 1239.941993] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
>>>> [ 1241.136693] BUG: unable to handle kernel NULL pointer dereference at   (null)
>>>> [ 1241.136738] IP: [<  (null)>]   (null)
>>>> [ 1241.136759] *pdpt = 0000000000000000 *pde = f0002a55f0002a55 [ 1241.136781]
>>>> [ 1241.136793] Oops: 0010 [#1] SMP
>>>>
>>>> What's odd is that when I added some printks on my own and enabled both
>>>> boot and htc debug levels it doesn't crash anymore. After everything
>>>> works normally after that, I can start AP mode and connect to it. Is it
>>>> a race somewhere?
>>>
>>> Yes. htc_wait_target() is called after hif_start(). The ep_rx_complete
>>> is set in htc_wait_target() [changed patch 4, but still too late].
>>>
>>> ep_rx_complete must be set prior to calling hif_start(). You probably
>>> crash on end of ath10k_htc_rx_completion_handler() when trying to call
>>> ep->ep_ops.ep_rx_complete(ar, skb).
>>
>> Yeah, just checked and ep->ep_ops.ep_rx_complete is NULL at the end of
>> ath10k_htc_rx_completion_handler().
>>
> It is indeed correct as Michal points out, there is a risk that the
> first HTC control message (typically an HTC ready message) is received
> before the HTC control endpoint is connected.
>
> I have experienced a similar race with my SDIO implementation as well.
> In this case I did solve the issue by enabling HIF target interrupts
> after the HTC control endpoint was connected. I am not sure however if
> this is the most elegant way to solve this problem.
>
> My SDIO target won't send the HTC ready message before this is done.
> The fix essentially consists of moving the ..._irg_enable call from
> hif_start into another hif op.

It makes more sense to move ep_rx_complete setup/assignment before
hif_start(). This assignment should be done very early as there is
nothing to change/override for this endpoint during operation, is
there? It's known what it needs to store very early on.


> I have made a few updates since I submitted the original RFC and created
> a repo on github:
>
> https://github.com/erstrom/linux-ath
>
> I have a bunch of branches that are all based on the tags on the ath master.
>
> As of this moment the latest version is:
>
> ath-201612131156-ath10k-sdio
>
> This branch contains the original RFC patches plus some addons/fixes.
>
> In the above mentioned branch there are a few commits related to this
> race condition. Perhaps you can have a look at them?
>
> The commits are:
> 821672913328cf737c9616786dc28d2e4e8a4a90

I would avoid if(bus==xx) checks.


> dd7fcf0a1f78e68876d14f90c12bd37f3a700ad7
> 7434b7b40875bd08a3a48a437ba50afed7754931
>
> Perhaps this approach can work with PCIe as well?

I think I did contemplate the unmask/start distinction at some point
but I didn't go with it for some reason I can't recall now.


Micha?


From ryanhsu at qca.qualcomm.com  Tue Dec 13 14:55:19 2016
From: ryanhsu at qca.qualcomm.com (ryanhsu at qca.qualcomm.com)
Date: Tue, 13 Dec 2016 14:55:19 -0800
Subject: [PATCH V2] ath10k: fix incorrect txpower set by P2P_DEVICE interface
Message-ID: <1481669719-3423-1-git-send-email-ryanhsu@qca.qualcomm.com>

From: Ryan Hsu <ryanhsu at qca.qualcomm.com>

Ath10k reports the phy capability that supports P2P_DEVICE interface.

When we use the P2P supported wpa_supplicant to start connection, it'll
create two interfaces, one is wlan0 (vdev_id=0) and one is P2P_DEVICE
p2p-dev-wlan0 which is for p2p control channel (vdev_id=1).

	ath10k_pci mac vdev create 0 (add interface) type 2 subtype 0
	ath10k_add_interface: vdev_id: 0, txpower: 0, bss_power: 0
	...
	ath10k_pci mac vdev create 1 (add interface) type 2 subtype 1
	ath10k_add_interface: vdev_id: 1, txpower: 0, bss_power: 0

And the txpower in per vif bss_conf will only be set to valid tx power when
the interface is assigned with channel_ctx.

But this P2P_DEVICE interface will never be used for any connection, so
that the uninitialized bss_conf.txpower=0 is assinged to the
arvif->txpower when interface created.

Since the txpower configuration is firmware per physical interface.
So the smallest txpower of all vifs will be the one limit the tx power
of the physical device, that causing the low txpower issue on other
active interfaces.

	wlan0: Limiting TX power to 21 (24 - 3) dBm
	ath10k_pci mac vdev_id 0 txpower 21
	ath10k_mac_txpower_recalc: vdev_id: 1, txpower: 0
	ath10k_mac_txpower_recalc: vdev_id: 0, txpower: 21
	ath10k_pci mac txpower 0

This issue only happens when we use the wpa_supplicant that supports
P2P or if we use the iw tool to create the control P2P_DEVICE interface.

Signed-off-by: Ryan Hsu <ryanhsu at qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index fe42bf5..6e1550b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4671,7 +4671,8 @@ static int ath10k_mac_txpower_recalc(struct ath10k *ar)
 	lockdep_assert_held(&ar->conf_mutex);
 
 	list_for_each_entry(arvif, &ar->arvifs, list) {
-		WARN_ON(arvif->txpower < 0);
+		if (arvif->txpower <= 0)
+			continue;
 
 		if (txpower == -1)
 			txpower = arvif->txpower;
@@ -4679,8 +4680,8 @@ static int ath10k_mac_txpower_recalc(struct ath10k *ar)
 			txpower = min(txpower, arvif->txpower);
 	}
 
-	if (WARN_ON(txpower == -1))
-		return -EINVAL;
+	if (txpower == -1)
+		return 0;
 
 	ret = ath10k_mac_txpower_setup(ar, txpower);
 	if (ret) {
-- 
1.9.1



From bmorgan at cococorp.com  Tue Dec 13 15:24:13 2016
From: bmorgan at cococorp.com (Benjamin Morgan)
Date: Tue, 13 Dec 2016 15:24:13 -0800
Subject: ath10k firmware crashes in mesh mode on QCA9880
In-Reply-To: <58504113.2080702@cococorp.com>
References: <583DD564.8040704@cococorp.com>
 <20161201070908.GB11953@atheros-ThinkPad-T61> <58421FA2.2020004@cococorp.com>
 <20161203124358.GB31861@atheros-ThinkPad-T61>
 <20161203124600.GC31861@atheros-ThinkPad-T61> <5845B325.6060002@cococorp.com>
 <d8eb0ba5828d43dd83030247ba443b88@aphydexm01f.ap.qualcomm.com>
 <58472E7B.7090603@cococorp.com> <58504113.2080702@cococorp.com>
Message-ID: <5850831D.7020206@cococorp.com>

Tested the 10.2.4.70.59-2 firmware and wpa_supplicant running WITHOUT 
encryption and it still crashes. I suspect this means wpa_supplicant is 
setting up the interface incorrectly and/or transmitting a malformed 
packet that is causing the driver to crash.

[  162.010206] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 
d30144f6-a8fb-4c0d-bcdf-6ff3b2c37243)
[  162.019322] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c 
chip_id 0x043202ff sub 0000:0000
[  162.028687] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1 
tracing 0 dfs 1 testmode 1
[  162.041764] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.59-2 api 
5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
[  162.053908] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A 
crc32 bebc7c08
[  162.061332] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 
cal file max-sta 128 raw 0 hwcrypto 1
[  162.072975] ath10k_pci 0000:01:00.0: firmware register dump:
[  162.078732] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 
0x009A45AF 0x00955B31
[  162.086771] ath10k_pci 0000:01:00.0: [04]: 0x009A45AF 0x00060130 
0x00000001 0x40000000
[  162.094804] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074 
0x00407120 0x004436CC
[  162.102849] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000 
0x009A3550 0x009A355E
[  162.110892] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D 
0x00000000 0x00000000
[  162.118935] ath10k_pci 0000:01:00.0: [20]: 0x409A45AF 0x0040AAC4 
0x0040AC60 0x0040AC09
[  162.126978] ath10k_pci 0000:01:00.0: [24]: 0x809A44F2 0x0040AB24 
0x00000000 0xC09A45AF
[  162.135011] ath10k_pci 0000:01:00.0: [28]: 0x809A3A16 0x0040AB84 
0x0044110C 0x00442074
[  162.143056] ath10k_pci 0000:01:00.0: [32]: 0x809A601A 0x0040ABB4 
0x0044110C 0x00407120
[  162.151099] ath10k_pci 0000:01:00.0: [36]: 0x809A2EA4 0x0040ABF4 
0x0040AC10 0x00001580
[  162.159142] ath10k_pci 0000:01:00.0: [40]: 0x80990F63 0x0040AD04 
0x009C6458 0x004436CC
[  162.167185] ath10k_pci 0000:01:00.0: [44]: 0x80998520 0x0040AD64 
0x004208FC 0x00439E4C
[  162.175225] ath10k_pci 0000:01:00.0: [48]: 0x8099AEA5 0x0040AD84 
0x004208FC 0x004265C4
[  162.183253] ath10k_pci 0000:01:00.0: [52]: 0x809BFC39 0x0040AEE4 
0x00424FE8 0x00000002
[  162.191298] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14 
0x00000004 0x004039D0
[  162.297229] ieee80211 phy0: Hardware restart was requested
[  162.302880] ath10k_pci 0000:01:00.0: wmi disable pktlog

~Benjamin


On 12/13/2016 10:42 AM, Benjamin Morgan wrote:
> Just tested the latest 10.2.4.70.59-2 firmware and it still crashes 
> with wpa_supplicant encrypted mesh =(
>
> [   85.201440] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 
> b7f44483-0488-46af-8dff-db88f4b56327)
> [   85.210573] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 
> 0x4100016c chip_id 0x043202ff sub 0000:0000
> [   85.219940] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1 
> tracing 0 dfs 1 testmode 1
> [   85.233034] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.59-2 
> api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
> [   85.245177] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A 
> crc32 bebc7c08
> [   85.252592] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 
> cal file max-sta 128 raw 0 hwcrypto 1
> [   85.264235] ath10k_pci 0000:01:00.0: firmware register dump:
> [   85.269992] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 
> 0x009A45AF 0x00955B31
> [   85.278031] ath10k_pci 0000:01:00.0: [04]: 0x009A45AF 0x00060130 
> 0x00000002 0x00439E98
> [   85.286078] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074 
> 0x00407120 0x004436CC
> [   85.294107] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000 
> 0x009A3550 0x009A355E
> [   85.302152] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D 
> 0x00000000 0x00000000
> [   85.310195] ath10k_pci 0000:01:00.0: [20]: 0x409A45AF 0x0040AAC4 
> 0x0040AC60 0x0040AC09
> [   85.318239] ath10k_pci 0000:01:00.0: [24]: 0x809A44F2 0x0040AB24 
> 0x00400000 0xC09A45AF
> [   85.326282] ath10k_pci 0000:01:00.0: [28]: 0x809A3A16 0x0040AB84 
> 0x0044110C 0x00442074
> [   85.334314] ath10k_pci 0000:01:00.0: [32]: 0x809A601A 0x0040ABB4 
> 0x0044110C 0x00407120
> [   85.342350] ath10k_pci 0000:01:00.0: [36]: 0x809A2EA4 0x0040ABF4 
> 0x0040AC14 0x00001580
> [   85.350393] ath10k_pci 0000:01:00.0: [40]: 0x80990F63 0x0040AD04 
> 0x009C6458 0x004436CC
> [   85.358437] ath10k_pci 0000:01:00.0: [44]: 0x80998520 0x0040AD64 
> 0x004208FC 0x00439E4C
> [   85.366479] ath10k_pci 0000:01:00.0: [48]: 0x8099AEA5 0x0040AD84 
> 0x004208FC 0x00425AAC
> [   85.374512] ath10k_pci 0000:01:00.0: [52]: 0x809BFC39 0x0040AEE4 
> 0x00424FE8 0x00000002
> [   85.382548] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14 
> 0x00000004 0x004039D0
> [   85.487067] ieee80211 phy0: Hardware restart was requested
> [   85.492701] ath10k_pci 0000:01:00.0: wmi disable pktlog
>
> Any new leads on tracking down this issue?
>
> ~Benjamin
>
>
> On 12/06/2016 01:32 PM, Benjamin Morgan wrote:
>> 1. Yes, this appears to happens every time a unicast packet with 
>> wpa_supplicant encryption in VHT80 mode is received. I haven't seen a 
>> successful ping-pong pair.
>> 2. We tried with 10.2.4.70.42-2 firmware and still saw crashes.
>> 3. We ran our experiment again with extra debugging turned on.
>>     Node A: 18:A6:F7:23:6E:66 | 10.230.5.41
>>     Node B: 18:A6:F7:26:0F:21 | 10.230.5.42
>>     The ping command we used was run on Node A was 'ping -s 1500 -i 
>> 0.1 10.230.5.42'
>>     Here is the dmesg log from Node B.
>>
>> [ 5413.478170] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5413.503954] ath10k_pci 0000:01:00.0: scan event bss channel type 4 
>> reason 3 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running 
>> (2)
>> [ 5413.503985] ath10k_pci 0000:01:00.0: chan info err_code 0 freq 
>> 5825 cmd_flags 1 noise_floor -105 rx_clear_count 7692807 cycle_count 
>> 312271423
>> [ 5413.504029] ath10k_pci 0000:01:00.0: scan event completed type 2 
>> reason 0 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running 
>> (2)
>> [ 5413.525868] ath10k_pci 0000:01:00.0: wmi vdev install key idx 1 
>> cipher 4 len 16
>> [ 5413.526014] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31 
>> value 1
>> [ 5413.526193] ath10k_pci 0000:01:00.0: mac vdev 0 set keyidx 1
>> [ 5413.526216] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31 
>> value 1
>> [ 5413.526532] ath10k_pci 0000:01:00.0: mac chanctx add freq 5180 
>> width 3 ptr 86db29b0
>> [ 5413.526556] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0 
>> needed? 0 allowed? 1
>> [ 5413.526574] ath10k_pci 0000:01:00.0: mac chanctx assign ptr 
>> 86db29b0 vdev_id 0
>> [ 5413.526592] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq 
>> 5180 phymode 11ac-vht80
>> [ 5413.526616] ath10k_pci 0000:01:00.0: wmi vdev start id 0x0 flags: 
>> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
>> [ 5413.533099] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
>> [ 5413.533148] ath10k_pci 0000:01:00.0: mac vdev_id 0 txpower 23
>> [ 5413.533163] ath10k_pci 0000:01:00.0: mac txpower 23
>> [ 5413.533180] ath10k_pci 0000:01:00.0: wmi pdev set param 3 value 46
>> [ 5413.533247] ath10k_pci 0000:01:00.0: wmi pdev set param 4 value 46
>> [ 5413.533295] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180 
>> width 3 ptr 86db29b0 changed 10
>> [ 5413.533318] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180 
>> width 3 ptr 86db29b0 changed 2
>> [ 5413.533337] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0 
>> needed? 1 allowed? 1
>> [ 5413.533357] ath10k_pci 0000:01:00.0: WMI vdev create: id 1 type 4 
>> subtype 0 macaddr 18:a6:f7:26:0f:21
>> [ 5413.533412] ath10k_pci 0000:01:00.0: mac monitor vdev 1 created
>> [ 5413.533463] ath10k_pci 0000:01:00.0: wmi vdev start id 0x1 flags: 
>> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
>> [ 5413.937652] ath10k_pci 0000:01:00.0: wmi event debug mesg len 152
>> [ 5413.978273] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5414.478363] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5414.527015] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
>> [ 5414.527067] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x1 assoc 
>> id 0 bssid 18:a6:f7:26:0f:21
>> [ 5414.527121] ath10k_pci 0000:01:00.0: mac monitor vdev 1 started
>> [ 5414.527165] ath10k_pci 0000:01:00.0: mac monitor started
>> [ 5414.527216] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 3 
>> value 1000
>> [ 5414.527262] ath10k_pci 0000:01:00.0: mac vdev 0 beacon_interval 1000
>> [ 5414.527278] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
>> staggered
>> [ 5414.527294] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 5414.527314] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 5414.527330] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
>> value 2
>> [ 5414.527457] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x0 assoc 
>> id 0 bssid 00:00:00:00:00:00
>> [ 5414.527501] ath10k_pci 0000:01:00.0: mac vdev 0 up
>> [ 5414.527564] ath10k_pci 0000:01:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
>> [ 5414.541090] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1 
>> needed? 1 allowed? 1
>> [ 5414.978454] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5415.478548] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5415.978649] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5416.445280] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1 
>> needed? 1 allowed? 1
>> [ 5416.478761] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5416.978879] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5417.478985] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5417.979081] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5418.479190] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5418.979301] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5419.479403] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5419.979551] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5420.479643] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5420.979746] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5421.479841] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5421.979940] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5422.480288] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5422.980386] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5423.480490] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5423.980600] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5424.480702] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5424.971969] ath10k_pci 0000:01:00.0: mac vdev 0 peer create 
>> 18:a6:f7:23:6e:66 (new sta) sta 1 / 128 peer 2 / 144
>> [ 5424.972000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0 
>> peer_addr 18:a6:f7:23:6e:66
>> [ 5424.975107] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
>> staggered
>> [ 5424.975134] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 5424.975219] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 5424.975238] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
>> value 2
>> [ 5424.980787] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5425.204468] ath10k_pci 0000:01:00.0: mac sta 18:a6:f7:23:6e:66 
>> associated
>> [ 5425.204531] ath10k_pci 0000:01:00.0: mac ht peer 18:a6:f7:23:6e:66 
>> mcs cnt 24 nss 3
>> [ 5425.204548] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66 qos 1
>> [ 5425.204563] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66 
>> phymode 11na-ht40
>> [ 5425.204585] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr 
>> 18:a6:f7:23:6e:66 (new)
>> [ 5425.204614] ath10k_pci 0000:01:00.0: wmi vdev 0 peer 
>> 0x18:a6:f7:23:6e:66 set param 1 value 0
>> [ 5425.205376] ath10k_pci 0000:01:00.0: received event id 36891 not 
>> implemented
>> [ 5425.209240] ath10k_pci 0000:01:00.0: wmi vdev install key idx 0 
>> cipher 4 len 16
>> [ 5425.209655] ath10k_pci 0000:01:00.0: wmi vdev install key idx 1 
>> cipher 4 len 16
>> [ 5425.209848] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31 
>> value 1
>> [ 5425.210196] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
>> staggered
>> [ 5425.210221] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 5425.210296] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 5425.210315] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
>> value 2
>> [ 5425.480863] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5425.938619] ath10k_pci 0000:01:00.0: wmi event debug mesg len 100
>> [ 5425.980946] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5425.995007] ath10k_pci 0000:01:00.0: mac sta rc update for 
>> 18:a6:f7:23:6e:66 changed 00000001 bw 2 nss 3 smps 1
>> [ 5425.995060] ath10k_pci 0000:01:00.0: mac update sta 
>> 18:a6:f7:23:6e:66 peer bw 2
>> [ 5425.995081] ath10k_pci 0000:01:00.0: wmi vdev 0 peer 
>> 0x18:a6:f7:23:6e:66 set param 4 value 2
>> [ 5426.481030] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5426.981117] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5427.481206] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5427.981294] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5428.481628] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5428.981718] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5429.481812] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5429.981894] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5430.481985] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5430.982073] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5431.482174] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5431.982505] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5432.482597] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5432.982679] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5433.482765] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5433.982857] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5434.482946] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5434.983008] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5435.483100] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5435.983181] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5436.483276] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5436.983366] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5437.483445] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5437.983516] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5438.483607] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5438.983692] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5439.439875] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 
>> db76b67c-ca98-4519-a762-4ff4edb45526)
>> [ 5439.449007] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 
>> 0x4100016c chip_id 0x043202ff sub 0000:0000
>> [ 5439.458378] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1 
>> tracing 0 dfs 1 testmode 1
>> [ 5439.471460] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api 
>> 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
>> [ 5439.481844] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A 
>> crc32 bebc7c08
>> [ 5439.489267] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 
>> cal file max-sta 128 raw 0 hwcrypto 1
>> [ 5439.500918] ath10k_pci 0000:01:00.0: firmware register dump:
>> [ 5439.506678] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 
>> 0x009A4577 0x00955B31
>> [ 5439.514706] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130 
>> 0x00000002 0x00439E98
>> [ 5439.522751] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074 
>> 0x00407120 0x004436CC
>> [ 5439.530794] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000 
>> 0x009A3518 0x009A3526
>> [ 5439.538834] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D 
>> 0x00000000 0x00000000
>> [ 5439.546871] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4 
>> 0x0040AC60 0x0040AC09
>> [ 5439.554915] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24 
>> 0x00400000 0xC09A4577
>> [ 5439.562948] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84 
>> 0x0044110C 0x00442074
>> [ 5439.570992] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4 
>> 0x0044110C 0x00407120
>> [ 5439.579032] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4 
>> 0x0040AC14 0x00001580
>> [ 5439.587070] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04 
>> 0x009C643C 0x004436CC
>> [ 5439.595113] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64 
>> 0x004208FC 0x00439E4C
>> [ 5439.603146] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84 
>> 0x004208FC 0x00425E00
>> [ 5439.611191] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4 
>> 0x00424FE8 0x00000002
>> [ 5439.619230] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14 
>> 0x00000004 0x004039D0
>> [ 5439.726818] ieee80211 phy0: Hardware restart was requested
>> [ 5439.732433] ath10k_pci 0000:01:00.0: wmi mgmt vdev down id 0x1
>> [ 5439.732461] ath10k_pci 0000:01:00.0: wmi vdev stop id 0x1
>> [ 5439.732482] ath10k_pci 0000:01:00.0: failed to synchronize monitor 
>> vdev 1 stop: -143
>> [ 5439.740370] ath10k_pci 0000:01:00.0: mac monitor vdev 1 stopped
>> [ 5439.740386] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: 
>> -143
>> [ 5439.747042] ath10k_pci 0000:01:00.0: wmi disable pktlog
>>
>> We noticed in this log that when the radio starts up it says that it 
>> is in VHT80 mode:
>> [ 5413.526592] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq 
>> 5180 phymode 11ac-vht80
>>
>> But when a peer connects it seems to think the peer is in HT40 mode:
>> [ 5425.204563] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66 
>> phymode 11na-ht40
>>
>> Compared to no encryption case - this log was taken from Node A:
>>
>> [   24.874253] ath10k_pci 0000:01:00.0: mac chanctx add freq 5180 
>> width 3 ptr 86d26db0
>> [   24.874278] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0 
>> needed? 0 allowed? 1
>> [   24.874296] ath10k_pci 0000:01:00.0: mac chanctx assign ptr 
>> 86d26db0 vdev_id 0
>> [   24.874312] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq 
>> 5180 phymode 11ac-vht80
>> [   24.874337] ath10k_pci 0000:01:00.0: wmi vdev start id 0x0 flags: 
>> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
>> [   24.881335] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
>> [   24.881423] ath10k_pci 0000:01:00.0: mac vdev_id 0 txpower 23
>> [   24.881438] ath10k_pci 0000:01:00.0: mac txpower 23
>> [   24.881454] ath10k_pci 0000:01:00.0: wmi pdev set param 3 value 46
>> [   24.881491] ath10k_pci 0000:01:00.0: wmi pdev set param 4 value 46
>> [   24.881515] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180 
>> width 3 ptr 86d26db0 changed 10
>> [   24.881535] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180 
>> width 3 ptr 86d26db0 changed 2
>> [   24.881554] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0 
>> needed? 1 allowed? 1
>> [   24.881574] ath10k_pci 0000:01:00.0: WMI vdev create: id 1 type 4 
>> subtype 0 macaddr 18:a6:f7:23:6e:66
>> [   24.881689] ath10k_pci 0000:01:00.0: mac monitor vdev 1 created
>> [   24.881745] ath10k_pci 0000:01:00.0: wmi vdev start id 0x1 flags: 
>> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
>> [   25.273460] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [   25.730570] ath10k_pci 0000:01:00.0: wmi event debug mesg len 300
>> [   25.773566] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [   25.874556] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
>> [   25.879992] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x1 assoc 
>> id 0 bssid 18:a6:f7:23:6e:66
>> [   25.880077] ath10k_pci 0000:01:00.0: mac monitor vdev 1 started
>> [   25.880093] ath10k_pci 0000:01:00.0: mac monitor started
>> [   25.880139] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 3 
>> value 1000
>> [   25.880184] ath10k_pci 0000:01:00.0: mac vdev 0 beacon_interval 1000
>> [   25.880199] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
>> staggered
>> [   25.880215] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [   25.880235] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [   25.880250] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
>> value 2
>> [   25.880988] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x0 assoc 
>> id 0 bssid 00:00:00:00:00:00
>> [   25.881035] ath10k_pci 0000:01:00.0: mac vdev 0 up
>> [   25.881097] ath10k_pci 0000:01:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
>> [   25.882968] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
>> [   25.928796] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
>> staggered
>> [   25.928821] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [   25.928866] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [   25.928883] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
>> value 2
>> [   25.929020] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1 
>> needed? 1 allowed? 1
>> [   25.941886] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
>> staggered
>> [   25.941911] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [   25.941955] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [   25.941972] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
>> value 2
>> [   25.953727] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
>> staggered
>> [   25.953753] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [   25.953798] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [   25.953817] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
>> value 2
>> [   25.970588] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
>> staggered
>> [   25.970614] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [   25.970659] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [   25.970676] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
>> value 2
>> [   25.989056] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
>> staggered
>> [   25.989081] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [   25.989126] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [   25.989143] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
>> value 2
>> [   26.071686] ath10k_pci 0000:01:00.0: mac vdev 0 peer create 
>> 18:a6:f7:26:0f:21 (new sta) sta 1 / 128 peer 2 / 144
>> [   26.071712] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0 
>> peer_addr 18:a6:f7:26:0f:21
>> [   26.071952] ath10k_pci 0000:01:00.0: mac sta 18:a6:f7:26:0f:21 
>> associated
>> [   26.071981] ath10k_pci 0000:01:00.0: mac ht peer 18:a6:f7:26:0f:21 
>> mcs cnt 24 nss 3
>> [   26.071999] ath10k_pci 0000:01:00.0: mac vht peer 
>> 18:a6:f7:26:0f:21 max_mpdu 1048575 flags 0x601b001
>> [   26.072013] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:26:0f:21 qos 1
>> [   26.072028] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:26:0f:21 
>> phymode 11ac-vht80
>> [   26.072047] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr 
>> 18:a6:f7:26:0f:21 (new)
>> [   26.072071] ath10k_pci 0000:01:00.0: wmi vdev 0 peer 
>> 0x18:a6:f7:26:0f:21 set param 1 value 0
>> [   26.072502] ath10k_pci 0000:01:00.0: received event id 36891 not 
>> implemented
>> [   26.074194] ath10k_pci 0000:01:00.0: mac sta rc update for 
>> 18:a6:f7:26:0f:21 changed 00000000 bw 2 nss 3 smps 1
>> [   26.074586] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to 
>> staggered
>> [   26.074609] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [   26.074682] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [   26.074701] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 
>> value 2
>> [   26.074760] ath10k_pci 0000:01:00.0: mac vdev 0 slot_time 2
>> [   26.074779] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 7 
>> value 2
>> [   26.273652] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [   26.730650] ath10k_pci 0000:01:00.0: wmi event debug mesg len 44
>> [   26.773733] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [   27.135445] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1 
>> needed? 1 allowed? 1
>> [   27.273810] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>>
>> It seems to start up in VHT80 mode and when it peers with Node B it 
>> thinks Node B is also in VHT80 mode and ping works.
>>
>> 4. Beacons are sent at 6 Mb/s basic rate and unicast QoS Data is sent 
>> with three spatial streams. Attached is the full pcap of the experiment.
>>
>> Thank you for looking into this!
>>
>> ~Benjamin
>>
>> On 12/05/2016 11:24 AM, Nagarajan, Ashok Raj wrote:
>>> 0x009A4577 0x00955B31
>>>
>>> Benjamin, Thanks for the logs.
>>> Quick questions to further debug the issue here,
>>>
>>> 1. Is this issue seen every time you start sending data traffic?
>>> 2. Issue seen with older firmwares? (FYR, 
>>> http://linuxwireless.org/en/users/Drivers/ath10k/firmware/ )
>>> 3. Could you please share the dmesg from your device after enabling 
>>> MAC and WMI logs in ath10k driver
>>>     To enable debug logs please see 
>>> http://linuxwireless.org/en/users/Drivers/ath10k/debug/
>>> 4. Do you know what is the Number of Spatial Streams seen in mesh 
>>> beacons and in mesh data packet?
>>>
>>> Thanks,
>>> Ashok
>>
>



From rmanohar at qca.qualcomm.com  Tue Dec 13 15:51:32 2016
From: rmanohar at qca.qualcomm.com (Manoharan, Rajkumar)
Date: Tue, 13 Dec 2016 23:51:32 +0000
Subject: ath10k firmware crashes in mesh mode on QCA9880
In-Reply-To: <5850831D.7020206@cococorp.com>
References: <583DD564.8040704@cococorp.com>
 <20161201070908.GB11953@atheros-ThinkPad-T61> <58421FA2.2020004@cococorp.com>
 <20161203124358.GB31861@atheros-ThinkPad-T61>
 <20161203124600.GC31861@atheros-ThinkPad-T61> <5845B325.6060002@cococorp.com>
 <d8eb0ba5828d43dd83030247ba443b88@aphydexm01f.ap.qualcomm.com>
 <58472E7B.7090603@cococorp.com> <58504113.2080702@cococorp.com>
 <5850831D.7020206@cococorp.com>
Message-ID: <ccf17009a52748c99accdaa005ea837a@NALASEXR01H.na.qualcomm.com>

> Tested the 10.2.4.70.59-2 firmware and wpa_supplicant running WITHOUT
> encryption and it still crashes. I suspect this means wpa_supplicant is setting up
> the interface incorrectly and/or transmitting a malformed packet that is causing
> the driver to crash.
> 
Ben,

IIRC mesh support was validated in qca988x in VHT mode while ago.  Either it could
be regression in driver/fw or lede mac80211 package.

1) Could you please try plain backports in lede w/o applying ath10k patches.
     I do see 160MHz support in LEDE.
2) There are some peer stats dump from your earlier log. Disable peer stats 
     by "peer_stats" debugfs.
3) Please confirm the behavior with older firmware revisions.
4) use iw to bring up open mesh to rule out wpa_s config

-Rajkumar


From agreen at cococorp.com  Tue Dec 13 21:36:46 2016
From: agreen at cococorp.com (Alexis Green)
Date: Tue, 13 Dec 2016 21:36:46 -0800
Subject: ath10k firmware crashes in mesh mode on QCA9880
In-Reply-To: <ccf17009a52748c99accdaa005ea837a@NALASEXR01H.na.qualcomm.com>
References: <583DD564.8040704@cococorp.com>
 <20161201070908.GB11953@atheros-ThinkPad-T61>
 <58421FA2.2020004@cococorp.com> <20161203124358.GB31861@atheros-ThinkPad-T61>
 <20161203124600.GC31861@atheros-ThinkPad-T61> <5845B325.6060002@cococorp.com>
 <d8eb0ba5828d43dd83030247ba443b88@aphydexm01f.ap.qualcomm.com>
 <58472E7B.7090603@cococorp.com> <58504113.2080702@cococorp.com>
 <5850831D.7020206@cococorp.com>
 <ccf17009a52748c99accdaa005ea837a@NALASEXR01H.na.qualcomm.com>
Message-ID: <CAAnMG+OmeataRKYRjOjtBXF_1-De-F4zWbUsWoYRhVu02NPrrw@mail.gmail.com>

Thank you for your help Rajkumar,

We've traced the problem down to a peering issue. Looks like there was
a missing compile flag that caused some kind of incongruence. My best
guest is that beacons are generated by firmware and advertise support
for AC mode, whereas wpa_supplicant, when not compiled with
CONFIG_IEEE80211AC=y, sends mesh peering messages and creates peers
without AC support, causing firmware to get confused. After
recompiling supplicant with the correct flag, no more crashes were
observed in casual testing. I submitted a pull request to LEDE to,
hopefully, fix it in upstream.

Best regards,

Alexis

On Tue, Dec 13, 2016 at 3:51 PM, Manoharan, Rajkumar
<rmanohar at qca.qualcomm.com> wrote:
>> Tested the 10.2.4.70.59-2 firmware and wpa_supplicant running WITHOUT
>> encryption and it still crashes. I suspect this means wpa_supplicant is setting up
>> the interface incorrectly and/or transmitting a malformed packet that is causing
>> the driver to crash.
>>
> Ben,
>
> IIRC mesh support was validated in qca988x in VHT mode while ago.  Either it could
> be regression in driver/fw or lede mac80211 package.
>
> 1) Could you please try plain backports in lede w/o applying ath10k patches.
>      I do see 160MHz support in LEDE.
> 2) There are some peer stats dump from your earlier log. Disable peer stats
>      by "peer_stats" debugfs.
> 3) Please confirm the behavior with older firmware revisions.
> 4) use iw to bring up open mesh to rule out wpa_s config
>
> -Rajkumar
>


From adrian at freebsd.org  Tue Dec 13 21:53:46 2016
From: adrian at freebsd.org (Adrian Chadd)
Date: Tue, 13 Dec 2016 21:53:46 -0800
Subject: ath10k firmware crashes in mesh mode on QCA9880
In-Reply-To: <CAAnMG+OmeataRKYRjOjtBXF_1-De-F4zWbUsWoYRhVu02NPrrw@mail.gmail.com>
References: <583DD564.8040704@cococorp.com>
 <20161201070908.GB11953@atheros-ThinkPad-T61>
 <58421FA2.2020004@cococorp.com> <20161203124358.GB31861@atheros-ThinkPad-T61>
 <20161203124600.GC31861@atheros-ThinkPad-T61> <5845B325.6060002@cococorp.com>
 <d8eb0ba5828d43dd83030247ba443b88@aphydexm01f.ap.qualcomm.com>
 <58472E7B.7090603@cococorp.com> <58504113.2080702@cococorp.com>
 <5850831D.7020206@cococorp.com>
 <ccf17009a52748c99accdaa005ea837a@NALASEXR01H.na.qualcomm.com>
 <CAAnMG+OmeataRKYRjOjtBXF_1-De-F4zWbUsWoYRhVu02NPrrw@mail.gmail.com>
Message-ID: <CAJ-Vmo=iLryhOS--PPYCGa9pE2GovPDOXi6xoH22xFOYXXKNVA@mail.gmail.com>

Hi!

Hm! So is there a firmware bug if there are 11n only capable nodes in
an 11s mesh?



-adrian


From agreen at cococorp.com  Tue Dec 13 22:06:27 2016
From: agreen at cococorp.com (Alexis Green)
Date: Tue, 13 Dec 2016 22:06:27 -0800
Subject: ath10k firmware crashes in mesh mode on QCA9880
In-Reply-To: <CAJ-Vmo=iLryhOS--PPYCGa9pE2GovPDOXi6xoH22xFOYXXKNVA@mail.gmail.com>
References: <583DD564.8040704@cococorp.com>
 <20161201070908.GB11953@atheros-ThinkPad-T61>
 <58421FA2.2020004@cococorp.com> <20161203124358.GB31861@atheros-ThinkPad-T61>
 <20161203124600.GC31861@atheros-ThinkPad-T61> <5845B325.6060002@cococorp.com>
 <d8eb0ba5828d43dd83030247ba443b88@aphydexm01f.ap.qualcomm.com>
 <58472E7B.7090603@cococorp.com> <58504113.2080702@cococorp.com>
 <5850831D.7020206@cococorp.com>
 <ccf17009a52748c99accdaa005ea837a@NALASEXR01H.na.qualcomm.com>
 <CAAnMG+OmeataRKYRjOjtBXF_1-De-F4zWbUsWoYRhVu02NPrrw@mail.gmail.com>
 <CAJ-Vmo=iLryhOS--PPYCGa9pE2GovPDOXi6xoH22xFOYXXKNVA@mail.gmail.com>
Message-ID: <CAAnMG+MY=LhfJxxUVdfRNYUW-2R+EXdLm2o6yDcCH0T1brRVxw@mail.gmail.com>

Hi Adrian,

I have not done much testing of ath10k and ath9k devices in a single
encrypted mesh recently, but I have a memory of only having this issue
when communicating between ath10k devices.

Alexis

On Tue, Dec 13, 2016 at 9:53 PM, Adrian Chadd <adrian at freebsd.org> wrote:
> Hi!
>
> Hm! So is there a firmware bug if there are 11n only capable nodes in
> an 11s mesh?
>
>
>
> -adrian


From adrian at freebsd.org  Tue Dec 13 22:17:57 2016
From: adrian at freebsd.org (Adrian Chadd)
Date: Tue, 13 Dec 2016 22:17:57 -0800
Subject: ath10k firmware crashes in mesh mode on QCA9880
In-Reply-To: <CAAnMG+MY=LhfJxxUVdfRNYUW-2R+EXdLm2o6yDcCH0T1brRVxw@mail.gmail.com>
References: <583DD564.8040704@cococorp.com>
 <20161201070908.GB11953@atheros-ThinkPad-T61>
 <58421FA2.2020004@cococorp.com> <20161203124358.GB31861@atheros-ThinkPad-T61>
 <20161203124600.GC31861@atheros-ThinkPad-T61> <5845B325.6060002@cococorp.com>
 <d8eb0ba5828d43dd83030247ba443b88@aphydexm01f.ap.qualcomm.com>
 <58472E7B.7090603@cococorp.com> <58504113.2080702@cococorp.com>
 <5850831D.7020206@cococorp.com>
 <ccf17009a52748c99accdaa005ea837a@NALASEXR01H.na.qualcomm.com>
 <CAAnMG+OmeataRKYRjOjtBXF_1-De-F4zWbUsWoYRhVu02NPrrw@mail.gmail.com>
 <CAJ-Vmo=iLryhOS--PPYCGa9pE2GovPDOXi6xoH22xFOYXXKNVA@mail.gmail.com>
 <CAAnMG+MY=LhfJxxUVdfRNYUW-2R+EXdLm2o6yDcCH0T1brRVxw@mail.gmail.com>
Message-ID: <CAJ-VmomEMCxfyy2=440epuTP1rGMaEKBKwPA4qC5V8Hj8LmSbw@mail.gmail.com>

Hi!

ok, thanks! I've seen some .. annoying rate control related firmware
crashes if you aren't using 11ac / 11n rates (ie you're /really/
legacy, so I wondered if something similar is going on here.

Thanks!


-a


On 13 December 2016 at 22:06, Alexis Green <agreen at cococorp.com> wrote:
> Hi Adrian,
>
> I have not done much testing of ath10k and ath9k devices in a single
> encrypted mesh recently, but I have a memory of only having this issue
> when communicating between ath10k devices.
>
> Alexis
>
> On Tue, Dec 13, 2016 at 9:53 PM, Adrian Chadd <adrian at freebsd.org> wrote:
>> Hi!
>>
>> Hm! So is there a firmware bug if there are 11n only capable nodes in
>> an 11s mesh?
>>
>>
>>
>> -adrian


From mohammed at codeaurora.org  Tue Dec 13 23:33:38 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Wed, 14 Dec 2016 13:03:38 +0530
Subject: [PATCH 1/2] ath10k: add accounting for the extended peer
 statistics
In-Reply-To: <2870294.lMmxz9iPmq@debian64>
References: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
 <20161207062824.GA3404@atheros-ThinkPad-T61>
 <2870294.lMmxz9iPmq@debian64>
Message-ID: <20161214073337.GA4046@atheros-ThinkPad-T61>

On Tue, Dec 13, 2016 at 01:41:33PM +0100, Christian Lamparter wrote:
> Hello,
> 
> It looks like google put your mail into the spam-can. 
> I'm sorry for not answering sooner.

[shafi] np, thanks for your reply !

> 
> On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Shafi Shajakhan wrote:
> > On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote:
> > > The 10.4 firmware adds extended peer information to the
> > > firmware's statistics payload. This additional info is
> > > stored as a separate data field and the elements are
> > > stored in their own "peers_extd" list.
> > > 
> > > These elements can pile up in the same way as the peer
> > > information elements. This is because the
> > > ath10k_wmi_10_4_op_pull_fw_stats() function tries to
> > > pull the same amount (num_peer_stats) for every statistic
> > > data unit.
> > > 
> > > Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
> > > Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>
> > > ---
> > >  drivers/net/wireless/ath/ath10k/debug.c | 7 +++++--
> > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> > > index 82a4c67f3672..4acd9eb65910 100644
> > > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > > @@ -399,6 +399,7 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> > >  			 * prevent firmware from DoS-ing the host.
> > >  			 */
> > >  			ath10k_fw_stats_peers_free(&ar->debug.fw_stats.peers);
> > > +			ath10k_fw_extd_stats_peers_free(&ar->debug.fw_stats.peers_extd);
> > 
> > [shafi] thanks for fixing this !
> > 
> > >  			ath10k_warn(ar, "dropping fw peer stats\n");
> > >  			goto free;
> > >  		}
> > > @@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> > >  			goto free;
> > >  		}
> > >  
> > > +		if (!list_empty(&stats.peers))
> > 
> > [shafi] sorry please correct me if i am wrong, for 'extended peer stats' we are checking
> > for normal 'peer stats' ? Is this the fix intended, i had started a build to
> > check your change and we will keep you posted, does this fix displaying
> > 'rx_duration' in ath10k fw_stats.
> The idea is not to queue any "extended peer stats" when there where no "peer stats" to
> begin with. Because otherwise, the function is still vulnerable to OOM since the 
> extended peers stats will be queued unchecked (not that this is currently a problem).

[shafi] list_splice_tail_init should still check for non-empty 'peers_extd' list
and append if required ? please let me know if i am still missing something

>  
> > > +			list_splice_tail_init(&stats.peers_extd,
> > > +					      &ar->debug.fw_stats.peers_extd);
> > > +
> > >  		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);
> 
> Regards,
> Christian
> 
> 


From kvalo at qca.qualcomm.com  Wed Dec 14 05:46:38 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Wed, 14 Dec 2016 13:46:38 +0000
Subject: [RFC v2 05/11] ath10k: htc: refactorization
In-Reply-To: <70b8a055-e6ba-857d-8b03-06f50e3f10fe@gmail.com> (Erik
 Stromdahl's message of "Tue, 13 Dec 2016 19:37:30 +0100")
References: <1479496971-19174-1-git-send-email-erik.stromdahl@gmail.com>
 <1479496971-19174-6-git-send-email-erik.stromdahl@gmail.com>
 <87inqoymd0.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQkuUFxnra75B4LpF5+k9yE7hkNYDXbtUMBLq2LFuPSasg@mail.gmail.com>
 <871sxbzqo6.fsf@kamboji.qca.qualcomm.com>
 <70b8a055-e6ba-857d-8b03-06f50e3f10fe@gmail.com>
Message-ID: <871sxay66a.fsf@kamboji.qca.qualcomm.com>

Erik Stromdahl <erik.stromdahl at gmail.com> writes:

> I have made a few updates since I submitted the original RFC and created
> a repo on github:
>
> https://github.com/erstrom/linux-ath
>
> I have a bunch of branches that are all based on the tags on the ath master.
>
> As of this moment the latest version is:
>
> ath-201612131156-ath10k-sdio
>
> This branch contains the original RFC patches plus some addons/fixes.

Good, this makes it easier to follow the development. So what's the
current status with this branch? What works and what doesn't?

Especially I'm interested about the state of the HTT high latency
support. How much work is to add that? It would also make it easier to
add USB support to ath10k.

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Wed Dec 14 05:49:10 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Wed, 14 Dec 2016 13:49:10 +0000
Subject: [RFC v2 05/11] ath10k: htc: refactorization
In-Reply-To: <CA+BoTQmRV59imnmSykjs=ym0qut9akUHzFKfAMioK=MT8my98A@mail.gmail.com>	(Michal
 Kazior's message of "Tue, 13 Dec 2016 20:21:53 +0100")
References: <1479496971-19174-1-git-send-email-erik.stromdahl@gmail.com>
 <1479496971-19174-6-git-send-email-erik.stromdahl@gmail.com>
 <87inqoymd0.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQkuUFxnra75B4LpF5+k9yE7hkNYDXbtUMBLq2LFuPSasg@mail.gmail.com>
 <871sxbzqo6.fsf@kamboji.qca.qualcomm.com>
 <70b8a055-e6ba-857d-8b03-06f50e3f10fe@gmail.com>
 <CA+BoTQmRV59imnmSykjs=ym0qut9akUHzFKfAMioK=MT8my98A@mail.gmail.com>
Message-ID: <87wpf2wrhm.fsf@kamboji.qca.qualcomm.com>

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

>> I have made a few updates since I submitted the original RFC and created
>> a repo on github:
>>
>> https://github.com/erstrom/linux-ath
>>
>> I have a bunch of branches that are all based on the tags on the ath master.
>>
>> As of this moment the latest version is:
>>
>> ath-201612131156-ath10k-sdio
>>
>> This branch contains the original RFC patches plus some addons/fixes.
>>
>> In the above mentioned branch there are a few commits related to this
>> race condition. Perhaps you can have a look at them?
>>
>> The commits are:
>> 821672913328cf737c9616786dc28d2e4e8a4a90
>
> I would avoid if(bus==xx) checks.

Very much agreed. For example to enable HTT high latency support you
could add an enum to ath10k_core_create() with values for both high and
low latency. This way sdio.c and pci.c can enable the correct mode
during initialisation.

-- 
Kalle Valo

From chunkeey at googlemail.com  Wed Dec 14 08:38:02 2016
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Wed, 14 Dec 2016 17:38:02 +0100
Subject: [PATCH 1/2] ath10k: add accounting for the extended peer
 statistics
In-Reply-To: <20161214073337.GA4046@atheros-ThinkPad-T61>
References: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
 <2870294.lMmxz9iPmq@debian64> <20161214073337.GA4046@atheros-ThinkPad-T61>
Message-ID: <1859306.unY1Rqbrx8@debian64>

On Wednesday, December 14, 2016 1:03:38 PM CET Mohammed Shafi Shajakhan wrote:
> > On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Shafi Shajakhan wrote:
> > > On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote:
> > > > @@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> > > >  			goto free;
> > > >  		}
> > > >  
> > > > +		if (!list_empty(&stats.peers))
> > > 
> > > [shafi] sorry please correct me if i am wrong, for 'extended peer stats' we are checking
> > > for normal 'peer stats' ? Is this the fix intended, i had started a build to
> > > check your change and we will keep you posted, does this fix displaying
> > > 'rx_duration' in ath10k fw_stats.
> > The idea is not to queue any "extended peer stats" when there where no "peer stats" to
> > begin with. Because otherwise, the function is still vulnerable to OOM since the 
> > extended peers stats will be queued unchecked (not that this is currently a problem).
> 
> [shafi] list_splice_tail_init should still check for non-empty 'peers_extd' list
> and append if required ? please let me know if i am still missing something
Well, you can also count the entries in peers_extd and delete the old entries
if they start to overflow. If you want to do it differently, please go ahead.

Regards,
Christian


From greearb at candelatech.com  Wed Dec 14 10:28:44 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 14 Dec 2016 10:28:44 -0800
Subject: ath10k firmware sends probes on DFS channels without radar
 detection
In-Reply-To: <00e701d25635$e0108480$a0318d80$@acksys.fr>
References: <004a01d24fe2$94da8dc0$be8fa940$@acksys.fr>
 <63c731f2-ee21-6450-2ae4-2808e7130eb5@candelatech.com>
 <00e701d25635$e0108480$a0318d80$@acksys.fr>
Message-ID: <3f785944-2fd6-17e0-71f5-1e2668a4ae33@candelatech.com>

On 12/14/2016 10:14 AM, Jean-Pierre Tosoni wrote:
> On 12/06/15 08:36 PM, Ben Greear wrote:
>> On 12/06/2016 09:02 AM, Jean-Pierre Tosoni wrote:
>>> This follows on the previous discussion
>>> 	"Client station sends probes on DFS channels"
>>>
>>> Problem:
>>> The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
>>> wpa_supplicant do not comply with the norm ETSI/EN 301-893 section
>>> 4.7; because they can send probes for 600s when no AP is around.
>>>
>>> Analysis:
>>> The problem seems to lie in the firmware, which regards the presence
>>> of *any* beacon as a proof that the channel is radar-clean for 600s.
>>>
>>> This is a wrong hypothesis, since a rogue AP sending fraudulent
>>> beacons should not induce a scrupulous STA in sending illegal probes.
>>>
>>> Moreover, the norm (table D.1) sets a time limit of 10s to shutdown
>>> when no AP positively allows the STA to transmit on the DFS channel.
>>>
>>> Status:
>>> - there is no known plan at QCA to fix the issue.
>>> - ath10k firmware is not publicly available for fixes.
>>> - there is no obvious fix working in ath10k.
>>> - the issue does not show up with other mac80211 devices like ath9k.
>>> - wpa_supplicant considers this is a kernel issue [2]
>>
>> Have you confirmed that there are no probe requests being sent by ath10k
>> driver?
>
> I have put a printk in the ath10k_tx function (in the path for management
> frames) and it does not show up.
> On another hand I cannot find any other function preparing / sending probes.
> There is only the wmi command that starts scans.

That wmi command causes probes, so make sure it is not being called.


>> You could also try disabling the station keep-alive and roaming logic in
>> the firmware by tweaking the wmi initial setup logic.  I disable that in
>> my firmware, for instance, because mac80211 can do a better job and then I
>> can save resources in the firmware.
>
> Do you mean the values set in wmi.c:: ath10k_wmi_start_scan_init() ?
>
> Should I replace all the scan offload by a mac80211-controlled scan like
> in ath9k? The problem then is to switch channels; channel switching
> seems very different from ath9k.

You might try one or more of these settings in the ath10k_wmi_10_1_op_gen_init
method (or 10.2 if that is the FW you are using):

	config.roam_offload_max_vdev = 0; /* disable roaming */
	config.roam_offload_max_ap_profiles = 0; /* disable roaming */
	config.bmiss_offload_max_vdev = 0;

I have only tested this using my CT firmware, and I have some additional
patches in my driver to enable mac80211 keep-alive logic when using my
CT firmware.

Thanks,
Ben

>
> Thanks,
> JP
>
>> Finally, if that doesn't work, then I could probably fix that in CT
>> firmware in case that is of interest.
>>
>> Thanks,
>> Ben
>>
>>>
>>> Jean-Pierre Tosoni
>>>
>>>
>>>
>>>> -----Message d'origine-----
>>>> De : ath10k [mailto:ath10k-bounces at lists.infradead.org] De la part de
>>>> Jean-Pierre Tosoni Envoy? : mercredi 30 novembre 2016 19:04 ? :
>>>> ath10k at lists.infradead.org Objet : Client station sends probes on DFS
>>>> channels
>>>>
>>>> Hello list,
>>>>
>>>> There is a case where I can see probes on a DFS channel, from a non-
>>>> associated station using ath10k. (note that the problem does not
>>>> arise when using ath9k).
>>>>
>>>> *The setup*
>>>>
>>>> I am using Openwrt, wpa_supplicant and compat-wireless 2016-10-08,
>>>> Card firmware is	ath10k_pci: qca988x hw2.0 (0x4100016c, 0x043202ff)
>>>> 		fw 10.2.4.70-2 api 5 htt-ver 2.1 wmi-op 5 htt-op 2
>>>> 		cal otp max-sta 128 features no-p2p
>>>> 	ath10k_pci: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
>>>>
>>>> I am using channel 116, regdom US or FR, where I see no traffic at
>>>> all using wireshark+Airpcap.
>>>> I set wpa_supplicant to scan this channel only for a specific SSID
>>>> "ssid1".
>>>>
>>>> At initial startup of the client device, no probes are going out,
>>>> which is OK.
>>>>
>>>> Then, on another device, I start a hostapd set to channel 116, with a
>>>> different SSID "otherssid" so that the supplicant will not associate.
>>>>
>>>> Shortly (1-2s) after the beacons appear in the air, the client begins
>>>> to Send probe request in the air, which is unexpected, but acceptable
>>>> since the client can infer absence of radars from the presence of
>> beacons.
>>>>
>>>> *The problem*
>>>>
>>>> If I power down the AP, the client continues to send probes for
>>>> around
>>>> 10 minutes, which is unacceptable since it cannot handle radar
>>>> detection, as it is a slave device in the meaning of ETSI/EN 301-
>> 893[1].
>>>>
>>>>
>>>> Some tests I made:
>>>> - I tried to investigate the "beacon hint" mechanism but it appears
>>>>   that it is not used on DFS channels.
>>>>
>>>> - I tried to force the IEEE80211_NO_IR flag when IEEE80211_CHAN_DFS
>>>>   is set.
>>>>
>>>> - When I reload the reg. domain using "iw reg set", the probes cease,
>>>>   but will reappear if I cycle my AP again On then Off.
>>>>
>>>> - When I let the client associate, then disassociate and stop the AP,
>>>>   the same problem arises. It disappears if I add a call to
>>>>   ath10k_regd_update() in mac.c after a disconnection (This is not a
>>>>   fix, since in my case the client never associates).
>>>>
>>>> - Since at startup, the client does not send probes, I infer that the
>>>>   problem is *not* caused by a hidden AP that the card could see but
>>>>   not airpcap.
>>>>
>>>> - I tried with channels 52 and 100, with regdom FR or US: same problem.
>>>>
>>>> Any ideas?
>>>>
>>>>
>>>> [1] http://www.etsi.org/deliver/etsi_en/301800_301899/301893/
>>>> 01.08.01_60/en_301893v010801p.pdf
>>> [2] http://lists.shmoo.com/pipermail/hostap/2015-January/031906.html
>>>>
>>>> J.P. Tosoni - ACKSYS
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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 jp.tosoni at acksys.fr  Wed Dec 14 10:14:13 2016
From: jp.tosoni at acksys.fr (Jean-Pierre Tosoni)
Date: Wed, 14 Dec 2016 19:14:13 +0100
Subject: ath10k firmware sends probes on DFS channels without radar
 detection
In-Reply-To: <63c731f2-ee21-6450-2ae4-2808e7130eb5@candelatech.com>
References: <004a01d24fe2$94da8dc0$be8fa940$@acksys.fr>
 <63c731f2-ee21-6450-2ae4-2808e7130eb5@candelatech.com>
Message-ID: <00e701d25635$e0108480$a0318d80$@acksys.fr>

On 12/06/15 08:36 PM, Ben Greear wrote: 
> On 12/06/2016 09:02 AM, Jean-Pierre Tosoni wrote:
> > This follows on the previous discussion
> > 	"Client station sends probes on DFS channels"
> >
> > Problem:
> > The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
> > wpa_supplicant do not comply with the norm ETSI/EN 301-893 section
> > 4.7; because they can send probes for 600s when no AP is around.
> >
> > Analysis:
> > The problem seems to lie in the firmware, which regards the presence
> > of *any* beacon as a proof that the channel is radar-clean for 600s.
> >
> > This is a wrong hypothesis, since a rogue AP sending fraudulent
> > beacons should not induce a scrupulous STA in sending illegal probes.
> >
> > Moreover, the norm (table D.1) sets a time limit of 10s to shutdown
> > when no AP positively allows the STA to transmit on the DFS channel.
> >
> > Status:
> > - there is no known plan at QCA to fix the issue.
> > - ath10k firmware is not publicly available for fixes.
> > - there is no obvious fix working in ath10k.
> > - the issue does not show up with other mac80211 devices like ath9k.
> > - wpa_supplicant considers this is a kernel issue [2]
> 
> Have you confirmed that there are no probe requests being sent by ath10k
> driver?

I have put a printk in the ath10k_tx function (in the path for management
frames) and it does not show up.
On another hand I cannot find any other function preparing / sending probes.
There is only the wmi command that starts scans.

> 
> You could also try disabling the station keep-alive and roaming logic in
> the firmware by tweaking the wmi initial setup logic.  I disable that in
> my firmware, for instance, because mac80211 can do a better job and then I
> can save resources in the firmware.

Do you mean the values set in wmi.c:: ath10k_wmi_start_scan_init() ?

Should I replace all the scan offload by a mac80211-controlled scan like
in ath9k? The problem then is to switch channels; channel switching
seems very different from ath9k.

Thanks,
JP

> Finally, if that doesn't work, then I could probably fix that in CT
> firmware in case that is of interest.
> 
> Thanks,
> Ben
> 
> >
> > Jean-Pierre Tosoni
> >
> >
> >
> >> -----Message d'origine-----
> >> De : ath10k [mailto:ath10k-bounces at lists.infradead.org] De la part de
> >> Jean-Pierre Tosoni Envoy? : mercredi 30 novembre 2016 19:04 ? :
> >> ath10k at lists.infradead.org Objet : Client station sends probes on DFS
> >> channels
> >>
> >> Hello list,
> >>
> >> There is a case where I can see probes on a DFS channel, from a non-
> >> associated station using ath10k. (note that the problem does not
> >> arise when using ath9k).
> >>
> >> *The setup*
> >>
> >> I am using Openwrt, wpa_supplicant and compat-wireless 2016-10-08,
> >> Card firmware is	ath10k_pci: qca988x hw2.0 (0x4100016c, 0x043202ff)
> >> 		fw 10.2.4.70-2 api 5 htt-ver 2.1 wmi-op 5 htt-op 2
> >> 		cal otp max-sta 128 features no-p2p
> >> 	ath10k_pci: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
> >>
> >> I am using channel 116, regdom US or FR, where I see no traffic at
> >> all using wireshark+Airpcap.
> >> I set wpa_supplicant to scan this channel only for a specific SSID
> >> "ssid1".
> >>
> >> At initial startup of the client device, no probes are going out,
> >> which is OK.
> >>
> >> Then, on another device, I start a hostapd set to channel 116, with a
> >> different SSID "otherssid" so that the supplicant will not associate.
> >>
> >> Shortly (1-2s) after the beacons appear in the air, the client begins
> >> to Send probe request in the air, which is unexpected, but acceptable
> >> since the client can infer absence of radars from the presence of
> beacons.
> >>
> >> *The problem*
> >>
> >> If I power down the AP, the client continues to send probes for
> >> around
> >> 10 minutes, which is unacceptable since it cannot handle radar
> >> detection, as it is a slave device in the meaning of ETSI/EN 301-
> 893[1].
> >>
> >>
> >> Some tests I made:
> >> - I tried to investigate the "beacon hint" mechanism but it appears
> >>   that it is not used on DFS channels.
> >>
> >> - I tried to force the IEEE80211_NO_IR flag when IEEE80211_CHAN_DFS
> >>   is set.
> >>
> >> - When I reload the reg. domain using "iw reg set", the probes cease,
> >>   but will reappear if I cycle my AP again On then Off.
> >>
> >> - When I let the client associate, then disassociate and stop the AP,
> >>   the same problem arises. It disappears if I add a call to
> >>   ath10k_regd_update() in mac.c after a disconnection (This is not a
> >>   fix, since in my case the client never associates).
> >>
> >> - Since at startup, the client does not send probes, I infer that the
> >>   problem is *not* caused by a hidden AP that the card could see but
> >>   not airpcap.
> >>
> >> - I tried with channels 52 and 100, with regdom FR or US: same problem.
> >>
> >> Any ideas?
> >>
> >>
> >> [1] http://www.etsi.org/deliver/etsi_en/301800_301899/301893/
> >> 01.08.01_60/en_301893v010801p.pdf
> > [2] http://lists.shmoo.com/pipermail/hostap/2015-January/031906.html
> >>
> >> J.P. Tosoni - ACKSYS
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> 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 j at w1.fi  Wed Dec 14 11:58:05 2016
From: j at w1.fi (Jouni Malinen)
Date: Wed, 14 Dec 2016 21:58:05 +0200
Subject: ath10k firmware sends probes on DFS channels without radar
 detection
In-Reply-To: <004a01d24fe2$94da8dc0$be8fa940$@acksys.fr>
References: <004a01d24fe2$94da8dc0$be8fa940$@acksys.fr>
Message-ID: <20161214195805.GA15022@w1.fi>

On Tue, Dec 06, 2016 at 06:02:52PM +0100, Jean-Pierre Tosoni wrote:
> This follows on the previous discussion
> 	"Client station sends probes on DFS channels"
> 
> Problem:
> The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
> wpa_supplicant do not comply with the norm ETSI/EN 301-893
> section 4.7; because they can send probes for 600s when no
> AP is around.
> 
> Analysis:
> The problem seems to lie in the firmware, which regards the presence
> of *any* beacon as a proof that the channel is radar-clean for 600s.

I don't think this is really firmware, but cfg80211 regulatory code and
how it interacts with ath10k..

> - there is no obvious fix working in ath10k.
> - the issue does not show up with other mac80211 devices like ath9k.
> - wpa_supplicant considers this is a kernel issue [2]

There seems to be a difference between ath9k (mac80211-based Probe
Request frame sending) and ath10k (firmware) in this area for active
scanning. mac80211 uses IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR
while ath10k uses IEEE80211_CHAN_NO_IR. I'd assume this difference
results in ath10k using cfg80211 beacon hints (etc.) to update the NO_IR
flag and that might be behind the difference you see.

Could you check whether the following change gets you the behavior you
want to see here? I have not had a chance to test this yet, but based on
code review, it looks like something that brings the same behavior to
ath10k that ath9k has for this through mac80211.


diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index aa545a1..758dbbd 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2973,7 +2973,8 @@ static int ath10k_update_channel_list(struct ath10k *ar)
 			ch->chan_radar =
 				!!(channel->flags & IEEE80211_CHAN_RADAR);
 
-			passive = channel->flags & IEEE80211_CHAN_NO_IR;
+			passive = channel->flags & (IEEE80211_CHAN_NO_IR |
+						    IEEE80211_CHAN_RADAR);
 			ch->passive = passive;
 
 			ch->freq = channel->center_freq;

-- 
Jouni Malinen                                            PGP id EFC895FA


From erik.stromdahl at gmail.com  Wed Dec 14 13:07:50 2016
From: erik.stromdahl at gmail.com (Erik Stromdahl)
Date: Wed, 14 Dec 2016 22:07:50 +0100
Subject: [RFC v2 05/11] ath10k: htc: refactorization
In-Reply-To: <871sxay66a.fsf@kamboji.qca.qualcomm.com>
References: <1479496971-19174-1-git-send-email-erik.stromdahl@gmail.com>
 <1479496971-19174-6-git-send-email-erik.stromdahl@gmail.com>
 <87inqoymd0.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQkuUFxnra75B4LpF5+k9yE7hkNYDXbtUMBLq2LFuPSasg@mail.gmail.com>
 <871sxbzqo6.fsf@kamboji.qca.qualcomm.com>
 <70b8a055-e6ba-857d-8b03-06f50e3f10fe@gmail.com>
 <871sxay66a.fsf@kamboji.qca.qualcomm.com>
Message-ID: <b3068401-aee9-47bc-141e-692ea72ffb74@gmail.com>



On 12/14/2016 02:46 PM, Valo, Kalle wrote:
> Erik Stromdahl <erik.stromdahl at gmail.com> writes:
> 
>> I have made a few updates since I submitted the original RFC and created
>> a repo on github:
>>
>> https://github.com/erstrom/linux-ath
>>
>> I have a bunch of branches that are all based on the tags on the ath master.
>>
>> As of this moment the latest version is:
>>
>> ath-201612131156-ath10k-sdio
>>
>> This branch contains the original RFC patches plus some addons/fixes.
> 
> Good, this makes it easier to follow the development. So what's the
> current status with this branch? What works and what doesn't?
> 
Well, everything in there has been tested (limited though, as you
yourself experienced), but it is not complete. I still have some other
patches that need some more refurbishing before I can push them.

I will push those patches that I consider "good enough" for publish to
this repo. Most likely I will rewrite/squash etc. some of it before
submitting a new RFC series.

So, there are still some additional stuff that needs to be added. In my
case I have a series of patches related to OCB (Outside the Context of a
BSS) mode of operation (since the chipset I am using is intended for
this purpose). These patches are still not complete.

Other SDIO 11ac chipsets might just need an item in the struct
ath10k_hw_params array together with some firmware files.

> Especially I'm interested about the state of the HTT high latency
> support. How much work is to add that? It would also make it easier to
> add USB support to ath10k.
> 

I actually have some patches regarding this, but they have not been
tested at all since I have not yet managed to fully configure my SDIO
chip properly so far. I must finish the OCB code I mentioned earlier and
fix another really annoying issue with a missing HTT version response
(sometimes target won't respond to the HTT version request).

Then, hopefully, I can make some TX and RX tests.

I think the HTT TX part is fairly straight forward. But the RX part is a
little bit more tricky since I am not really sure about how to interface
mac80211 in the RX path.

My work flow goes like this:

As soon as there is a new tag on the ath.git master, I rebase my stuff
on top of it and push a new branch to my repo.

I will continuously push updates to the latest branch (the branch based
on the latest ath tag).

Older branches will not be maintained.

/Erik


From kvalo at qca.qualcomm.com  Thu Dec 15 01:18:15 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 15 Dec 2016 10:18:15 +0100
Subject: ath10k: Avoid potential page alloc BUG_ON in tx free path
In-Reply-To: <1481086832-17281-1-git-send-email-mohammed@qca.qualcomm.com>
References: <1481086832-17281-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <d64a028b471e4d38b6d9ac3e664f7c4d@euamsexm01a.eu.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> 'ath10k_htt_tx_free_cont_txbuf' and 'ath10k_htt_tx_free_cont_frag_desc'
> have NULL pointer checks to avoid crash if they are called twice
> but this is as of now not sufficient as these pointers are not assigned
> to NULL once the contiguous DMA memory allocation is freed, fix this.
> Though this may not be hit with the explicity check of state variable
> 'tx_mem_allocated' check, good to have this addressed as well.
> 
> Below BUG_ON is hit when the above scenario is simulated
> with kernel debugging enabled
> 
>  page:f6d09a00 count:0 mapcount:-127 mapping:  (null)
> index:0x0
>  flags: 0x40000000()
>  page dumped because: VM_BUG_ON_PAGE(page_ref_count(page)
> == 0)
>  ------------[ cut here ]------------
>  kernel BUG at ./include/linux/mm.h:445!
>  invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
>  EIP is at put_page_testzero.part.88+0xd/0xf
>  Call Trace:
>   [<c118a2cc>] __free_pages+0x3c/0x40
>   [<c118a30e>] free_pages+0x3e/0x50
>   [<c10222b4>] dma_generic_free_coherent+0x24/0x30
>   [<f8c1d9a8>] ath10k_htt_tx_free_cont_txbuf+0xf8/0x140
> 
>   [<f8c1e2a9>] ath10k_htt_tx_destroy+0x29/0xa0
> 
>   [<f8c143e0>] ath10k_core_destroy+0x60/0x80 [ath10k_core]
>   [<f8acd7e9>] ath10k_pci_remove+0x79/0xa0 [ath10k_pci]
>   [<c13ed7a8>] pci_device_remove+0x38/0xb0
>   [<c14d3492>] __device_release_driver+0x72/0x100
>   [<c14d36b7>] driver_detach+0x97/0xa0
>   [<c14d29c0>] bus_remove_driver+0x40/0x80
>   [<c14d427a>] driver_unregister+0x2a/0x60
>   [<c13ec768>] pci_unregister_driver+0x18/0x70
>   [<f8aced4f>] ath10k_pci_exit+0xd/0x2be [ath10k_pci]
>   [<c1101e78>] SyS_delete_module+0x158/0x210
>   [<c11b34f1>] ? __might_fault+0x41/0xa0
>   [<c11b353b>] ? __might_fault+0x8b/0xa0
>   [<c1001a4b>] do_fast_syscall_32+0x9b/0x1c0
>   [<c178da34>] sysenter_past_esp+0x45/0x74
> 
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Patch applied to ath-next branch of ath.git, thanks.

02a9e08d7374 ath10k: Avoid potential page alloc BUG_ON in tx free path

-- 
https://patchwork.kernel.org/patch/9463923/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From jp.tosoni at acksys.fr  Thu Dec 15 07:22:34 2016
From: jp.tosoni at acksys.fr (Jean-Pierre Tosoni)
Date: Thu, 15 Dec 2016 16:22:34 +0100
Subject: ath10k firmware sends probes on DFS channels without radar
 detection
In-Reply-To: <20161214195805.GA15022@w1.fi>
References: <004a01d24fe2$94da8dc0$be8fa940$@acksys.fr>
 <20161214195805.GA15022@w1.fi>
Message-ID: <00f501d256e7$0f8d5380$2ea7fa80$@acksys.fr>

Jouni,

Thanks for the suggestion, I already tried something like this in wmi.c,
with the same result:

- Before patching the firmware scans DFS channels actively (with probes).

- After patching, the firmware scans DFS channels passively *until* any
beacon is received on the DFS channel. When *any* beacon is seen, the
firmware decides to scan actively on its own, without any new IR/RADAR
info from the driver.

So, your patch is required but not sufficient.

Somehow I was able to overcome this by reloading the regulation domain
in the radio card before each scan request:

////// awful patch ahead ////////

--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2842,7 +2842,9 @@ static int ath10k_update_channel_list(st
 			ch->chan_radar =
 				!!(channel->flags & IEEE80211_CHAN_RADAR);
 
-			passive = channel->flags & IEEE80211_CHAN_NO_IR;
+			passive = channel->flags & (IEEE80211_CHAN_NO_IR |
+						    IEEE80211_CHAN_RADAR);
+
 			ch->passive = passive;
 
 			ch->freq = channel->center_freq;
@@ -3548,6 +3550,9 @@ static int ath10k_start_scan(struct ath1
 
 	lockdep_assert_held(&ar->conf_mutex);
 
+	if (ar->state == ATH10K_STATE_ON)
+		ath10k_regd_update(ar);
+
 	ret = ath10k_wmi_start_scan(ar, arg);
 	if (ret)
 		return ret;

////////////////////////////////////////

...But this sets a terrible penalty on performance when applied to
background scan.


On 12/14/16 20:58 Jouni Malinen wrote:
> 
> On Tue, Dec 06, 2016 at 06:02:52PM +0100, Jean-Pierre Tosoni wrote:
> > This follows on the previous discussion
> > 	"Client station sends probes on DFS channels"
> >
> > Problem:
> > The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
> > wpa_supplicant do not comply with the norm ETSI/EN 301-893 section
> > 4.7; because they can send probes for 600s when no AP is around.
> >
> > Analysis:
> > The problem seems to lie in the firmware, which regards the presence
> > of *any* beacon as a proof that the channel is radar-clean for 600s.
> 
> I don't think this is really firmware, but cfg80211 regulatory code and
> how it interacts with ath10k..
> 
> > - there is no obvious fix working in ath10k.
> > - the issue does not show up with other mac80211 devices like ath9k.
> > - wpa_supplicant considers this is a kernel issue [2]
> 
> There seems to be a difference between ath9k (mac80211-based Probe Request
> frame sending) and ath10k (firmware) in this area for active scanning.
> mac80211 uses IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR while ath10k
> uses IEEE80211_CHAN_NO_IR. I'd assume this difference results in ath10k
> using cfg80211 beacon hints (etc.) to update the NO_IR flag and that might
> be behind the difference you see.
> 
> Could you check whether the following change gets you the behavior you
> want to see here? I have not had a chance to test this yet, but based on
> code review, it looks like something that brings the same behavior to
> ath10k that ath9k has for this through mac80211.
> 
> 
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> b/drivers/net/wireless/ath/ath10k/mac.c
> index aa545a1..758dbbd 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -2973,7 +2973,8 @@ static int ath10k_update_channel_list(struct ath10k
> *ar)
>  			ch->chan_radar =
>  				!!(channel->flags & IEEE80211_CHAN_RADAR);
> 
> -			passive = channel->flags & IEEE80211_CHAN_NO_IR;
> +			passive = channel->flags & (IEEE80211_CHAN_NO_IR |
> +						    IEEE80211_CHAN_RADAR);
>  			ch->passive = passive;
> 
>  			ch->freq = channel->center_freq;
> 
> --
> Jouni Malinen                                            PGP id EFC895FA
> 
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k



From mohammed at codeaurora.org  Thu Dec 15 08:26:59 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Thu, 15 Dec 2016 21:56:59 +0530
Subject: [PATCH 1/2] ath10k: add accounting for the extended peer
 statistics
In-Reply-To: <1859306.unY1Rqbrx8@debian64>
References: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
 <2870294.lMmxz9iPmq@debian64>
 <20161214073337.GA4046@atheros-ThinkPad-T61>
 <1859306.unY1Rqbrx8@debian64>
Message-ID: <20161215162659.GA8030@atheros-ThinkPad-T61>

Hello Christian,

On Wed, Dec 14, 2016 at 05:38:02PM +0100, Christian Lamparter wrote:
> On Wednesday, December 14, 2016 1:03:38 PM CET Mohammed Shafi Shajakhan wrote:
> > > On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Shafi Shajakhan wrote:
> > > > On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote:
> > > > > @@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> > > > >  			goto free;
> > > > >  		}
> > > > >  
> > > > > +		if (!list_empty(&stats.peers))
> > > > 
> > > > [shafi] sorry please correct me if i am wrong, for 'extended peer stats' we are checking
> > > > for normal 'peer stats' ? Is this the fix intended, i had started a build to
> > > > check your change and we will keep you posted, does this fix displaying
> > > > 'rx_duration' in ath10k fw_stats.
> > > The idea is not to queue any "extended peer stats" when there where no "peer stats" to
> > > begin with. Because otherwise, the function is still vulnerable to OOM since the 
> > > extended peers stats will be queued unchecked (not that this is currently a problem).
> > 
> > [shafi] list_splice_tail_init should still check for non-empty 'peers_extd' list
> > and append if required ? please let me know if i am still missing something
> Well, you can also count the entries in peers_extd and delete the old entries
> if they start to overflow. If you want to do it differently, please go ahead.
>
[shafi] sorry for the delay (got stuck up with something else), I will add some prints explicitly
and keep you posted ASAP. Since the extended peer stats gets updated periodically I
would like to confirm the debug linked list associated to the extended peer
stats does not overflows and potentially cause OOM.

regards,
shafi


From greearb at candelatech.com  Thu Dec 15 08:32:44 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 15 Dec 2016 08:32:44 -0800
Subject: ath10k firmware sends probes on DFS channels without radar
 detection
In-Reply-To: <00f501d256e7$0f8d5380$2ea7fa80$@acksys.fr>
References: <004a01d24fe2$94da8dc0$be8fa940$@acksys.fr>
 <20161214195805.GA15022@w1.fi> <00f501d256e7$0f8d5380$2ea7fa80$@acksys.fr>
Message-ID: <5852C5AC.6090408@candelatech.com>

On 12/15/2016 07:22 AM, Jean-Pierre Tosoni wrote:
> Jouni,
>
> Thanks for the suggestion, I already tried something like this in wmi.c,
> with the same result:
>
> - Before patching the firmware scans DFS channels actively (with probes).
>
> - After patching, the firmware scans DFS channels passively *until* any
> beacon is received on the DFS channel. When *any* beacon is seen, the
> firmware decides to scan actively on its own, without any new IR/RADAR
> info from the driver.
>
> So, your patch is required but not sufficient.
>
> Somehow I was able to overcome this by reloading the regulation domain
> in the radio card before each scan request:
>
> ////// awful patch ahead ////////
>
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -2842,7 +2842,9 @@ static int ath10k_update_channel_list(st
>   			ch->chan_radar =
>   				!!(channel->flags & IEEE80211_CHAN_RADAR);
>
> -			passive = channel->flags & IEEE80211_CHAN_NO_IR;
> +			passive = channel->flags & (IEEE80211_CHAN_NO_IR |
> +						    IEEE80211_CHAN_RADAR);

So, should we add a new flag in firmware and driver that means 'really-no-IR', or
should the NO_IR flag here just always make the firmware never do IR when probing
regardless of whether it has seen beacons or not?

Thanks,
Ben

> +
>   			ch->passive = passive;
>
>   			ch->freq = channel->center_freq;
> @@ -3548,6 +3550,9 @@ static int ath10k_start_scan(struct ath1
>
>   	lockdep_assert_held(&ar->conf_mutex);
>
> +	if (ar->state == ATH10K_STATE_ON)
> +		ath10k_regd_update(ar);
> +
>   	ret = ath10k_wmi_start_scan(ar, arg);
>   	if (ret)
>   		return ret;
>
> ////////////////////////////////////////
>
> ...But this sets a terrible penalty on performance when applied to
> background scan.
>
>
> On 12/14/16 20:58 Jouni Malinen wrote:
>>
>> On Tue, Dec 06, 2016 at 06:02:52PM +0100, Jean-Pierre Tosoni wrote:
>>> This follows on the previous discussion
>>> 	"Client station sends probes on DFS channels"
>>>
>>> Problem:
>>> The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
>>> wpa_supplicant do not comply with the norm ETSI/EN 301-893 section
>>> 4.7; because they can send probes for 600s when no AP is around.
>>>
>>> Analysis:
>>> The problem seems to lie in the firmware, which regards the presence
>>> of *any* beacon as a proof that the channel is radar-clean for 600s.
>>
>> I don't think this is really firmware, but cfg80211 regulatory code and
>> how it interacts with ath10k..
>>
>>> - there is no obvious fix working in ath10k.
>>> - the issue does not show up with other mac80211 devices like ath9k.
>>> - wpa_supplicant considers this is a kernel issue [2]
>>
>> There seems to be a difference between ath9k (mac80211-based Probe Request
>> frame sending) and ath10k (firmware) in this area for active scanning.
>> mac80211 uses IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR while ath10k
>> uses IEEE80211_CHAN_NO_IR. I'd assume this difference results in ath10k
>> using cfg80211 beacon hints (etc.) to update the NO_IR flag and that might
>> be behind the difference you see.
>>
>> Could you check whether the following change gets you the behavior you
>> want to see here? I have not had a chance to test this yet, but based on
>> code review, it looks like something that brings the same behavior to
>> ath10k that ath9k has for this through mac80211.
>>
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
>> b/drivers/net/wireless/ath/ath10k/mac.c
>> index aa545a1..758dbbd 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -2973,7 +2973,8 @@ static int ath10k_update_channel_list(struct ath10k
>> *ar)
>>   			ch->chan_radar =
>>   				!!(channel->flags & IEEE80211_CHAN_RADAR);
>>
>> -			passive = channel->flags & IEEE80211_CHAN_NO_IR;
>> +			passive = channel->flags & (IEEE80211_CHAN_NO_IR |
>> +						    IEEE80211_CHAN_RADAR);
>>   			ch->passive = passive;
>>
>>   			ch->freq = channel->center_freq;
>>
>> --
>> Jouni Malinen                                            PGP id EFC895FA
>>
>> _______________________________________________
>> 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 kvalo at qca.qualcomm.com  Thu Dec 15 08:40:24 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 15 Dec 2016 16:40:24 +0000
Subject: [RFC v2 11/11] ath10k: Added sdio support
In-Reply-To: <1479496971-19174-12-git-send-email-erik.stromdahl@gmail.com>
 (Erik Stromdahl's message of "Fri, 18 Nov 2016 20:22:51 +0100")
References: <1479496971-19174-1-git-send-email-erik.stromdahl@gmail.com>
 <1479496971-19174-12-git-send-email-erik.stromdahl@gmail.com>
Message-ID: <87oa0duow8.fsf@kamboji.qca.qualcomm.com>

Erik Stromdahl <erik.stromdahl at gmail.com> writes:

> Initial HIF sdio/mailbox implementation.
>
> Signed-off-by: Erik Stromdahl <erik.stromdahl at gmail.com>
> ---
>  drivers/net/wireless/ath/ath10k/Kconfig  |    6 +
>  drivers/net/wireless/ath/ath10k/Makefile |    3 +
>  drivers/net/wireless/ath/ath10k/sdio.c   | 1860 ++++++++++++++++++++++++++++++
>  drivers/net/wireless/ath/ath10k/sdio.h   |  276 +++++
>  4 files changed, 2145 insertions(+)
>  create mode 100644 drivers/net/wireless/ath/ath10k/sdio.c
>  create mode 100644 drivers/net/wireless/ath/ath10k/sdio.h

AFAIK the sdio firmware binary is different from pci and usb. And as all
the firmware images need to coexist in the same repository I suspect we
can't continue to use firmware-N.bin for both pcie and sdio (and in
future usb). So should we somehow rename the sdio firmware filename to
something else, like firmware-sdio-N.bin?

-- 
Kalle Valo

From mohammed at codeaurora.org  Thu Dec 15 08:43:39 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Thu, 15 Dec 2016 22:13:39 +0530
Subject: [PATCH 1/2] ath10k: add accounting for the extended peer
 statistics
In-Reply-To: <20161215162659.GA8030@atheros-ThinkPad-T61>
References: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
 <2870294.lMmxz9iPmq@debian64>
 <20161214073337.GA4046@atheros-ThinkPad-T61>
 <1859306.unY1Rqbrx8@debian64>
 <20161215162659.GA8030@atheros-ThinkPad-T61>
Message-ID: <20161215164338.GB8030@atheros-ThinkPad-T61>

Hi Christian,

I am also thinking, as of now there is not much use in appending
the extended peer stats (which gets periodically ) to the linked list
'&ar->debug.fw_stats.peers_extd)'  and should we get rid of the below
(and the required cleanup as well) 

list_splice_tail_init(&stats.peers_extd,
		&ar->debug.fw_stats.peers_extd);


since rx_duration is getting updated periodically to the per sta
information. Kindly let me know your thoughts about this.

regards,
shafi

On Thu, Dec 15, 2016 at 09:56:59PM +0530, Mohammed Shafi Shajakhan wrote:
> Hello Christian,
> 
> On Wed, Dec 14, 2016 at 05:38:02PM +0100, Christian Lamparter wrote:
> > On Wednesday, December 14, 2016 1:03:38 PM CET Mohammed Shafi Shajakhan wrote:
> > > > On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Shafi Shajakhan wrote:
> > > > > On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote:
> > > > > > @@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> > > > > >  			goto free;
> > > > > >  		}
> > > > > >  
> > > > > > +		if (!list_empty(&stats.peers))
> > > > > 
> > > > > [shafi] sorry please correct me if i am wrong, for 'extended peer stats' we are checking
> > > > > for normal 'peer stats' ? Is this the fix intended, i had started a build to
> > > > > check your change and we will keep you posted, does this fix displaying
> > > > > 'rx_duration' in ath10k fw_stats.
> > > > The idea is not to queue any "extended peer stats" when there where no "peer stats" to
> > > > begin with. Because otherwise, the function is still vulnerable to OOM since the 
> > > > extended peers stats will be queued unchecked (not that this is currently a problem).
> > > 
> > > [shafi] list_splice_tail_init should still check for non-empty 'peers_extd' list
> > > and append if required ? please let me know if i am still missing something
> > Well, you can also count the entries in peers_extd and delete the old entries
> > if they start to overflow. If you want to do it differently, please go ahead.
> >
> [shafi] sorry for the delay (got stuck up with something else), I will add some prints explicitly
> and keep you posted ASAP. Since the extended peer stats gets updated periodically I
> would like to confirm the debug linked list associated to the extended peer
> stats does not overflows and potentially cause OOM.
> 
> regards,
> shafi


From chunkeey at googlemail.com  Thu Dec 15 09:24:13 2016
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Thu, 15 Dec 2016 18:24:13 +0100
Subject: [PATCH 1/2] ath10k: add accounting for the extended peer
 statistics
In-Reply-To: <20161215164338.GB8030@atheros-ThinkPad-T61>
References: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
 <20161215162659.GA8030@atheros-ThinkPad-T61>
 <20161215164338.GB8030@atheros-ThinkPad-T61>
Message-ID: <2970240.ih558OrmaK@debian64>

Hello Shafi,

On Thursday, December 15, 2016 10:13:39 PM CET Mohammed Shafi Shajakhan wrote:
> I am also thinking, as of now there is not much use in appending
> the extended peer stats (which gets periodically ) to the linked list
> '&ar->debug.fw_stats.peers_extd)'  and should we get rid of the below
> (and the required cleanup as well) 
> 
> list_splice_tail_init(&stats.peers_extd,
> 		&ar->debug.fw_stats.peers_extd);
> 
> 
> since rx_duration is getting updated periodically to the per sta
> information. Kindly let me know your thoughts about this.

Yes, of course. I see what your are trying to do and I think it's much better
to get rid of peers_extd and ath10k_fw_extd_stats_peers_free.

Regards,
Christian


From erik.stromdahl at gmail.com  Thu Dec 15 12:52:16 2016
From: erik.stromdahl at gmail.com (Erik Stromdahl)
Date: Thu, 15 Dec 2016 21:52:16 +0100
Subject: [RFC v2 11/11] ath10k: Added sdio support
In-Reply-To: <87oa0duow8.fsf@kamboji.qca.qualcomm.com>
References: <1479496971-19174-1-git-send-email-erik.stromdahl@gmail.com>
 <1479496971-19174-12-git-send-email-erik.stromdahl@gmail.com>
 <87oa0duow8.fsf@kamboji.qca.qualcomm.com>
Message-ID: <4d9b8000-47c1-3537-1e76-12c0dfa7d382@gmail.com>



On 12/15/2016 05:40 PM, Valo, Kalle wrote:
> Erik Stromdahl <erik.stromdahl at gmail.com> writes:
> 
>> Initial HIF sdio/mailbox implementation.
>>
>> Signed-off-by: Erik Stromdahl <erik.stromdahl at gmail.com>
>> ---
>>  drivers/net/wireless/ath/ath10k/Kconfig  |    6 +
>>  drivers/net/wireless/ath/ath10k/Makefile |    3 +
>>  drivers/net/wireless/ath/ath10k/sdio.c   | 1860 ++++++++++++++++++++++++++++++
>>  drivers/net/wireless/ath/ath10k/sdio.h   |  276 +++++
>>  4 files changed, 2145 insertions(+)
>>  create mode 100644 drivers/net/wireless/ath/ath10k/sdio.c
>>  create mode 100644 drivers/net/wireless/ath/ath10k/sdio.h
> 
> AFAIK the sdio firmware binary is different from pci and usb. And as all
> the firmware images need to coexist in the same repository I suspect we
> can't continue to use firmware-N.bin for both pcie and sdio (and in
> future usb). So should we somehow rename the sdio firmware filename to
> something else, like firmware-sdio-N.bin?
> 
I suppose you are right. I would be surprised if the firmware images
were the same for sdio, usb and pci. Hopefully all sdio chipsets sharing
the same device id and BMI version will use the same firmware image.
Currently, these two params are the only two that are used when
selecting firmware.

struct bmi_target_info also has a type parameter, but I can't see it
being used anywhere in the code.

If it turns out that several sdio chipsets uses the same BMI version and
device id, this parameter might be used (together with the other two) to
select hw params.


From jp.tosoni at acksys.fr  Thu Dec 15 09:53:47 2016
From: jp.tosoni at acksys.fr (Jean-Pierre Tosoni)
Date: Thu, 15 Dec 2016 18:53:47 +0100
Subject: ath10k firmware sends probes on DFS channels without radar
 detection
In-Reply-To: <5852C5AC.6090408@candelatech.com>
References: <004a01d24fe2$94da8dc0$be8fa940$@acksys.fr>
 <20161214195805.GA15022@w1.fi> <00f501d256e7$0f8d5380$2ea7fa80$@acksys.fr>
 <5852C5AC.6090408@candelatech.com>
Message-ID: <00fd01d256fc$2f780db0$8e682910$@acksys.fr>

> -----Message d'origine-----
> De?: Ben Greear [mailto:greearb at candelatech.com]
> Envoy??: jeudi 15 d?cembre 2016 17:33
> ??: Jean-Pierre Tosoni; 'Jouni Malinen'
> Cc?: linux-wireless at vger.kernel.org; ath10k at lists.infradead.org
> Objet?: Re: ath10k firmware sends probes on DFS channels without radar
> detection
> 
> On 12/15/2016 07:22 AM, Jean-Pierre Tosoni wrote:
> > Jouni,
> >
> > Thanks for the suggestion, I already tried something like this in
> > wmi.c, with the same result:
> >
> > - Before patching the firmware scans DFS channels actively (with
> probes).
> >
> > - After patching, the firmware scans DFS channels passively *until*
> > any beacon is received on the DFS channel. When *any* beacon is seen,
> > the firmware decides to scan actively on its own, without any new
> > IR/RADAR info from the driver.
> >
> > So, your patch is required but not sufficient.
> >
> > Somehow I was able to overcome this by reloading the regulation domain
> > in the radio card before each scan request:
> >
> > ////// awful patch ahead ////////
> >
> > --- a/drivers/net/wireless/ath/ath10k/mac.c
> > +++ b/drivers/net/wireless/ath/ath10k/mac.c
> > @@ -2842,7 +2842,9 @@ static int ath10k_update_channel_list(st
> >   			ch->chan_radar =
> >   				!!(channel->flags & IEEE80211_CHAN_RADAR);
> >
> > -			passive = channel->flags & IEEE80211_CHAN_NO_IR;
> > +			passive = channel->flags & (IEEE80211_CHAN_NO_IR |
> > +						    IEEE80211_CHAN_RADAR);
> 
> So, should we add a new flag in firmware and driver that means 'really-no-
> IR', or should the NO_IR flag here just always make the firmware never do
> IR when probing regardless of whether it has seen beacons or not?

The distinction between NO_IR and CHAN_RADAR is not very clear to me.
NO_IR appears only in the world regulatory domain so it's not relevant here.

I'd say
 "the CHAN_RADAR flag should always make the firmware never do IR when
probing"
...maybe, except if the channel is the operating channel. (this should
exclude
unassociated stations)

I am out of office for the next week.
Regards,
Jean-Pierre
> 
> Thanks,
> Ben
> 
> > +
> >   			ch->passive = passive;
> >
> >   			ch->freq = channel->center_freq;
> > @@ -3548,6 +3550,9 @@ static int ath10k_start_scan(struct ath1
> >
> >   	lockdep_assert_held(&ar->conf_mutex);
> >
> > +	if (ar->state == ATH10K_STATE_ON)
> > +		ath10k_regd_update(ar);
> > +
> >   	ret = ath10k_wmi_start_scan(ar, arg);
> >   	if (ret)
> >   		return ret;
> >
> > ////////////////////////////////////////
> >
> > ...But this sets a terrible penalty on performance when applied to
> > background scan.
> >
> >
> > On 12/14/16 20:58 Jouni Malinen wrote:
> >>
> >> On Tue, Dec 06, 2016 at 06:02:52PM +0100, Jean-Pierre Tosoni wrote:
> >>> This follows on the previous discussion
> >>> 	"Client station sends probes on DFS channels"
> >>>
> >>> Problem:
> >>> The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
> >>> wpa_supplicant do not comply with the norm ETSI/EN 301-893 section
> >>> 4.7; because they can send probes for 600s when no AP is around.
> >>>
> >>> Analysis:
> >>> The problem seems to lie in the firmware, which regards the presence
> >>> of *any* beacon as a proof that the channel is radar-clean for 600s.
> >>
> >> I don't think this is really firmware, but cfg80211 regulatory code
> >> and how it interacts with ath10k..
> >>
> >>> - there is no obvious fix working in ath10k.
> >>> - the issue does not show up with other mac80211 devices like ath9k.
> >>> - wpa_supplicant considers this is a kernel issue [2]
> >>
> >> There seems to be a difference between ath9k (mac80211-based Probe
> >> Request frame sending) and ath10k (firmware) in this area for active
> scanning.
> >> mac80211 uses IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR while
> >> ath10k uses IEEE80211_CHAN_NO_IR. I'd assume this difference results
> >> in ath10k using cfg80211 beacon hints (etc.) to update the NO_IR flag
> >> and that might be behind the difference you see.
> >>
> >> Could you check whether the following change gets you the behavior
> >> you want to see here? I have not had a chance to test this yet, but
> >> based on code review, it looks like something that brings the same
> >> behavior to ath10k that ath9k has for this through mac80211.
> >>
> >>
> >> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> >> b/drivers/net/wireless/ath/ath10k/mac.c
> >> index aa545a1..758dbbd 100644
> >> --- a/drivers/net/wireless/ath/ath10k/mac.c
> >> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> >> @@ -2973,7 +2973,8 @@ static int ath10k_update_channel_list(struct
> >> ath10k
> >> *ar)
> >>   			ch->chan_radar =
> >>   				!!(channel->flags & IEEE80211_CHAN_RADAR);
> >>
> >> -			passive = channel->flags & IEEE80211_CHAN_NO_IR;
> >> +			passive = channel->flags & (IEEE80211_CHAN_NO_IR |
> >> +						    IEEE80211_CHAN_RADAR);
> >>   			ch->passive = passive;
> >>
> >>   			ch->freq = channel->center_freq;
> >>
> >> --
> >> Jouni Malinen                                            PGP id
> EFC895FA
> >>
> >> _______________________________________________
> >> 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 j at w1.fi  Thu Dec 15 14:58:27 2016
From: j at w1.fi (Jouni Malinen)
Date: Fri, 16 Dec 2016 00:58:27 +0200
Subject: ath10k firmware sends probes on DFS channels without radar
 detection
In-Reply-To: <00fd01d256fc$2f780db0$8e682910$@acksys.fr>
References: <004a01d24fe2$94da8dc0$be8fa940$@acksys.fr>
 <20161214195805.GA15022@w1.fi>
 <00f501d256e7$0f8d5380$2ea7fa80$@acksys.fr>
 <5852C5AC.6090408@candelatech.com>
 <00fd01d256fc$2f780db0$8e682910$@acksys.fr>
Message-ID: <20161215225827.GB24883@w1.fi>

On Thu, Dec 15, 2016 at 06:53:47PM +0100, Jean-Pierre Tosoni wrote:
> > > Thanks for the suggestion, I already tried something like this in
> > > wmi.c, with the same result:
> > >
> > > - Before patching the firmware scans DFS channels actively (with
> > probes).
> > >
> > > - After patching, the firmware scans DFS channels passively *until*
> > > any beacon is received on the DFS channel. When *any* beacon is seen,
> > > the firmware decides to scan actively on its own, without any new
> > > IR/RADAR info from the driver.
> > >
> > > So, your patch is required but not sufficient.
> > >
> > > Somehow I was able to overcome this by reloading the regulation domain
> > > in the radio card before each scan request:

Interesting.. I'm not completely sure what could have changed the
behavior based on beacon hint. I thought it was cfg80211, but if the
simple change for doing NO_IR | RADAR is not sufficient, it would seem
to imply that something else can do this. Some more debugging to do, I
guess.

> The distinction between NO_IR and CHAN_RADAR is not very clear to me.
> NO_IR appears only in the world regulatory domain so it's not relevant here.

NO_IR is a combination of not allowing AP, IBSS, or active scanning
without having somehow been enabled by another device. RADAR has that
same impact and in addition, requirement for doing radar detection and
DFS by a master device.

> I'd say
>  "the CHAN_RADAR flag should always make the firmware never do IR when
> probing"
> ...maybe, except if the channel is the operating channel. (this should
> exclude
> unassociated stations)

For most cases, I'd agree that active scanning should not be used on DFS
channels. That said, unicast Probe Request frame to the current AP while
associated could be a reasonable exception. In addition, WPS with PBC
depends on Probe Request frames to allow PBC session overlap detection,
so there might be sufficient justification to allow Probe Request frame
to be sent out for a very short duration (couple of seconds) after
seeing a Beacon frame on the channel for such special cases.

-- 
Jouni Malinen                                            PGP id EFC895FA


From mohammed at codeaurora.org  Thu Dec 15 21:24:18 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Fri, 16 Dec 2016 10:54:18 +0530
Subject: [PATCH 1/2] ath10k: add accounting for the extended peer
 statistics
In-Reply-To: <2970240.ih558OrmaK@debian64>
References: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
 <20161215162659.GA8030@atheros-ThinkPad-T61>
 <20161215164338.GB8030@atheros-ThinkPad-T61>
 <2970240.ih558OrmaK@debian64>
Message-ID: <20161216052418.GA8936@atheros-ThinkPad-T61>

Hi Christian,

> On Thursday, December 15, 2016 10:13:39 PM CET Mohammed Shafi Shajakhan wrote:
> > I am also thinking, as of now there is not much use in appending
> > the extended peer stats (which gets periodically ) to the linked list
> > '&ar->debug.fw_stats.peers_extd)'  and should we get rid of the below
> > (and the required cleanup as well) 
> > 
> > list_splice_tail_init(&stats.peers_extd,
> > 		&ar->debug.fw_stats.peers_extd);
> > 
> > 
> > since rx_duration is getting updated periodically to the per sta
> > information. Kindly let me know your thoughts about this.
> 
> Yes, of course. I see what your are trying to do and I think it's much better
> to get rid of peers_extd and ath10k_fw_extd_stats_peers_free.
>
[shafi] Feel free to post the change and I can test the same for you(next week) !
Let me know if you are busy on something else, I can take this up.
As discussed, the fix to free 'extd stats' when number of peers exceeds the range
is definitely needed. Thank you for looking into this.

thanks,
shafi



From tamizhchelvam at codeaurora.org  Thu Dec 15 21:53:52 2016
From: tamizhchelvam at codeaurora.org (Tamizh chelvam)
Date: Fri, 16 Dec 2016 11:23:52 +0530
Subject: [PATCH 2/4] cfg80211: Add new NL80211_CMD_SET_BTCOEX_PRIORITY to
 support BTCOEX
In-Reply-To: <1481645351.20412.34.camel@sipsolutions.net>
References: <1478610932-21954-1-git-send-email-c_traja@qti.qualcomm.com>
 <1478610932-21954-3-git-send-email-c_traja@qti.qualcomm.com>
 <1480949353.31788.27.camel@sipsolutions.net>
 <5e5e8971c96293a81e7cb37bcdfbd593@codeaurora.org>
 <1481645351.20412.34.camel@sipsolutions.net>
Message-ID: <134cc8e58ecb804b6dda0137c4c37be8@codeaurora.org>

Hi Johannes,

Thanks for the comments

On 2016-12-13 21:39, Johannes Berg wrote:
>> > > ?/**
>> > > + * wiphy_btcoex_support_flags
>> > > + *	This enum has the driver supported frame types for
>> > > BTCOEX.
>> > > + * @WIPHY_WLAN_BE_PREFERRED - Supports Best Effort frame for
>> > > BTCOEX
>> > > + * @WIPHY_WLAN_BK_PREFERRED - supports Background frame for
>> > > BTCOEX
>> > > + * @WIPHY_WLAN_VI_PREFERRED - supports Video frame for BTCOEX
>> > > + * @WIPHY_WLAN_VO_PREFERRED - supports Voice frame for BTCOEX
>> > > + * @WIPHY_WLAN_BEACON_PREFERRED - supports Beacon frame for
>> > > BTCOEX
>> > > + * @WIPHY_WLAN_MGMT_PREFERRED - supports Management frames for
>> > > BTCOEX.
>> > > + */
>> >
>> > That's not making much sense to me?
>> >
>> 
>> is it fine to have as WIPHY_BTCOEX_BE_PREFERRED ?
> 
> It's not really clear to me what you intend to do this - if it's really
> support flags then you really should name those better.
> 
This is support flags and it used by the driver to intimate driver 
supported frame type
for the BTCOEX to cfg like "wiphy_wowlan_support_flags" implementation.
Please suggest if this is ok ? I will be thankful if you can suggest a 
better one if this is not ok
"WIPHY_BTCOEX_SUPPORTS_BE"

>> > > +/**
>> > > + * enum wiphy_btcoex_priority - BTCOEX priority level
>> > > + *	This enum defines priority level for BTCOEX
>> > > + * WIPHY_WLAN_PREFERRED_LOW - low priority frames over BT
>> > > traffic
>> > > + * WIPHY_WLAN_PREFERRED_HIGH - high priority frames over BT
>> > > traffic
>> > > + */
>> > > +
>> > > +enum wiphy_btcoex_priority {
>> > > +	WIPHY_WLAN_PREFERRED_LOW = false,
>> > > +	WIPHY_WLAN_PREFERRED_HIGH = true,
>> > > +};
>> >
>> > That false/true seems just strange.
>> >
>> 
>> I will just use as a enum without assigning false/true.
> 
> What do you even need this enum for though?
> 
Ok. I will directly assign true for the flag.

>> > > +enum nl80211_btcoex_priority {
>> > > +	__NL80211_WLAN_PREFERRED_INVALID,
>> > > +	NL80211_WLAN_BE_PREFERRED,
>> > > +	NL80211_WLAN_BK_PREFERRED,
>> > > +	NL80211_WLAN_VI_PREFERRED,
>> > > +	NL80211_WLAN_VO_PREFERRED,
>> > > +	NL80211_WLAN_BEACON_PREFERRED,
>> > > +	NL80211_WLAN_MGMT_PREFERRED,
>> > > +	__NL80211_WLAN_PREFERRED_LAST,
>> > > +	NL80211_WLAN_PREFERRED_MAX =
>> > > +			__NL80211_WLAN_PREFERRED_LAST - 1,
>> > > +};
>> >
>> > Wouldn't a bitmap be easier?
>> >
>> since this is to distinguish between different btcoex priorities and
>> we?
>> are not going to do any manipulations on these parameters.
>> It is just used as flag attribute.
> 
> But why the (parsing) complexity, when a single bitmap would do?
> 
Do you mean to say, sending a value from user space and parse that in 
the driver?



From johannes at sipsolutions.net  Fri Dec 16 01:37:04 2016
From: johannes at sipsolutions.net (Johannes Berg)
Date: Fri, 16 Dec 2016 10:37:04 +0100
Subject: [PATCH 2/4] cfg80211: Add new NL80211_CMD_SET_BTCOEX_PRIORITY
 to support BTCOEX
In-Reply-To: <134cc8e58ecb804b6dda0137c4c37be8@codeaurora.org>
References: <1478610932-21954-1-git-send-email-c_traja@qti.qualcomm.com>
 <1478610932-21954-3-git-send-email-c_traja@qti.qualcomm.com>
 <1480949353.31788.27.camel@sipsolutions.net>
 <5e5e8971c96293a81e7cb37bcdfbd593@codeaurora.org>
 <1481645351.20412.34.camel@sipsolutions.net>
 <134cc8e58ecb804b6dda0137c4c37be8@codeaurora.org>
Message-ID: <1481881024.27953.14.camel@sipsolutions.net>

> > > is it fine to have as WIPHY_BTCOEX_BE_PREFERRED ?
> > 
> > It's not really clear to me what you intend to do this - if it's
> > really support flags then you really should name those better.
> > 
> 
> This is support flags and it used by the driver to intimate driver?
> supported frame type for the BTCOEX to cfg like
> "wiphy_wowlan_support_flags" implementation. Please suggest if this
> is ok ? I will be thankful if you can suggest a? better one if this
> is not ok "WIPHY_BTCOEX_SUPPORTS_BE"

Well, I see a few things here:

1) does it even make sense to split it out per AC? wouldn't it be weird
if you supported this only for VO and BK, and not the others, or
something like that?

2) Wouldn't it make more sense to define this in nl80211 and just pass
the bitmap through to userspace? That would save quite a bit of netlink
mangling complexity.

3) I think the naming is confusing - "WIPHY_BTCOEX_SUPPORTS_BE_PREF" or
so might be more appropriate?

> Do you mean to say, sending a value from user space and parse that
> in? the driver?

I was more thinking of the capability advertisement, but yeah, both
ways seems reasonable.

johannes


From kvalo at qca.qualcomm.com  Fri Dec 16 02:23:54 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Fri, 16 Dec 2016 10:23:54 +0000
Subject: [RFC v2 06/11] ath10k: htc: Added ATH10K_HTC_FLAG_BUNDLE_LSB
In-Reply-To: <1479496971-19174-7-git-send-email-erik.stromdahl@gmail.com>
 (Erik Stromdahl's message of "Fri, 18 Nov 2016 20:22:46 +0100")
References: <1479496971-19174-1-git-send-email-erik.stromdahl@gmail.com>
 <1479496971-19174-7-git-send-email-erik.stromdahl@gmail.com>
Message-ID: <877f70uq86.fsf@kamboji.qca.qualcomm.com>

Erik Stromdahl <erik.stromdahl at gmail.com> writes:

> Signed-off-by: Erik Stromdahl <erik.stromdahl at gmail.com>
> ---
>  drivers/net/wireless/ath/ath10k/htc.h |    2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/htc.h b/drivers/net/wireless/ath/ath10k/htc.h
> index f94b25a..2963694 100644
> --- a/drivers/net/wireless/ath/ath10k/htc.h
> +++ b/drivers/net/wireless/ath/ath10k/htc.h
> @@ -62,6 +62,8 @@ enum ath10k_htc_rx_flags {
>  	ATH10K_HTC_FLAG_BUNDLE_MASK     = 0xF0
>  };
>  
> +#define ATH10K_HTC_FLAG_BUNDLE_LSB         4
> +

I think you could fold patches from 6 to 11 into one patch. They are all
about adding code, and most of the commit logs are empty anyway.

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Fri Dec 16 03:21:52 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Fri, 16 Dec 2016 11:21:52 +0000
Subject: [RFC v2 11/11] ath10k: Added sdio support
In-Reply-To: <1479496971-19174-12-git-send-email-erik.stromdahl@gmail.com>
 (Erik Stromdahl's message of "Fri, 18 Nov 2016 20:22:51 +0100")
References: <1479496971-19174-1-git-send-email-erik.stromdahl@gmail.com>
 <1479496971-19174-12-git-send-email-erik.stromdahl@gmail.com>
Message-ID: <871sx8unjn.fsf@kamboji.qca.qualcomm.com>

Erik Stromdahl <erik.stromdahl at gmail.com> writes:

> Initial HIF sdio/mailbox implementation.
>
> Signed-off-by: Erik Stromdahl <erik.stromdahl at gmail.com>

I know most of this coming from ath6kl but I think we should still
improve the code. Lots of comments will follow, don't get scared :)

> +#define CALC_TXRX_PADDED_LEN(ar_sdio, len) \
> +	(__ALIGN_MASK((len), (ar_sdio)->mbox_info.block_mask))

I think this could be a proper static inline function. Andrew Morton
once said: "Write in C, not CPP" (or something like that), I think
that's a really good point.

> +static int ath10k_sdio_read_write_sync(struct ath10k *ar, u32 addr, u8 *buf,
> +				       u32 len, u32 request);
> +static int ath10k_sdio_hif_diag_read(struct ath10k *ar, u32 address, void *buf,
> +				     size_t buf_len);
> +static int ath10k_sdio_hif_diag_read32(struct ath10k *ar, u32 address,
> +				       u32 *value);

We prefer to avoid forward declarations if at all possible. I didn't
check but if there's a clean way to avoid these please remove them.

> +/* HIF mbox interrupt handling */
> +
> +static int ath10k_sdio_mbox_rx_process_packet(struct ath10k_sdio *ar_sdio,
> +					      struct ath10k_sdio_rx_data *pkt,
> +					      u32 *lookaheads,
> +					      int *n_lookaheads)
> +{

So the style in ath10k is that all functions (of course this doesn't
apply to callbacks etc) have "struct ath10k *ar" as the first parameter.
This way there's no need to check if a function takes ar or ar_sdio.

> +	int status = 0;

In ath10k we prefer to use ret. And avoid initialising it, please.

> +	struct ath10k_htc *htc = &ar_sdio->ar->htc;
> +	struct sk_buff *skb = pkt->skb;
> +	struct ath10k_htc_hdr *htc_hdr = (struct ath10k_htc_hdr *)skb->data;
> +	bool trailer_present = htc_hdr->flags & ATH10K_HTC_FLAG_TRAILER_PRESENT;
> +	u16 payload_len;
> +
> +	payload_len = le16_to_cpu(htc_hdr->len);
> +
> +	if (trailer_present) {
> +		u8 *trailer;
> +		enum ath10k_htc_ep_id eid;
> +
> +		trailer = skb->data + sizeof(struct ath10k_htc_hdr) +
> +			  payload_len - htc_hdr->trailer_len;
> +
> +		eid = (enum ath10k_htc_ep_id)htc_hdr->eid;

A some kind of mapping function for ep id would be nice, it makes it
more visible how it works.

> +static int ath10k_sdio_mbox_rx_process_packets(struct ath10k_sdio *ar_sdio,
> +					       u32 lookaheads[],
> +					       int *n_lookahead)
> +{
> +	struct ath10k *ar = ar_sdio->ar;
> +	struct ath10k_htc *htc = &ar->htc;
> +	struct ath10k_sdio_rx_data *pkt;
> +	int status = 0, i;
> +
> +	for (i = 0; i < ar_sdio->n_rx_pkts; i++) {
> +		struct ath10k_htc_ep *ep;
> +		enum ath10k_htc_ep_id id;
> +		u32 *lookaheads_local = lookaheads;
> +		int *n_lookahead_local = n_lookahead;
> +
> +		id = ((struct ath10k_htc_hdr *)&lookaheads[i])->eid;
> +
> +		if (id >= ATH10K_HTC_EP_COUNT) {
> +			ath10k_err(ar, "Invalid endpoint in look-ahead: %d\n",
> +				   id);

In ath10k we use ath10k_err() for errors from which can't survive and
ath10k_warn() for errors where we try to continue. So ath10k_warn()
would be more approriate here and most of other cases in sdio.c

> +			status = -ENOMEM;
> +			goto out;
> +		}
> +
> +		ep = &htc->endpoint[id];
> +
> +		if (ep->service_id == 0) {
> +			ath10k_err(ar, "ep %d is not connected !\n", id);
> +			status = -ENOMEM;
> +			goto out;
> +		}
> +
> +		pkt = &ar_sdio->rx_pkts[i];
> +
> +		if (pkt->part_of_bundle && !pkt->last_in_bundle) {
> +			/* Only read lookahead's from RX trailers
> +			 * for the last packet in a bundle.
> +			 */
> +			lookaheads_local = NULL;
> +			n_lookahead_local = NULL;
> +		}
> +
> +		status = ath10k_sdio_mbox_rx_process_packet(ar_sdio,
> +							    pkt,
> +							    lookaheads_local,
> +							    n_lookahead_local);
> +		if (status)
> +			goto out;
> +
> +		ep->ep_ops.ep_rx_complete(ar_sdio->ar, pkt->skb);
> +		/* The RX complete handler now owns the skb...*/
> +		pkt->skb = NULL;
> +		pkt->alloc_len = 0;
> +	}
> +
> +out:
> +	/* Free all packets that was not passed on to the RX completion
> +	 * handler...
> +	 */
> +	for (; i < ar_sdio->n_rx_pkts; i++)
> +		ath10k_sdio_mbox_free_rx_pkt(&ar_sdio->rx_pkts[i]);

I got a bit fooled by not initialising i here and only then realised
why. I guess it's ok but a bit of so and so

> +
> +	return status;
> +}
> +
> +static int alloc_pkt_bundle(struct ath10k *ar,
> +			    struct ath10k_sdio_rx_data *rx_pkts,
> +			    struct ath10k_htc_hdr *htc_hdr,
> +			    size_t full_len, size_t act_len, size_t *bndl_cnt)
> +{
> +	int i, status = 0;
> +
> +	*bndl_cnt = (htc_hdr->flags & ATH10K_HTC_FLAG_BUNDLE_MASK) >>
> +		    ATH10K_HTC_FLAG_BUNDLE_LSB;

We recently got FIELD_GET() and FIELD_PREP() to kernel for handling
bitmasks. ath10k is not yet converted (patches welcome!) but it would be
good to use those already in sdio.c. Also SM() could be replaced with
those.

> +int ath10k_sdio_mbox_rxmsg_pending_handler(struct ath10k_sdio *ar_sdio,
> +					   u32 msg_lookahead, bool *done)
> +{
> +	struct ath10k *ar = ar_sdio->ar;
> +	int status = 0;
> +	u32 lookaheads[ATH10K_SDIO_MAX_RX_MSGS];
> +	int n_lookaheads = 1;
> +
> +	*done = true;
> +
> +	/* Copy the lookahead obtained from the HTC register table into our
> +	 * temp array as a start value.
> +	 */
> +	lookaheads[0] = msg_lookahead;
> +
> +	for (;;) {

Iternal loops in kernel can be dangerous. Better to add some sort of
timeout check with a warning message, something like:

while ((time_before(jiffies, timeout)) {
}

if (timed out)
        ath10k_warn("timeout in foo");

> +		/* Try to allocate as many HTC RX packets indicated by
> +		 * n_lookaheads.
> +		 */
> +		status = ath10k_sdio_mbox_rx_alloc(ar_sdio, lookaheads,
> +						   n_lookaheads);
> +		if (status)
> +			break;
> +
> +		if (ar_sdio->n_rx_pkts >= 2)
> +			/* A recv bundle was detected, force IRQ status
> +			 * re-check again.
> +			 */
> +			*done = false;
> +
> +		status = ath10k_sdio_mbox_rx_fetch(ar_sdio);
> +
> +		/* Process fetched packets. This will potentially update
> +		 * n_lookaheads depending on if the packets contain lookahead
> +		 * reports.
> +		 */
> +		n_lookaheads = 0;
> +		status = ath10k_sdio_mbox_rx_process_packets(ar_sdio,
> +							     lookaheads,
> +							     &n_lookaheads);
> +
> +		if (!n_lookaheads || status)
> +			break;
> +
> +		/* For SYNCH processing, if we get here, we are running
> +		 * through the loop again due to updated lookaheads. Set
> +		 * flag that we should re-check IRQ status registers again
> +		 * before leaving IRQ processing, this can net better
> +		 * performance in high throughput situations.
> +		 */
> +		*done = false;
> +	}
> +
> +	if (status && (status != -ECANCELED))
> +		ath10k_err(ar, "failed to get pending recv messages: %d\n",
> +			   status);
> +
> +	if (atomic_read(&ar_sdio->stopping)) {
> +		ath10k_warn(ar, "host is going to stop. Turning of RX\n");
> +		ath10k_sdio_hif_rx_control(ar_sdio, false);
> +	}

I'm always skeptic when I use atomic variables used like this, I doubt
it's really correct.

> +
> +	return status;
> +}
> +
> +static int ath10k_sdio_mbox_proc_dbg_intr(struct ath10k_sdio *ar_sdio)
> +{
> +	int ret;
> +	u32 dummy;
> +	struct ath10k *ar = ar_sdio->ar;
> +
> +	ath10k_warn(ar, "firmware crashed\n");

We have firmware crash dump support in ath10k. You could add a "TODO:"
comment about implementing that later.

> +static int ath10k_sdio_mbox_proc_err_intr(struct ath10k_sdio *ar_sdio)
> +{
> +	int status;
> +	u8 error_int_status;
> +	u8 reg_buf[4];
> +	struct ath10k_sdio_irq_data *irq_data = &ar_sdio->irq_data;
> +	struct ath10k *ar = ar_sdio->ar;
> +
> +	ath10k_dbg(ar, ATH10K_DBG_SDIO, "error interrupt\n");
> +
> +	error_int_status = irq_data->irq_proc_reg.error_int_status & 0x0F;
> +	if (!error_int_status) {
> +		WARN_ON(1);
> +		return -EIO;
> +	}
> +
> +	ath10k_dbg(ar, ATH10K_DBG_SDIO,
> +		   "valid interrupt source(s) in ERROR_INT_STATUS: 0x%x\n",
> +		   error_int_status);
> +
> +	if (MS(error_int_status, MBOX_ERROR_INT_STATUS_WAKEUP))
> +		ath10k_dbg(ar, ATH10K_DBG_SDIO, "error : wakeup\n");
> +
> +	if (MS(error_int_status, MBOX_ERROR_INT_STATUS_RX_UNDERFLOW))
> +		ath10k_err(ar, "rx underflow\n");
> +
> +	if (MS(error_int_status, MBOX_ERROR_INT_STATUS_TX_OVERFLOW))
> +		ath10k_err(ar, "tx overflow\n");
> +
> +	/* Clear the interrupt */
> +	irq_data->irq_proc_reg.error_int_status &= ~error_int_status;
> +
> +	/* set W1C value to clear the interrupt, this hits the register first */
> +	reg_buf[0] = error_int_status;
> +	reg_buf[1] = 0;
> +	reg_buf[2] = 0;
> +	reg_buf[3] = 0;
> +
> +	status = ath10k_sdio_read_write_sync(ar,
> +					     MBOX_ERROR_INT_STATUS_ADDRESS,
> +					     reg_buf, 4, HIF_WR_SYNC_BYTE_FIX);
> +
> +	WARN_ON(status);

This is a bit dangerous, in worst case it can spam the kernel log and
force a host reboot due watchdog timing out etc.

Better to replace with standard warning message:

ret = ath10k_sdio_read_write_sync(ar,
				     MBOX_ERROR_INT_STATUS_ADDRESS,
				     reg_buf, 4, HIF_WR_SYNC_BYTE_FIX);
if (ret) {
        ath10k_warn("failed to read interrupr status: %d", ret);
        return ret;
}

> +static int ath10k_sdio_mbox_proc_cpu_intr(struct ath10k_sdio *ar_sdio)
> +{
> +	int status;
> +	struct ath10k_sdio_irq_data *irq_data = &ar_sdio->irq_data;
> +	struct ath10k *ar = ar_sdio->ar;
> +	u8 cpu_int_status, reg_buf[4];
> +
> +	cpu_int_status = irq_data->irq_proc_reg.cpu_int_status &
> +			 irq_data->irq_en_reg.cpu_int_status_en;
> +	if (!cpu_int_status) {
> +		WARN_ON(1);
> +		return -EIO;
> +	}

Ditto about WARN_ON(), ath10k_warn() is much better.

> +/* process pending interrupts synchronously */
> +static int ath10k_sdio_mbox_proc_pending_irqs(struct ath10k_sdio *ar_sdio,
> +					      bool *done)
> +{
> +	struct ath10k_sdio_irq_data *irq_data = &ar_sdio->irq_data;
> +	struct ath10k *ar = ar_sdio->ar;
> +	struct ath10k_sdio_irq_proc_registers *rg;
> +	int status = 0;
> +	u8 host_int_status = 0;
> +	u32 lookahead = 0;
> +	u8 htc_mbox = 1 << ATH10K_HTC_MAILBOX;
> +
> +	/* NOTE: HIF implementation guarantees that the context of this
> +	 * call allows us to perform SYNCHRONOUS I/O, that is we can block,
> +	 * sleep or call any API that can block or switch thread/task
> +	 * contexts. This is a fully schedulable context.
> +	 */
> +
> +	/* Process pending intr only when int_status_en is clear, it may
> +	 * result in unnecessary bus transaction otherwise. Target may be
> +	 * unresponsive at the time.
> +	 */
> +	if (irq_data->irq_en_reg.int_status_en) {
> +		/* Read the first sizeof(struct ath10k_irq_proc_registers)
> +		 * bytes of the HTC register table. This
> +		 * will yield us the value of different int status
> +		 * registers and the lookahead registers.
> +		 */
> +		status = ath10k_sdio_read_write_sync(
> +				ar,
> +				MBOX_HOST_INT_STATUS_ADDRESS,
> +				(u8 *)&irq_data->irq_proc_reg,
> +				sizeof(irq_data->irq_proc_reg),
> +				HIF_RD_SYNC_BYTE_INC);
> +		if (status)
> +			goto out;
> +
> +		/* Update only those registers that are enabled */
> +		host_int_status = irq_data->irq_proc_reg.host_int_status &
> +				  irq_data->irq_en_reg.int_status_en;
> +
> +		/* Look at mbox status */
> +		if (host_int_status & htc_mbox) {
> +			/* Mask out pending mbox value, we use look ahead as
> +			 * the real flag for mbox processing.
> +			 */
> +			host_int_status &= ~htc_mbox;
> +			if (irq_data->irq_proc_reg.rx_lookahead_valid &
> +			    htc_mbox) {
> +				rg = &irq_data->irq_proc_reg;
> +				lookahead = le32_to_cpu(
> +					rg->rx_lookahead[ATH10K_HTC_MAILBOX]);
> +				if (!lookahead)
> +					ath10k_err(ar, "lookahead is zero!\n");
> +			}
> +		}
> +	}
> +
> +	if (!host_int_status && !lookahead) {
> +		*done = true;
> +		goto out;
> +	}
> +
> +	if (lookahead) {
> +		ath10k_dbg(ar, ATH10K_DBG_SDIO,
> +			   "pending mailbox msg, lookahead: 0x%08X\n",
> +			   lookahead);
> +
> +		status = ath10k_sdio_mbox_rxmsg_pending_handler(ar_sdio,
> +								lookahead,
> +								done);
> +		if (status)
> +			goto out;
> +	}
> +
> +	/* now, handle the rest of the interrupts */
> +	ath10k_dbg(ar, ATH10K_DBG_SDIO,
> +		   "valid interrupt source(s) for other interrupts: 0x%x\n",
> +		   host_int_status);
> +
> +	if (MS(host_int_status, MBOX_HOST_INT_STATUS_CPU)) {
> +		/* CPU Interrupt */
> +		status = ath10k_sdio_mbox_proc_cpu_intr(ar_sdio);
> +		if (status)
> +			goto out;
> +	}
> +
> +	if (MS(host_int_status, MBOX_HOST_INT_STATUS_ERROR)) {
> +		/* Error Interrupt */
> +		status = ath10k_sdio_mbox_proc_err_intr(ar_sdio);
> +		if (status)
> +			goto out;
> +	}
> +
> +	if (MS(host_int_status, MBOX_HOST_INT_STATUS_COUNTER))
> +		/* Counter Interrupt */
> +		status = ath10k_sdio_mbox_proc_counter_intr(ar_sdio);
> +
> +out:
> +	/* An optimization to bypass reading the IRQ status registers
> +	 * unecessarily which can re-wake the target, if upper layers
> +	 * determine that we are in a low-throughput mode, we can rely on
> +	 * taking another interrupt rather than re-checking the status
> +	 * registers which can re-wake the target.
> +	 *
> +	 * NOTE : for host interfaces that makes use of detecting pending
> +	 * mbox messages at hif can not use this optimization due to
> +	 * possible side effects, SPI requires the host to drain all
> +	 * messages from the mailbox before exiting the ISR routine.
> +	 */
> +
> +	ath10k_dbg(ar, ATH10K_DBG_SDIO,
> +		   "%s: (done:%d, status=%d)\n", __func__, *done, status);

We try to follow this kind of format for debug messages:

"sdio pending irqs done %d status %d"

So start with the debug level name followed by the debug separated with spaces.

And IIRC no need for "\n", the macro adds that automatically.

> +
> +	return status;
> +}
> +
> +/* Macro to check if DMA buffer is WORD-aligned and DMA-able.
> + * Most host controllers assume the buffer is DMA'able and will
> + * bug-check otherwise (i.e. buffers on the stack). virt_addr_valid
> + * check fails on stack memory.
> + */
> +static inline bool buf_needs_bounce(u8 *buf)
> +{
> +	return ((unsigned long)buf & 0x3) || !virt_addr_valid(buf);
> +}

IS_ALIGNED()? And this is super ugly, do we really need this? I would
much prefer that we would directly use struct sk_buff, more of that
later.

> +static inline enum ath10k_htc_ep_id pipe_id_to_eid(u8 pipe_id)
> +{
> +	return (enum ath10k_htc_ep_id)pipe_id;
> +}

Oh, we already have a this kind of mapping function? Can't this be used
earlier?

> +static void ath10k_sdio_set_mbox_info(struct ath10k_sdio *ar_sdio)
> +{
> +	struct ath10k_mbox_info *mbox_info = &ar_sdio->mbox_info;
> +	u16 device = ar_sdio->func->device;
> +
> +	mbox_info->htc_addr = ATH10K_HIF_MBOX_BASE_ADDR;
> +	mbox_info->block_size = ATH10K_HIF_MBOX_BLOCK_SIZE;
> +	mbox_info->block_mask = ATH10K_HIF_MBOX_BLOCK_SIZE - 1;
> +	mbox_info->gmbox_addr = ATH10K_HIF_GMBOX_BASE_ADDR;
> +	mbox_info->gmbox_sz = ATH10K_HIF_GMBOX_WIDTH;
> +
> +	mbox_info->ext_info[0].htc_ext_addr = ATH10K_HIF_MBOX0_EXT_BASE_ADDR;
> +
> +	if ((device & ATH10K_MANUFACTURER_ID_REV_MASK) < 4)
> +		mbox_info->ext_info[0].htc_ext_sz = ATH10K_HIF_MBOX0_EXT_WIDTH;
> +	else
> +		/* from rome 2.0(0x504), the width has been extended
> +		 * to 56K
> +		 */
> +		mbox_info->ext_info[0].htc_ext_sz =
> +			ATH10K_HIF_MBOX0_EXT_WIDTH_ROME_2_0;
> +
> +	mbox_info->ext_info[1].htc_ext_addr =
> +		mbox_info->ext_info[0].htc_ext_addr +
> +		mbox_info->ext_info[0].htc_ext_sz +
> +		ATH10K_HIF_MBOX_DUMMY_SPACE_SIZE;
> +	mbox_info->ext_info[1].htc_ext_sz = ATH10K_HIF_MBOX1_EXT_WIDTH;
> +}
> +
> +static inline void ath10k_sdio_set_cmd52_arg(u32 *arg, u8 write, u8 raw,
> +					     unsigned int address,
> +					     unsigned char val)
> +{
> +	const u8 func = 0;
> +
> +	*arg = ((write & 1) << 31) |
> +	       ((func & 0x7) << 28) |
> +	       ((raw & 1) << 27) |
> +	       (1 << 26) |
> +	       ((address & 0x1FFFF) << 9) |
> +	       (1 << 8) |
> +	       (val & 0xFF);
> +}

Quite ugly. FIELD_PREP() & co?

> +
> +static int ath10k_sdio_func0_cmd52_wr_byte(struct mmc_card *card,
> +					   unsigned int address,
> +					   unsigned char byte)
> +{
> +	struct mmc_command io_cmd;
> +
> +	memset(&io_cmd, 0, sizeof(io_cmd));
> +	ath10k_sdio_set_cmd52_arg(&io_cmd.arg, 1, 0, address, byte);
> +	io_cmd.opcode = SD_IO_RW_DIRECT;
> +	io_cmd.flags = MMC_RSP_R5 | MMC_CMD_AC;
> +
> +	return mmc_wait_for_cmd(card->host, &io_cmd, 0);
> +}
> +
> +static int ath10k_sdio_func0_cmd52_rd_byte(struct mmc_card *card,
> +					   unsigned int address,
> +					   unsigned char *byte)
> +{
> +	int ret;
> +	struct mmc_command io_cmd;
> +
> +	memset(&io_cmd, 0, sizeof(io_cmd));
> +	ath10k_sdio_set_cmd52_arg(&io_cmd.arg, 0, 0, address, 0);
> +	io_cmd.opcode = SD_IO_RW_DIRECT;
> +	io_cmd.flags = MMC_RSP_R5 | MMC_CMD_AC;
> +
> +	ret = mmc_wait_for_cmd(card->host, &io_cmd, 0);
> +	if (!ret)
> +		*byte = io_cmd.resp[0];
> +
> +	return ret;
> +}
> +
> +static int ath10k_sdio_io(struct ath10k_sdio *ar_sdio, u32 request, u32 addr,
> +			  u8 *buf, u32 len)
> +{
> +	int ret = 0;

Avoid these kind of unnecessary initialisations.

> +	struct sdio_func *func = ar_sdio->func;
> +	struct ath10k *ar = ar_sdio->ar;
> +
> +	sdio_claim_host(func);
> +
> +	if (request & HIF_WRITE) {
> +		if (request & HIF_FIXED_ADDRESS)
> +			ret = sdio_writesb(func, addr, buf, len);
> +		else
> +			ret = sdio_memcpy_toio(func, addr, buf, len);
> +	} else {
> +		if (request & HIF_FIXED_ADDRESS)
> +			ret = sdio_readsb(func, buf, addr, len);
> +		else
> +			ret = sdio_memcpy_fromio(func, buf, addr, len);
> +	}
> +
> +	sdio_release_host(func);
> +
> +	ath10k_dbg(ar, ATH10K_DBG_SDIO, "%s addr 0x%x%s buf 0x%p len %d\n",
> +		   request & HIF_WRITE ? "wr" : "rd", addr,
> +		   request & HIF_FIXED_ADDRESS ? " (fixed)" : "", buf, len);
> +	ath10k_dbg_dump(ar, ATH10K_DBG_SDIO_DUMP, NULL,
> +			request & HIF_WRITE ? "sdio wr " : "sdio rd ",
> +			buf, len);
> +
> +	return ret;
> +}
> +
> +static struct ath10k_sdio_bus_request
> +*ath10k_sdio_alloc_busreq(struct ath10k_sdio *ar_sdio)
> +{
> +	struct ath10k_sdio_bus_request *bus_req;
> +
> +	spin_lock_bh(&ar_sdio->lock);
> +
> +	if (list_empty(&ar_sdio->bus_req_freeq)) {
> +		spin_unlock_bh(&ar_sdio->lock);
> +		return NULL;
> +	}
> +
> +	bus_req = list_first_entry(&ar_sdio->bus_req_freeq,
> +				   struct ath10k_sdio_bus_request, list);
> +	list_del(&bus_req->list);
> +
> +	spin_unlock_bh(&ar_sdio->lock);
> +
> +	return bus_req;
> +}
> +
> +static void ath10k_sdio_free_bus_req(struct ath10k_sdio *ar_sdio,
> +				     struct ath10k_sdio_bus_request *bus_req)
> +{
> +	spin_lock_bh(&ar_sdio->lock);
> +	list_add_tail(&bus_req->list, &ar_sdio->bus_req_freeq);
> +	spin_unlock_bh(&ar_sdio->lock);
> +}
> +
> +static int ath10k_sdio_read_write_sync(struct ath10k *ar, u32 addr, u8 *buf,
> +				       u32 len, u32 request)
> +{
> +	struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
> +	u8  *tbuf = NULL;

Extra space after u8?

> +	int ret;
> +	bool bounced = false;
> +
> +	if (request & HIF_BLOCK_BASIS)
> +		len = round_down(len, ar_sdio->mbox_info.block_size);
> +
> +	if (buf_needs_bounce(buf)) {
> +		if (!ar_sdio->dma_buffer)
> +			return -ENOMEM;
> +		/* FIXME: I am not sure if it is always correct to assume
> +		 * that the SDIO irq is a "fake" irq and sleep is possible.
> +		 * (this function will get called from
> +		 * ath10k_sdio_irq_handler
> +		 */
> +		mutex_lock(&ar_sdio->dma_buffer_mutex);
> +		tbuf = ar_sdio->dma_buffer;
> +
> +		if (request & HIF_WRITE)
> +			memcpy(tbuf, buf, len);
> +
> +		bounced = true;
> +	} else {
> +		tbuf = buf;
> +	}

So I really hate that ar_sdio->dma_buffer, do we really need it? What if
we just get rid of it and allocate struct sk_buff and pass that around?
No need to do extra copying then, I hope :)

> +
> +	ret = ath10k_sdio_io(ar_sdio, request, addr, tbuf, len);
> +	if ((request & HIF_READ) && bounced)
> +		memcpy(buf, tbuf, len);
> +
> +	if (bounced)
> +		mutex_unlock(&ar_sdio->dma_buffer_mutex);
> +
> +	return ret;
> +}
> +
> +static void __ath10k_sdio_write_async(struct ath10k_sdio *ar_sdio,
> +				      struct ath10k_sdio_bus_request *req)
> +{
> +	int status;
> +	struct ath10k_htc_ep *ep;
> +	struct sk_buff *skb;
> +
> +	skb = req->skb;
> +	status = ath10k_sdio_read_write_sync(ar_sdio->ar, req->address,
> +					     skb->data, req->len,
> +					     req->request);
> +	ep = &ar_sdio->ar->htc.endpoint[req->eid];
> +	ath10k_htc_notify_tx_completion(ep, skb);
> +	ath10k_sdio_free_bus_req(ar_sdio, req);
> +}
> +
> +static void ath10k_sdio_write_async_work(struct work_struct *work)
> +{
> +	struct ath10k_sdio *ar_sdio;
> +	struct ath10k_sdio_bus_request *req, *tmp_req;
> +
> +	ar_sdio = container_of(work, struct ath10k_sdio, wr_async_work);
> +
> +	spin_lock_bh(&ar_sdio->wr_async_lock);
> +	list_for_each_entry_safe(req, tmp_req, &ar_sdio->wr_asyncq, list) {
> +		list_del(&req->list);
> +		spin_unlock_bh(&ar_sdio->wr_async_lock);
> +		__ath10k_sdio_write_async(ar_sdio, req);
> +		spin_lock_bh(&ar_sdio->wr_async_lock);
> +	}
> +	spin_unlock_bh(&ar_sdio->wr_async_lock);
> +}
> +
> +static void ath10k_sdio_irq_handler(struct sdio_func *func)
> +{
> +	int status = 0;
> +	unsigned long timeout;
> +	struct ath10k_sdio *ar_sdio;
> +	bool done = false;
> +
> +	ar_sdio = sdio_get_drvdata(func);
> +	atomic_set(&ar_sdio->irq_handling, 1);
> +
> +	/* Release the host during interrupts so we can pick it back up when
> +	 * we process commands.
> +	 */
> +	sdio_release_host(ar_sdio->func);
> +
> +	timeout = jiffies + ATH10K_SDIO_HIF_COMMUNICATION_TIMEOUT_HZ;
> +	while (time_before(jiffies, timeout) && !done) {
> +		status = ath10k_sdio_mbox_proc_pending_irqs(ar_sdio, &done);
> +		if (status)
> +			break;
> +	}
> +
> +	sdio_claim_host(ar_sdio->func);
> +
> +	atomic_set(&ar_sdio->irq_handling, 0);
> +	wake_up(&ar_sdio->irq_wq);
> +
> +	WARN_ON(status && status != -ECANCELED);
> +}

Questionable use of an atomic variable again, looks like badly implement
poor man's locking to me. And instead of wake_up() we should workqueues
or threaded irqs (if sdio supports that).

> +
> +static int ath10k_sdio_hif_disable_intrs(struct ath10k_sdio *ar_sdio)
> +{
> +	int ret;
> +	struct ath10k_sdio_irq_enable_reg regs;
> +	struct ath10k_sdio_irq_data *irq_data = &ar_sdio->irq_data;
> +
> +	memset(&regs, 0, sizeof(regs));
> +
> +	ret = ath10k_sdio_read_write_sync(ar_sdio->ar,
> +					  MBOX_INT_STATUS_ENABLE_ADDRESS,
> +					  &regs.int_status_en, sizeof(regs),
> +					  HIF_WR_SYNC_BYTE_INC);
> +	if (ret) {
> +		ath10k_err(ar_sdio->ar, "Unable to disable sdio interrupts\n");
> +		return ret;
> +	}
> +
> +	spin_lock_bh(&irq_data->lock);
> +	irq_data->irq_en_reg = regs;
> +	spin_unlock_bh(&irq_data->lock);
> +
> +	return 0;
> +}
> +
> +static int ath10k_sdio_hif_power_up(struct ath10k *ar)
> +{
> +	struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
> +	struct sdio_func *func = ar_sdio->func;
> +	int ret = 0;
> +
> +	if (!ar_sdio->is_disabled)
> +		return 0;
> +
> +	ath10k_dbg(ar, ATH10K_DBG_BOOT, "sdio power on\n");
> +
> +	sdio_claim_host(func);
> +
> +	ret = sdio_enable_func(func);
> +	if (ret) {
> +		ath10k_err(ar, "Unable to enable sdio func: %d)\n", ret);
> +		sdio_release_host(func);
> +		return ret;
> +	}
> +
> +	sdio_release_host(func);
> +
> +	/* Wait for hardware to initialise. It should take a lot less than
> +	 * 20 ms but let's be conservative here.
> +	 */
> +	msleep(20);
> +
> +	ar_sdio->is_disabled = false;
> +
> +	ret = ath10k_sdio_hif_disable_intrs(ar_sdio);
> +
> +	return ret;
> +}
> +
> +static void ath10k_sdio_hif_power_down(struct ath10k *ar)
> +{
> +	struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
> +	int ret;
> +
> +	if (ar_sdio->is_disabled)
> +		return;
> +
> +	ath10k_dbg(ar, ATH10K_DBG_BOOT, "sdio power off\n");
> +
> +	/* Disable the card */
> +	sdio_claim_host(ar_sdio->func);
> +	ret = sdio_disable_func(ar_sdio->func);
> +	sdio_release_host(ar_sdio->func);
> +
> +	if (ret)
> +		ath10k_dbg(ar, ATH10K_DBG_BOOT,
> +			   "Unable to disable sdio: %d\n", ret);

Shouldn't this be ath10k_warn()?

> +
> +	ar_sdio->is_disabled = true;
> +}
> +
> +int ath10k_sdio_hif_tx_sg(struct ath10k *ar, u8 pipe_id,
> +			  struct ath10k_hif_sg_item *items, int n_items)
> +{
> +	int i;
> +	u32 address;
> +	struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
> +	struct ath10k_sdio_bus_request *bus_req;
> +
> +	bus_req = ath10k_sdio_alloc_busreq(ar_sdio);
> +
> +	if (WARN_ON_ONCE(!bus_req))
> +		return -ENOMEM;

Is ath10k_warn() more approriate?

> +	for (i = 0; i < n_items; i++) {
> +		bus_req->skb = items[i].transfer_context;
> +		bus_req->request = HIF_WRITE;
> +		bus_req->eid = pipe_id_to_eid(pipe_id);
> +		/* Write TX data to the end of the mbox address space */
> +		address = ar_sdio->mbox_addr[bus_req->eid] +
> +			  ar_sdio->mbox_size[bus_req->eid] - bus_req->skb->len;
> +		bus_req->address = address;
> +		bus_req->len = CALC_TXRX_PADDED_LEN(ar_sdio, bus_req->skb->len);
> +
> +		spin_lock_bh(&ar_sdio->wr_async_lock);
> +		list_add_tail(&bus_req->list, &ar_sdio->wr_asyncq);
> +		spin_unlock_bh(&ar_sdio->wr_async_lock);
> +	}
> +
> +	queue_work(ar_sdio->workqueue, &ar_sdio->wr_async_work);
> +
> +	return 0;
> +}
> +
> +static int ath10k_sdio_hif_enable_intrs(struct ath10k_sdio *ar_sdio)
> +{
> +	struct ath10k_sdio_irq_enable_reg regs;
> +	int status;
> +	struct ath10k_sdio_irq_data *irq_data = &ar_sdio->irq_data;
> +
> +	memset(&regs, 0, sizeof(regs));
> +
> +	/* Enable all but CPU interrupts */
> +	regs.int_status_en = SM(0x01, MBOX_INT_STATUS_ENABLE_ERROR) |
> +			     SM(0x01, MBOX_INT_STATUS_ENABLE_CPU) |
> +			     SM(0x01, MBOX_INT_STATUS_ENABLE_COUNTER);
> +
> +	/* NOTE: There are some cases where HIF can do detection of
> +	 * pending mbox messages which is disabled now.
> +	 */
> +	regs.int_status_en |= SM(0x01, MBOX_INT_STATUS_ENABLE_MBOX_DATA);
> +
> +	/* Set up the CPU Interrupt status Register */
> +	regs.cpu_int_status_en = 0;
> +
> +	/* Set up the Error Interrupt status Register */
> +	regs.err_int_status_en =
> +		SM(0x01, MBOX_ERROR_STATUS_ENABLE_RX_UNDERFLOW) |
> +		SM(0x01, MBOX_ERROR_STATUS_ENABLE_TX_OVERFLOW);
> +
> +	/* Enable Counter interrupt status register to get fatal errors for
> +	 * debugging.
> +	 */
> +	regs.cntr_int_status_en = SM(ATH10K_SDIO_TARGET_DEBUG_INTR_MASK,
> +				     MBOX_COUNTER_INT_STATUS_ENABLE_BIT);
> +
> +	status = ath10k_sdio_read_write_sync(ar_sdio->ar,
> +					     MBOX_INT_STATUS_ENABLE_ADDRESS,
> +					     &regs.int_status_en, sizeof(regs),
> +					     HIF_WR_SYNC_BYTE_INC);
> +	if (status) {
> +		ath10k_err(ar_sdio->ar,
> +			   "failed to update interrupt ctl reg err: %d\n",
> +			   status);
> +		return status;
> +	}
> +
> +	spin_lock_bh(&irq_data->lock);
> +	irq_data->irq_en_reg = regs;
> +	spin_unlock_bh(&irq_data->lock);
> +
> +	return 0;
> +}
> +
> +static int ath10k_sdio_hif_start(struct ath10k *ar)
> +{
> +	int ret;
> +	struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
> +	u32 addr, val;
> +
> +	addr = host_interest_item_address(HI_ITEM(hi_acs_flags));
> +
> +	ret = ath10k_sdio_hif_diag_read32(ar, addr, &val);
> +	if (ret) {
> +		ath10k_err(ar, "Unable to read diag mem: %d\n", ret);
> +		goto out;
> +	}
> +
> +	if (val & HI_ACS_FLAGS_SDIO_SWAP_MAILBOX_FW_ACK) {
> +		ath10k_dbg(ar, ATH10K_DBG_SDIO,
> +			   "Mailbox SWAP Service is enabled\n");
> +		ar_sdio->swap_mbox = true;
> +	}
> +
> +	/* eid 0 always uses the lower part of the extended mailbox address
> +	 * space (ext_info[0].htc_ext_addr).
> +	 */
> +	ar_sdio->mbox_addr[0] = ar_sdio->mbox_info.ext_info[0].htc_ext_addr;
> +	ar_sdio->mbox_size[0] = ar_sdio->mbox_info.ext_info[0].htc_ext_sz;
> +
> +	sdio_claim_host(ar_sdio->func);
> +
> +	/* Register the isr */
> +	ret =  sdio_claim_irq(ar_sdio->func, ath10k_sdio_irq_handler);
> +	if (ret) {
> +		ath10k_err(ar, "Failed to claim sdio irq: %d\n", ret);
> +		sdio_release_host(ar_sdio->func);
> +		goto out;
> +	}
> +
> +	sdio_release_host(ar_sdio->func);
> +
> +	ret = ath10k_sdio_hif_enable_intrs(ar_sdio);
> +	if (ret)
> +		ath10k_err(ar, "Failed to enable sdio interrupts: %d\n", ret);
> +
> +out:
> +	return ret;
> +}
> +
> +static bool ath10k_sdio_is_on_irq(struct ath10k *ar)
> +{
> +	struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
> +
> +	return !atomic_read(&ar_sdio->irq_handling);
> +}

Yikes.

> +
> +static void ath10k_sdio_irq_disable(struct ath10k *ar)
> +{
> +	struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
> +	int ret;
> +
> +	sdio_claim_host(ar_sdio->func);
> +
> +	atomic_set(&ar_sdio->stopping, 1);
> +
> +	if (atomic_read(&ar_sdio->irq_handling)) {
> +		sdio_release_host(ar_sdio->func);
> +
> +		ret = wait_event_interruptible(ar_sdio->irq_wq,
> +					       ath10k_sdio_is_on_irq(ar));
> +		if (ret)
> +			return;
> +
> +		sdio_claim_host(ar_sdio->func);
> +	}

There has to be a better way to implement this, now it feels that it's
just reimplementing the wheel. We should have proper way to wait for
interrupt handlers and workqueues to end etc.

> +	ret = sdio_release_irq(ar_sdio->func);
> +	if (ret)
> +		ath10k_err(ar, "Failed to release sdio irq: %d\n", ret);
> +
> +	sdio_release_host(ar_sdio->func);
> +}
> +
> +static int ath10k_sdio_config(struct ath10k_sdio *ar_sdio)
> +{
> +	struct ath10k *ar = ar_sdio->ar;
> +	struct sdio_func *func = ar_sdio->func;
> +	unsigned char byte, asyncintdelay = 2;
> +	int ret;
> +
> +	ath10k_dbg(ar, ATH10K_DBG_BOOT, "SDIO configuration\n");
> +
> +	sdio_claim_host(func);
> +
> +	byte = 0;
> +	ret = ath10k_sdio_func0_cmd52_rd_byte(func->card,
> +					      SDIO_CCCR_DRIVE_STRENGTH,
> +					      &byte);
> +
> +	byte = (byte & (~(SDIO_DRIVE_DTSx_MASK << SDIO_DRIVE_DTSx_SHIFT))) |
> +		SDIO_DTSx_SET_TYPE_D;

FIELD_PREP(). There are lots of places where that an be used.

> +static void ath10k_sdio_write32(struct ath10k *ar, u32 offset, u32 value)
> +{
> +}
> +
> +static u32 ath10k_sdio_read32(struct ath10k *ar, u32 offset)
> +{
> +	return 0;
> +}

Somekind of FIXME/TODO comments for write32() and read32()? What
functionality are we going to miss when we don't implement these?

> +static void ath10k_sdio_hif_send_complete_check(struct ath10k *ar,
> +						u8 pipe, int force)
> +{
> +}
> +
> +static u16 ath10k_sdio_hif_get_free_queue_number(struct ath10k *ar, u8 pipe)
> +{
> +	return 0;
> +}

Similar comments here also.

> +
> +static const struct ath10k_hif_ops ath10k_sdio_hif_ops = {
> +	.tx_sg			= ath10k_sdio_hif_tx_sg,
> +	.diag_read		= ath10k_sdio_hif_diag_read,
> +	.diag_write		= ath10k_sdio_diag_write_mem,
> +	.exchange_bmi_msg	= ath10k_sdio_hif_exchange_bmi_msg,
> +	.start			= ath10k_sdio_hif_start,
> +	.stop			= ath10k_sdio_hif_stop,
> +	.map_service_to_pipe	= ath10k_sdio_hif_map_service_to_pipe,
> +	.get_default_pipe	= ath10k_sdio_hif_get_default_pipe,
> +	.send_complete_check	= ath10k_sdio_hif_send_complete_check,
> +	.get_free_queue_number	= ath10k_sdio_hif_get_free_queue_number,
> +	.power_up		= ath10k_sdio_hif_power_up,
> +	.power_down		= ath10k_sdio_hif_power_down,
> +	.read32			= ath10k_sdio_read32,
> +	.write32		= ath10k_sdio_write32,
> +#ifdef CONFIG_PM
> +	.suspend		= ath10k_sdio_hif_suspend,
> +	.resume			= ath10k_sdio_hif_resume,
> +#endif
> +	.fetch_cal_eeprom	= ath10k_sdio_hif_fetch_cal_eeprom,
> +};
> +
> +#ifdef CONFIG_PM_SLEEP
> +
> +/* Empty handlers so that mmc subsystem doesn't remove us entirely during
> + * suspend. We instead follow cfg80211 suspend/resume handlers.
> + */
> +static int ath10k_sdio_pm_suspend(struct device *device)
> +{
> +	return 0;
> +}
> +
> +static int ath10k_sdio_pm_resume(struct device *device)
> +{
> +	return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(ath10k_sdio_pm_ops, ath10k_sdio_pm_suspend,
> +			 ath10k_sdio_pm_resume);
> +
> +#define ATH10K_SDIO_PM_OPS (&ath10k_sdio_pm_ops)
> +
> +#else
> +
> +#define ATH10K_SDIO_PM_OPS NULL
> +
> +#endif /* CONFIG_PM_SLEEP */
> +
> +static int ath10k_sdio_probe(struct sdio_func *func,
> +			     const struct sdio_device_id *id)
> +{
> +	int ret;
> +	struct ath10k_sdio *ar_sdio;
> +	struct ath10k *ar;
> +	int i;
> +	enum ath10k_hw_rev hw_rev;
> +
> +	hw_rev = ATH10K_HW_QCA6174;

This needs a comment, at least to remind if ever add something else than
QCA6174 based SDIO design.

> +
> +	ar = ath10k_core_create(sizeof(*ar_sdio), &func->dev, ATH10K_BUS_SDIO,
> +				hw_rev, &ath10k_sdio_hif_ops);
> +	if (!ar) {
> +		dev_err(&func->dev, "failed to allocate core\n");
> +		return -ENOMEM;
> +	}
> +
> +	ath10k_dbg(ar, ATH10K_DBG_BOOT,
> +		   "sdio new func %d vendor 0x%x device 0x%x block 0x%x/0x%x\n",
> +		   func->num, func->vendor, func->device,
> +		   func->max_blksize, func->cur_blksize);
> +
> +	ar_sdio = ath10k_sdio_priv(ar);
> +
> +	ar_sdio->dma_buffer = kzalloc(ATH10K_HIF_DMA_BUFFER_SIZE, GFP_KERNEL);
> +	if (!ar_sdio->dma_buffer) {
> +		ret = -ENOMEM;
> +		goto err_core_destroy;
> +	}
> +
> +	ar_sdio->func = func;
> +	sdio_set_drvdata(func, ar_sdio);
> +
> +	ar_sdio->is_disabled = true;
> +	ar_sdio->ar = ar;
> +
> +	spin_lock_init(&ar_sdio->lock);
> +	spin_lock_init(&ar_sdio->wr_async_lock);
> +	spin_lock_init(&ar_sdio->irq_data.lock);
> +	mutex_init(&ar_sdio->dma_buffer_mutex);
> +
> +	INIT_LIST_HEAD(&ar_sdio->bus_req_freeq);
> +	INIT_LIST_HEAD(&ar_sdio->wr_asyncq);
> +
> +	INIT_WORK(&ar_sdio->wr_async_work, ath10k_sdio_write_async_work);
> +	ar_sdio->workqueue = create_singlethread_workqueue("ath10k_sdio_wq");
> +	if (!ar_sdio->workqueue)
> +		goto err;
> +
> +	init_waitqueue_head(&ar_sdio->irq_wq);
> +
> +	for (i = 0; i < ATH10K_SDIO_BUS_REQUEST_MAX_NUM; i++)
> +		ath10k_sdio_free_bus_req(ar_sdio, &ar_sdio->bus_req[i]);
> +
> +	ar->dev_id = id->device;
> +	ar->id.vendor = id->vendor;
> +	ar->id.device = id->device;
> +
> +	ath10k_sdio_set_mbox_info(ar_sdio);
> +
> +	ret = ath10k_sdio_config(ar_sdio);
> +	if (ret) {
> +		ath10k_err(ar, "Failed to config sdio: %d\n", ret);
> +		goto err;
> +	}
> +
> +	ret = ath10k_core_register(ar, 0/*chip_id is not applicaple for SDIO*/);
> +	if (ret) {
> +		ath10k_err(ar, "failed to register driver core: %d\n", ret);
> +		goto err;
> +	}

I would assume that chip_id is applicaple also with SDIO, there has to
be a register where to get it. Also this kind of comment style is
preferred:

/* TODO: don't know yet how to get chip_id with SDIO */
chip_id = 0;

ret = ath10k_core_register(ar, chip_id);

> +
> +	return ret;
> +
> +err:
> +	kfree(ar_sdio->dma_buffer);
> +err_core_destroy:
> +	ath10k_core_destroy(ar);
> +
> +	return ret;
> +}
> +
> +static void ath10k_sdio_remove(struct sdio_func *func)
> +{
> +	struct ath10k_sdio *ar_sdio;
> +	struct ath10k *ar;
> +
> +	ar_sdio = sdio_get_drvdata(func);
> +	ar = ar_sdio->ar;
> +
> +	ath10k_dbg(ar, ATH10K_DBG_BOOT,
> +		   "sdio removed func %d vendor 0x%x device 0x%x\n",
> +		   func->num, func->vendor, func->device);
> +
> +	(void)ath10k_sdio_hif_disable_intrs(ar_sdio);
> +	cancel_work_sync(&ar_sdio->wr_async_work);
> +	ath10k_core_unregister(ar);
> +	ath10k_core_destroy(ar);
> +
> +	kfree(ar_sdio->dma_buffer);
> +}
> +
> +static const struct sdio_device_id ath10k_sdio_devices[] = {
> +	{SDIO_DEVICE(ATH10K_MANUFACTURER_CODE,
> +		     (ATH10K_MANUFACTURER_ID_AR6005_BASE | 0xA))},
> +	{},
> +};

I suspect there's a more sensible way to create the device table than
this, just no time to check it now. Anyone know?

The naming "ath10k manufacturer" is also wrong, it should be QCA or
Qualcomm.

-- 
Kalle Valo

From chunkeey at googlemail.com  Sat Dec 17 09:46:34 2016
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Sat, 17 Dec 2016 18:46:34 +0100
Subject: [PATCH] ath10k: merge extended peer info data with existing peers info
In-Reply-To: <20161216052418.GA8936@atheros-ThinkPad-T61>
References: <20161216052418.GA8936@atheros-ThinkPad-T61>
Message-ID: <20161217174634.4531-1-chunkeey@googlemail.com>

The 10.4 firmware adds extended peer information to the
firmware's statistics payload. This additional info is
stored as a separate data field. During review of
"ath10k: add accounting for the extended peer statistics" [0]

Mohammed Shafi Shajakhan commented that the extended peer statistics
lists are of little use:"... there is not much use in appending
the extended peer stats (which gets periodically updated) to the
linked list '&ar->debug.fw_stats.peers_extd)' and should we get
rid of the below (and the required cleanup as well)

list_splice_tail_init(&stats.peers_extd,
                &ar->debug.fw_stats.peers_extd);

since rx_duration is getting updated periodically to the per sta
information."

This patch replaces the extended peers list with a lookup and
puts the retrieved data (rx_duration) into the existing
ath10k_fw_stats_peer entry that was created earlier.

[0] <https://lkml.kernel.org/r/992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey at googlemail.com>
Cc: Mohammed Shafi Shajakhan <mohammed at codeaurora.org>
Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>
---
 drivers/net/wireless/ath/ath10k/core.h        |  2 --
 drivers/net/wireless/ath/ath10k/debug.c       | 17 --------------
 drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 ++-----------------------
 drivers/net/wireless/ath/ath10k/wmi.c         | 34 ++++++++++++++++++++-------
 4 files changed, 28 insertions(+), 57 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 09ff8b8a6441..3fffbbb18c25 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -268,11 +268,9 @@ struct ath10k_fw_stats_pdev {
 };
 
 struct ath10k_fw_stats {
-	bool extended;
 	struct list_head pdevs;
 	struct list_head vdevs;
 	struct list_head peers;
-	struct list_head peers_extd;
 };
 
 #define ATH10K_TPC_TABLE_TYPE_FLAG	1
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 82a4c67f3672..89f7fde77cdf 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -315,25 +315,13 @@ 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);
 	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);
-	ath10k_fw_extd_stats_peers_free(&ar->debug.fw_stats.peers_extd);
 	spin_unlock_bh(&ar->data_lock);
 }
 
@@ -348,7 +336,6 @@ 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);
@@ -411,8 +398,6 @@ 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);
@@ -424,7 +409,6 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
 	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);
 }
@@ -2347,7 +2331,6 @@ 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/debugfs_sta.c b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
index fce6f8137d33..bf2d49cbb3bb 100644
--- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
+++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
@@ -18,27 +18,8 @@
 #include "wmi-ops.h"
 #include "debug.h"
 
-static void ath10k_sta_update_extd_stats_rx_duration(struct ath10k *ar,
-						     struct ath10k_fw_stats *stats)
-{
-	struct ath10k_fw_extd_stats_peer *peer;
-	struct ieee80211_sta *sta;
-	struct ath10k_sta *arsta;
-
-	rcu_read_lock();
-	list_for_each_entry(peer, &stats->peers_extd, 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 ath10k_fw_stats *stats)
+void ath10k_sta_update_rx_duration(struct ath10k *ar,
+				   struct ath10k_fw_stats *stats)
 {
 	struct ath10k_fw_stats_peer *peer;
 	struct ieee80211_sta *sta;
@@ -56,15 +37,6 @@ static void ath10k_sta_update_stats_rx_duration(struct ath10k *ar,
 	rcu_read_unlock();
 }
 
-void ath10k_sta_update_rx_duration(struct ath10k *ar,
-				   struct ath10k_fw_stats *stats)
-{
-	if (stats->extended)
-		ath10k_sta_update_extd_stats_rx_duration(ar, stats);
-	else
-		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)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index c893314a191f..c7ec7b9e9b55 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3044,23 +3044,41 @@ 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;
+		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;
+		/* Because the stat data may exceed htc-wmi buffer
+		 * limit the firmware might split the stats data
+		 * and delivers it in multiple update events.
+		 * if we can't find the entry in the current event
+		 * payload, we have to look in main list as well.
+		 */
+		list_for_each_entry(dst, &stats->peers, list) {
+			if (ether_addr_equal(dst->peer_macaddr,
+					     src->peer_macaddr.addr))
+				goto found;
+		}
+
+#ifdef CONFIG_ATH10K_DEBUGFS
+		list_for_each_entry(dst, &ar->debug.fw_stats.peers, list) {
+			if (ether_addr_equal(dst->peer_macaddr,
+					     src->peer_macaddr.addr))
+				goto found;
+		}
+#endif
+
+		ath10k_dbg(ar, ATH10K_DBG_WMI,
+			   "Orphaned extended stats entry for station %pM.\n",
+			   src->peer_macaddr.addr);
+		continue;
 
-		ether_addr_copy(dst->peer_macaddr, src->peer_macaddr.addr);
+found:
 		dst->rx_duration = __le32_to_cpu(src->rx_duration);
-		list_add_tail(&dst->list, &stats->peers_extd);
 	}
 
 	return 0;
-- 
2.11.0



From msokolovskii at gmail.com  Sat Dec 17 13:42:31 2016
From: msokolovskii at gmail.com (Mikhail Sokolovskyy)
Date: Sat, 17 Dec 2016 23:42:31 +0200
Subject: Compex WLE900VX wireless driver
Message-ID: <000301d258ae$79b8be70$6d2a3b50$@gmail.com>

HI to all!


I've been trying to build my own wireless router from a regular PC for a
while now. Everything works fine except the wireless NIC Compex WLE900VX
which is based on Atheros QCA9880 chipset. Although I am able to run it in n
mode I'm getting this output on the command "dmesg | grep ath10". 

[    2.134534] ath10k_pci 0000:02:00.0: could not fetch firmware file
'ath10k/QCA988X/hw2.0/firmware-4.bin': -2
[    2.134561] ath10k_pci 0000:02:00.0: could not fetch firmware file
'ath10k/QCA988X/hw2.0/firmware-3.bin': -2

The card doesn't want to start at ac mode at all. The OS is ClearOS which is
based on Red Hat products. Here is the output for "ethtool -i wlp2s0"

driver: ath10k_pci
version: 3.10.0-327.36.3.v7.x86_64
firmware-version: 999.999.0.636
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no 

Any help is much appreciated. If any extra information needed please let me
know.
Thanks!



From tamizhchelvam at codeaurora.org  Mon Dec 19 00:11:35 2016
From: tamizhchelvam at codeaurora.org (Tamizh chelvam)
Date: Mon, 19 Dec 2016 13:41:35 +0530
Subject: [PATCH 2/4] cfg80211: Add new NL80211_CMD_SET_BTCOEX_PRIORITY to
 support BTCOEX
In-Reply-To: <1481881024.27953.14.camel@sipsolutions.net>
References: <1478610932-21954-1-git-send-email-c_traja@qti.qualcomm.com>
 <1478610932-21954-3-git-send-email-c_traja@qti.qualcomm.com>
 <1480949353.31788.27.camel@sipsolutions.net>
 <5e5e8971c96293a81e7cb37bcdfbd593@codeaurora.org>
 <1481645351.20412.34.camel@sipsolutions.net>
 <134cc8e58ecb804b6dda0137c4c37be8@codeaurora.org>
 <1481881024.27953.14.camel@sipsolutions.net>
Message-ID: <ae82112880d55451342e7a6e5a47c33f@codeaurora.org>

Hi Johannes,

Thanks for your comments.

On 2016-12-16 15:07, Johannes Berg wrote:
>> > > is it fine to have as WIPHY_BTCOEX_BE_PREFERRED ?
>> >
>> > It's not really clear to me what you intend to do this - if it's
>> > really support flags then you really should name those better.
>> >
>> 
>> This is support flags and it used by the driver to intimate driver?
>> supported frame type for the BTCOEX to cfg like
>> "wiphy_wowlan_support_flags" implementation. Please suggest if this
>> is ok ? I will be thankful if you can suggest a? better one if this
>> is not ok "WIPHY_BTCOEX_SUPPORTS_BE"
> 
> Well, I see a few things here:
> 
> 1) does it even make sense to split it out per AC? wouldn't it be weird
> if you supported this only for VO and BK, and not the others, or
> something like that?
> 
It has support for BE, VI, management and beacon frames also.
Or do you meant to say like support only for VO and BK?

> 2) Wouldn't it make more sense to define this in nl80211 and just pass
> the bitmap through to userspace? That would save quite a bit of netlink
> mangling complexity.
> 
Please let me know if the below design/thought is fine to you.

iw phyX set btcoex_priority <[vi, vo, be, bk, mgmt, beacon]>

By this command user should give one or more than one frame types for 
this btcoex priority,
we will parse that in "iw" and send as a single bitmap(less than 0x64) 
to
the driver?

> 3) I think the naming is confusing - "WIPHY_BTCOEX_SUPPORTS_BE_PREF" or
> so might be more appropriate?
> 
If the above suggestion is fine, we may not need these flags.

>> Do you mean to say, sending a value from user space and parse that
>> in? the driver?
> 
> I was more thinking of the capability advertisement, but yeah, both
> ways seems reasonable.
> 
Okay.

Thanks,
Tamizh.


From baantunes at gmail.com  Mon Dec 19 04:28:48 2016
From: baantunes at gmail.com (Bruno Antunes)
Date: Mon, 19 Dec 2016 12:28:48 +0000
Subject: Compex WLE900VX wireless driver
In-Reply-To: <000301d258ae$79b8be70$6d2a3b50$@gmail.com>
References: <000301d258ae$79b8be70$6d2a3b50$@gmail.com>
Message-ID: <CABUTiXVO_v5ujfvu=DB+gwj8YQFFuU9SYa0+_+SeTrWFO9o1Kg@mail.gmail.com>

Hi,

On 17 December 2016 at 21:42, Mikhail Sokolovskyy
<msokolovskii at gmail.com> wrote:
> HI to all!
>

> The card doesn't want to start at ac mode at all. The OS is ClearOS which is

That can be the hostapd configuration file or hostapd version.

> based on Red Hat products. Here is the output for "ethtool -i wlp2s0"
>
> driver: ath10k_pci
> version: 3.10.0-327.36.3.v7.x86_64
> firmware-version: 999.999.0.636

Is there any reason to use this firmware version?

You can upgrade to more recent versions:
https://github.com/kvalo/ath10k-firmware

Some info and instructions can be found here:
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/firmware

Regards,
Bruno


From greearb at candelatech.com  Mon Dec 19 07:07:31 2016
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 19 Dec 2016 07:07:31 -0800
Subject: ath10k truesize issue?
Message-ID: <5857F7B3.206@candelatech.com>

This warning is from the code below.  Anyone seen this recently?

I think this was from a 9984 NIC (we have several different
NICs in this chassis).


} else {
                 if (skb_shinfo(to)->nr_frags +
                     skb_shinfo(from)->nr_frags > MAX_SKB_FRAGS)
                         return false;

                 delta = from->truesize - SKB_TRUESIZE(skb_end_offset(from));
         }

         WARN_ON_ONCE(delta < len);

Dec 18 22:40:36 ct524-9933 kernel: WARNING: CPU: 7 PID: 0 at /home/greearb/git/linux-4.7.dev.y/net/core/skbuff.c:4283 skb_try_coalesce+0x402/0x410
Dec 18 22:40:36 ct524-9933 kernel: Modules linked in: nf_conntrack_netlink nf_conntrack nfnetlink wanlink(O) nf_defrag_ipv4 macvlan pktgen fuse vfat fat 
coretemp intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm irqbypass ath10k_pci ath10k_core ath mac80211 iTCO_wdt iTCO_vendor_support ipmi_ssif 
cfg80211 hci_uart joydev i2c_i801 btbcm btqca btintel ie31200_edac bluetooth edac_core shpchp acpi_als tpm_tis kfifo_buf pinctrl_sunrisepoint intel_lpss_acpi 
ipmi_msghandler tpm industrialio video pinctrl_intel intel_lpss acpi_power_meter sch_fq_codel nfsd auth_rpcgss nfs_acl lockd grace sunrpc 8021q garp stp llc mrp 
ast drm_kms_helper ttm drm igb i2c_algo_bit ixgbe mdio hwmon dca ptp pps_core i2c_hid i2c_core fjes efivarfs ipv6 [last unloaded: nfnetlink]
Dec 18 22:40:36 ct524-9933 kernel: CPU: 7 PID: 0 Comm: swapper/7 Tainted: G           O    4.7.10+ #46
Dec 18 22:40:36 ct524-9933 kernel: Hardware name: Supermicro Super Server/X11SSM, BIOS 1.0b 12/29/2015
Dec 18 22:40:36 ct524-9933 kernel:  0000000000000000 ffff8804779c3688 ffffffff81409351 0000000000000000
Dec 18 22:40:36 ct524-9933 kernel:  0000000000000000 ffff8804779c36c8 ffffffff81103976 000010bb779c36a8
Dec 18 22:40:36 ct524-9933 kernel:  ffff88007ce1f800 00000000000005a8 ffff8804779c3724 ffff880075b85000
Dec 18 22:40:36 ct524-9933 kernel: Call Trace:
Dec 18 22:40:36 ct524-9933 kernel:  <IRQ> [<ffffffff81409351>] dump_stack+0x63/0x82
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81103976>] __warn+0xc6/0xe0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81103a48>] warn_slowpath_null+0x18/0x20
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81760c62>] skb_try_coalesce+0x402/0x410
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817c7b79>] tcp_try_coalesce+0x39/0xa0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81761671>] ? skb_checksum+0x21/0x30
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817c8322>] tcp_queue_rcv+0x52/0x140
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817cee84>] tcp_rcv_established+0x364/0x6f0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817d9286>] tcp_v4_do_rcv+0x136/0x210
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817dab49>] tcp_v4_rcv+0x8d9/0xaf0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff8180a7f2>] ? iptable_filter_hook+0x22/0x60
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817b4bdb>] ip_local_deliver_finish+0x9b/0x1f0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817b4edb>] ip_local_deliver+0x5b/0xd0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817b4b40>] ? ip_rcv_finish+0x3f0/0x3f0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817b486a>] ip_rcv_finish+0x11a/0x3f0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817b51af>] ip_rcv+0x25f/0x380
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817b4750>] ? inet_del_offload+0x40/0x40
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81773cb4>] __netif_receive_skb_core+0x684/0xa80
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff8124925a>] ? kmem_cache_free+0x17a/0x180
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817740c3>] __netif_receive_skb+0x13/0x60
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81774133>] netif_receive_skb_internal+0x23/0x90
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817741b7>] netif_receive_skb+0x17/0x80
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffffa0a08d07>] ieee80211_deliver_skb+0x157/0x1b0 [mac80211]
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffffa0a0ad9a>] ieee80211_rx_handlers+0xa8a/0x2560 [mac80211]
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff8155717a>] ? dma_pte_clear_level+0x14a/0x190
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffffa0a0d077>] ieee80211_prepare_and_rx_handle+0x597/0x10a0 [mac80211]
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffffa0a0ddfa>] ieee80211_rx_napi+0x27a/0x930 [mac80211]
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffffa0c179cc>] ath10k_process_rx+0x2ac/0x4a0 [ath10k_core]
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffffa0c17bf5>] ath10k_htt_rx_h_deliver+0x35/0x80 [ath10k_core]
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffffa0c1a421>] ath10k_htt_txrx_compl_task+0xc91/0xe60 [ath10k_core]
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81108afb>] tasklet_action+0x10b/0x120
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81108eca>] __do_softirq+0xca/0x2b0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff811091e9>] irq_exit+0x89/0x90
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff8102e69f>] do_IRQ+0x4f/0xd0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff8184db42>] common_interrupt+0x82/0x82
Dec 18 22:40:36 ct524-9933 kernel:  <EOI> [<ffffffff816e8020>] ? cpuidle_enter_state+0x110/0x290
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff816e81c2>] cpuidle_enter+0x12/0x20
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81144bb5>] call_cpuidle+0x25/0x40
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81144f72>] cpu_startup_entry+0x2b2/0x370
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff8104d8cd>] start_secondary+0x14d/0x170
Dec 18 22:40:36 ct524-9933 kernel: ---[ end trace fa9eabf037886c79 ]---


Thanks,
Ben

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



From mohammed at codeaurora.org  Mon Dec 19 08:49:57 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Mon, 19 Dec 2016 22:19:57 +0530
Subject: [PATCH] ath10k: merge extended peer info data with existing
 peers info
In-Reply-To: <20161217174634.4531-1-chunkeey@googlemail.com>
References: <20161216052418.GA8936@atheros-ThinkPad-T61>
 <20161217174634.4531-1-chunkeey@googlemail.com>
Message-ID: <20161219164957.GA13022@atheros-ThinkPad-T61>

Hi Christian,

On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote:
> The 10.4 firmware adds extended peer information to the
> firmware's statistics payload. This additional info is
> stored as a separate data field. During review of
> "ath10k: add accounting for the extended peer statistics" [0]
> 
> Mohammed Shafi Shajakhan commented that the extended peer statistics
> lists are of little use:"... there is not much use in appending
> the extended peer stats (which gets periodically updated) to the
> linked list '&ar->debug.fw_stats.peers_extd)' and should we get
> rid of the below (and the required cleanup as well)
> 
> list_splice_tail_init(&stats.peers_extd,
>                 &ar->debug.fw_stats.peers_extd);
> 
> since rx_duration is getting updated periodically to the per sta
> information."

[shafi] thanks !

> 
> This patch replaces the extended peers list with a lookup and
> puts the retrieved data (rx_duration) into the existing
> ath10k_fw_stats_peer entry that was created earlier.

[shafi] Its good to maintain the extended stats variable
and retain the two different functions to update rx_duration.

a) extended peer stats supported - mainly for 10.4
b) extender peer stats not supported - for 10.2


> 
> [0] <https://lkml.kernel.org/r/992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey at googlemail.com>
> Cc: Mohammed Shafi Shajakhan <mohammed at codeaurora.org>
> Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>
> ---
>  drivers/net/wireless/ath/ath10k/core.h        |  2 --
>  drivers/net/wireless/ath/ath10k/debug.c       | 17 --------------
>  drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 ++-----------------------
>  drivers/net/wireless/ath/ath10k/wmi.c         | 34 ++++++++++++++++++++-------
>  4 files changed, 28 insertions(+), 57 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> index 09ff8b8a6441..3fffbbb18c25 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -268,11 +268,9 @@ struct ath10k_fw_stats_pdev {
>  };
>  
>  struct ath10k_fw_stats {
> -	bool extended;
>  	struct list_head pdevs;
>  	struct list_head vdevs;
>  	struct list_head peers;
> -	struct list_head peers_extd;
>  };
>  
>  #define ATH10K_TPC_TABLE_TYPE_FLAG	1
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> index 82a4c67f3672..89f7fde77cdf 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -315,25 +315,13 @@ 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);
>  	ar->debug.fw_stats_done = false;
> -	ar->debug.fw_stats.extended = false;

[shafi] this looks fine, but not removing the 'extended' variable 
from ath10k_fw_stats structure, I see the design for 'rx_duration'
arguably some what convoluted !

*We get periodic events from firmware updating 'ath10k_debug_fw_stats_process'
*Fetch rx_duration from  'ath10k_wmi_pull_fw_stats(ar, skb, &stats)'
{certainly 'stats' object is for this particular update only, and freed
up later)
*Update immediately using 'ath10k_sta_update_rx_duration'

'ath10k_wmi_pull_fw_stats' has a slightly different implementation
for 10.2 and 10.4 (the later supporting extended peer stats)



>  	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);
>  }
>  
> @@ -348,7 +336,6 @@ 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);
> @@ -411,8 +398,6 @@ 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);
> @@ -424,7 +409,6 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
>  	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);
>  }
> @@ -2347,7 +2331,6 @@ 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/debugfs_sta.c b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> index fce6f8137d33..bf2d49cbb3bb 100644
> --- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> +++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> @@ -18,27 +18,8 @@
>  #include "wmi-ops.h"
>  #include "debug.h"
>  
> -static void ath10k_sta_update_extd_stats_rx_duration(struct ath10k *ar,
> -						     struct ath10k_fw_stats *stats)
> -{
> -	struct ath10k_fw_extd_stats_peer *peer;
> -	struct ieee80211_sta *sta;
> -	struct ath10k_sta *arsta;
> -
> -	rcu_read_lock();
> -	list_for_each_entry(peer, &stats->peers_extd, 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 ath10k_fw_stats *stats)
> +void ath10k_sta_update_rx_duration(struct ath10k *ar,
> +				   struct ath10k_fw_stats *stats)
>  {
>  	struct ath10k_fw_stats_peer *peer;
>  	struct ieee80211_sta *sta;
> @@ -56,15 +37,6 @@ static void ath10k_sta_update_stats_rx_duration(struct ath10k *ar,
>  	rcu_read_unlock();
>  }
>  
> -void ath10k_sta_update_rx_duration(struct ath10k *ar,
> -				   struct ath10k_fw_stats *stats)
> -{
> -	if (stats->extended)
> -		ath10k_sta_update_extd_stats_rx_duration(ar, stats);
> -	else
> -		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)
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> index c893314a191f..c7ec7b9e9b55 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -3044,23 +3044,41 @@ 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;
> +		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;
> +		/* Because the stat data may exceed htc-wmi buffer
> +		 * limit the firmware might split the stats data
> +		 * and delivers it in multiple update events.
> +		 * if we can't find the entry in the current event
> +		 * payload, we have to look in main list as well.
> +		 */
> +		list_for_each_entry(dst, &stats->peers, list) {
> +			if (ether_addr_equal(dst->peer_macaddr,
> +					     src->peer_macaddr.addr))
> +				goto found;
> +		}
> +
> +#ifdef CONFIG_ATH10K_DEBUGFS
> +		list_for_each_entry(dst, &ar->debug.fw_stats.peers, list) {
> +			if (ether_addr_equal(dst->peer_macaddr,
> +					     src->peer_macaddr.addr))
> +				goto found;
> +		}
> +#endif
> +
> +		ath10k_dbg(ar, ATH10K_DBG_WMI,
> +			   "Orphaned extended stats entry for station %pM.\n",
> +			   src->peer_macaddr.addr);
> +		continue;
>  
> -		ether_addr_copy(dst->peer_macaddr, src->peer_macaddr.addr);
> +found:
>  		dst->rx_duration = __le32_to_cpu(src->rx_duration);
> -		list_add_tail(&dst->list, &stats->peers_extd);
>  	}
>  
>  	return 0;

[shafi] Yes i am bit concerned about this change making 10.4 to update
over the existing peer_stats structure, the idea is to maintain uniformity
between the structures shared between ath10k and its corresponding to avoid
confusion/ bugs in the future. Kindly let me know your thoughts, feel free
to correct me if any of my analysis is incorrect. thank you !

regards,
shafi



From mohammed at codeaurora.org  Mon Dec 19 08:58:58 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Mon, 19 Dec 2016 22:28:58 +0530
Subject: [PATCH] ath10k: merge extended peer info data with existing
 peers info
In-Reply-To: <20161219164957.GA13022@atheros-ThinkPad-T61>
References: <20161216052418.GA8936@atheros-ThinkPad-T61>
 <20161217174634.4531-1-chunkeey@googlemail.com>
 <20161219164957.GA13022@atheros-ThinkPad-T61>
Message-ID: <20161219165858.GB13022@atheros-ThinkPad-T61>

On Mon, Dec 19, 2016 at 10:19:57PM +0530, Mohammed Shafi Shajakhan wrote:
> Hi Christian,
> 
> On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote:
> > The 10.4 firmware adds extended peer information to the
> > firmware's statistics payload. This additional info is
> > stored as a separate data field. During review of
> > "ath10k: add accounting for the extended peer statistics" [0]
> > 
> > Mohammed Shafi Shajakhan commented that the extended peer statistics
> > lists are of little use:"... there is not much use in appending
> > the extended peer stats (which gets periodically updated) to the
> > linked list '&ar->debug.fw_stats.peers_extd)' and should we get
> > rid of the below (and the required cleanup as well)
> > 
> > list_splice_tail_init(&stats.peers_extd,
> >                 &ar->debug.fw_stats.peers_extd);
> > 
> > since rx_duration is getting updated periodically to the per sta
> > information."
> 
> [shafi] thanks !
> 
> > 
> > This patch replaces the extended peers list with a lookup and
> > puts the retrieved data (rx_duration) into the existing
> > ath10k_fw_stats_peer entry that was created earlier.
> 
> [shafi] Its good to maintain the extended stats variable
> and retain the two different functions to update rx_duration.
> 
> a) extended peer stats supported - mainly for 10.4
> b) extender peer stats not supported - for 10.2
> 
> 
> > 
> > [0] <https://lkml.kernel.org/r/992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey at googlemail.com>
> > Cc: Mohammed Shafi Shajakhan <mohammed at codeaurora.org>
> > Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>
> > ---
> >  drivers/net/wireless/ath/ath10k/core.h        |  2 --
> >  drivers/net/wireless/ath/ath10k/debug.c       | 17 --------------
> >  drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 ++-----------------------
> >  drivers/net/wireless/ath/ath10k/wmi.c         | 34 ++++++++++++++++++++-------
> >  4 files changed, 28 insertions(+), 57 deletions(-)
> > 
> > diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> > index 09ff8b8a6441..3fffbbb18c25 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.h
> > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > @@ -268,11 +268,9 @@ struct ath10k_fw_stats_pdev {
> >  };
> >  
> >  struct ath10k_fw_stats {
> > -	bool extended;
> >  	struct list_head pdevs;
> >  	struct list_head vdevs;
> >  	struct list_head peers;
> > -	struct list_head peers_extd;
> >  };
> >  
> >  #define ATH10K_TPC_TABLE_TYPE_FLAG	1
> > diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> > index 82a4c67f3672..89f7fde77cdf 100644
> > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > @@ -315,25 +315,13 @@ 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);
> >  	ar->debug.fw_stats_done = false;
> > -	ar->debug.fw_stats.extended = false;
> 
> [shafi] this looks fine, but not removing the 'extended' variable 
> from ath10k_fw_stats structure, I see the design for 'rx_duration'
> arguably some what convoluted !
> 
> *We get periodic events from firmware updating 'ath10k_debug_fw_stats_process'
> *Fetch rx_duration from  'ath10k_wmi_pull_fw_stats(ar, skb, &stats)'
> {certainly 'stats' object is for this particular update only, and freed
> up later)
> *Update immediately using 'ath10k_sta_update_rx_duration'
> 
> 'ath10k_wmi_pull_fw_stats' has a slightly different implementation
> for 10.2 and 10.4 (the later supporting extended peer stats)
> 
> 
> 
> >  	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);
> >  }
> >  
> > @@ -348,7 +336,6 @@ 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);
> > @@ -411,8 +398,6 @@ 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);
> > @@ -424,7 +409,6 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> >  	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);
> >  }
> > @@ -2347,7 +2331,6 @@ 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/debugfs_sta.c b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> > index fce6f8137d33..bf2d49cbb3bb 100644
> > --- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> > +++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> > @@ -18,27 +18,8 @@
> >  #include "wmi-ops.h"
> >  #include "debug.h"
> >  
> > -static void ath10k_sta_update_extd_stats_rx_duration(struct ath10k *ar,
> > -						     struct ath10k_fw_stats *stats)
> > -{
> > -	struct ath10k_fw_extd_stats_peer *peer;
> > -	struct ieee80211_sta *sta;
> > -	struct ath10k_sta *arsta;
> > -
> > -	rcu_read_lock();
> > -	list_for_each_entry(peer, &stats->peers_extd, 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 ath10k_fw_stats *stats)
> > +void ath10k_sta_update_rx_duration(struct ath10k *ar,
> > +				   struct ath10k_fw_stats *stats)
> >  {
> >  	struct ath10k_fw_stats_peer *peer;
> >  	struct ieee80211_sta *sta;
> > @@ -56,15 +37,6 @@ static void ath10k_sta_update_stats_rx_duration(struct ath10k *ar,
> >  	rcu_read_unlock();
> >  }
> >  
> > -void ath10k_sta_update_rx_duration(struct ath10k *ar,
> > -				   struct ath10k_fw_stats *stats)
> > -{
> > -	if (stats->extended)
> > -		ath10k_sta_update_extd_stats_rx_duration(ar, stats);
> > -	else
> > -		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)
> > diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> > index c893314a191f..c7ec7b9e9b55 100644
> > --- a/drivers/net/wireless/ath/ath10k/wmi.c
> > +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> > @@ -3044,23 +3044,41 @@ 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;
> > +		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;
> > +		/* Because the stat data may exceed htc-wmi buffer
> > +		 * limit the firmware might split the stats data
> > +		 * and delivers it in multiple update events.
> > +		 * if we can't find the entry in the current event
> > +		 * payload, we have to look in main list as well.
> > +		 */
> > +		list_for_each_entry(dst, &stats->peers, list) {
> > +			if (ether_addr_equal(dst->peer_macaddr,
> > +					     src->peer_macaddr.addr))
> > +				goto found;
> > +		}
> > +
> > +#ifdef CONFIG_ATH10K_DEBUGFS
> > +		list_for_each_entry(dst, &ar->debug.fw_stats.peers, list) {
> > +			if (ether_addr_equal(dst->peer_macaddr,
> > +					     src->peer_macaddr.addr))
> > +				goto found;
> > +		}
> > +#endif
> > +
> > +		ath10k_dbg(ar, ATH10K_DBG_WMI,
> > +			   "Orphaned extended stats entry for station %pM.\n",
> > +			   src->peer_macaddr.addr);
> > +		continue;
> >  
> > -		ether_addr_copy(dst->peer_macaddr, src->peer_macaddr.addr);
> > +found:
> >  		dst->rx_duration = __le32_to_cpu(src->rx_duration);
> > -		list_add_tail(&dst->list, &stats->peers_extd);
> >  	}
> >  
> >  	return 0;
> 
> [shafi] Yes i am bit concerned about this change making 10.4 to update
> over the existing peer_stats structure, the idea is to maintain uniformity
> between the structures shared between ath10k and its corresponding *firmware* to avoid
> bugs in the future. Kindly let me know your thoughts, feel free
> to correct me if any of my analysis is incorrect. thank you !

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


From chunkeey at googlemail.com  Mon Dec 19 10:37:18 2016
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Mon, 19 Dec 2016 19:37:18 +0100
Subject: [PATCH] ath10k: merge extended peer info data with existing peers
 info
In-Reply-To: <20161219164957.GA13022@atheros-ThinkPad-T61>
References: <20161216052418.GA8936@atheros-ThinkPad-T61>
 <20161217174634.4531-1-chunkeey@googlemail.com>
 <20161219164957.GA13022@atheros-ThinkPad-T61>
Message-ID: <2696316.Ugl5Pim1oL@debian64>

Hello Shafi,

On Monday, December 19, 2016 10:19:57 PM CET Mohammed Shafi Shajakhan wrote:
> On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote:
> > The 10.4 firmware adds extended peer information to the
> > firmware's statistics payload. This additional info is
> > stored as a separate data field. During review of
> > "ath10k: add accounting for the extended peer statistics" [0]
> > 
> > Mohammed Shafi Shajakhan commented that the extended peer statistics
> > lists are of little use:"... there is not much use in appending
> > the extended peer stats (which gets periodically updated) to the
> > linked list '&ar->debug.fw_stats.peers_extd)' and should we get
> > rid of the below (and the required cleanup as well)
> > 
> > list_splice_tail_init(&stats.peers_extd,
> >                 &ar->debug.fw_stats.peers_extd);
> > 
> > since rx_duration is getting updated periodically to the per sta
> > information."
> > 
> > This patch replaces the extended peers list with a lookup and
> > puts the retrieved data (rx_duration) into the existing
> > ath10k_fw_stats_peer entry that was created earlier.
> 
> [shafi] Its good to maintain the extended stats variable
> and retain the two different functions to update rx_duration.
> 
> a) extended peer stats supported - mainly for 10.4
> b) extender peer stats not supported - for 10.2
Well, I have to ask why you want to retain the two different
functions to update the same arsta->rx_duration? I think a
little bit of code that helps to explain what's on your mind
(or how you would do it) would help immensely in this case.
Since I have the feeling that this is the problem here. 
So please explain it in C(lang).

> > [0] <https://lkml.kernel.org/r/992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey at googlemail.com>
> > Cc: Mohammed Shafi Shajakhan <mohammed at codeaurora.org>
> > Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>
> > ---
> >  drivers/net/wireless/ath/ath10k/core.h        |  2 --
> >  drivers/net/wireless/ath/ath10k/debug.c       | 17 --------------
> >  drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 ++-----------------------
> >  drivers/net/wireless/ath/ath10k/wmi.c         | 34 ++++++++++++++++++++-------
> >  4 files changed, 28 insertions(+), 57 deletions(-)
> > 
> > diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> > index 09ff8b8a6441..3fffbbb18c25 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.h
> > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > @@ -268,11 +268,9 @@ struct ath10k_fw_stats_pdev {
> >  };
> >  
> >  struct ath10k_fw_stats {
> > -	bool extended;
> >  	struct list_head pdevs;
> >  	struct list_head vdevs;
> >  	struct list_head peers;
> > -	struct list_head peers_extd;
> >  };
> >  
> >  #define ATH10K_TPC_TABLE_TYPE_FLAG	1
> > diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> > index 82a4c67f3672..89f7fde77cdf 100644
> > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > @@ -315,25 +315,13 @@ 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);
> >  	ar->debug.fw_stats_done = false;
> > -	ar->debug.fw_stats.extended = false;
> 
> [shafi] this looks fine, but not removing the 'extended' variable 
> from ath10k_fw_stats structure, I see the design for 'rx_duration'
> arguably some what convoluted !
I removed extended because it is now a write-only variable.
So I figured, there's no point in keeping it around? I don't have
access to the firmware interface documentation, so I don't know
if there's a reason why it would be good to have it later.
So please tell me, what information do we gain from it?

> *We get periodic events from firmware updating 'ath10k_debug_fw_stats_process'
> *Fetch rx_duration from  'ath10k_wmi_pull_fw_stats(ar, skb, &stats)'
> {certainly 'stats' object is for this particular update only, and freed
> up later)
> *Update immediately using 'ath10k_sta_update_rx_duration'
> 
> 'ath10k_wmi_pull_fw_stats' has a slightly different implementation
> for 10.2 and 10.4 (the later supporting extended peer stats)

I see that 10.2.4's ath10k_wmi_10_2_4_op_pull_fw_stats()
passes the rx_duration as part of the wmi_10_2_4_ext_peer_stats
element which is basically a carbon-copy of wmi_10_2_4_peer_stats
(but with one extra __le32 for the rx_duration at the end.)
This rx_duration is then used to set the rx_duration field in the
generated ath10k_fw_stats_peer struct.

10.4's ath10k_wmi_10_4_op_pull_fw_stats() has a "fixed" wmi_10_4_peer_stats
element and uses an separate "fixed" wmi_10_4_peer_extd_stats element for
the communicating the rx_duration to the driver.

Thing is, both function have the same signature. They produce the same
struct ath10k_fw_stats_peer for the given data in the sk_buff input. So
why does 10.4 need to have it's peer_extd infrastructure, when it can use
the existing rx_duration field in the *universal* ath10k_fw_stats_peer?

What's with the extra layers / HAL here? Because it looks like it's merged
back together in the same manner into the same arsta->rx_duration?
[ath10k_sta_update_stats_rx_duration() vs. 
 ath10k_sta_update_extd_stats_rx_duration() - they are almost carbon copies too]

> > diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> > index c893314a191f..c7ec7b9e9b55 100644
> > --- a/drivers/net/wireless/ath/ath10k/wmi.c
> > +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> > @@ -3044,23 +3044,41 @@ 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;
> > +		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;
> > +		/* Because the stat data may exceed htc-wmi buffer
> > +		 * limit the firmware might split the stats data
> > +		 * and delivers it in multiple update events.
> > +		 * if we can't find the entry in the current event
> > +		 * payload, we have to look in main list as well.
> > +		 */
> > +		list_for_each_entry(dst, &stats->peers, list) {
> > +			if (ether_addr_equal(dst->peer_macaddr,
> > +					     src->peer_macaddr.addr))
> > +				goto found;
> > +		}
> > +
> > +#ifdef CONFIG_ATH10K_DEBUGFS
> > +		list_for_each_entry(dst, &ar->debug.fw_stats.peers, list) {
> > +			if (ether_addr_equal(dst->peer_macaddr,
> > +					     src->peer_macaddr.addr))
> > +				goto found;
> > +		}
> > +#endif
> > +
> > +		ath10k_dbg(ar, ATH10K_DBG_WMI,
> > +			   "Orphaned extended stats entry for station %pM.\n",
> > +			   src->peer_macaddr.addr);
> > +		continue;
> >  
> > -		ether_addr_copy(dst->peer_macaddr, src->peer_macaddr.addr);
> > +found:
> >  		dst->rx_duration = __le32_to_cpu(src->rx_duration);
> > -		list_add_tail(&dst->list, &stats->peers_extd);
> >  	}
> >  
> >  	return 0;
> 
> [shafi] Yes i am bit concerned about this change making 10.4 to update
> over the existing peer_stats structure, the idea is to maintain uniformity
> between the structures shared between ath10k and its corresponding to avoid
> confusion/ bugs in the future. Kindly let me know your thoughts, feel free
> to correct me if any of my analysis is incorrect. thank you !
Isn't the point of the ath10k_wmi_10_*_op_pull_fw_stats() functions to make 
a "universal" statistic (in your case a unified ath10k_fw_stats_peer structure)
that other functions can use, without caring about if the FW was 10.4 
or 10.2.4?

There's no indication that the rx_duration field in wmi_10_2_4_ext_peer_stats
conveys any different information than the rx_duration in 
wmi_10_4_peer_extd_stats. So, what's going on here? Can't you just make
wmi_10_4_peer_extd_stats's rx_duration use the existing field in
ath10k_fw_stats_peer? And if not: why exactly?

Regards,
Christian


From mohammed at qti.qualcomm.com  Tue Dec 20 00:05:35 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Tue, 20 Dec 2016 13:35:35 +0530
Subject: [PATCH v2] ath10k: Fix crash during rmmod when probe firmware fails
Message-ID: <1482221135-23960-1-git-send-email-mohammed@qca.qualcomm.com>

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

This fixes the below crash when ath10k probe firmware fails,
NAPI polling tries to access a rx ring resource which was never
allocated, fix this by disabling NAPI right away once the probe
firmware fails by calling 'ath10k_hif_stop'. Its good to note
that the error is never propogated to 'ath10k_pci_probe' when
ath10k_core_register fails, so calling 'ath10k_hif_stop' to cleanup
PCI related things seems to be ok

BUG: unable to handle kernel NULL pointer dereference at (null)
IP:  __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
__ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]

Call Trace:

[<ffffffffa113ec62>] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90
[ath10k_core]
[<ffffffffa113f393>] ath10k_htt_txrx_compl_task+0x433/0x17d0
[ath10k_core]
[<ffffffff8114406d>] ? __wake_up_common+0x4d/0x80
[<ffffffff811349ec>] ? cpu_load_update+0xdc/0x150
[<ffffffffa119301d>] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]
[<ffffffffa1195b17>] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]
[<ffffffff817863af>] net_rx_action+0x20f/0x370

Reported-by: Ben Greear <greearb at candelatech.com>
Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")

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

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index f7ea4de..15bccc9 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2164,6 +2164,7 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
 	ath10k_core_free_firmware_files(ar);
 
 err_power_down:
+	ath10k_hif_stop(ar);
 	ath10k_hif_power_down(ar);
 
 	return ret;
-- 
1.9.1



From mohammed at qti.qualcomm.com  Tue Dec 20 00:09:11 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Tue, 20 Dec 2016 13:39:11 +0530
Subject: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails
Message-ID: <1482221351-24029-1-git-send-email-mohammed@qca.qualcomm.com>

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

This fixes the below crash when ath10k probe firmware fails,
NAPI polling tries to access a rx ring resource which was never
allocated, fix this by disabling NAPI right away once the probe
firmware fails by calling 'ath10k_hif_stop'. Its good to note
that the error is never propogated to 'ath10k_pci_probe' when
ath10k_core_register fails, so calling 'ath10k_hif_stop' to cleanup
PCI related things seems to be ok

BUG: unable to handle kernel NULL pointer dereference at (null)
IP:  __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
__ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]

Call Trace:

[<ffffffffa113ec62>] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90
[ath10k_core]
[<ffffffffa113f393>] ath10k_htt_txrx_compl_task+0x433/0x17d0
[ath10k_core]
[<ffffffff8114406d>] ? __wake_up_common+0x4d/0x80
[<ffffffff811349ec>] ? cpu_load_update+0xdc/0x150
[<ffffffffa119301d>] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]
[<ffffffffa1195b17>] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]
[<ffffffff817863af>] net_rx_action+0x20f/0x370

Reported-by: Ben Greear <greearb at candelatech.com>
Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index f7ea4de..15bccc9 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2164,6 +2164,7 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
 	ath10k_core_free_firmware_files(ar);
 
 err_power_down:
+	ath10k_hif_stop(ar);
 	ath10k_hif_power_down(ar);
 
 	return ret;
-- 
1.9.1



From kvalo at qca.qualcomm.com  Tue Dec 20 07:06:03 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 20 Dec 2016 16:06:03 +0100
Subject: ath10k: free host-mem with DMA_BIRECTIONAL flag.
In-Reply-To: <1480962519-13027-1-git-send-email-greearb@candelatech.com>
References: <1480962519-13027-1-git-send-email-greearb@candelatech.com>
Message-ID: <0be4c93a51fc4404a4612ae689db9bc8@euamsexm01a.eu.qualcomm.com>

Ben Greear <greearb at candelatech.com> wrote:
> From: Ben Greear <greearb at candelatech.com>
> 
> Hopefully this fixes the problem reported by Kalle:
> 
> Noticed this in my log, but I don't have time to investigate this in
> detail right now:
> 
> [  413.795346] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [  414.158755] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [  477.439659] ath10k_pci 0000:02:00.0: could not get mac80211 beacon
> [  481.666630] ------------[ cut here ]------------
> [  481.666669] WARNING: CPU: 0 PID: 1978 at lib/dma-debug.c:1155 check_unmap+0x320/0x8e0
> [  481.666688] ath10k_pci 0000:02:00.0: DMA-API: device driver frees DMA memory with different direction [device address=0x000000002d130000] [size=63800 bytes] [mapped with DMA_BIDIRECTIONAL] [unmapped with DMA_TO_DEVICE]
> [  481.666703] Modules linked in: ctr ccm ath10k_pci(E-) ath10k_core(E) ath(E) mac80211(E) cfg80211(E) snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi arc4 snd_rawmidi snd_seq_midi_event snd_seq btusb btintel snd_seq_device joydev coret
> [  481.671468] CPU: 0 PID: 1978 Comm: rmmod Tainted: G            E   4.9.0-rc7-wt+ #54
> [  481.671478] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD Ver. F.04 01/27/2010
> [  481.671489]  ef49dcec c842ee92 c8b5830e ef49dd34 ef49dd20 c80850f5 c8b5a13c ef49dd50
> [  481.671560]  000007ba c8b5830e 00000483 c8461830 c8461830 00000483 ef49ddcc f34e64b8
> [  481.671641]  c8b58360 ef49dd3c c80851bb 00000009 00000000 ef49dd34 c8b5a13c ef49dd50
> [  481.671716] Call Trace:
> [  481.671731]  [<c842ee92>] dump_stack+0x76/0xb4
> [  481.671745]  [<c80850f5>] __warn+0xe5/0x100
> [  481.671757]  [<c8461830>] ? check_unmap+0x320/0x8e0
> [  481.671769]  [<c8461830>] ? check_unmap+0x320/0x8e0
> [  481.671780]  [<c80851bb>] warn_slowpath_fmt+0x3b/0x40
> [  481.671791]  [<c8461830>] check_unmap+0x320/0x8e0
> [  481.671804]  [<c8462054>] debug_dma_unmap_page+0x84/0xa0
> [  481.671835]  [<f937cd7a>] ath10k_wmi_free_host_mem+0x9a/0xe0 [ath10k_core]
> [  481.671861]  [<f9363400>] ath10k_core_destroy+0x50/0x60 [ath10k_core]
> [  481.671875]  [<f8e13969>] ath10k_pci_remove+0x79/0xa0 [ath10k_pci]
> [  481.671889]  [<c848d8d8>] pci_device_remove+0x38/0xb0
> [  481.671901]  [<c859fe4b>] __device_release_driver+0x7b/0x110
> [  481.671913]  [<c85a00e7>] driver_detach+0x97/0xa0
> [  481.671923]  [<c859ef8b>] bus_remove_driver+0x4b/0xb0
> [  481.671934]  [<c85a0cda>] driver_unregister+0x2a/0x60
> [  481.671949]  [<c848c888>] pci_unregister_driver+0x18/0x70
> [  481.671965]  [<f8e14dae>] ath10k_pci_exit+0xd/0x25f [ath10k_pci]
> [  481.671979]  [<c812bb84>] SyS_delete_module+0xf4/0x180
> [  481.671995]  [<c81f801b>] ? __might_fault+0x8b/0xa0
> [  481.672009]  [<c80037d0>] do_fast_syscall_32+0xa0/0x1e0
> [  481.672025]  [<c88d4c88>] sysenter_past_esp+0x45/0x74
> [  481.672037] ---[ end trace 3fd23759e17e1622 ]---
> [  481.672049] Mapped at:
> [  481.672060]  [  481.672072] [<c846062c>] debug_dma_map_page.part.25+0x1c/0xf0
> [  481.672083]  [  481.672095] [<c8460799>] debug_dma_map_page+0x99/0xc0
> [  481.672106]  [  481.672132] [<f93745ec>] ath10k_wmi_alloc_chunk+0x12c/0x1f0 [ath10k_core]
> [  481.672142]  [  481.672168] [<f937d0c4>] ath10k_wmi_event_service_ready_work+0x304/0x540 [ath10k_core]
> [  481.672178]  [  481.672190] [<c80a3643>] process_one_work+0x1c3/0x670
> [  482.137134] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
> [  482.313144] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:02:00.0.bin failed with error -2
> [  482.313274] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/cal-pci-0000:02:00.0.bin failed with error -2
> [  482.313768] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
> [  482.313777] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 0 testmode 1
> [  482.313974] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
> [  482.369858] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
> [  482.370011] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
> [  483.596770] 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
> [  483.701686] ath: EEPROM regdomain: 0x0
> [  483.701706] ath: EEPROM indicates default country code should be used
> [  483.701713] ath: doing EEPROM country->regdmn map search
> [  483.701721] ath: country maps to regdmn code: 0x3a
> [  483.701730] ath: Country alpha2 being used: US
> [  483.701737] ath: Regpair used: 0x3a
> 
> Reported-by: Kalle Valo <kvalo at qca.qualcomm.com>
> Signed-off-by: Ben Greear <greearb at candelatech.com>

Patch applied to ath-current branch of ath.git, thanks.

d4166b8b3365 ath10k: free host-mem with DMA_BIRECTIONAL flag

-- 
https://patchwork.kernel.org/patch/9461307/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From erik.stromdahl at gmail.com  Tue Dec 20 10:14:19 2016
From: erik.stromdahl at gmail.com (Erik Stromdahl)
Date: Tue, 20 Dec 2016 19:14:19 +0100
Subject: [RFC v2 11/11] ath10k: Added sdio support
In-Reply-To: <871sx8unjn.fsf@kamboji.qca.qualcomm.com>
References: <1479496971-19174-1-git-send-email-erik.stromdahl@gmail.com>
 <1479496971-19174-12-git-send-email-erik.stromdahl@gmail.com>
 <871sx8unjn.fsf@kamboji.qca.qualcomm.com>
Message-ID: <db9add38-ee9c-d9ac-0349-ba133fc153c1@gmail.com>


On 12/16/2016 12:21 PM, Valo, Kalle wrote:
> Erik Stromdahl <erik.stromdahl at gmail.com> writes:
> 
>> Initial HIF sdio/mailbox implementation.
>>
>> Signed-off-by: Erik Stromdahl <erik.stromdahl at gmail.com>
> 
> I know most of this coming from ath6kl but I think we should still
> improve the code. Lots of comments will follow, don't get scared :)
> 

I have started to fix most of the review comments below and added a new
branch on my git repo (https://github.com/erstrom/linux-ath) for this:

ath-201612150919-ath10k-sdio-kvalo-review

The changes are quite massive and I am not entirely finished yet.
I will of course squash these commits before submitting a new RFC.
You can have a look to see where I am heading.

The dma_buffer removal was a little bit tricky since there are a lot of
places in the code where the sdio functions are called with stack
allocated buffers. This does not seem to be a problem on the hardware I
am running (NXP/Freescale iMX6ul) but I am afraid that there could be
problems on other architectures.

Therefore I have introduced some temporary dynamically allocated buffers
on a few places.

>> +#define CALC_TXRX_PADDED_LEN(ar_sdio, len) \
>> +	(__ALIGN_MASK((len), (ar_sdio)->mbox_info.block_mask))
> 
> I think this could be a proper static inline function. Andrew Morton
> once said: "Write in C, not CPP" (or something like that), I think
> that's a really good point.
> 
>> +static int ath10k_sdio_read_write_sync(struct ath10k *ar, u32 addr, u8 *buf,
>> +				       u32 len, u32 request);
>> +static int ath10k_sdio_hif_diag_read(struct ath10k *ar, u32 address, void *buf,
>> +				     size_t buf_len);
>> +static int ath10k_sdio_hif_diag_read32(struct ath10k *ar, u32 address,
>> +				       u32 *value);
> 
> We prefer to avoid forward declarations if at all possible. I didn't
> check but if there's a clean way to avoid these please remove them.
> 
>> +/* HIF mbox interrupt handling */
>> +
>> +static int ath10k_sdio_mbox_rx_process_packet(struct ath10k_sdio *ar_sdio,
>> +					      struct ath10k_sdio_rx_data *pkt,
>> +					      u32 *lookaheads,
>> +					      int *n_lookaheads)
>> +{
> 
> So the style in ath10k is that all functions (of course this doesn't
> apply to callbacks etc) have "struct ath10k *ar" as the first parameter.
> This way there's no need to check if a function takes ar or ar_sdio.
> 
>> +	int status = 0;
> 
> In ath10k we prefer to use ret. And avoid initialising it, please.
> 
>> +	struct ath10k_htc *htc = &ar_sdio->ar->htc;
>> +	struct sk_buff *skb = pkt->skb;
>> +	struct ath10k_htc_hdr *htc_hdr = (struct ath10k_htc_hdr *)skb->data;
>> +	bool trailer_present = htc_hdr->flags & ATH10K_HTC_FLAG_TRAILER_PRESENT;
>> +	u16 payload_len;
>> +
>> +	payload_len = le16_to_cpu(htc_hdr->len);
>> +
>> +	if (trailer_present) {
>> +		u8 *trailer;
>> +		enum ath10k_htc_ep_id eid;
>> +
>> +		trailer = skb->data + sizeof(struct ath10k_htc_hdr) +
>> +			  payload_len - htc_hdr->trailer_len;
>> +
>> +		eid = (enum ath10k_htc_ep_id)htc_hdr->eid;
> 
> A some kind of mapping function for ep id would be nice, it makes it
> more visible how it works.
> 
>> +static int ath10k_sdio_mbox_rx_process_packets(struct ath10k_sdio *ar_sdio,
>> +					       u32 lookaheads[],
>> +					       int *n_lookahead)
>> +{
>> +	struct ath10k *ar = ar_sdio->ar;
>> +	struct ath10k_htc *htc = &ar->htc;
>> +	struct ath10k_sdio_rx_data *pkt;
>> +	int status = 0, i;
>> +
>> +	for (i = 0; i < ar_sdio->n_rx_pkts; i++) {
>> +		struct ath10k_htc_ep *ep;
>> +		enum ath10k_htc_ep_id id;
>> +		u32 *lookaheads_local = lookaheads;
>> +		int *n_lookahead_local = n_lookahead;
>> +
>> +		id = ((struct ath10k_htc_hdr *)&lookaheads[i])->eid;
>> +
>> +		if (id >= ATH10K_HTC_EP_COUNT) {
>> +			ath10k_err(ar, "Invalid endpoint in look-ahead: %d\n",
>> +				   id);
> 
> In ath10k we use ath10k_err() for errors from which can't survive and
> ath10k_warn() for errors where we try to continue. So ath10k_warn()
> would be more approriate here and most of other cases in sdio.c
> 
>> +			status = -ENOMEM;
>> +			goto out;
>> +		}
>> +
>> +		ep = &htc->endpoint[id];
>> +
>> +		if (ep->service_id == 0) {
>> +			ath10k_err(ar, "ep %d is not connected !\n", id);
>> +			status = -ENOMEM;
>> +			goto out;
>> +		}
>> +
>> +		pkt = &ar_sdio->rx_pkts[i];
>> +
>> +		if (pkt->part_of_bundle && !pkt->last_in_bundle) {
>> +			/* Only read lookahead's from RX trailers
>> +			 * for the last packet in a bundle.
>> +			 */
>> +			lookaheads_local = NULL;
>> +			n_lookahead_local = NULL;
>> +		}
>> +
>> +		status = ath10k_sdio_mbox_rx_process_packet(ar_sdio,
>> +							    pkt,
>> +							    lookaheads_local,
>> +							    n_lookahead_local);
>> +		if (status)
>> +			goto out;
>> +
>> +		ep->ep_ops.ep_rx_complete(ar_sdio->ar, pkt->skb);
>> +		/* The RX complete handler now owns the skb...*/
>> +		pkt->skb = NULL;
>> +		pkt->alloc_len = 0;
>> +	}
>> +
>> +out:
>> +	/* Free all packets that was not passed on to the RX completion
>> +	 * handler...
>> +	 */
>> +	for (; i < ar_sdio->n_rx_pkts; i++)
>> +		ath10k_sdio_mbox_free_rx_pkt(&ar_sdio->rx_pkts[i]);
> 
> I got a bit fooled by not initialising i here and only then realised
> why. I guess it's ok but a bit of so and so
> 
>> +
>> +	return status;
>> +}
>> +
>> +static int alloc_pkt_bundle(struct ath10k *ar,
>> +			    struct ath10k_sdio_rx_data *rx_pkts,
>> +			    struct ath10k_htc_hdr *htc_hdr,
>> +			    size_t full_len, size_t act_len, size_t *bndl_cnt)
>> +{
>> +	int i, status = 0;
>> +
>> +	*bndl_cnt = (htc_hdr->flags & ATH10K_HTC_FLAG_BUNDLE_MASK) >>
>> +		    ATH10K_HTC_FLAG_BUNDLE_LSB;
> 
> We recently got FIELD_GET() and FIELD_PREP() to kernel for handling
> bitmasks. ath10k is not yet converted (patches welcome!) but it would be
> good to use those already in sdio.c. Also SM() could be replaced with
> those.
> 
>> +int ath10k_sdio_mbox_rxmsg_pending_handler(struct ath10k_sdio *ar_sdio,
>> +					   u32 msg_lookahead, bool *done)
>> +{
>> +	struct ath10k *ar = ar_sdio->ar;
>> +	int status = 0;
>> +	u32 lookaheads[ATH10K_SDIO_MAX_RX_MSGS];
>> +	int n_lookaheads = 1;
>> +
>> +	*done = true;
>> +
>> +	/* Copy the lookahead obtained from the HTC register table into our
>> +	 * temp array as a start value.
>> +	 */
>> +	lookaheads[0] = msg_lookahead;
>> +
>> +	for (;;) {
> 
> Iternal loops in kernel can be dangerous. Better to add some sort of
> timeout check with a warning message, something like:
> 
> while ((time_before(jiffies, timeout)) {
> }
> 
> if (timed out)
>         ath10k_warn("timeout in foo");
> 
>> +		/* Try to allocate as many HTC RX packets indicated by
>> +		 * n_lookaheads.
>> +		 */
>> +		status = ath10k_sdio_mbox_rx_alloc(ar_sdio, lookaheads,
>> +						   n_lookaheads);
>> +		if (status)
>> +			break;
>> +
>> +		if (ar_sdio->n_rx_pkts >= 2)
>> +			/* A recv bundle was detected, force IRQ status
>> +			 * re-check again.
>> +			 */
>> +			*done = false;
>> +
>> +		status = ath10k_sdio_mbox_rx_fetch(ar_sdio);
>> +
>> +		/* Process fetched packets. This will potentially update
>> +		 * n_lookaheads depending on if the packets contain lookahead
>> +		 * reports.
>> +		 */
>> +		n_lookaheads = 0;
>> +		status = ath10k_sdio_mbox_rx_process_packets(ar_sdio,
>> +							     lookaheads,
>> +							     &n_lookaheads);
>> +
>> +		if (!n_lookaheads || status)
>> +			break;
>> +
>> +		/* For SYNCH processing, if we get here, we are running
>> +		 * through the loop again due to updated lookaheads. Set
>> +		 * flag that we should re-check IRQ status registers again
>> +		 * before leaving IRQ processing, this can net better
>> +		 * performance in high throughput situations.
>> +		 */
>> +		*done = false;
>> +	}
>> +
>> +	if (status && (status != -ECANCELED))
>> +		ath10k_err(ar, "failed to get pending recv messages: %d\n",
>> +			   status);
>> +
>> +	if (atomic_read(&ar_sdio->stopping)) {
>> +		ath10k_warn(ar, "host is going to stop. Turning of RX\n");
>> +		ath10k_sdio_hif_rx_control(ar_sdio, false);
>> +	}
> 
> I'm always skeptic when I use atomic variables used like this, I doubt
> it's really correct.
> 
>> +
>> +	return status;
>> +}
>> +
>> +static int ath10k_sdio_mbox_proc_dbg_intr(struct ath10k_sdio *ar_sdio)
>> +{
>> +	int ret;
>> +	u32 dummy;
>> +	struct ath10k *ar = ar_sdio->ar;
>> +
>> +	ath10k_warn(ar, "firmware crashed\n");
> 
> We have firmware crash dump support in ath10k. You could add a "TODO:"
> comment about implementing that later.
> 
>> +static int ath10k_sdio_mbox_proc_err_intr(struct ath10k_sdio *ar_sdio)
>> +{
>> +	int status;
>> +	u8 error_int_status;
>> +	u8 reg_buf[4];
>> +	struct ath10k_sdio_irq_data *irq_data = &ar_sdio->irq_data;
>> +	struct ath10k *ar = ar_sdio->ar;
>> +
>> +	ath10k_dbg(ar, ATH10K_DBG_SDIO, "error interrupt\n");
>> +
>> +	error_int_status = irq_data->irq_proc_reg.error_int_status & 0x0F;
>> +	if (!error_int_status) {
>> +		WARN_ON(1);
>> +		return -EIO;
>> +	}
>> +
>> +	ath10k_dbg(ar, ATH10K_DBG_SDIO,
>> +		   "valid interrupt source(s) in ERROR_INT_STATUS: 0x%x\n",
>> +		   error_int_status);
>> +
>> +	if (MS(error_int_status, MBOX_ERROR_INT_STATUS_WAKEUP))
>> +		ath10k_dbg(ar, ATH10K_DBG_SDIO, "error : wakeup\n");
>> +
>> +	if (MS(error_int_status, MBOX_ERROR_INT_STATUS_RX_UNDERFLOW))
>> +		ath10k_err(ar, "rx underflow\n");
>> +
>> +	if (MS(error_int_status, MBOX_ERROR_INT_STATUS_TX_OVERFLOW))
>> +		ath10k_err(ar, "tx overflow\n");
>> +
>> +	/* Clear the interrupt */
>> +	irq_data->irq_proc_reg.error_int_status &= ~error_int_status;
>> +
>> +	/* set W1C value to clear the interrupt, this hits the register first */
>> +	reg_buf[0] = error_int_status;
>> +	reg_buf[1] = 0;
>> +	reg_buf[2] = 0;
>> +	reg_buf[3] = 0;
>> +
>> +	status = ath10k_sdio_read_write_sync(ar,
>> +					     MBOX_ERROR_INT_STATUS_ADDRESS,
>> +					     reg_buf, 4, HIF_WR_SYNC_BYTE_FIX);
>> +
>> +	WARN_ON(status);
> 
> This is a bit dangerous, in worst case it can spam the kernel log and
> force a host reboot due watchdog timing out etc.
> 
> Better to replace with standard warning message:
> 
> ret = ath10k_sdio_read_write_sync(ar,
> 				     MBOX_ERROR_INT_STATUS_ADDRESS,
> 				     reg_buf, 4, HIF_WR_SYNC_BYTE_FIX);
> if (ret) {
>         ath10k_warn("failed to read interrupr status: %d", ret);
>         return ret;
> }
> 
>> +static int ath10k_sdio_mbox_proc_cpu_intr(struct ath10k_sdio *ar_sdio)
>> +{
>> +	int status;
>> +	struct ath10k_sdio_irq_data *irq_data = &ar_sdio->irq_data;
>> +	struct ath10k *ar = ar_sdio->ar;
>> +	u8 cpu_int_status, reg_buf[4];
>> +
>> +	cpu_int_status = irq_data->irq_proc_reg.cpu_int_status &
>> +			 irq_data->irq_en_reg.cpu_int_status_en;
>> +	if (!cpu_int_status) {
>> +		WARN_ON(1);
>> +		return -EIO;
>> +	}
> 
> Ditto about WARN_ON(), ath10k_warn() is much better.
> 
>> +/* process pending interrupts synchronously */
>> +static int ath10k_sdio_mbox_proc_pending_irqs(struct ath10k_sdio *ar_sdio,
>> +					      bool *done)
>> +{
>> +	struct ath10k_sdio_irq_data *irq_data = &ar_sdio->irq_data;
>> +	struct ath10k *ar = ar_sdio->ar;
>> +	struct ath10k_sdio_irq_proc_registers *rg;
>> +	int status = 0;
>> +	u8 host_int_status = 0;
>> +	u32 lookahead = 0;
>> +	u8 htc_mbox = 1 << ATH10K_HTC_MAILBOX;
>> +
>> +	/* NOTE: HIF implementation guarantees that the context of this
>> +	 * call allows us to perform SYNCHRONOUS I/O, that is we can block,
>> +	 * sleep or call any API that can block or switch thread/task
>> +	 * contexts. This is a fully schedulable context.
>> +	 */
>> +
>> +	/* Process pending intr only when int_status_en is clear, it may
>> +	 * result in unnecessary bus transaction otherwise. Target may be
>> +	 * unresponsive at the time.
>> +	 */
>> +	if (irq_data->irq_en_reg.int_status_en) {
>> +		/* Read the first sizeof(struct ath10k_irq_proc_registers)
>> +		 * bytes of the HTC register table. This
>> +		 * will yield us the value of different int status
>> +		 * registers and the lookahead registers.
>> +		 */
>> +		status = ath10k_sdio_read_write_sync(
>> +				ar,
>> +				MBOX_HOST_INT_STATUS_ADDRESS,
>> +				(u8 *)&irq_data->irq_proc_reg,
>> +				sizeof(irq_data->irq_proc_reg),
>> +				HIF_RD_SYNC_BYTE_INC);
>> +		if (status)
>> +			goto out;
>> +
>> +		/* Update only those registers that are enabled */
>> +		host_int_status = irq_data->irq_proc_reg.host_int_status &
>> +				  irq_data->irq_en_reg.int_status_en;
>> +
>> +		/* Look at mbox status */
>> +		if (host_int_status & htc_mbox) {
>> +			/* Mask out pending mbox value, we use look ahead as
>> +			 * the real flag for mbox processing.
>> +			 */
>> +			host_int_status &= ~htc_mbox;
>> +			if (irq_data->irq_proc_reg.rx_lookahead_valid &
>> +			    htc_mbox) {
>> +				rg = &irq_data->irq_proc_reg;
>> +				lookahead = le32_to_cpu(
>> +					rg->rx_lookahead[ATH10K_HTC_MAILBOX]);
>> +				if (!lookahead)
>> +					ath10k_err(ar, "lookahead is zero!\n");
>> +			}
>> +		}
>> +	}
>> +
>> +	if (!host_int_status && !lookahead) {
>> +		*done = true;
>> +		goto out;
>> +	}
>> +
>> +	if (lookahead) {
>> +		ath10k_dbg(ar, ATH10K_DBG_SDIO,
>> +			   "pending mailbox msg, lookahead: 0x%08X\n",
>> +			   lookahead);
>> +
>> +		status = ath10k_sdio_mbox_rxmsg_pending_handler(ar_sdio,
>> +								lookahead,
>> +								done);
>> +		if (status)
>> +			goto out;
>> +	}
>> +
>> +	/* now, handle the rest of the interrupts */
>> +	ath10k_dbg(ar, ATH10K_DBG_SDIO,
>> +		   "valid interrupt source(s) for other interrupts: 0x%x\n",
>> +		   host_int_status);
>> +
>> +	if (MS(host_int_status, MBOX_HOST_INT_STATUS_CPU)) {
>> +		/* CPU Interrupt */
>> +		status = ath10k_sdio_mbox_proc_cpu_intr(ar_sdio);
>> +		if (status)
>> +			goto out;
>> +	}
>> +
>> +	if (MS(host_int_status, MBOX_HOST_INT_STATUS_ERROR)) {
>> +		/* Error Interrupt */
>> +		status = ath10k_sdio_mbox_proc_err_intr(ar_sdio);
>> +		if (status)
>> +			goto out;
>> +	}
>> +
>> +	if (MS(host_int_status, MBOX_HOST_INT_STATUS_COUNTER))
>> +		/* Counter Interrupt */
>> +		status = ath10k_sdio_mbox_proc_counter_intr(ar_sdio);
>> +
>> +out:
>> +	/* An optimization to bypass reading the IRQ status registers
>> +	 * unecessarily which can re-wake the target, if upper layers
>> +	 * determine that we are in a low-throughput mode, we can rely on
>> +	 * taking another interrupt rather than re-checking the status
>> +	 * registers which can re-wake the target.
>> +	 *
>> +	 * NOTE : for host interfaces that makes use of detecting pending
>> +	 * mbox messages at hif can not use this optimization due to
>> +	 * possible side effects, SPI requires the host to drain all
>> +	 * messages from the mailbox before exiting the ISR routine.
>> +	 */
>> +
>> +	ath10k_dbg(ar, ATH10K_DBG_SDIO,
>> +		   "%s: (done:%d, status=%d)\n", __func__, *done, status);
> 
> We try to follow this kind of format for debug messages:
> 
> "sdio pending irqs done %d status %d"
> 
> So start with the debug level name followed by the debug separated with spaces.
> 
> And IIRC no need for "\n", the macro adds that automatically.
> 
>> +
>> +	return status;
>> +}
>> +
>> +/* Macro to check if DMA buffer is WORD-aligned and DMA-able.
>> + * Most host controllers assume the buffer is DMA'able and will
>> + * bug-check otherwise (i.e. buffers on the stack). virt_addr_valid
>> + * check fails on stack memory.
>> + */
>> +static inline bool buf_needs_bounce(u8 *buf)
>> +{
>> +	return ((unsigned long)buf & 0x3) || !virt_addr_valid(buf);
>> +}
> 
> IS_ALIGNED()? And this is super ugly, do we really need this? I would
> much prefer that we would directly use struct sk_buff, more of that
> later.
> 
>> +static inline enum ath10k_htc_ep_id pipe_id_to_eid(u8 pipe_id)
>> +{
>> +	return (enum ath10k_htc_ep_id)pipe_id;
>> +}
> 
> Oh, we already have a this kind of mapping function? Can't this be used
> earlier?
> 
>> +static void ath10k_sdio_set_mbox_info(struct ath10k_sdio *ar_sdio)
>> +{
>> +	struct ath10k_mbox_info *mbox_info = &ar_sdio->mbox_info;
>> +	u16 device = ar_sdio->func->device;
>> +
>> +	mbox_info->htc_addr = ATH10K_HIF_MBOX_BASE_ADDR;
>> +	mbox_info->block_size = ATH10K_HIF_MBOX_BLOCK_SIZE;
>> +	mbox_info->block_mask = ATH10K_HIF_MBOX_BLOCK_SIZE - 1;
>> +	mbox_info->gmbox_addr = ATH10K_HIF_GMBOX_BASE_ADDR;
>> +	mbox_info->gmbox_sz = ATH10K_HIF_GMBOX_WIDTH;
>> +
>> +	mbox_info->ext_info[0].htc_ext_addr = ATH10K_HIF_MBOX0_EXT_BASE_ADDR;
>> +
>> +	if ((device & ATH10K_MANUFACTURER_ID_REV_MASK) < 4)
>> +		mbox_info->ext_info[0].htc_ext_sz = ATH10K_HIF_MBOX0_EXT_WIDTH;
>> +	else
>> +		/* from rome 2.0(0x504), the width has been extended
>> +		 * to 56K
>> +		 */
>> +		mbox_info->ext_info[0].htc_ext_sz =
>> +			ATH10K_HIF_MBOX0_EXT_WIDTH_ROME_2_0;
>> +
>> +	mbox_info->ext_info[1].htc_ext_addr =
>> +		mbox_info->ext_info[0].htc_ext_addr +
>> +		mbox_info->ext_info[0].htc_ext_sz +
>> +		ATH10K_HIF_MBOX_DUMMY_SPACE_SIZE;
>> +	mbox_info->ext_info[1].htc_ext_sz = ATH10K_HIF_MBOX1_EXT_WIDTH;
>> +}
>> +
>> +static inline void ath10k_sdio_set_cmd52_arg(u32 *arg, u8 write, u8 raw,
>> +					     unsigned int address,
>> +					     unsigned char val)
>> +{
>> +	const u8 func = 0;
>> +
>> +	*arg = ((write & 1) << 31) |
>> +	       ((func & 0x7) << 28) |
>> +	       ((raw & 1) << 27) |
>> +	       (1 << 26) |
>> +	       ((address & 0x1FFFF) << 9) |
>> +	       (1 << 8) |
>> +	       (val & 0xFF);
>> +}
> 
> Quite ugly. FIELD_PREP() & co?
> 
>> +
>> +static int ath10k_sdio_func0_cmd52_wr_byte(struct mmc_card *card,
>> +					   unsigned int address,
>> +					   unsigned char byte)
>> +{
>> +	struct mmc_command io_cmd;
>> +
>> +	memset(&io_cmd, 0, sizeof(io_cmd));
>> +	ath10k_sdio_set_cmd52_arg(&io_cmd.arg, 1, 0, address, byte);
>> +	io_cmd.opcode = SD_IO_RW_DIRECT;
>> +	io_cmd.flags = MMC_RSP_R5 | MMC_CMD_AC;
>> +
>> +	return mmc_wait_for_cmd(card->host, &io_cmd, 0);
>> +}
>> +
>> +static int ath10k_sdio_func0_cmd52_rd_byte(struct mmc_card *card,
>> +					   unsigned int address,
>> +					   unsigned char *byte)
>> +{
>> +	int ret;
>> +	struct mmc_command io_cmd;
>> +
>> +	memset(&io_cmd, 0, sizeof(io_cmd));
>> +	ath10k_sdio_set_cmd52_arg(&io_cmd.arg, 0, 0, address, 0);
>> +	io_cmd.opcode = SD_IO_RW_DIRECT;
>> +	io_cmd.flags = MMC_RSP_R5 | MMC_CMD_AC;
>> +
>> +	ret = mmc_wait_for_cmd(card->host, &io_cmd, 0);
>> +	if (!ret)
>> +		*byte = io_cmd.resp[0];
>> +
>> +	return ret;
>> +}
>> +
>> +static int ath10k_sdio_io(struct ath10k_sdio *ar_sdio, u32 request, u32 addr,
>> +			  u8 *buf, u32 len)
>> +{
>> +	int ret = 0;
> 
> Avoid these kind of unnecessary initialisations.
> 
>> +	struct sdio_func *func = ar_sdio->func;
>> +	struct ath10k *ar = ar_sdio->ar;
>> +
>> +	sdio_claim_host(func);
>> +
>> +	if (request & HIF_WRITE) {
>> +		if (request & HIF_FIXED_ADDRESS)
>> +			ret = sdio_writesb(func, addr, buf, len);
>> +		else
>> +			ret = sdio_memcpy_toio(func, addr, buf, len);
>> +	} else {
>> +		if (request & HIF_FIXED_ADDRESS)
>> +			ret = sdio_readsb(func, buf, addr, len);
>> +		else
>> +			ret = sdio_memcpy_fromio(func, buf, addr, len);
>> +	}
>> +
>> +	sdio_release_host(func);
>> +
>> +	ath10k_dbg(ar, ATH10K_DBG_SDIO, "%s addr 0x%x%s buf 0x%p len %d\n",
>> +		   request & HIF_WRITE ? "wr" : "rd", addr,
>> +		   request & HIF_FIXED_ADDRESS ? " (fixed)" : "", buf, len);
>> +	ath10k_dbg_dump(ar, ATH10K_DBG_SDIO_DUMP, NULL,
>> +			request & HIF_WRITE ? "sdio wr " : "sdio rd ",
>> +			buf, len);
>> +
>> +	return ret;
>> +}
>> +
>> +static struct ath10k_sdio_bus_request
>> +*ath10k_sdio_alloc_busreq(struct ath10k_sdio *ar_sdio)
>> +{
>> +	struct ath10k_sdio_bus_request *bus_req;
>> +
>> +	spin_lock_bh(&ar_sdio->lock);
>> +
>> +	if (list_empty(&ar_sdio->bus_req_freeq)) {
>> +		spin_unlock_bh(&ar_sdio->lock);
>> +		return NULL;
>> +	}
>> +
>> +	bus_req = list_first_entry(&ar_sdio->bus_req_freeq,
>> +				   struct ath10k_sdio_bus_request, list);
>> +	list_del(&bus_req->list);
>> +
>> +	spin_unlock_bh(&ar_sdio->lock);
>> +
>> +	return bus_req;
>> +}
>> +
>> +static void ath10k_sdio_free_bus_req(struct ath10k_sdio *ar_sdio,
>> +				     struct ath10k_sdio_bus_request *bus_req)
>> +{
>> +	spin_lock_bh(&ar_sdio->lock);
>> +	list_add_tail(&bus_req->list, &ar_sdio->bus_req_freeq);
>> +	spin_unlock_bh(&ar_sdio->lock);
>> +}
>> +
>> +static int ath10k_sdio_read_write_sync(struct ath10k *ar, u32 addr, u8 *buf,
>> +				       u32 len, u32 request)
>> +{
>> +	struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
>> +	u8  *tbuf = NULL;
> 
> Extra space after u8?
> 
>> +	int ret;
>> +	bool bounced = false;
>> +
>> +	if (request & HIF_BLOCK_BASIS)
>> +		len = round_down(len, ar_sdio->mbox_info.block_size);
>> +
>> +	if (buf_needs_bounce(buf)) {
>> +		if (!ar_sdio->dma_buffer)
>> +			return -ENOMEM;
>> +		/* FIXME: I am not sure if it is always correct to assume
>> +		 * that the SDIO irq is a "fake" irq and sleep is possible.
>> +		 * (this function will get called from
>> +		 * ath10k_sdio_irq_handler
>> +		 */
>> +		mutex_lock(&ar_sdio->dma_buffer_mutex);
>> +		tbuf = ar_sdio->dma_buffer;
>> +
>> +		if (request & HIF_WRITE)
>> +			memcpy(tbuf, buf, len);
>> +
>> +		bounced = true;
>> +	} else {
>> +		tbuf = buf;
>> +	}
> 
> So I really hate that ar_sdio->dma_buffer, do we really need it? What if
> we just get rid of it and allocate struct sk_buff and pass that around?
> No need to do extra copying then, I hope :)
> 
>> +
>> +	ret = ath10k_sdio_io(ar_sdio, request, addr, tbuf, len);
>> +	if ((request & HIF_READ) && bounced)
>> +		memcpy(buf, tbuf, len);
>> +
>> +	if (bounced)
>> +		mutex_unlock(&ar_sdio->dma_buffer_mutex);
>> +
>> +	return ret;
>> +}
>> +
>> +static void __ath10k_sdio_write_async(struct ath10k_sdio *ar_sdio,
>> +				      struct ath10k_sdio_bus_request *req)
>> +{
>> +	int status;
>> +	struct ath10k_htc_ep *ep;
>> +	struct sk_buff *skb;
>> +
>> +	skb = req->skb;
>> +	status = ath10k_sdio_read_write_sync(ar_sdio->ar, req->address,
>> +					     skb->data, req->len,
>> +					     req->request);
>> +	ep = &ar_sdio->ar->htc.endpoint[req->eid];
>> +	ath10k_htc_notify_tx_completion(ep, skb);
>> +	ath10k_sdio_free_bus_req(ar_sdio, req);
>> +}
>> +
>> +static void ath10k_sdio_write_async_work(struct work_struct *work)
>> +{
>> +	struct ath10k_sdio *ar_sdio;
>> +	struct ath10k_sdio_bus_request *req, *tmp_req;
>> +
>> +	ar_sdio = container_of(work, struct ath10k_sdio, wr_async_work);
>> +
>> +	spin_lock_bh(&ar_sdio->wr_async_lock);
>> +	list_for_each_entry_safe(req, tmp_req, &ar_sdio->wr_asyncq, list) {
>> +		list_del(&req->list);
>> +		spin_unlock_bh(&ar_sdio->wr_async_lock);
>> +		__ath10k_sdio_write_async(ar_sdio, req);
>> +		spin_lock_bh(&ar_sdio->wr_async_lock);
>> +	}
>> +	spin_unlock_bh(&ar_sdio->wr_async_lock);
>> +}
>> +
>> +static void ath10k_sdio_irq_handler(struct sdio_func *func)
>> +{
>> +	int status = 0;
>> +	unsigned long timeout;
>> +	struct ath10k_sdio *ar_sdio;
>> +	bool done = false;
>> +
>> +	ar_sdio = sdio_get_drvdata(func);
>> +	atomic_set(&ar_sdio->irq_handling, 1);
>> +
>> +	/* Release the host during interrupts so we can pick it back up when
>> +	 * we process commands.
>> +	 */
>> +	sdio_release_host(ar_sdio->func);
>> +
>> +	timeout = jiffies + ATH10K_SDIO_HIF_COMMUNICATION_TIMEOUT_HZ;
>> +	while (time_before(jiffies, timeout) && !done) {
>> +		status = ath10k_sdio_mbox_proc_pending_irqs(ar_sdio, &done);
>> +		if (status)
>> +			break;
>> +	}
>> +
>> +	sdio_claim_host(ar_sdio->func);
>> +
>> +	atomic_set(&ar_sdio->irq_handling, 0);
>> +	wake_up(&ar_sdio->irq_wq);
>> +
>> +	WARN_ON(status && status != -ECANCELED);
>> +}
> 
> Questionable use of an atomic variable again, looks like badly implement
> poor man's locking to me. And instead of wake_up() we should workqueues
> or threaded irqs (if sdio supports that).
> 
>> +
>> +static int ath10k_sdio_hif_disable_intrs(struct ath10k_sdio *ar_sdio)
>> +{
>> +	int ret;
>> +	struct ath10k_sdio_irq_enable_reg regs;
>> +	struct ath10k_sdio_irq_data *irq_data = &ar_sdio->irq_data;
>> +
>> +	memset(&regs, 0, sizeof(regs));
>> +
>> +	ret = ath10k_sdio_read_write_sync(ar_sdio->ar,
>> +					  MBOX_INT_STATUS_ENABLE_ADDRESS,
>> +					  &regs.int_status_en, sizeof(regs),
>> +					  HIF_WR_SYNC_BYTE_INC);
>> +	if (ret) {
>> +		ath10k_err(ar_sdio->ar, "Unable to disable sdio interrupts\n");
>> +		return ret;
>> +	}
>> +
>> +	spin_lock_bh(&irq_data->lock);
>> +	irq_data->irq_en_reg = regs;
>> +	spin_unlock_bh(&irq_data->lock);
>> +
>> +	return 0;
>> +}
>> +
>> +static int ath10k_sdio_hif_power_up(struct ath10k *ar)
>> +{
>> +	struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
>> +	struct sdio_func *func = ar_sdio->func;
>> +	int ret = 0;
>> +
>> +	if (!ar_sdio->is_disabled)
>> +		return 0;
>> +
>> +	ath10k_dbg(ar, ATH10K_DBG_BOOT, "sdio power on\n");
>> +
>> +	sdio_claim_host(func);
>> +
>> +	ret = sdio_enable_func(func);
>> +	if (ret) {
>> +		ath10k_err(ar, "Unable to enable sdio func: %d)\n", ret);
>> +		sdio_release_host(func);
>> +		return ret;
>> +	}
>> +
>> +	sdio_release_host(func);
>> +
>> +	/* Wait for hardware to initialise. It should take a lot less than
>> +	 * 20 ms but let's be conservative here.
>> +	 */
>> +	msleep(20);
>> +
>> +	ar_sdio->is_disabled = false;
>> +
>> +	ret = ath10k_sdio_hif_disable_intrs(ar_sdio);
>> +
>> +	return ret;
>> +}
>> +
>> +static void ath10k_sdio_hif_power_down(struct ath10k *ar)
>> +{
>> +	struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
>> +	int ret;
>> +
>> +	if (ar_sdio->is_disabled)
>> +		return;
>> +
>> +	ath10k_dbg(ar, ATH10K_DBG_BOOT, "sdio power off\n");
>> +
>> +	/* Disable the card */
>> +	sdio_claim_host(ar_sdio->func);
>> +	ret = sdio_disable_func(ar_sdio->func);
>> +	sdio_release_host(ar_sdio->func);
>> +
>> +	if (ret)
>> +		ath10k_dbg(ar, ATH10K_DBG_BOOT,
>> +			   "Unable to disable sdio: %d\n", ret);
> 
> Shouldn't this be ath10k_warn()?
> 
>> +
>> +	ar_sdio->is_disabled = true;
>> +}
>> +
>> +int ath10k_sdio_hif_tx_sg(struct ath10k *ar, u8 pipe_id,
>> +			  struct ath10k_hif_sg_item *items, int n_items)
>> +{
>> +	int i;
>> +	u32 address;
>> +	struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
>> +	struct ath10k_sdio_bus_request *bus_req;
>> +
>> +	bus_req = ath10k_sdio_alloc_busreq(ar_sdio);
>> +
>> +	if (WARN_ON_ONCE(!bus_req))
>> +		return -ENOMEM;
> 
> Is ath10k_warn() more approriate?
> 
>> +	for (i = 0; i < n_items; i++) {
>> +		bus_req->skb = items[i].transfer_context;
>> +		bus_req->request = HIF_WRITE;
>> +		bus_req->eid = pipe_id_to_eid(pipe_id);
>> +		/* Write TX data to the end of the mbox address space */
>> +		address = ar_sdio->mbox_addr[bus_req->eid] +
>> +			  ar_sdio->mbox_size[bus_req->eid] - bus_req->skb->len;
>> +		bus_req->address = address;
>> +		bus_req->len = CALC_TXRX_PADDED_LEN(ar_sdio, bus_req->skb->len);
>> +
>> +		spin_lock_bh(&ar_sdio->wr_async_lock);
>> +		list_add_tail(&bus_req->list, &ar_sdio->wr_asyncq);
>> +		spin_unlock_bh(&ar_sdio->wr_async_lock);
>> +	}
>> +
>> +	queue_work(ar_sdio->workqueue, &ar_sdio->wr_async_work);
>> +
>> +	return 0;
>> +}
>> +
>> +static int ath10k_sdio_hif_enable_intrs(struct ath10k_sdio *ar_sdio)
>> +{
>> +	struct ath10k_sdio_irq_enable_reg regs;
>> +	int status;
>> +	struct ath10k_sdio_irq_data *irq_data = &ar_sdio->irq_data;
>> +
>> +	memset(&regs, 0, sizeof(regs));
>> +
>> +	/* Enable all but CPU interrupts */
>> +	regs.int_status_en = SM(0x01, MBOX_INT_STATUS_ENABLE_ERROR) |
>> +			     SM(0x01, MBOX_INT_STATUS_ENABLE_CPU) |
>> +			     SM(0x01, MBOX_INT_STATUS_ENABLE_COUNTER);
>> +
>> +	/* NOTE: There are some cases where HIF can do detection of
>> +	 * pending mbox messages which is disabled now.
>> +	 */
>> +	regs.int_status_en |= SM(0x01, MBOX_INT_STATUS_ENABLE_MBOX_DATA);
>> +
>> +	/* Set up the CPU Interrupt status Register */
>> +	regs.cpu_int_status_en = 0;
>> +
>> +	/* Set up the Error Interrupt status Register */
>> +	regs.err_int_status_en =
>> +		SM(0x01, MBOX_ERROR_STATUS_ENABLE_RX_UNDERFLOW) |
>> +		SM(0x01, MBOX_ERROR_STATUS_ENABLE_TX_OVERFLOW);
>> +
>> +	/* Enable Counter interrupt status register to get fatal errors for
>> +	 * debugging.
>> +	 */
>> +	regs.cntr_int_status_en = SM(ATH10K_SDIO_TARGET_DEBUG_INTR_MASK,
>> +				     MBOX_COUNTER_INT_STATUS_ENABLE_BIT);
>> +
>> +	status = ath10k_sdio_read_write_sync(ar_sdio->ar,
>> +					     MBOX_INT_STATUS_ENABLE_ADDRESS,
>> +					     &regs.int_status_en, sizeof(regs),
>> +					     HIF_WR_SYNC_BYTE_INC);
>> +	if (status) {
>> +		ath10k_err(ar_sdio->ar,
>> +			   "failed to update interrupt ctl reg err: %d\n",
>> +			   status);
>> +		return status;
>> +	}
>> +
>> +	spin_lock_bh(&irq_data->lock);
>> +	irq_data->irq_en_reg = regs;
>> +	spin_unlock_bh(&irq_data->lock);
>> +
>> +	return 0;
>> +}
>> +
>> +static int ath10k_sdio_hif_start(struct ath10k *ar)
>> +{
>> +	int ret;
>> +	struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
>> +	u32 addr, val;
>> +
>> +	addr = host_interest_item_address(HI_ITEM(hi_acs_flags));
>> +
>> +	ret = ath10k_sdio_hif_diag_read32(ar, addr, &val);
>> +	if (ret) {
>> +		ath10k_err(ar, "Unable to read diag mem: %d\n", ret);
>> +		goto out;
>> +	}
>> +
>> +	if (val & HI_ACS_FLAGS_SDIO_SWAP_MAILBOX_FW_ACK) {
>> +		ath10k_dbg(ar, ATH10K_DBG_SDIO,
>> +			   "Mailbox SWAP Service is enabled\n");
>> +		ar_sdio->swap_mbox = true;
>> +	}
>> +
>> +	/* eid 0 always uses the lower part of the extended mailbox address
>> +	 * space (ext_info[0].htc_ext_addr).
>> +	 */
>> +	ar_sdio->mbox_addr[0] = ar_sdio->mbox_info.ext_info[0].htc_ext_addr;
>> +	ar_sdio->mbox_size[0] = ar_sdio->mbox_info.ext_info[0].htc_ext_sz;
>> +
>> +	sdio_claim_host(ar_sdio->func);
>> +
>> +	/* Register the isr */
>> +	ret =  sdio_claim_irq(ar_sdio->func, ath10k_sdio_irq_handler);
>> +	if (ret) {
>> +		ath10k_err(ar, "Failed to claim sdio irq: %d\n", ret);
>> +		sdio_release_host(ar_sdio->func);
>> +		goto out;
>> +	}
>> +
>> +	sdio_release_host(ar_sdio->func);
>> +
>> +	ret = ath10k_sdio_hif_enable_intrs(ar_sdio);
>> +	if (ret)
>> +		ath10k_err(ar, "Failed to enable sdio interrupts: %d\n", ret);
>> +
>> +out:
>> +	return ret;
>> +}
>> +
>> +static bool ath10k_sdio_is_on_irq(struct ath10k *ar)
>> +{
>> +	struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
>> +
>> +	return !atomic_read(&ar_sdio->irq_handling);
>> +}
> 
> Yikes.
> 
>> +
>> +static void ath10k_sdio_irq_disable(struct ath10k *ar)
>> +{
>> +	struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
>> +	int ret;
>> +
>> +	sdio_claim_host(ar_sdio->func);
>> +
>> +	atomic_set(&ar_sdio->stopping, 1);
>> +
>> +	if (atomic_read(&ar_sdio->irq_handling)) {
>> +		sdio_release_host(ar_sdio->func);
>> +
>> +		ret = wait_event_interruptible(ar_sdio->irq_wq,
>> +					       ath10k_sdio_is_on_irq(ar));
>> +		if (ret)
>> +			return;
>> +
>> +		sdio_claim_host(ar_sdio->func);
>> +	}
> 
> There has to be a better way to implement this, now it feels that it's
> just reimplementing the wheel. We should have proper way to wait for
> interrupt handlers and workqueues to end etc.
> 
>> +	ret = sdio_release_irq(ar_sdio->func);
>> +	if (ret)
>> +		ath10k_err(ar, "Failed to release sdio irq: %d\n", ret);
>> +
>> +	sdio_release_host(ar_sdio->func);
>> +}
>> +
>> +static int ath10k_sdio_config(struct ath10k_sdio *ar_sdio)
>> +{
>> +	struct ath10k *ar = ar_sdio->ar;
>> +	struct sdio_func *func = ar_sdio->func;
>> +	unsigned char byte, asyncintdelay = 2;
>> +	int ret;
>> +
>> +	ath10k_dbg(ar, ATH10K_DBG_BOOT, "SDIO configuration\n");
>> +
>> +	sdio_claim_host(func);
>> +
>> +	byte = 0;
>> +	ret = ath10k_sdio_func0_cmd52_rd_byte(func->card,
>> +					      SDIO_CCCR_DRIVE_STRENGTH,
>> +					      &byte);
>> +
>> +	byte = (byte & (~(SDIO_DRIVE_DTSx_MASK << SDIO_DRIVE_DTSx_SHIFT))) |
>> +		SDIO_DTSx_SET_TYPE_D;
> 
> FIELD_PREP(). There are lots of places where that an be used.
> 
>> +static void ath10k_sdio_write32(struct ath10k *ar, u32 offset, u32 value)
>> +{
>> +}
>> +
>> +static u32 ath10k_sdio_read32(struct ath10k *ar, u32 offset)
>> +{
>> +	return 0;
>> +}
> 
> Somekind of FIXME/TODO comments for write32() and read32()? What
> functionality are we going to miss when we don't implement these?
> 
>> +static void ath10k_sdio_hif_send_complete_check(struct ath10k *ar,
>> +						u8 pipe, int force)
>> +{
>> +}
>> +
>> +static u16 ath10k_sdio_hif_get_free_queue_number(struct ath10k *ar, u8 pipe)
>> +{
>> +	return 0;
>> +}
> 
> Similar comments here also.
> 
>> +
>> +static const struct ath10k_hif_ops ath10k_sdio_hif_ops = {
>> +	.tx_sg			= ath10k_sdio_hif_tx_sg,
>> +	.diag_read		= ath10k_sdio_hif_diag_read,
>> +	.diag_write		= ath10k_sdio_diag_write_mem,
>> +	.exchange_bmi_msg	= ath10k_sdio_hif_exchange_bmi_msg,
>> +	.start			= ath10k_sdio_hif_start,
>> +	.stop			= ath10k_sdio_hif_stop,
>> +	.map_service_to_pipe	= ath10k_sdio_hif_map_service_to_pipe,
>> +	.get_default_pipe	= ath10k_sdio_hif_get_default_pipe,
>> +	.send_complete_check	= ath10k_sdio_hif_send_complete_check,
>> +	.get_free_queue_number	= ath10k_sdio_hif_get_free_queue_number,
>> +	.power_up		= ath10k_sdio_hif_power_up,
>> +	.power_down		= ath10k_sdio_hif_power_down,
>> +	.read32			= ath10k_sdio_read32,
>> +	.write32		= ath10k_sdio_write32,
>> +#ifdef CONFIG_PM
>> +	.suspend		= ath10k_sdio_hif_suspend,
>> +	.resume			= ath10k_sdio_hif_resume,
>> +#endif
>> +	.fetch_cal_eeprom	= ath10k_sdio_hif_fetch_cal_eeprom,
>> +};
>> +
>> +#ifdef CONFIG_PM_SLEEP
>> +
>> +/* Empty handlers so that mmc subsystem doesn't remove us entirely during
>> + * suspend. We instead follow cfg80211 suspend/resume handlers.
>> + */
>> +static int ath10k_sdio_pm_suspend(struct device *device)
>> +{
>> +	return 0;
>> +}
>> +
>> +static int ath10k_sdio_pm_resume(struct device *device)
>> +{
>> +	return 0;
>> +}
>> +
>> +static SIMPLE_DEV_PM_OPS(ath10k_sdio_pm_ops, ath10k_sdio_pm_suspend,
>> +			 ath10k_sdio_pm_resume);
>> +
>> +#define ATH10K_SDIO_PM_OPS (&ath10k_sdio_pm_ops)
>> +
>> +#else
>> +
>> +#define ATH10K_SDIO_PM_OPS NULL
>> +
>> +#endif /* CONFIG_PM_SLEEP */
>> +
>> +static int ath10k_sdio_probe(struct sdio_func *func,
>> +			     const struct sdio_device_id *id)
>> +{
>> +	int ret;
>> +	struct ath10k_sdio *ar_sdio;
>> +	struct ath10k *ar;
>> +	int i;
>> +	enum ath10k_hw_rev hw_rev;
>> +
>> +	hw_rev = ATH10K_HW_QCA6174;
> 
> This needs a comment, at least to remind if ever add something else than
> QCA6174 based SDIO design.
> 
>> +
>> +	ar = ath10k_core_create(sizeof(*ar_sdio), &func->dev, ATH10K_BUS_SDIO,
>> +				hw_rev, &ath10k_sdio_hif_ops);
>> +	if (!ar) {
>> +		dev_err(&func->dev, "failed to allocate core\n");
>> +		return -ENOMEM;
>> +	}
>> +
>> +	ath10k_dbg(ar, ATH10K_DBG_BOOT,
>> +		   "sdio new func %d vendor 0x%x device 0x%x block 0x%x/0x%x\n",
>> +		   func->num, func->vendor, func->device,
>> +		   func->max_blksize, func->cur_blksize);
>> +
>> +	ar_sdio = ath10k_sdio_priv(ar);
>> +
>> +	ar_sdio->dma_buffer = kzalloc(ATH10K_HIF_DMA_BUFFER_SIZE, GFP_KERNEL);
>> +	if (!ar_sdio->dma_buffer) {
>> +		ret = -ENOMEM;
>> +		goto err_core_destroy;
>> +	}
>> +
>> +	ar_sdio->func = func;
>> +	sdio_set_drvdata(func, ar_sdio);
>> +
>> +	ar_sdio->is_disabled = true;
>> +	ar_sdio->ar = ar;
>> +
>> +	spin_lock_init(&ar_sdio->lock);
>> +	spin_lock_init(&ar_sdio->wr_async_lock);
>> +	spin_lock_init(&ar_sdio->irq_data.lock);
>> +	mutex_init(&ar_sdio->dma_buffer_mutex);
>> +
>> +	INIT_LIST_HEAD(&ar_sdio->bus_req_freeq);
>> +	INIT_LIST_HEAD(&ar_sdio->wr_asyncq);
>> +
>> +	INIT_WORK(&ar_sdio->wr_async_work, ath10k_sdio_write_async_work);
>> +	ar_sdio->workqueue = create_singlethread_workqueue("ath10k_sdio_wq");
>> +	if (!ar_sdio->workqueue)
>> +		goto err;
>> +
>> +	init_waitqueue_head(&ar_sdio->irq_wq);
>> +
>> +	for (i = 0; i < ATH10K_SDIO_BUS_REQUEST_MAX_NUM; i++)
>> +		ath10k_sdio_free_bus_req(ar_sdio, &ar_sdio->bus_req[i]);
>> +
>> +	ar->dev_id = id->device;
>> +	ar->id.vendor = id->vendor;
>> +	ar->id.device = id->device;
>> +
>> +	ath10k_sdio_set_mbox_info(ar_sdio);
>> +
>> +	ret = ath10k_sdio_config(ar_sdio);
>> +	if (ret) {
>> +		ath10k_err(ar, "Failed to config sdio: %d\n", ret);
>> +		goto err;
>> +	}
>> +
>> +	ret = ath10k_core_register(ar, 0/*chip_id is not applicaple for SDIO*/);
>> +	if (ret) {
>> +		ath10k_err(ar, "failed to register driver core: %d\n", ret);
>> +		goto err;
>> +	}
> 
> I would assume that chip_id is applicaple also with SDIO, there has to
> be a register where to get it. Also this kind of comment style is
> preferred:
> 
> /* TODO: don't know yet how to get chip_id with SDIO */
> chip_id = 0;
> 
> ret = ath10k_core_register(ar, chip_id);
> 
>> +
>> +	return ret;
>> +
>> +err:
>> +	kfree(ar_sdio->dma_buffer);
>> +err_core_destroy:
>> +	ath10k_core_destroy(ar);
>> +
>> +	return ret;
>> +}
>> +
>> +static void ath10k_sdio_remove(struct sdio_func *func)
>> +{
>> +	struct ath10k_sdio *ar_sdio;
>> +	struct ath10k *ar;
>> +
>> +	ar_sdio = sdio_get_drvdata(func);
>> +	ar = ar_sdio->ar;
>> +
>> +	ath10k_dbg(ar, ATH10K_DBG_BOOT,
>> +		   "sdio removed func %d vendor 0x%x device 0x%x\n",
>> +		   func->num, func->vendor, func->device);
>> +
>> +	(void)ath10k_sdio_hif_disable_intrs(ar_sdio);
>> +	cancel_work_sync(&ar_sdio->wr_async_work);
>> +	ath10k_core_unregister(ar);
>> +	ath10k_core_destroy(ar);
>> +
>> +	kfree(ar_sdio->dma_buffer);
>> +}
>> +
>> +static const struct sdio_device_id ath10k_sdio_devices[] = {
>> +	{SDIO_DEVICE(ATH10K_MANUFACTURER_CODE,
>> +		     (ATH10K_MANUFACTURER_ID_AR6005_BASE | 0xA))},
>> +	{},
>> +};
> 
> I suspect there's a more sensible way to create the device table than
> this, just no time to check it now. Anyone know?
> 
> The naming "ath10k manufacturer" is also wrong, it should be QCA or
> Qualcomm.
> 


From Charles.Gordon at digi.com  Tue Dec 20 14:35:41 2016
From: Charles.Gordon at digi.com (Gordon, Charles)
Date: Tue, 20 Dec 2016 22:35:41 +0000
Subject: Can the ath10k driver support more than one MAC address?
Message-ID: <ED4D0B085DB73545BAA27FA575E389E48101A2@MTK-SMS-XCH02.digi.com>

Hi,

We are trying to use the ath10k driver in an embedded application.  We want to support a wifi client with multiple access points.  Does the ath10k driver support this?  Can the ath10k hardware and driver support multiple simultaneous MAC addresses?  Can it support multiple APs?

Thanks for any information.

Charles


From janusz.dziedzic at tieto.com  Wed Dec 21 00:18:44 2016
From: janusz.dziedzic at tieto.com (Janusz Dziedzic)
Date: Wed, 21 Dec 2016 09:18:44 +0100
Subject: Can the ath10k driver support more than one MAC address?
In-Reply-To: <ED4D0B085DB73545BAA27FA575E389E48101A2@MTK-SMS-XCH02.digi.com>
References: <ED4D0B085DB73545BAA27FA575E389E48101A2@MTK-SMS-XCH02.digi.com>
Message-ID: <CALhHN=qLK+ZBBmpA940g8hcXDcUhuXYxoTUVR6imjfLPZDCiLQ@mail.gmail.com>

On 20 December 2016 at 23:35, Gordon, Charles <Charles.Gordon at digi.com> wrote:
> Hi,
>
> We are trying to use the ath10k driver in an embedded application.  We want to support a wifi client with multiple access points.  Does the ath10k driver support this?  Can the ath10k hardware and driver support multiple simultaneous MAC addresses?  Can it support multiple APs?
>
iw wlan0 interface add wlan0_1 type managed
ifconfig wlan0_1 hw ether <new_mac>

Depends on HW you have, some ath10k support single/multi channel concurrency.
You can check this using
iw phyX info - and next check valid combinations (channels <= 1 mean
SCC, so best if you have <= 2)

BR
Janusz

> Thanks for any information.
>
> Charles
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From adrian at freebsd.org  Wed Dec 21 00:29:53 2016
From: adrian at freebsd.org (Adrian Chadd)
Date: Wed, 21 Dec 2016 00:29:53 -0800
Subject: Can the ath10k driver support more than one MAC address?
Message-ID: <CAJ-VmonG3p2K69kjcLscRgWsOEQhyzj4_3c_aGhK=fXcZqXB=g@mail.gmail.com>

hiya,

This is the kind of thing that Ben Greear has spent a lot of time
debugging in his firmware branch.


-adrian


On 21 December 2016 at 00:18, Janusz Dziedzic <janusz.dziedzic at tieto.com> wrote:
> On 20 December 2016 at 23:35, Gordon, Charles <Charles.Gordon at digi.com> wrote:
>> Hi,
>>
>> We are trying to use the ath10k driver in an embedded application.  We want to support a wifi client with multiple access points.  Does the ath10k driver support this?  Can the ath10k hardware and driver support multiple simultaneous MAC addresses?  Can it support multiple APs?
>>
> iw wlan0 interface add wlan0_1 type managed
> ifconfig wlan0_1 hw ether <new_mac>
>
> Depends on HW you have, some ath10k support single/multi channel concurrency.
> You can check this using
> iw phyX info - and next check valid combinations (channels <= 1 mean
> SCC, so best if you have <= 2)
>
> BR
> Janusz
>
>> Thanks for any information.
>>
>> Charles
>>
>> _______________________________________________
>> 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


From kvalo at qca.qualcomm.com  Wed Dec 21 04:19:21 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 21 Dec 2016 14:19:21 +0200
Subject: [PATCH] ath10k: support dev_coredump for crash dump
Message-ID: <20161221121921.25119.93932.stgit@potku.adurom.net>

From: Arun Khandavalli <akhandav at qti.qualcomm.com>

Whenever firmware crashes, and both CONFIG_ATH10K_DEBUGFS and
CONFIG_ALLOW_DEV_COREDUMP are enabled, dump information about the crash via a
devcoredump device. Dump can be read from userspace for further analysis from:

/sys/class/devcoredump/devcd*/data

As until now we have provided the firmware crash dump file via fw_crash_dump
debugfs keep it still available but deprecate and a warning print that the user
should switch to using dev_coredump.

Future improvement would be not to depend on CONFIG_ATH10K_DEBUGFS, as there
might be systems which want to get the firmware crash dump but not enable
debugfs. How to handle memory consumption is also something which needs to be
taken into account.

Signed-off-by: Arun Khandavalli <akhandav at qti.qualcomm.com>
[kvalo at qca.qualcomm.com: rebase, fixes, improve commit log]
Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c  |    6 ++++
 drivers/net/wireless/ath/ath10k/debug.c |   43 +++++++++++++++++++++++++++++--
 drivers/net/wireless/ath/ath10k/debug.h |    8 ++++++
 3 files changed, 54 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 749e381edd38..3319db178c2e 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1510,6 +1510,7 @@ static int ath10k_init_hw_params(struct ath10k *ar)
 static void ath10k_core_restart(struct work_struct *work)
 {
 	struct ath10k *ar = container_of(work, struct ath10k, restart_work);
+	int ret;
 
 	set_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags);
 
@@ -1561,6 +1562,11 @@ static void ath10k_core_restart(struct work_struct *work)
 	}
 
 	mutex_unlock(&ar->conf_mutex);
+
+	ret = ath10k_debug_fw_devcoredump(ar);
+	if (ret)
+		ath10k_warn(ar, "failed to send firmware crash dump via devcoredump: %d",
+			    ret);
 }
 
 static void ath10k_core_set_coverage_class_work(struct work_struct *work)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 82a4c67f3672..e1a70dffc52a 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -21,6 +21,7 @@
 #include <linux/utsname.h>
 #include <linux/crc32.h>
 #include <linux/firmware.h>
+#include <linux/devcoredump.h>
 
 #include "core.h"
 #include "debug.h"
@@ -721,7 +722,8 @@ struct ath10k_fw_crash_data *
 }
 EXPORT_SYMBOL(ath10k_debug_get_new_fw_crash_data);
 
-static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
+static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar,
+							    bool mark_read)
 {
 	struct ath10k_fw_crash_data *crash_data = ar->debug.fw_crash_data;
 	struct ath10k_dump_file_data *dump_data;
@@ -790,19 +792,54 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
 	       sizeof(crash_data->registers));
 	sofar += sizeof(*dump_tlv) + sizeof(crash_data->registers);
 
-	ar->debug.fw_crash_data->crashed_since_read = false;
+	ar->debug.fw_crash_data->crashed_since_read = !mark_read;
 
 	spin_unlock_bh(&ar->data_lock);
 
 	return dump_data;
 }
 
+int ath10k_debug_fw_devcoredump(struct ath10k *ar)
+{
+	struct ath10k_dump_file_data *dump;
+	void *dump_ptr;
+	u32 dump_len;
+
+	/* To keep the dump file available also for debugfs don't mark the
+	 * file read, only debugfs should do that.
+	 */
+	dump = ath10k_build_dump_file(ar, false);
+	if (!dump) {
+		ath10k_warn(ar, "no crash dump data found for devcoredump");
+		return -ENODATA;
+	}
+
+	/* Make a copy of the dump file for dev_coredumpv() as during the
+	 * transition period we need to own the original file. Once
+	 * fw_crash_dump debugfs file is removed no need to have a copy
+	 * anymore.
+	 */
+	dump_len = le32_to_cpu(dump->len);
+	dump_ptr = vzalloc(dump_len);
+
+	if (!dump_ptr)
+		return -ENOMEM;
+
+	memcpy(dump_ptr, dump, dump_len);
+
+	dev_coredumpv(ar->dev, dump_ptr, dump_len, GFP_KERNEL);
+
+	return 0;
+}
+
 static int ath10k_fw_crash_dump_open(struct inode *inode, struct file *file)
 {
 	struct ath10k *ar = inode->i_private;
 	struct ath10k_dump_file_data *dump;
 
-	dump = ath10k_build_dump_file(ar);
+	ath10k_warn(ar, "fw_crash_dump debugfs file is deprecated, please use /sys/class/devcoredump instead.");
+
+	dump = ath10k_build_dump_file(ar, true);
 	if (!dump)
 		return -ENODATA;
 
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 335512b11ca2..2368f47314ae 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -84,6 +84,9 @@ struct ath10k_fw_crash_data *
 ath10k_debug_get_new_fw_crash_data(struct ath10k *ar);
 
 void ath10k_debug_dbglog_add(struct ath10k *ar, u8 *buffer, int len);
+
+int ath10k_debug_fw_devcoredump(struct ath10k *ar);
+
 #define ATH10K_DFS_STAT_INC(ar, c) (ar->debug.dfs_stats.c++)
 
 void ath10k_debug_get_et_strings(struct ieee80211_hw *hw,
@@ -166,6 +169,11 @@ static inline u32 ath10k_debug_get_fw_dbglog_level(struct ath10k *ar)
 	return 0;
 }
 
+static inline int ath10k_debug_fw_devcoredump(struct ath10k *ar)
+{
+	return 0;
+}
+
 #define ATH10K_DFS_STAT_INC(ar, c) do { } while (0)
 
 #define ath10k_debug_get_et_strings NULL



From greearb at candelatech.com  Wed Dec 21 05:21:00 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 21 Dec 2016 05:21:00 -0800
Subject: Can the ath10k driver support more than one MAC address?
In-Reply-To: <CAJ-VmonG3p2K69kjcLscRgWsOEQhyzj4_3c_aGhK=fXcZqXB=g@mail.gmail.com>
References: <CAJ-VmonG3p2K69kjcLscRgWsOEQhyzj4_3c_aGhK=fXcZqXB=g@mail.gmail.com>
Message-ID: <585A81BC.1040908@candelatech.com>

Yeah, seems to work fine for me with CT firmware.

It can probably work OK with stock FW too.

Thanks,
Ben

On 12/21/2016 12:29 AM, Adrian Chadd wrote:
> hiya,
>
> This is the kind of thing that Ben Greear has spent a lot of time
> debugging in his firmware branch.
>
>
> -adrian
>
>
> On 21 December 2016 at 00:18, Janusz Dziedzic <janusz.dziedzic at tieto.com> wrote:
>> On 20 December 2016 at 23:35, Gordon, Charles <Charles.Gordon at digi.com> wrote:
>>> Hi,
>>>
>>> We are trying to use the ath10k driver in an embedded application.  We want to support a wifi client with multiple access points.  Does the ath10k driver support this?  Can the ath10k hardware and driver support multiple simultaneous MAC addresses?  Can it support multiple APs?
>>>
>> iw wlan0 interface add wlan0_1 type managed
>> ifconfig wlan0_1 hw ether <new_mac>
>>
>> Depends on HW you have, some ath10k support single/multi channel concurrency.
>> You can check this using
>> iw phyX info - and next check valid combinations (channels <= 1 mean
>> SCC, so best if you have <= 2)
>>
>> BR
>> Janusz
>>
>>> Thanks for any information.
>>>
>>> Charles
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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 mohammed at codeaurora.org  Thu Dec 22 07:48:01 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Thu, 22 Dec 2016 21:18:01 +0530
Subject: [PATCH] ath10k: merge extended peer info data with existing
 peers info
In-Reply-To: <2696316.Ugl5Pim1oL@debian64>
References: <20161216052418.GA8936@atheros-ThinkPad-T61>
 <20161217174634.4531-1-chunkeey@googlemail.com>
 <20161219164957.GA13022@atheros-ThinkPad-T61>
 <2696316.Ugl5Pim1oL@debian64>
Message-ID: <20161222154801.GA16241@atheros-ThinkPad-T61>

Hi Christian,

once again sorry for the delay

> 
> On Monday, December 19, 2016 10:19:57 PM CET Mohammed Shafi Shajakhan wrote:
> > On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote:
> > > The 10.4 firmware adds extended peer information to the
> > > firmware's statistics payload. This additional info is
> > > stored as a separate data field. During review of
> > > "ath10k: add accounting for the extended peer statistics" [0]
> > > 
> > > Mohammed Shafi Shajakhan commented that the extended peer statistics
> > > lists are of little use:"... there is not much use in appending
> > > the extended peer stats (which gets periodically updated) to the
> > > linked list '&ar->debug.fw_stats.peers_extd)' and should we get
> > > rid of the below (and the required cleanup as well)
> > > 
> > > list_splice_tail_init(&stats.peers_extd,
> > >                 &ar->debug.fw_stats.peers_extd);
> > > 
> > > since rx_duration is getting updated periodically to the per sta
> > > information."
> > > 
> > > This patch replaces the extended peers list with a lookup and
> > > puts the retrieved data (rx_duration) into the existing
> > > ath10k_fw_stats_peer entry that was created earlier.
> > 
> > [shafi] Its good to maintain the extended stats variable
> > and retain the two different functions to update rx_duration.
> > 
> > a) extended peer stats supported - mainly for 10.4
> > b) extender peer stats not supported - for 10.2
> Well, I have to ask why you want to retain the two different
> functions to update the same arsta->rx_duration? I think a
> little bit of code that helps to explain what's on your mind
> (or how you would do it) would help immensely in this case.
> Since I have the feeling that this is the problem here. 
> So please explain it in C(lang).

[shafi] I see you prefer to stuff the 'rx_duration' from
the extended stats to the existing global 'ath10k_peer_stats'
The idea of extended stats is, ideally its not going to stop
for 'rx_duration' . Extended stats is maintained as a seperate
list / entry for addition of new fields as well

> 
> > > [0] <https://lkml.kernel.org/r/992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey at googlemail.com>
> > > Cc: Mohammed Shafi Shajakhan <mohammed at codeaurora.org>
> > > Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>
> > > ---
> > >  drivers/net/wireless/ath/ath10k/core.h        |  2 --
> > >  drivers/net/wireless/ath/ath10k/debug.c       | 17 --------------
> > >  drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 ++-----------------------
> > >  drivers/net/wireless/ath/ath10k/wmi.c         | 34 ++++++++++++++++++++-------
> > >  4 files changed, 28 insertions(+), 57 deletions(-)
> > > 
> > > diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> > > index 09ff8b8a6441..3fffbbb18c25 100644
> > > --- a/drivers/net/wireless/ath/ath10k/core.h
> > > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > > @@ -268,11 +268,9 @@ struct ath10k_fw_stats_pdev {
> > >  };
> > >  
> > >  struct ath10k_fw_stats {
> > > -	bool extended;
> > >  	struct list_head pdevs;
> > >  	struct list_head vdevs;
> > >  	struct list_head peers;
> > > -	struct list_head peers_extd;
> > >  };
> > >  
> > >  #define ATH10K_TPC_TABLE_TYPE_FLAG	1
> > > diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> > > index 82a4c67f3672..89f7fde77cdf 100644
> > > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > > @@ -315,25 +315,13 @@ 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);
> > >  	ar->debug.fw_stats_done = false;
> > > -	ar->debug.fw_stats.extended = false;
> > 
> > [shafi] this looks fine, but not removing the 'extended' variable 
> > from ath10k_fw_stats structure, I see the design for 'rx_duration'
> > arguably some what convoluted !
> I removed extended because it is now a write-only variable.
> So I figured, there's no point in keeping it around? I don't have
> access to the firmware interface documentation, so I don't know
> if there's a reason why it would be good to have it later.
> So please tell me, what information do we gain from it?

[shafi] while parsing the stats from 'wmi' we clearly mark there whether
the extended stats is available (or) not and if its there parse it and
deal with it seperately

> 
> > *We get periodic events from firmware updating 'ath10k_debug_fw_stats_process'
> > *Fetch rx_duration from  'ath10k_wmi_pull_fw_stats(ar, skb, &stats)'
> > {certainly 'stats' object is for this particular update only, and freed
> > up later)
> > *Update immediately using 'ath10k_sta_update_rx_duration'
> > 
> > 'ath10k_wmi_pull_fw_stats' has a slightly different implementation
> > for 10.2 and 10.4 (the later supporting extended peer stats)
> 
> I see that 10.2.4's ath10k_wmi_10_2_4_op_pull_fw_stats()
> passes the rx_duration as part of the wmi_10_2_4_ext_peer_stats
> element which is basically a carbon-copy of wmi_10_2_4_peer_stats
> (but with one extra __le32 for the rx_duration at the end.)
> This rx_duration is then used to set the rx_duration field in the
> generated ath10k_fw_stats_peer struct.
> 
> 10.4's ath10k_wmi_10_4_op_pull_fw_stats() has a "fixed" wmi_10_4_peer_stats
> element and uses an separate "fixed" wmi_10_4_peer_extd_stats element for
> the communicating the rx_duration to the driver.
> 
> Thing is, both function have the same signature. They produce the same
> struct ath10k_fw_stats_peer for the given data in the sk_buff input. So
> why does 10.4 need to have it's peer_extd infrastructure, when it can use
> the existing rx_duration field in the *universal* ath10k_fw_stats_peer?

[shafi] agreed we need to fix that, it would have been easier if 10.2.4
and 10.4 had the same definitions.

> 
> What's with the extra layers / HAL here? Because it looks like it's merged
> back together in the same manner into the same arsta->rx_duration?
> [ath10k_sta_update_stats_rx_duration() vs. 
>  ath10k_sta_update_extd_stats_rx_duration() - they are almost carbon copies too]
> 
> > > diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> > > index c893314a191f..c7ec7b9e9b55 100644
> > > --- a/drivers/net/wireless/ath/ath10k/wmi.c
> > > +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> > > @@ -3044,23 +3044,41 @@ 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;
> > > +		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;
> > > +		/* Because the stat data may exceed htc-wmi buffer
> > > +		 * limit the firmware might split the stats data
> > > +		 * and delivers it in multiple update events.
> > > +		 * if we can't find the entry in the current event
> > > +		 * payload, we have to look in main list as well.
> > > +		 */

[shafi] thanks ! sorry i might have missed this bug, did you happen
to see this condition being hit ?

> > > +		list_for_each_entry(dst, &stats->peers, list) {
> > > +			if (ether_addr_equal(dst->peer_macaddr,
> > > +					     src->peer_macaddr.addr))
> > > +				goto found;
> > > +		}
> > > +

[shafi] Again, we can simply cache the macaddress and rx_duration
and deal with it later, rather than doing the whole lookup here ?
Will it be an overhead for large number of clients ?

> > > +#ifdef CONFIG_ATH10K_DEBUGFS
> > > +		list_for_each_entry(dst, &ar->debug.fw_stats.peers, list) {
> > > +			if (ether_addr_equal(dst->peer_macaddr,
> > > +					     src->peer_macaddr.addr))
> > > +				goto found;
> > > +		}
> > > +#endif

[shafi] again, this could be handled seperately.

> > > +
> > > +		ath10k_dbg(ar, ATH10K_DBG_WMI,
> > > +			   "Orphaned extended stats entry for station %pM.\n",
> > > +			   src->peer_macaddr.addr);
> > > +		continue;
> > >  
> > > -		ether_addr_copy(dst->peer_macaddr, src->peer_macaddr.addr);
> > > +found:
> > >  		dst->rx_duration = __le32_to_cpu(src->rx_duration);
> > > -		list_add_tail(&dst->list, &stats->peers_extd);
> > >  	}
> > >  
> > >  	return 0;
> > 
> > [shafi] Yes i am bit concerned about this change making 10.4 to update
> > over the existing peer_stats structure, the idea is to maintain uniformity
> > between the structures shared between ath10k and its corresponding to avoid
> > confusion/ bugs in the future. Kindly let me know your thoughts, feel free
> > to correct me if any of my analysis is incorrect. thank you !
> Isn't the point of the ath10k_wmi_10_*_op_pull_fw_stats() functions to make 
> a "universal" statistic (in your case a unified ath10k_fw_stats_peer structure)
> that other functions can use, without caring about if the FW was 10.4 
> or 10.2.4?
> 
> There's no indication that the rx_duration field in wmi_10_2_4_ext_peer_stats
> conveys any different information than the rx_duration in 
> wmi_10_4_peer_extd_stats. So, what's going on here? Can't you just make
> wmi_10_4_peer_extd_stats's rx_duration use the existing field in
> ath10k_fw_stats_peer? And if not: why exactly?
>
[shafi] I will soon test your change and keep you posted. We will also
get Kalle's take/view on this. 

regards,
shafi


From chunkeey at googlemail.com  Thu Dec 22 09:58:41 2016
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Thu, 22 Dec 2016 18:58:41 +0100
Subject: [PATCH] ath10k: merge extended peer info data with existing peers
 info
In-Reply-To: <20161222154801.GA16241@atheros-ThinkPad-T61>
References: <20161216052418.GA8936@atheros-ThinkPad-T61>
 <2696316.Ugl5Pim1oL@debian64> <20161222154801.GA16241@atheros-ThinkPad-T61>
Message-ID: <1563376.k5ulprKP3Z@debian64>

Hello Shafi,

On Thursday, December 22, 2016 9:18:01 PM CET Mohammed Shafi Shajakhan wrote:
> > On Monday, December 19, 2016 10:19:57 PM CET Mohammed Shafi Shajakhan wrote:
> > > On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote:
> > > > The 10.4 firmware adds extended peer information to the
> > > > firmware's statistics payload. This additional info is
> > > > stored as a separate data field. During review of
> > > > "ath10k: add accounting for the extended peer statistics" [0]
> > > > 
> > > > Mohammed Shafi Shajakhan commented that the extended peer statistics
> > > > lists are of little use:"... there is not much use in appending
> > > > the extended peer stats (which gets periodically updated) to the
> > > > linked list '&ar->debug.fw_stats.peers_extd)' and should we get
> > > > rid of the below (and the required cleanup as well)
> > > > 
> > > > list_splice_tail_init(&stats.peers_extd,
> > > >                 &ar->debug.fw_stats.peers_extd);
> > > > 
> > > > since rx_duration is getting updated periodically to the per sta
> > > > information."
> > > > 
> > > > This patch replaces the extended peers list with a lookup and
> > > > puts the retrieved data (rx_duration) into the existing
> > > > ath10k_fw_stats_peer entry that was created earlier.
> > > 
> > > [shafi] Its good to maintain the extended stats variable
> > > and retain the two different functions to update rx_duration.
> > > 
> > > a) extended peer stats supported - mainly for 10.4
> > > b) extender peer stats not supported - for 10.2
> > Well, I have to ask why you want to retain the two different
> > functions to update the same arsta->rx_duration? I think a
> > little bit of code that helps to explain what's on your mind
> > (or how you would do it) would help immensely in this case.
> > Since I have the feeling that this is the problem here. 
> > So please explain it in C(lang).
> 
> [shafi] I see you prefer to stuff the 'rx_duration' from
> the extended stats to the existing global 'ath10k_peer_stats'
> The idea of extended stats is, ideally its not going to stop
> for 'rx_duration' . Extended stats is maintained as a seperate
> list / entry for addition of new fields as well
I'm guessing you are trying to say here:

replace:

dst->rx_duration = __le32_to_cpu(src->rx_duration); 

with

dst->rx_duration += __le32_to_cpu(src->rx_duration);

in ath10k_wmi_10_4_op_pull_fw_stats()?

Is this correct? If so then can you tell me why ath10k_wmi_10_4_op_pull_fw_stats()
is using for (i = 0; i < num_peer_stats; i++) to iterate over the extended peer
stats instead of looking up the number of extended peer items. Because this does
imply that there are the "same" (and every peer stat has a matching extended 
peer stat)... (This will be important for the comment below - so ***).
Of course, if this isn't true then this is a bug and should be fixed because
otherwise the ath10k_wmi_10_4_op_pull_fw_stats functions might return -EPROTO
at some point which causes a "failed to pull fw stats: -71" and unprocessed/lost
stats.
> > 
> > > > [0] <https://lkml.kernel.org/r/992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey at googlemail.com>
> > > > Cc: Mohammed Shafi Shajakhan <mohammed at codeaurora.org>
> > > > Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>
> > > > ---
> > > >  drivers/net/wireless/ath/ath10k/core.h        |  2 --
> > > >  drivers/net/wireless/ath/ath10k/debug.c       | 17 --------------
> > > >  drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 ++-----------------------
> > > >  drivers/net/wireless/ath/ath10k/wmi.c         | 34 ++++++++++++++++++++-------
> > > >  4 files changed, 28 insertions(+), 57 deletions(-)
> > > > 
> > > > diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> > > > index 09ff8b8a6441..3fffbbb18c25 100644
> > > > --- a/drivers/net/wireless/ath/ath10k/core.h
> > > > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > > > @@ -268,11 +268,9 @@ struct ath10k_fw_stats_pdev {
> > > >  };
> > > >  
> > > >  struct ath10k_fw_stats {
> > > > -	bool extended;
> > > >  	struct list_head pdevs;
> > > >  	struct list_head vdevs;
> > > >  	struct list_head peers;
> > > > -	struct list_head peers_extd;
> > > >  };
> > > >  
> > > >  #define ATH10K_TPC_TABLE_TYPE_FLAG	1
> > > > diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> > > > index 82a4c67f3672..89f7fde77cdf 100644
> > > > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > > > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > > > @@ -315,25 +315,13 @@ 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);
> > > >  	ar->debug.fw_stats_done = false;
> > > > -	ar->debug.fw_stats.extended = false;
> > > 
> > > [shafi] this looks fine, but not removing the 'extended' variable 
> > > from ath10k_fw_stats structure, I see the design for 'rx_duration'
> > > arguably some what convoluted !
> > I removed extended because it is now a write-only variable.
> > So I figured, there's no point in keeping it around? I don't have
> > access to the firmware interface documentation, so I don't know
> > if there's a reason why it would be good to have it later.
> > So please tell me, what information do we gain from it?
> 
> [shafi] while parsing the stats from 'wmi' we clearly mark there whether
> the extended stats is available (or) not and if its there parse it and
> deal with it seperately
No, there's no difference between stats or extended stats (10.2.4 vs 10.4):
both ath10k_sta_update_extd_stats_rx_duration() [0]
and ath10k_sta_update_stats_rx_duration() [1] are adding the
ath10k_fw_stats_peer(_extd)->rx_duration to ath10k_sta->rx_duration.

With the merge of the peer stats and extended peer stats, this also
removed the only usage of stats->extended. And hence it becomes a
write-only variable. So there's no point in keeping it around ATM (as
all other extended peer stats entries aren't used).

> > > *We get periodic events from firmware updating 'ath10k_debug_fw_stats_process'
> > > *Fetch rx_duration from  'ath10k_wmi_pull_fw_stats(ar, skb, &stats)'
> > > {certainly 'stats' object is for this particular update only, and freed
> > > up later)
> > > *Update immediately using 'ath10k_sta_update_rx_duration'
> > > 
> > > 'ath10k_wmi_pull_fw_stats' has a slightly different implementation
> > > for 10.2 and 10.4 (the later supporting extended peer stats)
> > 
> > I see that 10.2.4's ath10k_wmi_10_2_4_op_pull_fw_stats()
> > passes the rx_duration as part of the wmi_10_2_4_ext_peer_stats
> > element which is basically a carbon-copy of wmi_10_2_4_peer_stats
> > (but with one extra __le32 for the rx_duration at the end.)
> > This rx_duration is then used to set the rx_duration field in the
> > generated ath10k_fw_stats_peer struct.
> > 
> > 10.4's ath10k_wmi_10_4_op_pull_fw_stats() has a "fixed" wmi_10_4_peer_stats
> > element and uses an separate "fixed" wmi_10_4_peer_extd_stats element for
> > the communicating the rx_duration to the driver.
> > 
> > Thing is, both function have the same signature. They produce the same
> > struct ath10k_fw_stats_peer for the given data in the sk_buff input. So
> > why does 10.4 need to have it's peer_extd infrastructure, when it can use
> > the existing rx_duration field in the *universal* ath10k_fw_stats_peer?
> 
> [shafi] agreed we need to fix that, it would have been easier if 10.2.4
> and 10.4 had the same definitions.
Ok, I don't know the internals of the firmware to know what's the difference
between 10.2.4 and 10.4's rx_duration (how both firmwares define them 
differently in this context) ? From what I can tell, it's just that
the entry has moved from the peer stats to extended peer stats.
Of course, this is based on the logic that both 10.2.4 and 10.4 rx_durations
end up being added to arsta->rx_duration in the same way. There's no scaling
or a comment that would indicate a difference.

> > 
> > What's with the extra layers / HAL here? Because it looks like it's merged
> > back together in the same manner into the same arsta->rx_duration?
> > [ath10k_sta_update_stats_rx_duration() vs. 
> >  ath10k_sta_update_extd_stats_rx_duration() - they are almost carbon copies too]
> > 
> > > > diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> > > > index c893314a191f..c7ec7b9e9b55 100644
> > > > --- a/drivers/net/wireless/ath/ath10k/wmi.c
> > > > +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> > > > @@ -3044,23 +3044,41 @@ 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;
> > > > +		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;
> > > > +		/* Because the stat data may exceed htc-wmi buffer
> > > > +		 * limit the firmware might split the stats data
> > > > +		 * and delivers it in multiple update events.
> > > > +		 * if we can't find the entry in the current event
> > > > +		 * payload, we have to look in main list as well.
> > > > +		 */
> 
> [shafi] thanks ! sorry i might have missed this bug, did you happen
> to see this condition being hit ?
This was copied from ath10k_debug_fw_stats_process() [2]. I've added Michal
Kazior to the discussion since his patch "ath10k: fix fw stats processing"
added this in debug.c. I think he knows the firmware internals well enough
to tell if this is a problem or not. As it stands now, it is and will be
in the future.
 
> > > > +		list_for_each_entry(dst, &stats->peers, list) {
> > > > +			if (ether_addr_equal(dst->peer_macaddr,
> > > > +					     src->peer_macaddr.addr))
> > > > +				goto found;
> > > > +		}
> > > > +
> 
> [shafi] Again, we can simply cache the macaddress and rx_duration
> and deal with it later, rather than doing the whole lookup here ?
> Will it be an overhead for large number of clients ?
Well, show me how you would do it more efficiently otherwise? I don't
see how you can cache the macaddress and rx_duration since you are
basically forced to process all the peer stats first and later all
the extended peer stats. They don't mix.

As for how expensive it is: From what I can tell, the 10.4 firmware
sends the stat events every few seconds. So they are not part of any
rx or tx hot-paths. The list_for_each within the for
(i = 0; i < num_peers;i++)  is actually in the O(1) class as far
as both loops go. This might sound funny at first, but the number of
extended peer list is limited by TARGET_10_4_MAX_PEER_EXT_STATS to 16.
And thanks to (***) the limit of num_peers is also 16. Furthermore
we can add a if (ath10k_peer_stats_enabled(ar)) guard to skip it
entirely if the stats are disabled.


> > > > +#ifdef CONFIG_ATH10K_DEBUGFS
> > > > +		list_for_each_entry(dst, &ar->debug.fw_stats.peers, list) {
> > > > +			if (ether_addr_equal(dst->peer_macaddr,
> > > > +					     src->peer_macaddr.addr))
> > > > +				goto found;
> > > > +		}
> > > > +#endif
> 
> [shafi] again, this could be handled seperately.
This is more expensive. As fw_stats.peers can contain more entries than 16.
However, this might be unnecessary if both peers and extended peers stats
entries in the wmi event are always for the same stations.

Note: There's an alternative way too. Instead of writing rx_duration into
ath10k_fw_stats, we could skip the middle man write it directly into
arsta->rx_duration. This would also mean that we can get rid of
ath10k_sta_update_extd_stats_rx_duration(), ath10k_sta_update_stats_rx_duration()
and ath10k_sta_update_rx_duration(). This has the benifit that we can
remove even more.

> > > > +
> > > > +		ath10k_dbg(ar, ATH10K_DBG_WMI,
> > > > +			   "Orphaned extended stats entry for station %pM.\n",
> > > > +			   src->peer_macaddr.addr);
> > > > +		continue;
> > > >  
> > > > -		ether_addr_copy(dst->peer_macaddr, src->peer_macaddr.addr);
> > > > +found:
> > > >  		dst->rx_duration = __le32_to_cpu(src->rx_duration);
> > > > -		list_add_tail(&dst->list, &stats->peers_extd);
> > > >  	}
> > > >  
> > > >  	return 0;
> > > 
> > > [shafi] Yes i am bit concerned about this change making 10.4 to update
> > > over the existing peer_stats structure, the idea is to maintain uniformity
> > > between the structures shared between ath10k and its corresponding to avoid
> > > confusion/ bugs in the future. Kindly let me know your thoughts, feel free
> > > to correct me if any of my analysis is incorrect. thank you !
> > Isn't the point of the ath10k_wmi_10_*_op_pull_fw_stats() functions to make 
> > a "universal" statistic (in your case a unified ath10k_fw_stats_peer structure)
> > that other functions can use, without caring about if the FW was 10.4 
> > or 10.2.4?
> > 
> > There's no indication that the rx_duration field in wmi_10_2_4_ext_peer_stats
> > conveys any different information than the rx_duration in 
> > wmi_10_4_peer_extd_stats. So, what's going on here? Can't you just make
> > wmi_10_4_peer_extd_stats's rx_duration use the existing field in
> > ath10k_fw_stats_peer? And if not: why exactly?
> >
> [shafi] I will soon test your change and keep you posted. We will also
> get Kalle's take/view on this. 
Ok. That said, I added him to the CC from the beginning and so far
he silently agreed.

Regards,
Christian

[0] <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath10k/debugfs_sta.c#L21>
[1] <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath10k/debugfs_sta.c#L40>
[2] <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath10k/debug.c#L360>




From ryanhsu at qca.qualcomm.com  Thu Dec 22 14:31:46 2016
From: ryanhsu at qca.qualcomm.com (ryanhsu at qca.qualcomm.com)
Date: Thu, 22 Dec 2016 14:31:46 -0800
Subject: [PATCH] ath10k: recal the txpower when removing interface
Message-ID: <1482445906-20421-1-git-send-email-ryanhsu@qca.qualcomm.com>

From: Ryan Hsu <ryanhsu at qca.qualcomm.com>

The txpower is being recalculated when adding interface to make sure
txpower won't overshoot the spec, and when removing the interface,
the txpower should again to be recalculated to restore the correct value
from the active interface list.

Following is one of the scenario
	vdev0 is created as STA and connected: txpower:23
	vdev1 is created as P2P_DEVICE for control interface: txpower:0
	vdev2 is created as p2p go/gc interface: txpower is 21

So the vdev2 at txpower:21 will be set to firmware when vdev2 is created.
When we tear down the vdev2, the txpower needs to be recalculated to
re-set it to vdev0 at txpower:23 as vdev0/vdev1 are the active interface.

	ath10k_pci mac vdev 0 peer create 8c:fd:f0:01:62:98
	ath10k_pci mac vdev_id 0 txpower 23
	... (adding interface)
	ath10k_pci mac vdev create 2 (add interface) type 1 subtype 3
	ath10k_pci mac vdev_id 2 txpower 21
	ath10k_pci mac txpower 21
	... (removing interface)
	ath10k_pci mac vdev 2 delete (remove interface)
	ath10k_pci vdev 1 txpower 0
	ath10k_pci vdev 0 txpower 23
	ath10k_pci mac txpower 23

Signed-off-by: Ryan Hsu <ryanhsu at qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index aa545a1..6475dc8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5194,6 +5194,10 @@ static void ath10k_remove_interface(struct ieee80211_hw *hw,
 			ath10k_warn(ar, "failed to recalc monitor: %d\n", ret);
 	}
 
+	ret = ath10k_mac_txpower_recalc(ar);
+	if (ret)
+		ath10k_warn(ar, "failed to recalc tx power: %d\n", ret);
+
 	spin_lock_bh(&ar->htt.tx_lock);
 	ath10k_mac_vif_tx_unlock_all(arvif);
 	spin_unlock_bh(&ar->htt.tx_lock);
-- 
1.9.1



From ryanhsu at qca.qualcomm.com  Thu Dec 22 15:02:37 2016
From: ryanhsu at qca.qualcomm.com (ryanhsu at qca.qualcomm.com)
Date: Thu, 22 Dec 2016 15:02:37 -0800
Subject: [PATCH] ath10k: ignore configuring the incorrect board_id
Message-ID: <1482447757-23577-1-git-send-email-ryanhsu@qca.qualcomm.com>

From: Ryan Hsu <ryanhsu at qca.qualcomm.com>

With command to get board_id from otp, in the case of following

  boot get otp board id result 0x00000000 board_id 0 chip_id 0
  boot using board name 'bus=pci,bmi-chip-id=0,bmi-board-id=0"
  ...
  failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=0 from
  ath10k/QCA6174/hw3.0/board-2.bin

The invalid board_id=0 will be used as index to search in the board-2.bin.

Ignore the case with board_id=0, as it means the otp is not carrying
the board id information.

Signed-off-by: Ryan Hsu <ryanhsu at qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 749e381..1bf67ad 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -694,8 +694,11 @@ static int ath10k_core_get_board_id_from_otp(struct ath10k *ar)
 		   "boot get otp board id result 0x%08x board_id %d chip_id %d\n",
 		   result, board_id, chip_id);
 
-	if ((result & ATH10K_BMI_BOARD_ID_STATUS_MASK) != 0)
+	if ((result & ATH10K_BMI_BOARD_ID_STATUS_MASK) != 0 ||
+	    (board_id == 0)) {
+		ath10k_warn(ar, "board id is not exist in otp, ignore it\n");
 		return -EOPNOTSUPP;
+	}
 
 	ar->id.bmi_ids_valid = true;
 	ar->id.bmi_board_id = board_id;
-- 
1.9.1



From jp.tosoni at acksys.fr  Mon Dec 26 03:15:02 2016
From: jp.tosoni at acksys.fr (Jean-Pierre Tosoni)
Date: Mon, 26 Dec 2016 12:15:02 +0100
Subject: ath10k firmware sends probes on DFS channels without radar
 detection
In-Reply-To: <20161215225827.GB24883@w1.fi>
References: <004a01d24fe2$94da8dc0$be8fa940$@acksys.fr>
 <20161214195805.GA15022@w1.fi> <00f501d256e7$0f8d5380$2ea7fa80$@acksys.fr>
 <5852C5AC.6090408@candelatech.com>
 <00fd01d256fc$2f780db0$8e682910$@acksys.fr> <20161215225827.GB24883@w1.fi>
Message-ID: <012001d25f69$4df62ef0$e9e28cd0$@acksys.fr>

> -----Message d'origine-----
> De?: Jouni Malinen [mailto:j at w1.fi]
> Envoy??: jeudi 15 d?cembre 2016 23:58
> ??: Jean-Pierre Tosoni
> Cc?: 'Ben Greear'; linux-wireless at vger.kernel.org;
> ath10k at lists.infradead.org
> Objet?: Re: ath10k firmware sends probes on DFS channels without radar
> detection
> 
> On Thu, Dec 15, 2016 at 06:53:47PM +0100, Jean-Pierre Tosoni wrote:
> > > > Thanks for the suggestion, I already tried something like this in
> > > > wmi.c, with the same result:
> > > >
> > > > - Before patching the firmware scans DFS channels actively (with
> > > probes).
> > > >
> > > > - After patching, the firmware scans DFS channels passively
> > > > *until* any beacon is received on the DFS channel. When *any*
> > > > beacon is seen, the firmware decides to scan actively on its own,
> > > > without any new IR/RADAR info from the driver.
> > > >
> > > > So, your patch is required but not sufficient.
> > > >
> > > > Somehow I was able to overcome this by reloading the regulation
> > > > domain in the radio card before each scan request:
> 
> Interesting.. I'm not completely sure what could have changed the behavior
> based on beacon hint. I thought it was cfg80211, but if the simple change
> for doing NO_IR | RADAR is not sufficient, it would seem to imply that
> something else can do this. Some more debugging to do, I guess.

After some debugging I think the card firmware does this, probably due to
the lack of precise definition of NO_IR, see below.

> 
> > The distinction between NO_IR and CHAN_RADAR is not very clear to me.
> > NO_IR appears only in the world regulatory domain so it's not relevant
> here.
> 
> NO_IR is a combination of not allowing AP, IBSS, or active scanning
> without having somehow been enabled by another device. RADAR has that same
> impact and in addition, requirement for doing radar detection and DFS by a
> master device.

Ah, thanks. But then, NO_IR does not define the way for the "other device"
to enable the local device? So, depending on the interpretation, it can
render the local device unusable. OTOH RADAR defines a way which depends on
the local regulations.

> 
> > I'd say
> >  "the CHAN_RADAR flag should always make the firmware never do IR when
> > probing"
> > ...maybe, except if the channel is the operating channel. (this should
> > exclude unassociated stations)
> 
> For most cases, I'd agree that active scanning should not be used on DFS
> channels. That said, unicast Probe Request frame to the current AP while
> associated could be a reasonable exception. In addition, WPS with PBC
> depends on Probe Request frames to allow PBC session overlap detection, so
> there might be sufficient justification to allow Probe Request frame to be
> sent out for a very short duration (couple of seconds) after seeing a
> Beacon frame on the channel for such special cases.

I agree that unicast probes to the current AP should go through. It goes
with my condition "operating channel".

For WPS, I do not know it well, but I guess probes are acceptable if
1) they are not sent repeatedly over a long period of time during
unassociated state,
2) the AP uses CAC.
And here, both seem to be true.

> 
> --
> Jouni Malinen                                            PGP id EFC895FA

Regards, Jean-Pierre



From mohammed at qti.qualcomm.com  Tue Dec 27 05:32:35 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Tue, 27 Dec 2016 19:02:35 +0530
Subject: [PATCH] ath10k: Remove passing unused argument for ath10k_mac_tx
Message-ID: <1482845555-6076-1-git-send-email-mohammed@qca.qualcomm.com>

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

'ath10k_mac_tx' does not seems to use the per station table
entry pointer 'sta' (struct ieee80211_sta), hence remove passing
this unused argument

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

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 7d2f0ae..d0d3059 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3493,7 +3493,6 @@ static int ath10k_mac_tx_submit(struct ath10k *ar,
  */
 static int ath10k_mac_tx(struct ath10k *ar,
 			 struct ieee80211_vif *vif,
-			 struct ieee80211_sta *sta,
 			 enum ath10k_hw_txrx_mode txmode,
 			 enum ath10k_mac_tx_path txpath,
 			 struct sk_buff *skb)
@@ -3635,7 +3634,7 @@ void ath10k_offchan_tx_work(struct work_struct *work)
 		txmode = ath10k_mac_tx_h_get_txmode(ar, vif, sta, skb);
 		txpath = ath10k_mac_tx_h_get_txpath(ar, skb, txmode);
 
-		ret = ath10k_mac_tx(ar, vif, sta, txmode, txpath, skb);
+		ret = ath10k_mac_tx(ar, vif, txmode, txpath, skb);
 		if (ret) {
 			ath10k_warn(ar, "failed to transmit offchannel frame: %d\n",
 				    ret);
@@ -3822,7 +3821,7 @@ int ath10k_mac_tx_push_txq(struct ieee80211_hw *hw,
 		spin_unlock_bh(&ar->htt.tx_lock);
 	}
 
-	ret = ath10k_mac_tx(ar, vif, sta, txmode, txpath, skb);
+	ret = ath10k_mac_tx(ar, vif, txmode, txpath, skb);
 	if (unlikely(ret)) {
 		ath10k_warn(ar, "failed to push frame: %d\n", ret);
 
@@ -4103,7 +4102,7 @@ static void ath10k_mac_op_tx(struct ieee80211_hw *hw,
 		spin_unlock_bh(&ar->htt.tx_lock);
 	}
 
-	ret = ath10k_mac_tx(ar, vif, sta, txmode, txpath, skb);
+	ret = ath10k_mac_tx(ar, vif, txmode, txpath, skb);
 	if (ret) {
 		ath10k_warn(ar, "failed to transmit frame: %d\n", ret);
 		if (is_htt) {
-- 
1.9.1



From mohammed at qti.qualcomm.com  Tue Dec 27 07:23:35 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Tue, 27 Dec 2016 20:53:35 +0530
Subject: [PATCH] ath10k: Enable advertising support for channel 169, 5Ghz
Message-ID: <1482852215-6438-1-git-send-email-mohammed@qca.qualcomm.com>

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

Enable advertising support for channel 169, 5Ghz so that
based on the regulatory domain(country code) this channel
shall be active for use. For example in countries like India
this channel shall be available for use with latest regulatory updates

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

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 756e876..a19cef2 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -46,7 +46,7 @@
 #define WMI_READY_TIMEOUT (5 * HZ)
 #define ATH10K_FLUSH_TIMEOUT_HZ (5 * HZ)
 #define ATH10K_CONNECTION_LOSS_HZ (3 * HZ)
-#define ATH10K_NUM_CHANS 39
+#define ATH10K_NUM_CHANS 40
 
 /* Antenna noise floor */
 #define ATH10K_DEFAULT_NOISE_FLOOR -95
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 481842b..7d2f0ae 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7559,6 +7559,7 @@ struct ath10k_mac_change_chanctx_arg {
 	CHAN5G(157, 5785, 0),
 	CHAN5G(161, 5805, 0),
 	CHAN5G(165, 5825, 0),
+	CHAN5G(169, 5845, 0),
 };
 
 struct ath10k *ath10k_mac_create(size_t priv_size)
-- 
1.9.1



From kvalo at qca.qualcomm.com  Thu Dec 29 05:18:15 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 29 Dec 2016 14:18:15 +0100
Subject: [1/5] ath10k: fix IRAM banks number for QCA9377
In-Reply-To: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
References: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
Message-ID: <ad2a4327484c42999daeb8e94ea3e525@euamsexm01a.eu.qualcomm.com>

Bartosz Markowski <bartosz.markowski at tieto.com> wrote:
> QCA9377 firmware shall alloc 4 IRAM banks
> 
> Signed-off-by: Bartosz Markowski <bartosz.markowski at tieto.com>

5 patches applied to ath-next branch of ath.git, thanks.

77cf13ad5731 ath10k: fix IRAM banks number for QCA9377
b08b5b53a1ed ath10k: override CE5 config for QCA9377
35bac90abf5e ath10k: decrease num of peers support
7cfe0455ee12 ath10k: set CTS protection VDEV param only if VDEV is up
861769017404 ath10k: add debug trace to rts/cts set function

-- 
https://patchwork.kernel.org/patch/9464915/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From kvalo at qca.qualcomm.com  Thu Dec 29 06:11:21 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 29 Dec 2016 15:11:21 +0100
Subject: [1/2] ath10k: add accounting for the extended peer statistics
In-Reply-To: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
References: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
Message-ID: <c3f99e7634384475b475b97ff46bec76@euamsexm01a.eu.qualcomm.com>

Christian Lamparter <chunkeey at googlemail.com> wrote:
> The 10.4 firmware adds extended peer information to the
> firmware's statistics payload. This additional info is
> stored as a separate data field and the elements are
> stored in their own "peers_extd" list.
> 
> These elements can pile up in the same way as the peer
> information elements. This is because the
> ath10k_wmi_10_4_op_pull_fw_stats() function tries to
> pull the same amount (num_peer_stats) for every statistic
> data unit.
> 
> Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
> Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>

My understanding is that I should skip this patch 1. Please let me know if
I misunderstood. But I'm still plannning to apply patch 2.

Patch set to Changes Requested.

-- 
https://patchwork.kernel.org/patch/9461631/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From mohammed at codeaurora.org  Thu Dec 29 06:35:00 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Thu, 29 Dec 2016 20:05:00 +0530
Subject: [PATCH] ath10k: merge extended peer info data with existing
 peers info
In-Reply-To: <1563376.k5ulprKP3Z@debian64>
References: <20161216052418.GA8936@atheros-ThinkPad-T61>
 <2696316.Ugl5Pim1oL@debian64>
 <20161222154801.GA16241@atheros-ThinkPad-T61>
 <1563376.k5ulprKP3Z@debian64>
Message-ID: <20161229143459.GA3566@atheros-ThinkPad-T61>

Hi Christian,


On Thu, Dec 22, 2016 at 06:58:41PM +0100, Christian Lamparter wrote:
> Hello Shafi,
> 
> On Thursday, December 22, 2016 9:18:01 PM CET Mohammed Shafi Shajakhan wrote:
> > > On Monday, December 19, 2016 10:19:57 PM CET Mohammed Shafi Shajakhan wrote:
> > > > On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote:
> > > > > The 10.4 firmware adds extended peer information to the
> > > > > firmware's statistics payload. This additional info is
> > > > > stored as a separate data field. During review of
> > > > > "ath10k: add accounting for the extended peer statistics" [0]
> > > > > 
> > > > > Mohammed Shafi Shajakhan commented that the extended peer statistics
> > > > > lists are of little use:"... there is not much use in appending
> > > > > the extended peer stats (which gets periodically updated) to the
> > > > > linked list '&ar->debug.fw_stats.peers_extd)' and should we get
> > > > > rid of the below (and the required cleanup as well)
> > > > > 
> > > > > list_splice_tail_init(&stats.peers_extd,
> > > > >                 &ar->debug.fw_stats.peers_extd);
> > > > > 
> > > > > since rx_duration is getting updated periodically to the per sta
> > > > > information."
> > > > > 
> > > > > This patch replaces the extended peers list with a lookup and
> > > > > puts the retrieved data (rx_duration) into the existing
> > > > > ath10k_fw_stats_peer entry that was created earlier.
> > > > 
> > > > [shafi] Its good to maintain the extended stats variable
> > > > and retain the two different functions to update rx_duration.
> > > > 
> > > > a) extended peer stats supported - mainly for 10.4
> > > > b) extender peer stats not supported - for 10.2
> > > Well, I have to ask why you want to retain the two different
> > > functions to update the same arsta->rx_duration? I think a
> > > little bit of code that helps to explain what's on your mind
> > > (or how you would do it) would help immensely in this case.
> > > Since I have the feeling that this is the problem here. 
> > > So please explain it in C(lang).
> > 
> > [shafi] I see you prefer to stuff the 'rx_duration' from
> > the extended stats to the existing global 'ath10k_peer_stats'
> > The idea of extended stats is, ideally its not going to stop
> > for 'rx_duration' . Extended stats is maintained as a seperate
> > list / entry for addition of new fields as well
> I'm guessing you are trying to say here:
> 
> replace:
> 
> dst->rx_duration = __le32_to_cpu(src->rx_duration); 
> 
> with
> 
> dst->rx_duration += __le32_to_cpu(src->rx_duration);
> 
> in ath10k_wmi_10_4_op_pull_fw_stats()?

[shafi] oh no sorry, I am trying to say more members related
to stats shall be added in extended stats structure . The extended
stats structure is specifically introduced for adding more stats related
variables.

> 
> Is this correct? If so then can you tell me why ath10k_wmi_10_4_op_pull_fw_stats()
> is using for (i = 0; i < num_peer_stats; i++) to iterate over the extended peer
> stats instead of looking up the number of extended peer items. Because this does
> imply that there are the "same" (and every peer stat has a matching extended 
> peer stat)... (This will be important for the comment below - so ***).
> Of course, if this isn't true then this is a bug and should be fixed because
> otherwise the ath10k_wmi_10_4_op_pull_fw_stats functions might return -EPROTO
> at some point which causes a "failed to pull fw stats: -71" and unprocessed/lost
> stats.

[shafi] sorry i am not sure I got you, have you come across this error, please
let me know ?

> > > 
> > > > > [0] <https://lkml.kernel.org/r/992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey at googlemail.com>
> > > > > Cc: Mohammed Shafi Shajakhan <mohammed at codeaurora.org>
> > > > > Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>
> > > > > ---
> > > > >  drivers/net/wireless/ath/ath10k/core.h        |  2 --
> > > > >  drivers/net/wireless/ath/ath10k/debug.c       | 17 --------------
> > > > >  drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 ++-----------------------
> > > > >  drivers/net/wireless/ath/ath10k/wmi.c         | 34 ++++++++++++++++++++-------
> > > > >  4 files changed, 28 insertions(+), 57 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> > > > > index 09ff8b8a6441..3fffbbb18c25 100644
> > > > > --- a/drivers/net/wireless/ath/ath10k/core.h
> > > > > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > > > > @@ -268,11 +268,9 @@ struct ath10k_fw_stats_pdev {
> > > > >  };
> > > > >  
> > > > >  struct ath10k_fw_stats {
> > > > > -	bool extended;
> > > > >  	struct list_head pdevs;
> > > > >  	struct list_head vdevs;
> > > > >  	struct list_head peers;
> > > > > -	struct list_head peers_extd;
> > > > >  };
> > > > >  
> > > > >  #define ATH10K_TPC_TABLE_TYPE_FLAG	1
> > > > > diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> > > > > index 82a4c67f3672..89f7fde77cdf 100644
> > > > > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > > > > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > > > > @@ -315,25 +315,13 @@ 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);
> > > > >  	ar->debug.fw_stats_done = false;
> > > > > -	ar->debug.fw_stats.extended = false;
> > > > 
> > > > [shafi] this looks fine, but not removing the 'extended' variable 
> > > > from ath10k_fw_stats structure, I see the design for 'rx_duration'
> > > > arguably some what convoluted !
> > > I removed extended because it is now a write-only variable.
> > > So I figured, there's no point in keeping it around? I don't have
> > > access to the firmware interface documentation, so I don't know
> > > if there's a reason why it would be good to have it later.
> > > So please tell me, what information do we gain from it?

[shafi] sorry this is purely ath10k specific nothing to map with the firmware

> > 
> > [shafi] while parsing the stats from 'wmi' we clearly mark there whether
> > the extended stats is available (or) not and if its there parse it and
> > deal with it seperately
> No, there's no difference between stats or extended stats (10.2.4 vs 10.4):
> both ath10k_sta_update_extd_stats_rx_duration() [0]
> and ath10k_sta_update_stats_rx_duration() [1] are adding the
> ath10k_fw_stats_peer(_extd)->rx_duration to ath10k_sta->rx_duration.
> 
> With the merge of the peer stats and extended peer stats, this also
> removed the only usage of stats->extended. And hence it becomes a
> write-only variable. So there's no point in keeping it around ATM (as
> all other extended peer stats entries aren't used).

[shafi] ok, I see the extended stats structure is introduced for 10.4 and i was
thinking its good to have two seperate API's for updating the rx_duration ..

> 
> > > > *We get periodic events from firmware updating 'ath10k_debug_fw_stats_process'
> > > > *Fetch rx_duration from  'ath10k_wmi_pull_fw_stats(ar, skb, &stats)'
> > > > {certainly 'stats' object is for this particular update only, and freed
> > > > up later)
> > > > *Update immediately using 'ath10k_sta_update_rx_duration'
> > > > 
> > > > 'ath10k_wmi_pull_fw_stats' has a slightly different implementation
> > > > for 10.2 and 10.4 (the later supporting extended peer stats)
> > > 
> > > I see that 10.2.4's ath10k_wmi_10_2_4_op_pull_fw_stats()
> > > passes the rx_duration as part of the wmi_10_2_4_ext_peer_stats
> > > element which is basically a carbon-copy of wmi_10_2_4_peer_stats
> > > (but with one extra __le32 for the rx_duration at the end.)
> > > This rx_duration is then used to set the rx_duration field in the
> > > generated ath10k_fw_stats_peer struct.

[shafi] ok

> > > 
> > > 10.4's ath10k_wmi_10_4_op_pull_fw_stats() has a "fixed" wmi_10_4_peer_stats
> > > element and uses an separate "fixed" wmi_10_4_peer_extd_stats element for
> > > the communicating the rx_duration to the driver.

[shafi] ok

> > > 
> > > Thing is, both function have the same signature. They produce the same
> > > struct ath10k_fw_stats_peer for the given data in the sk_buff input. So
> > > why does 10.4 need to have it's peer_extd infrastructure, when it can use
> > > the existing rx_duration field in the *universal* ath10k_fw_stats_peer?
> > 
> > [shafi] agreed we need to fix that, it would have been easier if 10.2.4
> > and 10.4 had the same definitions.
> Ok, I don't know the internals of the firmware to know what's the difference
> between 10.2.4 and 10.4's rx_duration (how both firmwares define them 
> differently in this context) ? From what I can tell, it's just that
> the entry has moved from the peer stats to extended peer stats.
> Of course, this is based on the logic that both 10.2.4 and 10.4 rx_durations
> end up being added to arsta->rx_duration in the same way. There's no scaling
> or a comment that would indicate a difference.

[shafi] ok

> 
> > > 
> > > What's with the extra layers / HAL here? Because it looks like it's merged
> > > back together in the same manner into the same arsta->rx_duration?
> > > [ath10k_sta_update_stats_rx_duration() vs. 
> > >  ath10k_sta_update_extd_stats_rx_duration() - they are almost carbon copies too]

[shafi] my concern was for updating 'rx_duration' we just iterate over the list
and update the same.

> > > 
> > > > > diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> > > > > index c893314a191f..c7ec7b9e9b55 100644
> > > > > --- a/drivers/net/wireless/ath/ath10k/wmi.c
> > > > > +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> > > > > @@ -3044,23 +3044,41 @@ 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;
> > > > > +		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;
> > > > > +		/* Because the stat data may exceed htc-wmi buffer
> > > > > +		 * limit the firmware might split the stats data
> > > > > +		 * and delivers it in multiple update events.
> > > > > +		 * if we can't find the entry in the current event
> > > > > +		 * payload, we have to look in main list as well.
> > > > > +		 */
> > 
> > [shafi] thanks ! sorry i might have missed this bug, did you happen
> > to see this condition being hit ?
> This was copied from ath10k_debug_fw_stats_process() [2]. I've added Michal
> Kazior to the discussion since his patch "ath10k: fix fw stats processing"
> added this in debug.c. I think he knows the firmware internals well enough
> to tell if this is a problem or not. As it stands now, it is and will be
> in the future.

[shafi] sure.

>  
> > > > > +		list_for_each_entry(dst, &stats->peers, list) {
> > > > > +			if (ether_addr_equal(dst->peer_macaddr,
> > > > > +					     src->peer_macaddr.addr))
> > > > > +				goto found;
> > > > > +		}
> > > > > +
> > 
> > [shafi] Again, we can simply cache the macaddress and rx_duration
> > and deal with it later, rather than doing the whole lookup here ?
> > Will it be an overhead for large number of clients ?
> Well, show me how you would do it more efficiently otherwise? I don't
> see how you can cache the macaddress and rx_duration since you are
> basically forced to process all the peer stats first and later all
> the extended peer stats. They don't mix.

[shafi] hmmm, ok.

> 
> As for how expensive it is: From what I can tell, the 10.4 firmware
> sends the stat events every few seconds. So they are not part of any
> rx or tx hot-paths. The list_for_each within the for
> (i = 0; i < num_peers;i++)  is actually in the O(1) class as far
> as both loops go. This might sound funny at first, but the number of
> extended peer list is limited by TARGET_10_4_MAX_PEER_EXT_STATS to 16.
> And thanks to (***) the limit of num_peers is also 16. Furthermore
> we can add a if (ath10k_peer_stats_enabled(ar)) guard to skip it
> entirely if the stats are disabled.

[shafi] ok.
> 
> 
> > > > > +#ifdef CONFIG_ATH10K_DEBUGFS
> > > > > +		list_for_each_entry(dst, &ar->debug.fw_stats.peers, list) {
> > > > > +			if (ether_addr_equal(dst->peer_macaddr,
> > > > > +					     src->peer_macaddr.addr))
> > > > > +				goto found;
> > > > > +		}
> > > > > +#endif
> > 
> > [shafi] again, this could be handled seperately.
> This is more expensive. As fw_stats.peers can contain more entries than 16.
> However, this might be unnecessary if both peers and extended peers stats
> entries in the wmi event are always for the same stations.

[shafi] ok

> 
> Note: There's an alternative way too. Instead of writing rx_duration into
> ath10k_fw_stats, we could skip the middle man write it directly into
> arsta->rx_duration. This would also mean that we can get rid of
> ath10k_sta_update_extd_stats_rx_duration(), ath10k_sta_update_stats_rx_duration()
> and ath10k_sta_update_rx_duration(). This has the benifit that we can
> remove even more.
> 
> > > > > +
> > > > > +		ath10k_dbg(ar, ATH10K_DBG_WMI,
> > > > > +			   "Orphaned extended stats entry for station %pM.\n",
> > > > > +			   src->peer_macaddr.addr);
> > > > > +		continue;
> > > > >  
> > > > > -		ether_addr_copy(dst->peer_macaddr, src->peer_macaddr.addr);
> > > > > +found:
> > > > >  		dst->rx_duration = __le32_to_cpu(src->rx_duration);
> > > > > -		list_add_tail(&dst->list, &stats->peers_extd);
> > > > >  	}
> > > > >  
> > > > >  	return 0;
> > > > 
> > > > [shafi] Yes i am bit concerned about this change making 10.4 to update
> > > > over the existing peer_stats structure, the idea is to maintain uniformity
> > > > between the structures shared between ath10k and its corresponding to avoid
> > > > confusion/ bugs in the future. Kindly let me know your thoughts, feel free
> > > > to correct me if any of my analysis is incorrect. thank you !
> > > Isn't the point of the ath10k_wmi_10_*_op_pull_fw_stats() functions to make 
> > > a "universal" statistic (in your case a unified ath10k_fw_stats_peer structure)
> > > that other functions can use, without caring about if the FW was 10.4 
> > > or 10.2.4?
> > > 
> > > There's no indication that the rx_duration field in wmi_10_2_4_ext_peer_stats
> > > conveys any different information than the rx_duration in 
> > > wmi_10_4_peer_extd_stats. So, what's going on here? Can't you just make
> > > wmi_10_4_peer_extd_stats's rx_duration use the existing field in
> > > ath10k_fw_stats_peer? And if not: why exactly?
> > >
> > [shafi] I will soon test your change and keep you posted. We will also
> > get Kalle's take/view on this. 
> Ok. That said, I added him to the CC from the beginning and so far
> he silently agreed.

[shafi] sure, I guess i quickly tested this change and I found things
are fine, it would be good if you can share your test results as well please
Yes we can discuss with Kalle and Michal ! If you guys think this is a more
optimized version of updating the peer stats, I am fine with that as well.
There is no doubt you guys know about open source better than me :-)


> 
> Regards,
> Christian
> 
> [0] <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath10k/debugfs_sta.c#L21>
> [1] <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath10k/debugfs_sta.c#L40>
> [2] <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath10k/debug.c#L360>
> 
> 


From kvalo at qca.qualcomm.com  Fri Dec 30 01:11:38 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 30 Dec 2016 10:11:38 +0100
Subject: [2/2] ath10k: fix potential memory leak in
 ath10k_wmi_tlv_op_pull_fw_stats()
In-Reply-To: <e0909741dfae742197d5f5d60709d225cc179b42.1480974623.git.chunkeey@googlemail.com>
References: <e0909741dfae742197d5f5d60709d225cc179b42.1480974623.git.chunkeey@googlemail.com>
Message-ID: <afc9362500004eab995c4f1d5d16fcd9@euamsexm01a.eu.qualcomm.com>

Christian Lamparter <chunkeey at googlemail.com> wrote:
> ath10k_wmi_tlv_op_pull_fw_stats() uses tb = ath10k_wmi_tlv_parse_alloc(...)
> function, which allocates memory. If any of the three error-paths are
> taken, this tb needs to be freed.
> 
> Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>

Patch applied to ath-next branch of ath.git, thanks.

097e46d2ae90 ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats()

-- 
https://patchwork.kernel.org/patch/9461627/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From kvalo at qca.qualcomm.com  Fri Dec 30 01:13:11 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 30 Dec 2016 10:13:11 +0100
Subject: [V2] ath10k: fix incorrect txpower set by P2P_DEVICE interface
In-Reply-To: <1481669719-3423-1-git-send-email-ryanhsu@qca.qualcomm.com>
References: <1481669719-3423-1-git-send-email-ryanhsu@qca.qualcomm.com>
Message-ID: <e5044151a04d4f82a4c07c9e06369ea8@euamsexm01a.eu.qualcomm.com>

Ryan Hsu <ryanhsu at qca.qualcomm.com> wrote:
> From: Ryan Hsu <ryanhsu at qca.qualcomm.com>
> 
> Ath10k reports the phy capability that supports P2P_DEVICE interface.
> 
> When we use the P2P supported wpa_supplicant to start connection, it'll
> create two interfaces, one is wlan0 (vdev_id=0) and one is P2P_DEVICE
> p2p-dev-wlan0 which is for p2p control channel (vdev_id=1).
> 
> 	ath10k_pci mac vdev create 0 (add interface) type 2 subtype 0
> 	ath10k_add_interface: vdev_id: 0, txpower: 0, bss_power: 0
> 	...
> 	ath10k_pci mac vdev create 1 (add interface) type 2 subtype 1
> 	ath10k_add_interface: vdev_id: 1, txpower: 0, bss_power: 0
> 
> And the txpower in per vif bss_conf will only be set to valid tx power when
> the interface is assigned with channel_ctx.
> 
> But this P2P_DEVICE interface will never be used for any connection, so
> that the uninitialized bss_conf.txpower=0 is assinged to the
> arvif->txpower when interface created.
> 
> Since the txpower configuration is firmware per physical interface.
> So the smallest txpower of all vifs will be the one limit the tx power
> of the physical device, that causing the low txpower issue on other
> active interfaces.
> 
> 	wlan0: Limiting TX power to 21 (24 - 3) dBm
> 	ath10k_pci mac vdev_id 0 txpower 21
> 	ath10k_mac_txpower_recalc: vdev_id: 1, txpower: 0
> 	ath10k_mac_txpower_recalc: vdev_id: 0, txpower: 21
> 	ath10k_pci mac txpower 0
> 
> This issue only happens when we use the wpa_supplicant that supports
> P2P or if we use the iw tool to create the control P2P_DEVICE interface.
> 
> Signed-off-by: Ryan Hsu <ryanhsu at qca.qualcomm.com>

Patch applied to ath-next branch of ath.git, thanks.

88407beb1b14 ath10k: fix incorrect txpower set by P2P_DEVICE interface

-- 
https://patchwork.kernel.org/patch/9473309/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From kvalo at qca.qualcomm.com  Fri Dec 30 01:14:34 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 30 Dec 2016 10:14:34 +0100
Subject: ath10k: support dev_coredump for crash dump
In-Reply-To: <20161221121921.25119.93932.stgit@potku.adurom.net>
References: <20161221121921.25119.93932.stgit@potku.adurom.net>
Message-ID: <ea5cf07e249847d5a4f5078c8f31889e@euamsexm01a.eu.qualcomm.com>

Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> From: Arun Khandavalli <akhandav at qti.qualcomm.com>
> 
> Whenever firmware crashes, and both CONFIG_ATH10K_DEBUGFS and
> CONFIG_ALLOW_DEV_COREDUMP are enabled, dump information about the crash via a
> devcoredump device. Dump can be read from userspace for further analysis from:
> 
> /sys/class/devcoredump/devcd*/data
> 
> As until now we have provided the firmware crash dump file via fw_crash_dump
> debugfs keep it still available but deprecate and a warning print that the user
> should switch to using dev_coredump.
> 
> Future improvement would be not to depend on CONFIG_ATH10K_DEBUGFS, as there
> might be systems which want to get the firmware crash dump but not enable
> debugfs. How to handle memory consumption is also something which needs to be
> taken into account.
> 
> Signed-off-by: Arun Khandavalli <akhandav at qti.qualcomm.com>
> [kvalo at qca.qualcomm.com: rebase, fixes, improve commit log]
> Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>

Patch applied to ath-next branch of ath.git, thanks.

727000e6af34 ath10k: support dev_coredump for crash dump

-- 
https://patchwork.kernel.org/patch/9482989/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From kvalo at qca.qualcomm.com  Fri Dec 30 01:15:13 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 30 Dec 2016 10:15:13 +0100
Subject: ath10k: recal the txpower when removing interface
In-Reply-To: <1482445906-20421-1-git-send-email-ryanhsu@qca.qualcomm.com>
References: <1482445906-20421-1-git-send-email-ryanhsu@qca.qualcomm.com>
Message-ID: <9db0c0c5b7294f3fa73d25bf70eebad6@euamsexm01a.eu.qualcomm.com>

Ryan Hsu <ryanhsu at qca.qualcomm.com> wrote:
> From: Ryan Hsu <ryanhsu at qca.qualcomm.com>
> 
> The txpower is being recalculated when adding interface to make sure
> txpower won't overshoot the spec, and when removing the interface,
> the txpower should again to be recalculated to restore the correct value
> from the active interface list.
> 
> Following is one of the scenario
> 	vdev0 is created as STA and connected: txpower:23
> 	vdev1 is created as P2P_DEVICE for control interface: txpower:0
> 	vdev2 is created as p2p go/gc interface: txpower is 21
> 
> So the vdev2 at txpower:21 will be set to firmware when vdev2 is created.
> When we tear down the vdev2, the txpower needs to be recalculated to
> re-set it to vdev0 at txpower:23 as vdev0/vdev1 are the active interface.
> 
> 	ath10k_pci mac vdev 0 peer create 8c:fd:f0:01:62:98
> 	ath10k_pci mac vdev_id 0 txpower 23
> 	... (adding interface)
> 	ath10k_pci mac vdev create 2 (add interface) type 1 subtype 3
> 	ath10k_pci mac vdev_id 2 txpower 21
> 	ath10k_pci mac txpower 21
> 	... (removing interface)
> 	ath10k_pci mac vdev 2 delete (remove interface)
> 	ath10k_pci vdev 1 txpower 0
> 	ath10k_pci vdev 0 txpower 23
> 	ath10k_pci mac txpower 23
> 
> Signed-off-by: Ryan Hsu <ryanhsu at qca.qualcomm.com>

Patch applied to ath-next branch of ath.git, thanks.

d679fa1b3c89 ath10k: recal the txpower when removing interface

-- 
https://patchwork.kernel.org/patch/9486925/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From kvalo at qca.qualcomm.com  Fri Dec 30 01:15:57 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 30 Dec 2016 10:15:57 +0100
Subject: ath10k: ignore configuring the incorrect board_id
In-Reply-To: <1482447757-23577-1-git-send-email-ryanhsu@qca.qualcomm.com>
References: <1482447757-23577-1-git-send-email-ryanhsu@qca.qualcomm.com>
Message-ID: <d97a54233b874e629fd27cd98025030e@euamsexm01a.eu.qualcomm.com>

Ryan Hsu <ryanhsu at qca.qualcomm.com> wrote:
> From: Ryan Hsu <ryanhsu at qca.qualcomm.com>
> 
> With command to get board_id from otp, in the case of following
> 
>   boot get otp board id result 0x00000000 board_id 0 chip_id 0
>   boot using board name 'bus=pci,bmi-chip-id=0,bmi-board-id=0"
>   ...
>   failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=0 from
>   ath10k/QCA6174/hw3.0/board-2.bin
> 
> The invalid board_id=0 will be used as index to search in the board-2.bin.
> 
> Ignore the case with board_id=0, as it means the otp is not carrying
> the board id information.
> 
> Signed-off-by: Ryan Hsu <ryanhsu at qca.qualcomm.com>

Patch applied to ath-next branch of ath.git, thanks.

d2e202c06ca4 ath10k: ignore configuring the incorrect board_id

-- 
https://patchwork.kernel.org/patch/9486941/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From kvalo at qca.qualcomm.com  Fri Dec 30 01:16:56 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 30 Dec 2016 10:16:56 +0100
Subject: ath10k: Remove passing unused argument for ath10k_mac_tx
In-Reply-To: <1482845555-6076-1-git-send-email-mohammed@qca.qualcomm.com>
References: <1482845555-6076-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <b2b7af5ce38243759cfe7a171962c9da@euamsexm01a.eu.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> 'ath10k_mac_tx' does not seems to use the per station table
> entry pointer 'sta' (struct ieee80211_sta), hence remove passing
> this unused argument
> 
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Patch applied to ath-next branch of ath.git, thanks.

a7773b5db155 ath10k: Remove passing unused argument for ath10k_mac_tx

-- 
https://patchwork.kernel.org/patch/9489231/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From kvalo at qca.qualcomm.com  Fri Dec 30 01:19:24 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 30 Dec 2016 10:19:24 +0100
Subject: ath10k: Enable advertising support for channel 169, 5Ghz
In-Reply-To: <1482852215-6438-1-git-send-email-mohammed@qca.qualcomm.com>
References: <1482852215-6438-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <62f5c79aac6a4a72880cae899ae742e9@euamsexm01a.eu.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> Enable advertising support for channel 169, 5Ghz so that
> based on the regulatory domain(country code) this channel
> shall be active for use. For example in countries like India
> this channel shall be available for use with latest regulatory updates
> 
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Patch applied to ath-next branch of ath.git, thanks.

34c30b0a5e97 ath10k: enable advertising support for channel 169, 5Ghz

-- 
https://patchwork.kernel.org/patch/9489307/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From chunkeey at googlemail.com  Fri Dec 30 06:35:10 2016
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Fri, 30 Dec 2016 15:35:10 +0100
Subject: [1/2] ath10k: add accounting for the extended peer statistics
In-Reply-To: <c3f99e7634384475b475b97ff46bec76@euamsexm01a.eu.qualcomm.com>
References: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
 <c3f99e7634384475b475b97ff46bec76@euamsexm01a.eu.qualcomm.com>
Message-ID: <CAAd0S9DcCM9XQOihZx1sVf_1=S3VvDye4k1gEMgWEmNWDaBk5Q@mail.gmail.com>

On Thu, Dec 29, 2016 at 3:11 PM, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Christian Lamparter <chunkeey at googlemail.com> wrote:
>> The 10.4 firmware adds extended peer information to the
>> firmware's statistics payload. This additional info is
>> stored as a separate data field and the elements are
>> stored in their own "peers_extd" list.
>>
>> These elements can pile up in the same way as the peer
>> information elements. This is because the
>> ath10k_wmi_10_4_op_pull_fw_stats() function tries to
>> pull the same amount (num_peer_stats) for every statistic
>> data unit.
>>
>> Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
>> Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>
>
> My understanding is that I should skip this patch 1. Please let me know if
> I misunderstood. But I'm still plannning to apply patch 2.

I added Mohammed (I hope, he can reply to the open question when he
returns), Since I'm not sure what he wants or not.

As far as I'm aware, the "extended" boolean serves no purpose
because it was only used in once place in debugfs_sta which was
removed in the patch. ( "ath10k_sta_update_stats_rx_duration"
and "ath10k_sta_update_extd_stats_rx_duration" have been unified).


> Patch set to Changes Requested.
Isn't there a: "Waiting for Maintainer" state as well?
Otherwise, if nobody has any complains or question:
can you please queue it for the next merge window?

Regards,
Christian
> --
> https://patchwork.kernel.org/patch/9461631/
>
> Documentation about submitting wireless patches and checking status
> from patchwork:
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>


From kvalo at qca.qualcomm.com  Fri Dec 30 06:47:09 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Fri, 30 Dec 2016 14:47:09 +0000
Subject: [1/2] ath10k: add accounting for the extended peer statistics
In-Reply-To: <CAAd0S9DcCM9XQOihZx1sVf_1=S3VvDye4k1gEMgWEmNWDaBk5Q@mail.gmail.com>
 (Christian Lamparter's message of "Fri, 30 Dec 2016 15:35:10 +0100")
References: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
 <c3f99e7634384475b475b97ff46bec76@euamsexm01a.eu.qualcomm.com>
 <CAAd0S9DcCM9XQOihZx1sVf_1=S3VvDye4k1gEMgWEmNWDaBk5Q@mail.gmail.com>
Message-ID: <87inq1jwyc.fsf@kamboji.qca.qualcomm.com>

Christian Lamparter <chunkeey at googlemail.com> writes:

> On Thu, Dec 29, 2016 at 3:11 PM, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
>> Christian Lamparter <chunkeey at googlemail.com> wrote:
>>> The 10.4 firmware adds extended peer information to the
>>> firmware's statistics payload. This additional info is
>>> stored as a separate data field and the elements are
>>> stored in their own "peers_extd" list.
>>>
>>> These elements can pile up in the same way as the peer
>>> information elements. This is because the
>>> ath10k_wmi_10_4_op_pull_fw_stats() function tries to
>>> pull the same amount (num_peer_stats) for every statistic
>>> data unit.
>>>
>>> Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
>>> Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>
>>
>> My understanding is that I should skip this patch 1. Please let me know if
>> I misunderstood. But I'm still plannning to apply patch 2.
>
> I added Mohammed (I hope, he can reply to the open question when he
> returns), Since I'm not sure what he wants or not.
>
> As far as I'm aware, the "extended" boolean serves no purpose
> because it was only used in once place in debugfs_sta which was
> removed in the patch. ( "ath10k_sta_update_stats_rx_duration"
> and "ath10k_sta_update_extd_stats_rx_duration" have been unified).

I had problems following the discussion so the conclusion was not clear
for me.

>> Patch set to Changes Requested.
>
> Isn't there a: "Waiting for Maintainer" state as well?
> Otherwise, if nobody has any complains or question:
> can you please queue it for the next merge window?

There is a state called "Deferred" which I use whenever I need to
revisit a patch later time. I moved this patch to that state now:

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

-- 
Kalle Valo

From yevgeniy.melnichuk at googlemail.com  Fri Dec 30 07:56:53 2016
From: yevgeniy.melnichuk at googlemail.com (Yevgeniy Melnichuk)
Date: Fri, 30 Dec 2016 16:56:53 +0100
Subject: QCA9377 Bluetooth Audio not working with HSP profile
Message-ID: <CAJKEbddsdO=EkyhZSEwXGgnUpOhG3cAjBTbQsDQLHtLyzPH-VA@mail.gmail.com>

Hi,

when i use my bluetooth headset in A2DP everything works fine, but once i
switch over to HSP it does not work anymore (neither audio nor recording).
Somebody on the pulseaudio bugzilla pointed out, that it might be a problem
with firmware or device configuration. Here is the relevant entry in
buzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97064

i do not know how to go about this problem and would appreciate to have
some assistance. thank you in advance

i am running kernel 4.9.0, bluez 5.43, pulseaudio 9.0.
bluetooth is provided by QCA9377

sudo ethtool -i wlp1s0:
http://pastebin.com/k7qWGUDk

sudo lsusb -s 001:003 -v:
Bus 001 Device 003: ID 13d3:3496 IMC Networks
http://pastebin.com/u1Ndbiz2

lspci -s 01:00.0
01:00.0 Network controller: Qualcomm Atheros QCA9377 802.11ac Wireless
Network Adapter (rev 30)
http://pastebin.com/eEJhewXD

dmesg:
http://pastebin.com/QEcphmTj

please let me know if i can provide further information,
Yevgeniy


