Email change

[Michal Kazior]

Hi everyone,

I'm parting ways with Tieto today so my email is going  to become
defunct. I'll be reachable via: kazikcz at gmail dot com.


Michał

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

Re: Recent driver changes destabilized QCA9377 connection quality

[Michal Kazior]

On 26 February 2017 at 16:40, Tobias Predel  wrote:
> Hello,
[...]
> (2) Many FCS (frame check sequence) errors paired with "len 0"?
>
> [  872.338194] ath10k_pci :02:00.0: rx skb 88003765ec00 len 0 peer 
> 00:XX:XX:XX:XX:88  mcast sn 1470 legacy rate_idx 0 vht_nss 0 freq 2447 band 0 
> flag 0x1200020 fcs-err 1 mic-err 0 amsdu-more 0
> [  872.952364] ath10k_pci :02:00.0: rx skb 880011356400 len 0 peer 
> 00:XX:XX:XX:XX:88  mcast sn 1476 legacy rate_idx 0 vht_nss 0 freq 2447 band 0 
> flag 0x1200020 fcs-err 1 mic-err 0 amsdu-more 0
> [  873.259564] ath10k_pci :02:00.0: rx skb 88001ce2fd00 len 0 peer 
> 00:XX:XX:XX:XX:88  mcast sn 1479 legacy rate_idx 0 vht_nss 0 freq 2447 band 0 
> flag 0x1200020 fcs-err 1 mic-err 0 amsdu-more 0
> [  874.181195] ath10k_pci :02:00.0: rx skb 88004b26be00 len 0 peer 
> 00:XX:XX:XX:XX:88  mcast sn 1488 legacy rate_idx 0 vht_nss 0 freq 2447 band 0 
> flag 0x1200020 fcs-err 1 mic-err 0 amsdu-more 0
> [  874.488037] ath10k_pci :02:00.0: rx skb 88004b26bb00 len 0 peer 
> 00:XX:XX:XX:XX:88  mcast sn 1491 legacy rate_idx 0 vht_nss 0 freq 2447 band 0 
> flag 0x1200020 fcs-err 1 mic-err 0 amsdu-more 0
> [  874.795505] ath10k_pci :02:00.0: rx skb 880037856e00 len 0 peer 
> 00:XX:XX:XX:XX:88  mcast sn 1496 legacy rate_idx 0 vht_nss 0 freq 2447 band 0 
> flag 0x1200020 fcs-err 1 mic-err 0 amsdu-more 0

QCA9377 can report "offloaded" frames which don't carry rx descriptor.
I can imagine that if - for whatever reason - offloaded frame is
treated as non-offloaded it'd end up shorter and parsed incorrectly
(i.e. bad fcs). I'd be interested in seeing htt dumps of buffers
related to these rx skbs.


Michał

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

Re: [RFC] ath10k: silence firmware file probing warnings

[Michal Kazior]

On 20 January 2017 at 13:51, Kalle Valo <kv...@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kaz...@tieto.com> wrote:
>> Firmware files are versioned to prevent older
>> driver instances to load unsupported firmware
>> blobs. This is reflected with a fallback logic
>> which attempts to load several firmware files.
>>
>> This however produced a lot of unnecessary
>> warnings sometimes confusing users and leading
>> them to rename firmware files making things even
>> more confusing.
>>
>> Hence use request_firmware_direct() which does not
>> produce extra warnings. This shouldn't really
>> break anything because most modern systems don't
>> rely on udev/hotplug helpers to load firmware
>> files anymore.
>>
>> Signed-off-by: Michal Kazior <michal.kaz...@tieto.com>
>
> This ended into a rather long discussion, see the full thread from the 
> patchwork link
> below, but I'll try to summarise it here:
>
> * Nobody stepped up and mentioned that they need/use the user fallback helper 
> with ath10k.
>
> * Felix confirmed that LEDE creates the calibration file before loading ath10k
>   so this should not break LEDE.
>
> * This also fixes a 60 second delay per _each_ unexistent firmware/calibration
>   file with distros which have CONFIG_FW_LOADER_USER_HELPER_FALLBACK enabled,
>   RHEL being a notable example. Using ath10k with firmware-2.bin this might
>   end up into a five minute delay in boot.
>
> * Luis is working on new drvdata interface for kernel, but that's not merged 
> yet.
>
> Based on this I think the right approach is to apply this patch. Any concerns?
>
> While writing this I started to suspect is it just by accident that
> request_firmware_direct() does not print any error messages and
> request_firmware() again does print those? Let's hope nobody decides to change
> that.  And at least Luis' drvdata interface has a documented 'optional' flag,
> so we can always switch to using that (once it's merged):
>
> * struct drvdata_req_params - driver data request parameters
> * @optional: if true it is not a hard requirement by the caller that this
> *   file be present. An error will not be recorded if the file is not
> *   found.
>
> Michal, do you mind if I'll add more info to the commit log and submit this 
> RFC
> as a proper patch? It still seems to apply and work just fine.

I don't mind :)


Michał

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

Re: [PATCH] ath10k: prevent sta pointer rcu violation

[Michal Kazior]

On 13 January 2017 at 08:24, Johannes Berg  wrote:
>
>> Unless you then continue to use that sta pointer after you release
>> data_lock.
>
> Ouch, ok. That's rather strangely hidden though.
>
>> Consider this:
>>
>> >  CPU0 CPU1
>> > 1   synchronize_net()
>> > 2drv_sta_state()
>> > 3  htt_fetch_ind(pid,tid) called
>> > 4  rcu_read_lock()
>> > 5  get(data_lock)
>> > 6  txq=peers[pid]->sta->txq[tid]
>> > 7  put(data_lock)
>> > 8get(data_lock)
>> > 9 peer->sta=0
>> > 10   put(data_lock)
>> > 11 kfree(sta)
>> > 12 ieee80211_tx_dequeue(txq)
>>
>> Even though there's no code like (9) per se you can think of it as
>> anything that tries to "remove" the peer--sta association
>> (ath10k_peer
>> is removed implicitly via wmi peer delete command and waiting for htt
>> event completion).
>>
>> Holding data_lock for the entire duration of handling fetch
>> indication isn't really good for performance so it's better to fix
>> RCU handling.
>
> Yeah, I see it now - also the comment where this happens. You probably
> should mark some things __rcu though and actually use RCU primitives,
> so the code is actually understandable :)

Good point. I'll do that in another patch.


Michał

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

[PATCH] ath10k: prevent sta pointer rcu violation

[Michal Kazior]

Station pointers are RCU protected so driver must
be extra careful if it tries to store them
internally for later use outside of the RCU
section it obtained it in.

It was possible for station teardown to race with
some htt events. The possible outcome could be a
use-after-free and a crash.

Only peer-flow-control capable firmware was
affected (so hardware-wise qca99x0 and qca4019).

This could be done in sta_state() itself via
explicit synchronize_net() call but there's
already a convenient sta_pre_rcu_remove() op that
can be hooked up to avoid extra rcu stall.

The peer->sta pointer itself can't be set to
NULL/ERR_PTR because it is later used in
sta_state() for extra sanity checks.

Signed-off-by: Michal Kazior <michal.kaz...@tieto.com>
---
 drivers/net/wireless/ath/ath10k/core.h |  1 +
 drivers/net/wireless/ath/ath10k/mac.c  | 18 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index c7664d6569fa..1ab589296dff 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -314,6 +314,7 @@ struct ath10k_peer {
struct ieee80211_vif *vif;
struct ieee80211_sta *sta;
 
+   bool removed;
int vdev_id;
u8 addr[ETH_ALEN];
DECLARE_BITMAP(peer_ids, ATH10K_MAX_NUM_PEER_IDS);
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index d1b7edba5e49..aa91f55b35a4 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3774,6 +3774,9 @@ struct ieee80211_txq *ath10k_mac_txq_lookup(struct ath10k 
*ar,
if (!peer)
return NULL;
 
+   if (peer->removed)
+   return NULL;
+
if (peer->sta)
return peer->sta->txq[tid];
else if (peer->vif)
@@ -7476,6 +7479,20 @@ ath10k_mac_op_switch_vif_chanctx(struct ieee80211_hw *hw,
return 0;
 }
 
+static void ath10k_mac_op_sta_pre_rcu_remove(struct ieee80211_hw *hw,
+struct ieee80211_vif *vif,
+struct ieee80211_sta *sta)
+{
+   struct ath10k *ar;
+   struct ath10k_peer *peer;
+
+   ar = hw->priv;
+
+   list_for_each_entry(peer, >peers, list)
+   if (peer->sta == sta)
+   peer->removed = true;
+}
+
 static const struct ieee80211_ops ath10k_ops = {
.tx = ath10k_mac_op_tx,
.wake_tx_queue  = ath10k_mac_op_wake_tx_queue,
@@ -7516,6 +7533,7 @@ static const struct ieee80211_ops ath10k_ops = {
.assign_vif_chanctx = ath10k_mac_op_assign_vif_chanctx,
.unassign_vif_chanctx   = ath10k_mac_op_unassign_vif_chanctx,
.switch_vif_chanctx = ath10k_mac_op_switch_vif_chanctx,
+   .sta_pre_rcu_remove = ath10k_mac_op_sta_pre_rcu_remove,
 
CFG80211_TESTMODE_CMD(ath10k_tm_cmd)
 
-- 
2.1.4


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

Re: Regular firmware crashes with QCA6174

[Michal Kazior]

On 9 January 2017 at 13:36, Shaun Crampton <sh...@cantab.net> wrote:
> On Mon, 9 Jan 2017, 08:49 Michal Kazior, <michal.kaz...@tieto.com> wrote:
>> On 7 January 2017 at 22:41, Shaun Crampton <sh...@cantab.net> wrote:
>> > Hi,
>> >
>> > I'm getting regular QCA6174 firmware crashes on Ubuntu 16.10 with the
>> > QCA6174 (new Dell XPS 13, which shipped with Ubuntu 16.04).  Crash
>> > seems to be at random, roughly every 30 minutes.  After the crash,
>> > wifi stops working until I turn it off and on again.
>> >
>> > Any help or workaround appreciated.  I've copied the dmesg log in
>> > below.  I have the latest firmware from linux-firmware in
>> > /lib/firmware.
>> >
>> > Please CC in me any responses.
>> >
>> > Thanks,
>> >
>> > -Shaun
>> >
>> > [ 3683.563419] wlp58s0: AP 00:07:26:aa:e0:45 changed bandwidth, new
>> > config is 2472 MHz, width 2 (2462/0 MHz)
>>
>> Your AP seems to be toggling HT20 and HT40.
>>
>> Can you force your AP to run at HT20 at all times, please? If the
>> problem ceases it'll strongly point to firmware's rate control
>> becoming confused (e.g. due to driver not properly telling it how
>> peer's capabilities have changes).
>
> I don't think my AP has that setting, is there any way to disable it at the
> client side?

APs can expose this differently, e.g. mode (a/b/g/n), bandwidth (20,
40, auto), rate (54, 150, 300, 866). In any case, you want to avoid
"n/ac", >54mbps, !=20mhz.

You could force wpa_supplicant to run with disabe_ht=1 in the network
block to force legacy 11a/b/g mode which should ignore bandwidth
changes. I don't know how to force network manager (or similar) to do
that though.


Michał

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

Re: Regular firmware crashes with QCA6174

[Michal Kazior]

On 7 January 2017 at 22:41, Shaun Crampton  wrote:
> Hi,
>
> I'm getting regular QCA6174 firmware crashes on Ubuntu 16.10 with the
> QCA6174 (new Dell XPS 13, which shipped with Ubuntu 16.04).  Crash
> seems to be at random, roughly every 30 minutes.  After the crash,
> wifi stops working until I turn it off and on again.
>
> Any help or workaround appreciated.  I've copied the dmesg log in
> below.  I have the latest firmware from linux-firmware in
> /lib/firmware.
>
> Please CC in me any responses.
>
> Thanks,
>
> -Shaun
>
> [ 3683.563419] wlp58s0: AP 00:07:26:aa:e0:45 changed bandwidth, new
> config is 2472 MHz, width 2 (2462/0 MHz)

Your AP seems to be toggling HT20 and HT40.

Can you force your AP to run at HT20 at all times, please? If the
problem ceases it'll strongly point to firmware's rate control
becoming confused (e.g. due to driver not properly telling it how
peer's capabilities have changes).


Michał

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

Re: Direct firmware load for ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2

[Michal Kazior]

On 5 January 2017 at 14:28, Xavier Bestel  wrote:
> Hi,
>
> [Sorry if this is a FAQ, I didn't find the answer on 
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/firmware
> and the mailing-list isn't searchable]
>
> I have an XPS 13 9360 with a stock Killer 1535, and I suffer random
> freeze when enabling on-board WiFi. I'm not yet sure if it's due to
> i915 or ath10k.

Does it freeze the entire system? Try making sure ath10k_pci is loaded
with reset_mode, e.g. via /etc/modprobe.d/ with:

 options ath10k_pci reset_mode=1


> Anyway, while looking at the logs I noticed this:
> [3.685987] ath10k_pci :3a:00.0: pci irq msi oper_irq_mode 2 irq_mode 
> 0 reset_mode 0
> [3.969321] ath10k_pci :3a:00.0: firmware: failed to load 
> ath10k/pre-cal-pci-:3a:00.0.bin (-2)
> [3.969324] ath10k_pci :3a:00.0: Direct firmware load for 
> ath10k/pre-cal-pci-:3a:00.0.bin failed with error -2
> [3.969347] ath10k_pci :3a:00.0: firmware: failed to load 
> ath10k/cal-pci-:3a:00.0.bin (-2)
> [3.969350] ath10k_pci :3a:00.0: Direct firmware load for 
> ath10k/cal-pci-:3a:00.0.bin failed with error -2
> [3.969889] ath10k_pci :3a:00.0: firmware: failed to load 
> ath10k/QCA6174/hw3.0/firmware-5.bin (-2)
> [3.969892] ath10k_pci :3a:00.0: Direct firmware load for 
> ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2
> [3.969896] ath10k_pci :3a:00.0: could not fetch firmware file 
> 'ath10k/QCA6174/hw3.0/firmware-5.bin': -2
> [3.971125] ath10k_pci :3a:00.0: firmware: direct-loading firmware 
> ath10k/QCA6174/hw3.0/firmware-4.bin
> [3.971137] ath10k_pci :3a:00.0: qca6174 hw3.2 target 0x0503 
> chip_id 0x00340aff sub 1a56:1535
> [3.971140] ath10k_pci :3a:00.0: kconfig debug 0 debugfs 0 tracing 0 
> dfs 0 testmode 0
> [3.972789] ath10k_pci :3a:00.0: firmware ver 
> WLAN.RM.2.0-00180-QCARMSWPZ-1 api 4 features wowlan,ignore-otp,no-4addr-pad 
> crc32 75dee6c5
> [4.035365] ath10k_pci :3a:00.0: firmware: direct-loading firmware 
> ath10k/QCA6174/hw3.0/board-2.bin
> [4.035543] ath10k_pci :3a:00.0: board_file api 2 bmi_id N/A crc32 
> 6fc88fe7
> [6.156152] ath10k_pci :3a:00.0: htt-ver 3.26 wmi-op 4 htt-op 3 cal 
> otp max-sta 32 raw 0 hwcrypto 1
> [6.249858] ath10k_pci :3a:00.0 wlp58s0: renamed from wlan0
>
> Apparently there are files missing, and I can't even find them on 
> https://github.com/kvalo/ath10k-firmware
> but apparently the card is working anyway.
>
> So why does it try to load a firmware if it's not useful ?

Driver tries to load latest-to-oldest version blobs (for backward
compatibility) and uses whatever it finds first. Due to deficient
firmware API in kernel you see these "error" messages. There's been
some work going on but it's progressing slowly.


Michał

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

Re: [RFC v2 05/11] ath10k: htc: refactorization

[Michal Kazior]

On 13 December 2016 at 19:37, Erik Stromdahl <erik.stromd...@gmail.com> wrote:
>
>
> On 12/13/2016 06:26 PM, Valo, Kalle wrote:
>> Michal Kazior <michal.kaz...@tieto.com> writes:
>>
>>> On 13 December 2016 at 14:44, Valo, Kalle <kv...@qca.qualcomm.com> wrote:
>>>> Erik Stromdahl <erik.stromd...@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.stromd...@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 :02:00.0: pci irq msi oper_irq_mode 2 
>>>> irq_mode 0 reset_mode 0
>>>> [ 1239.885125] ath10k_pci :02:00.0: Direct firmware load for 
>>>> ath10k/pre-cal-pci-:02:00.0.bin failed with error -2
>>>> [ 1239.885260] ath10k_pci :02:00.0: Direct firmware load for 
>>>> ath10k/cal-pci-:02:00.0.bin failed with error -2
>>>> [ 1239.885687] ath10k_pci :02:00.0: qca988x hw2.0 target 0x4100016c 
>>>> chip_id 0x043202ff sub :
>>>> [ 1239.885699] ath10k_pci :02:00.0: kconfig debug 1 debugfs 1 tracing 
>>>> 1 dfs 1 testmode 1
>>>> [ 1239.885899] ath10k_pci :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 :02:00.0: Direct firmware load for 
>>>> ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
>>>> [ 1239.941993] ath10k_pci :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 =  *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 bran

Re: [RFC v2 05/11] ath10k: htc: refactorization

[Michal Kazior]

On 13 December 2016 at 14:44, Valo, Kalle  wrote:
> Erik Stromdahl  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 
>
> 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 :02:00.0: pci irq msi oper_irq_mode 2 irq_mode 
> 0 reset_mode 0
> [ 1239.885125] ath10k_pci :02:00.0: Direct firmware load for 
> ath10k/pre-cal-pci-:02:00.0.bin failed with error -2
> [ 1239.885260] ath10k_pci :02:00.0: Direct firmware load for 
> ath10k/cal-pci-:02:00.0.bin failed with error -2
> [ 1239.885687] ath10k_pci :02:00.0: qca988x hw2.0 target 0x4100016c 
> chip_id 0x043202ff sub :
> [ 1239.885699] ath10k_pci :02:00.0: kconfig debug 1 debugfs 1 tracing 1 
> dfs 1 testmode 1
> [ 1239.885899] ath10k_pci :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 :02:00.0: Direct firmware load for 
> ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
> [ 1239.941993] ath10k_pci :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 =  *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ł

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

Re: ath10k raw mode

[Michal Kazior]

On 12 December 2016 at 14:23, Andreas Christoforou  wrote:
> Dear Michal,
>
> unfortunately I am getting the following error
>
>   [ 50.416483] ath10k_pci :07:00.0: firmware crashed! (uuid
> bdf6b230-c8f5-4e61-b174-93b0980ee5dc)
> [   50.425506] ath10k_pci :07:00.0: qca988x hw2.0 (0x4100016c,
> 0x043202ff sub :) 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 :07:00.0: debug 1 debugfs 1 tracing 1 dfs 0
> testmode 1
> [   50.454283] ath10k_pci :07:00.0: firmware register dump:
> [   50.460008] ath10k_pci :07:00.0: [00]: 0x4100016C 0x
> 0x0097F8D5 0x
> [   50.467940] ath10k_pci :07:00.0: [04]: 0x 0x
> 0x 0x
> [   50.475908] ath10k_pci :07:00.0: [08]: 0x 0x
> 0x 0x
> [   50.483865] ath10k_pci :07:00.0: [12]: 0x 0x
> 0x 0x
> [   50.491869] ath10k_pci :07:00.0: [16]: 0x 0x
> 0x 0x0097F8D5
> [   50.499851] ath10k_pci :07:00.0: [20]: 0x 0x00401930
> 0x 0x
> [   50.507784] ath10k_pci :07:00.0: [24]: 0x 0x
> 0x 0x
> [   50.515756] ath10k_pci :07:00.0: [28]: 0x 0x
> 0x 0x
> [   50.523721] ath10k_pci :07:00.0: [32]: 0x 0x
> 0x 0x
> [   50.531692] ath10k_pci :07:00.0: [36]: 0x 0x
> 0x 0x
> [   50.539649] ath10k_pci :07:00.0: [40]: 0x 0x
> 0x 0x
> [   50.547592] ath10k_pci :07:00.0: [44]: 0x 0x
> 0x 0x
> [   50.47] ath10k_pci :07:00.0: [48]: 0x 0x
> 0x 0x
> [   50.563519] ath10k_pci :07:00.0: [52]: 0x 0x
> 0x 0x
> [   50.571478] ath10k_pci :07:00.0: [56]: 0x 0x
> 0x 0x
> [   50.583360] ath10k_warn: 6 callbacks suppressed
> [   50.587916] ath10k_pci :07:00.0: failed to start WMI vdev 0: -108
> [   50.594461] ath10k_pci :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 :07:00.0: failed to flush transmit queue (skip
> 1 ar-state 2): 500
> [   50.722235] ath10k_pci :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ł

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

Re: ath10k raw mode

[Michal Kazior]

On 8 December 2016 at 20:13, Andreas Christoforou
 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ł

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

Re: [PATCH 1/3] ath10k: Ensure there are no stale ar->txqs entries.

[Michal Kazior]

On 2 December 2016 at 01:24, Ben Greear <gree...@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,  <gree...@candelatech.com> wrote:
>>>>>
>>>>> From: Ben Greear <gree...@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(>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(>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ł

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

Re: [PATCH 1/2] mac80211: do not iterate active interfaces when in re-configure

[Michal Kazior]

On 2 December 2016 at 03:29,   wrote:
> From: Ben Greear 
>
> 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 :05:00.0: Initializing arvif: 8801ce97e320 on vif: 
> 8801ce97e1d8
>
> [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: 8801ce97e320  ar:   (null)
[...]
>
> Signed-off-by: Ben Greear 
> ---
>  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ł

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

Re: ath10k qca988x: hostapd does not start properly

[Michal Kazior]

On 23 November 2016 at 23:02, Zoilo Gomez  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-x1 root root197244 Nov 16  2016
> /root/firmware-2.bin_10.1.467.2-1
> -rwxr-xr-x1 root root235056 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

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

Re: IPQ4019 Firmware: board-2.bin vs board.bin

[Michal Kazior]

On 18 November 2016 at 17:46, Christian Lamparter
 wrote:
> Hello,
>
> I've acquired a IPQ4019 Router (Asus RT-AC58U). And It has a IPQ4019-SoC.
> I'm currently in the process of porting it to LEDE. I can report that the
> router is booting and I got the ath10k to work with 4.8.8 +
> LEDE's compat-wireless (2016-10-08-1).
>
> Now, I ran across a small discrepancy with the provided firmware for
> the IPQ4019. From the ath10k's driver prospective it seems that the
> board-2.bin provided on github[0] has the wrong filename:
>
> ath10k_ahb a00.wifi: Direct firmware load for 
> ath10k/pre-cal-ahb-a00.wifi.bin failed with error -2
> ath10k_ahb a00.wifi: Falling back to user helper
> firmware ath10k!pre-cal-ahb-a00.wifi.bin: firmware_loading_store: map 
> pages failed
> ath10k_ahb a00.wifi: qca4019 hw1.0 target 0x0100 chip_id 0x003b00ff 
> sub :
> ath10k_ahb a00.wifi: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
> ath10k_ahb a00.wifi: firmware ver 10.4-3.2.1-00044 api 5 features 
> no-p2p,mfp,peer-flow-ctrl,btcoex-param crc32 b9833652
> ath10k_ahb a00.wifi: failed to fetch board data for 
> bus=ahb,vendor=,device=,subsystem-vendor=,subsystem-devn

As far as I remember QCA4019 is supposed to used bmi chip
identification instead of pci ids for board files. For some reason the
driver uses pci ids on your device. Can you load ath10k_core with
debug_mask=0xff3f and post results, please? I recall OpenWRT was
messing with board file logic with its downstream patches and I
wouldn't be surprised if LEDE keeps on doing that as well.


> ath10k_ahb a00.wifi: Direct firmware load for 
> ath10k/QCA4019/hw1.0/board.bin failed with error -2
> ath10k_ahb a00.wifi: Falling back to user helper
> firmware ath10k!QCA4019!hw1.0!board.bin: firmware_loading_store: map pages 
> failed
> ath10k_ahb a00.wifi: failed to fetch board data
> ath10k_ahb a00.wifi: failed to fetch board file: -11
> ath10k_ahb a00.wifi: could not probe fw (-11)
>
> Now, If I rename board-2.bin to board.bin it works fine and the device 
> initializes
> successfully (and seems to work too):
>
> ath10k_ahb a00.wifi: Direct firmware load for 
> ath10k/pre-cal-ahb-a00.wifi.bin failed with error -2
> ath10k_ahb a00.wifi: Falling back to user helper
> firmware ath10k!pre-cal-ahb-a00.wifi.bin: firmware_loading_store: map 
> pages failed
> ath10k_ahb a00.wifi: qca4019 hw1.0 target 0x0100 chip_id 0x003b00ff 
> sub :
> ath10k_ahb a00.wifi: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
> ath10k_ahb a00.wifi: firmware ver 10.4-3.2.1-00044 api 5 features 
> no-p2p,mfp,peer-flow-ctrl,btcoex-param crc32 b9833652
> ath10k_ahb a00.wifi: Direct firmware load for 
> ath10k/QCA4019/hw1.0/board-2.bin failed with error -2
> ath10k_ahb a00.wifi: Falling back to user helper
> firmware ath10k!QCA4019!hw1.0!board-2.bin: firmware_loading_store: map pages 
> failed
> ath10k_ahb a00.wifi: board_file api 1 bmi_id N/A crc32 9e6ce62c
> ath10k_ahb a00.wifi: htt-ver 2.2 wmi-op 6 htt-op 4 cal file max-sta 512 
> raw 0 hwcrypto 1

Please don't do that. Your basically pushing bogus data as board data
to the device. I'm a ltittle surprised firmware didn't notice. Anyway,
expect the device to misbehave (crash, hang, regulatory violations)
with this "board.bin".


> ath: EEPROM regdomain: 0x0
> ath: EEPROM indicates default country code should be used
> ath: doing EEPROM country->regdmn map search
> ath: country maps to regdmn code: 0x3a
> ath: Country alpha2 being used: US
> ath: Regpair used: 0x3a
>
> What's up with the board-2.bin name? Kalle, can you rename it or
> should ath10k look for board-2.bin instead?

board-2 is a key-value store of actual board files. Some devices,
notably qca61x4 hw3+ and qca4019 need distinct board files to be
uploaded. Otherwise they fail in various ways.


Michal

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

Re: Connection Problems with on QCA9880-BR4A

[Michal Kazior]

On 15 November 2016 at 23:42, Felix  wrote:
> Hi,
>
> Connected is usually a few minutes away from dsiconnected. I am running
> tcpdump without pcap filters. Here are my iptables and udev rules. If I use
> the SR71 everything works fine therefore I doubt it has anything to do with
> these.
[...]
> The option debug_mask=0xff3f does not give me any addidtional entries in
> dmesg or journalctl. I also tried "modprobe ath10k_core
> debug_mask=0x" with the same result and shows the debug_mask value
> seems properly set:
>>> cat /sys/module/ath10k_core/parameters/debug_mask
> 4294967295
>>> python -c 'print "%i" % 0x'
> 4294967295
[...]
>>> journalctl
[...]
> Nov 15 21:27:17 android3427 kernel: ath10k_pci :02:00.0: qca988x hw2.0
> target 0x4100016c chip_id 0x043202ff sub 19b6:d03c
> Nov 15 21:27:17 android3427 kernel: ath10k_pci :02:00.0: kconfig debug 0
> debugfs 0 tracing 0 dfs 0 testmode 0
[...]

Your driver is compiled without debug prints which explains why you're
not seeing any difference after setting debug_mask. You'll need to
recompile for that.


[...]
> Nov 15 21:27:52 android29646 kernel: wlan0: authenticate with XXX0
> Nov 15 21:27:52 android29646 kernel: wlan0: send auth to XXX0 (try 1/3)
> Nov 15 21:27:52 android29646 kernel: wlan0: authenticated
> Nov 15 21:27:52 android29646 kernel: ath10k_pci :02:00.0 wlan0:
> disabling HT as WMM/QoS is not supported by the AP
> Nov 15 21:27:52 android29646 kernel: ath10k_pci :02:00.0 wlan0:
> disabling VHT as WMM/QoS is not supported by the AP

Your AP doesn't even HT nor VHT nor WMM enabled. Is this expected?


> Nov 15 21:27:52 android29646 kernel: wlan0: associate with XXX0 (try 1/3)
> Nov 15 21:27:52 android29646 kernel: wlan0: RX AssocResp from XXX0
> (capab=0x11 status=0 aid=1)
> Nov 15 21:27:52 android29646 kernel: wlan0: associated
> Nov 15 21:27:52 android29646 kernel: wlan0: Limiting TX power to 17 dBm as
> advertised by XXX0
[...]
> Nov 15 21:30:12 android29646 kernel: wlan0: deauthenticated from XXX0
> (Reason: 2=PREV_AUTH_NOT_VALID)

It seems AP is kicking you out. EAP likely didn't complete up all the
way and a timeout on AP is triggered.

I suspect lack of QoS is source of cofusion here. Either driver is
requesting firmware to use wrong tid or firmware tries to be clever
and ends up using wrong hardware queue where the final EAPOL gets
stuck and is never transmitted. That's just a guess though.

Driver dumps (debug_mask=0x actually) would be really useful here.


Michał

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

Re: Re[4]: Linux freezes after a time while running

[Michal Kazior]

On 16 November 2016 at 23:21, Conrad Kostecki <ck+ath...@bl4ckb0x.de> wrote:
> Hello Michal,
>
> Am 07.11.2016 17:43:02, "Michal Kazior" <michal.kaz...@tieto.com> schrieb:
>
>>
>> I assume you used a different kernel in the past compared to the
>> recent test you did. You could try re-testing the older kernel
>> (assuming you remember which one it was) and if it works you could
>> bisect your way to find the commit that breaks it for you.
>>
>>
> I don't have the older kernel config anymore, but it was pretty the same, as
> my current one.
> I've now done some tests and it's quite interesseting. Kernelversion did not
> matter for me.
>
> Running with current firmware-5.bin, it's always crashing. I tried different
> BIOS options, nothing helped.
>
> BUT: Downgrade to firmware-2.bin helps.
> ath10k_pci :03:00.0: firmware ver 10.1.467.3-1 api 2 features wmi-10.x,
> has-wmi-mgmt-tx,no-p2p crc32 2c3ffc2f
>
> Running such old firmware, the Wifi just runs stable. NO firmware crash
> happens. When I just change firmware back to firmware-5.bin, it crashes
> again.
> So there seems to changed something. Can be this debugged somehow?
>
> With firmware-2.bin, I am also getting such errors, but WiFi works fine:
> [   82.504901] ath10k_pci :03:00.0: SWBA overrun on vdev 0, skipped old
> beacon
> [   82.556103] ath10k_pci :03:00.0: SWBA overrun on vdev 1, skipped old
> beacon
> [   87.113085] ath10k_warn: 89 callbacks suppressed
>
> Currently, the workaround is for me firmware-2.bin, but IMHO it's not a
> solution..
> Any Ideas?

Hmm.. looks like there's a stall in target-host communication for ~5
seconds (89 suppressed warnings match 2 vifs beaconing at ~100ms
interval).

Did you try running without multi-BSS, i.e. just one AP vif? That's
probably not going to help but it's worth ruling that out.


Michał

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

Re: [RFC 04/12] ath10k: htc: refactorization

[Michal Kazior]

On 17 November 2016 at 17:32, Erik Stromdahl <erik.stromd...@gmail.com> wrote:
>
>
> On 11/15/2016 11:19 AM, Michal Kazior wrote:
>> On 14 November 2016 at 17:33, Erik Stromdahl <erik.stromd...@gmail.com> 
>> wrote:
>>> 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).
>>
>> This should be squashed with Patch 3 since it's inseparable part of
>> the same refactorization.
>>
>>
>> Michał
>>
>
>
> Hmm, I don't really see why this is an inseparable part of the previous
> patch.
>
> As far as I see this patch has nothing to do with patch 3, or am I
> missing anything?
>
> Are you really sure they should be squashed?

Hmm.. on second thought this should be fine as it is.


Michał

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

Re: [RFC 03/12] ath10k: htc: Changed order of wait target and ep connect

[Michal Kazior]

On 15 November 2016 at 18:07, Erik Stromdahl <erik.stromd...@gmail.com> wrote:
> On 11/15/2016 11:13 AM, Michal Kazior wrote:
>> On 14 November 2016 at 17:33, Erik Stromdahl <erik.stromd...@gmail.com> 
>> wrote:
>>> This patch changes the order in which the driver waits for the
>>> target to become ready and the service connect of the HTC
>>> control service.
>>>
>>> The HTC control service is connected before the driver starts
>>> waiting for the HTC ready control message.
>>>
>>> The reason for this is that the HTC ready control message is
>>> transmitted on EP 0 and that sdio/mbox based systems will ignore
>>> messages received on unconnected endpoints.
>>>
>>> Signed-off-by: Erik Stromdahl <erik.stromd...@gmail.com>
>>> ---
>>>  drivers/net/wireless/ath/ath10k/htc.c |   32 
>>> 
>>>  1 file changed, 16 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/htc.c 
>>> b/drivers/net/wireless/ath/ath10k/htc.c
>>> index e3f7bf4..7257366 100644
>>> --- a/drivers/net/wireless/ath/ath10k/htc.c
>>> +++ b/drivers/net/wireless/ath/ath10k/htc.c
>>> @@ -606,6 +606,22 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
>>> u16 credit_count;
>>> u16 credit_size;
>>>
>>> +   /* setup our pseudo HTC control endpoint connection */
>>> +   memset(_req, 0, sizeof(conn_req));
>>> +   memset(_resp, 0, sizeof(conn_resp));
>>> +   conn_req.ep_ops.ep_tx_complete = ath10k_htc_control_tx_complete;
>>> +   conn_req.ep_ops.ep_rx_complete = ath10k_htc_control_rx_complete;
>>> +   conn_req.max_send_queue_depth = ATH10K_NUM_CONTROL_TX_BUFFERS;
>>> +   conn_req.service_id = ATH10K_HTC_SVC_ID_RSVD_CTRL;
>>> +
>>> +   /* connect fake service */
>>> +   status = ath10k_htc_connect_service(htc, _req, _resp);
>>> +   if (status) {
>>> +   ath10k_err(ar, "could not connect to htc service (%d)\n",
>>> +  status);
>>> +   return status;
>>> +   }
>>> +
>>
>> How is this supposed to work? ath10k_htc_connect_service() requires
>> htc->target_credit_size to compute tx_credits_per_max_message. Or am I
>> missing something? Applying this patch alone results in:
>>
>> [6.680101] divide error:  [#1] SMP
>> [6.681342] Modules linked in: ath10k_pci(O) ath10k_core(O) ath
>> mac80211 cfg80211
>> [6.684876] CPU: 3 PID: 823 Comm: kworker/u8:2 Tainted: GW
>> O4.9.0-rc4-wt-ath+ #79
>> [6.688051] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>> BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
>> [6.691644] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core]
>> [6.694309] task: 88000a19 task.stack: c96d4000
>> [6.695458] RIP: 0010:[]  []
>> ath10k_htc_connect_service+0x21b/0x420 [ath10k_core]
>>
>>
>> Michał
>>
>
> You're right. I have totally missed this. What is strange is that my
> compiler (ARM linaro) seems to optimize the code in a way that removes
> the tx_credits_per_max_message value.
>
> If I add a printk in ath10k_htc_connect_service (printing the value) I
> get a similar oops.
>
> I think it has to do with the fact the this value isn't really used at
> all. grepping the code reveals that tx_credits_per_max_message is only
> used inside ath10k_htc_connect_service (only written, never read).
>
> Removing it doesn't seem to break anything, so perhaps it should be removed?

I think it's safe to remove now. This is legacy inherited from the
internal driver.

Otherwise this looks okay except commit log which is a bit unclear.
I'm still not sure *why* you need to reorder this. FWIW this can be a
general clean up thing that ends up moving the if (eid == EP0) {code}
to control endpoint handler in patch 4.


Michał

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

Re: Connection Problems with on QCA9880-BR4A

[Michal Kazior]

On 15 November 2016 at 13:59, Felix  wrote:
[...]
>>> cat /etc/wpa_supplicant/wpa_supplicant.conf
> ctrl_interface=/var/run/wpa_supplicant
> network={
> ssid="eduroam"
> proto=RSN
> pairwise=CCMP
> group=CCMP
> key_mgmt=WPA-EAP
> eap=TTLS
> domain_suffix_match="XXX"
> phase1="peaplabel=0"
> anonymous_identity="anonymous@XXX"
> phase2="auth=PAP"
> ca_cert="XXX"
> identity="XXX"
> password="XXX"
> }
>
>>> wpa_supplicant -i wlan0 -D nl80211 -c
>>> /etc/wpa_supplicant/wpa_supplicant.conf
> Successfully initialized wpa_supplicant
> wlan0: SME: Trying to authenticate with XXX (SSID='eduroam' freq=5240 MHz)
> wlan0: Trying to associate with XXX (SSID='eduroam' freq=5240 MHz)
> wlan0: Associated with XXX
> wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
> wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
> wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
> wlan0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=XXX
> wlan0: CTRL-EVENT-EAP-PEER-CERT depth=3 subject='XXX'
> wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='XXX'
> wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='XXX'
> wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='XXX'
> wlan0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
> wlan0: WPA: Key negotiation completed with XXX [PTK=CCMP GTK=CCMP]
> wlan0: CTRL-EVENT-CONNECTED - Connection to XXX completed [id=0 id_str=]
> wlan0: CTRL-EVENT-DISCONNECTED bssid=XXX reason=2

How long is CONNECTED away from DISCONNECTED? Running with "-t" should
add timestamps. At this point I would suggest "-ddd" to get verbose
logs.


>>> cat /etc/dhcp/dhclient.conf
> option rfc3442-classless-static-routes code 121 = array of unsigned integer
> 8;
> supersede dhcp-server-identifier 255.255.255.255;
> request subnet-mask, broadcast-address, time-offset, routers, interface-mtu,
> rfc3442-classless-static-routes;
> timeout 30;
> retry 30;
>
>>> journalctl -b | grep dhclient
> Nov 15 12:32:57 android10278 dhclient[852]: DHCPREQUEST on wlan0 to
> 255.255.255.255 port 67
[...]
>
>>> tcpdump -i wlan0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 12:26:31.765188 ARP, Request who-has 8.8.8.8 tell 192.168.0.1, length 28
> 12:26:31.765227 ARP, Request who-has 8.8.4.4 tell 192.168.0.1, length 28
[...]
> 12:26:57.181480 EAP packet (0) v2, len 6
> 12:26:57.192997 EAP packet (0) v2, len 1024
> 12:26:57.193250 EAP packet (0) v2, len 6
> 12:26:57.203442 EAP packet (0) v2, len 1024
> 12:26:57.203690 EAP packet (0) v2, len 6
> 12:26:57.214876 EAP packet (0) v2, len 461
> 12:26:57.228167 EAP packet (0) v2, len 140
> 12:26:57.238101 EAP packet (0) v2, len 69
> 12:26:57.239395 EAP packet (0) v2, len 144
> 12:26:57.309948 EAP packet (0) v2, len 4
> 12:26:57.310261 EAPOL key (3) v2, len 117
> 12:26:57.314455 EAPOL key (3) v2, len 117
> 12:26:57.316151 EAPOL key (3) v2, len 151
> 12:26:57.316485 EAPOL key (3) v2, len 95

This suggests key exchange has completed.


> 12:26:57.379388 IP XXX.152.54.netbios-ns > XXX.155.255.netbios-ns: NBT UDP
> PACKET(137): QUERY; REQUEST; BROADCAST
> 12:26:57.388661 IP XXX.154.22.netbios-ns > XXX.155.255.netbios-ns: NBT UDP
> PACKET(137): QUERY; REQUEST; BROADCAST
[...]
> 452 packets captured
> 8348 packets received by filter
> 7896 packets dropped by kernel#

What happened to all the packets? Are you really running just
"tcpdump" or are you applying pcap filters that you didn't mention?

There are no DHCP requests so either firmware is refusing to transmit
them OTA, have been filtered by kernel/tcpdump or you have some
firewall rule that drops the packets. Tcpdump does report some traffic
which I infer is just Rx suggesting crypto is (at least partially) set
up. Is there something you're not telling about your setup?

Can you load ath10k_core with debug_mask=0xff3f and provide logs?


Michał

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

Re: Getting ATH10K to work with Linksys WUSB6100M

[Michal Kazior]

On 15 November 2016 at 11:41, Johan Lindström
<johan.von.lindst...@gmail.com> wrote:
>
>> 14 nov. 2016 kl. 12:40 wrote Michal Kazior <michal.kaz...@tieto.com>:
>>
>> On 11 November 2016 at 00:56, Johan Lindström
>> <johan.von.lindst...@gmail.com> wrote:
>>> This device is running  QCA9377 chipset with the usb.id 13b1:0042
>>>
>>> Any ideas on how to add this device to the working devices? Does ath10k 
>>> even work with USB devices?
>>>
>>> See info: http://askubuntu.com/questions/799104/linksys-wusb6100m
>
>> USB transport is not implemented in ath10k. Adding it will require a
>> slight HTC/HTT rework and implementing the transport code itself. I'm
>> pretty sure qcacld[1] can used as reference.
>>
>> [1]: 
>> https://github.com/sktjdgns1189/qcacld-2.0/tree/master/CORE/SERVICES/HIF/USB
>>
>>
>> Michał
>
> Anyone up for this? I myself have not done anything close to this.

I'm not aware of anyone working on this.

Eric Stromdahl is currently working on adding SDIO support. This
requires HTC/HTT rework for the so called "high latency" devices. Both
SDIO and USB are considered such hence adding USB support will become
easier once Eric completes his SDIO work.


Michał

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

Re: [RFC 10/12] ath10k: Added QCA65XX hw definition

[Michal Kazior]

On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
> Signed-off-by: Erik Stromdahl 
> ---
>  drivers/net/wireless/ath/ath10k/hw.h |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
> b/drivers/net/wireless/ath/ath10k/hw.h
> index 46142e9..ef45ecf 100644
> --- a/drivers/net/wireless/ath/ath10k/hw.h
> +++ b/drivers/net/wireless/ath/ath10k/hw.h
> @@ -224,6 +224,7 @@ enum ath10k_hw_rev {
> ATH10K_HW_QCA9377,
> ATH10K_HW_QCA4019,
> ATH10K_HW_QCA9887,
> +   ATH10K_HW_QCA65XX,

Are you 100% positive that you're supporting all QCA65XX chips? The
rule of thumb is to avoid Xs as much as possible unless totally
perfectly completely sure.


Michał

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

Re: [RFC 09/12] ath10k: Mailbox address definitions

[Michal Kazior]

On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
> Address definitions for SDIO/mbox based chipsets.
>
> Signed-off-by: Erik Stromdahl 
> ---
>  drivers/net/wireless/ath/ath10k/hw.h |   53 
> ++
>  1 file changed, 53 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
> b/drivers/net/wireless/ath/ath10k/hw.h
> index 883547f..46142e9 100644
> --- a/drivers/net/wireless/ath/ath10k/hw.h
> +++ b/drivers/net/wireless/ath/ath10k/hw.h
> @@ -814,6 +814,59 @@ struct ath10k_hw_ops {
>  #define QCA9887_EEPROM_ADDR_LO_MASK0x00ff
>  #define QCA9887_EEPROM_ADDR_LO_LSB 16
>
> +#define MBOX_RESET_CONTROL_ADDRESS 0x
> +#define MBOX_HOST_INT_STATUS_ADDRESS   0x0800
> +#define MBOX_HOST_INT_STATUS_ERROR_LSB 7
> +#define MBOX_HOST_INT_STATUS_ERROR_MASK0x0080

I would again suggest using Jakub's bitfield GET_FIELD stuff to get
rid of MASK+LSB and just have single define per register field. Kalle,
thoughts?


Michał

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

Re: [RFC 06/12] ath10k: bmi: Added SOC reg read/write functions

[Michal Kazior]

On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
> Added functions implementing the following BMI commands:
>
> BMI_READ_SOC_REGISTER
> BMI_WRITE_SOC_REGISTER
>
> Reading and writing BMI registers is sometimes needed for
> SDIO chipsets.

I didn't see ath10k_bmi_write_soc_reg nor ath10k_bmi_read_soc_reg
being used in your Patch 12. Is this patch really necessary?


[...]
> diff --git a/drivers/net/wireless/ath/ath10k/bmi.c 
> b/drivers/net/wireless/ath/ath10k/bmi.c
> index 2872d34..1c378a2 100644
> --- a/drivers/net/wireless/ath/ath10k/bmi.c
> +++ b/drivers/net/wireless/ath/ath10k/bmi.c
> @@ -97,7 +97,8 @@ int ath10k_bmi_read_memory(struct ath10k *ar,
> u32 rxlen;
> int ret;
>
> -   ath10k_dbg(ar, ATH10K_DBG_BMI, "bmi read address 0x%x length %d\n",
> +   ath10k_dbg(ar, ATH10K_DBG_BMI,
> +  "bmi read memory address 0x%x length %d\n",
>address, length);
>
> if (ar->bmi.done_sent) {
> @@ -137,7 +138,8 @@ int ath10k_bmi_write_memory(struct ath10k *ar,
> u32 txlen;
> int ret;
>
> -   ath10k_dbg(ar, ATH10K_DBG_BMI, "bmi write address 0x%x length %d\n",
> +   ath10k_dbg(ar, ATH10K_DBG_BMI,
> +  "bmi write memory address 0x%x length %d\n",
>address, length);
>

These 2 hunks shouldn't be modified in this patch. If you want to do a
clean up this warrants a separate patch :)


Michał

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

Re: [RFC 05/12] ath10k: htc: Added ATH10K_HTC_FLAG_BUNDLE_LSB

[Michal Kazior]

On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
> Signed-off-by: Erik Stromdahl 
> ---
>  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 589800a..df16a04 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

Just an idea - we could start using FIELD_GET() with
ATH10K_HTC_FLAG_BUNDLE_MASK alone. I would love to see Jakub's
bitfield stuff be used more. Kalle, thoughts?


Michał

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

Re: [RFC 04/12] ath10k: htc: refactorization

[Michal Kazior]

On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
> 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).

This should be squashed with Patch 3 since it's inseparable part of
the same refactorization.


Michał

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

Re: [RFC 03/12] ath10k: htc: Changed order of wait target and ep connect

[Michal Kazior]

On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
> This patch changes the order in which the driver waits for the
> target to become ready and the service connect of the HTC
> control service.
>
> The HTC control service is connected before the driver starts
> waiting for the HTC ready control message.
>
> The reason for this is that the HTC ready control message is
> transmitted on EP 0 and that sdio/mbox based systems will ignore
> messages received on unconnected endpoints.
>
> Signed-off-by: Erik Stromdahl 
> ---
>  drivers/net/wireless/ath/ath10k/htc.c |   32 
>  1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/htc.c 
> b/drivers/net/wireless/ath/ath10k/htc.c
> index e3f7bf4..7257366 100644
> --- a/drivers/net/wireless/ath/ath10k/htc.c
> +++ b/drivers/net/wireless/ath/ath10k/htc.c
> @@ -606,6 +606,22 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
> u16 credit_count;
> u16 credit_size;
>
> +   /* setup our pseudo HTC control endpoint connection */
> +   memset(_req, 0, sizeof(conn_req));
> +   memset(_resp, 0, sizeof(conn_resp));
> +   conn_req.ep_ops.ep_tx_complete = ath10k_htc_control_tx_complete;
> +   conn_req.ep_ops.ep_rx_complete = ath10k_htc_control_rx_complete;
> +   conn_req.max_send_queue_depth = ATH10K_NUM_CONTROL_TX_BUFFERS;
> +   conn_req.service_id = ATH10K_HTC_SVC_ID_RSVD_CTRL;
> +
> +   /* connect fake service */
> +   status = ath10k_htc_connect_service(htc, _req, _resp);
> +   if (status) {
> +   ath10k_err(ar, "could not connect to htc service (%d)\n",
> +  status);
> +   return status;
> +   }
> +

How is this supposed to work? ath10k_htc_connect_service() requires
htc->target_credit_size to compute tx_credits_per_max_message. Or am I
missing something? Applying this patch alone results in:

[6.680101] divide error:  [#1] SMP
[6.681342] Modules linked in: ath10k_pci(O) ath10k_core(O) ath
mac80211 cfg80211
[6.684876] CPU: 3 PID: 823 Comm: kworker/u8:2 Tainted: GW
O4.9.0-rc4-wt-ath+ #79
[6.688051] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[6.691644] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core]
[6.694309] task: 88000a19 task.stack: c96d4000
[6.695458] RIP: 0010:[]  []
ath10k_htc_connect_service+0x21b/0x420 [ath10k_core]


Michał

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

[PATCH] ath10k: add spectral scan support to wmi-tlv

[Michal Kazior]

Command structure and event flow doesn't seem to
be any different compared to existing
implementation for other firmware branches.

This patch effectively adds in-driver support for
spectral scanning on QCA61x4 and QCA9377.

Tested QCA9377 w/ WLAN.TF.1.0-00267-1.

Signed-off-by: Michal Kazior <michal.kaz...@tieto.com>
---
 drivers/net/wireless/ath/ath10k/wmi-tlv.c | 72 +++
 1 file changed, 72 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c 
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index e64f59300a7c..7f9b1185b549 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -3136,6 +3136,76 @@ ath10k_wmi_tlv_op_gen_echo(struct ath10k *ar, u32 value)
return skb;
 }
 
+static struct sk_buff *
+ath10k_wmi_tlv_op_gen_vdev_spectral_conf(struct ath10k *ar,
+const struct 
wmi_vdev_spectral_conf_arg *arg)
+{
+   struct wmi_vdev_spectral_conf_cmd *cmd;
+   struct sk_buff *skb;
+   struct wmi_tlv *tlv;
+   void *ptr;
+   size_t len;
+
+   len = sizeof(*tlv) + sizeof(*cmd);
+   skb = ath10k_wmi_alloc_skb(ar, len);
+   if (!skb)
+   return ERR_PTR(-ENOMEM);
+
+   ptr = (void *)skb->data;
+   tlv = ptr;
+   tlv->tag = 
__cpu_to_le16(WMI_TLV_TAG_STRUCT_VDEV_SPECTRAL_CONFIGURE_CMD);
+   tlv->len = __cpu_to_le16(sizeof(*cmd));
+   cmd = (void *)tlv->value;
+   cmd->vdev_id = __cpu_to_le32(arg->vdev_id);
+   cmd->scan_count = __cpu_to_le32(arg->scan_count);
+   cmd->scan_period = __cpu_to_le32(arg->scan_period);
+   cmd->scan_priority = __cpu_to_le32(arg->scan_priority);
+   cmd->scan_fft_size = __cpu_to_le32(arg->scan_fft_size);
+   cmd->scan_gc_ena = __cpu_to_le32(arg->scan_gc_ena);
+   cmd->scan_restart_ena = __cpu_to_le32(arg->scan_restart_ena);
+   cmd->scan_noise_floor_ref = __cpu_to_le32(arg->scan_noise_floor_ref);
+   cmd->scan_init_delay = __cpu_to_le32(arg->scan_init_delay);
+   cmd->scan_nb_tone_thr = __cpu_to_le32(arg->scan_nb_tone_thr);
+   cmd->scan_str_bin_thr = __cpu_to_le32(arg->scan_str_bin_thr);
+   cmd->scan_wb_rpt_mode = __cpu_to_le32(arg->scan_wb_rpt_mode);
+   cmd->scan_rssi_rpt_mode = __cpu_to_le32(arg->scan_rssi_rpt_mode);
+   cmd->scan_rssi_thr = __cpu_to_le32(arg->scan_rssi_thr);
+   cmd->scan_pwr_format = __cpu_to_le32(arg->scan_pwr_format);
+   cmd->scan_rpt_mode = __cpu_to_le32(arg->scan_rpt_mode);
+   cmd->scan_bin_scale = __cpu_to_le32(arg->scan_bin_scale);
+   cmd->scan_dbm_adj = __cpu_to_le32(arg->scan_dbm_adj);
+   cmd->scan_chn_mask = __cpu_to_le32(arg->scan_chn_mask);
+
+   return skb;
+}
+
+static struct sk_buff *
+ath10k_wmi_tlv_op_gen_vdev_spectral_enable(struct ath10k *ar, u32 vdev_id,
+  u32 trigger, u32 enable)
+{
+   struct wmi_vdev_spectral_enable_cmd *cmd;
+   struct sk_buff *skb;
+   struct wmi_tlv *tlv;
+   void *ptr;
+   size_t len;
+
+   len = sizeof(*tlv) + sizeof(*cmd);
+   skb = ath10k_wmi_alloc_skb(ar, len);
+   if (!skb)
+   return ERR_PTR(-ENOMEM);
+
+   ptr = (void *)skb->data;
+   tlv = ptr;
+   tlv->tag = __cpu_to_le16(WMI_TLV_TAG_STRUCT_VDEV_SPECTRAL_ENABLE_CMD);
+   tlv->len = __cpu_to_le16(sizeof(*cmd));
+   cmd = (void *)tlv->value;
+   cmd->vdev_id = __cpu_to_le32(vdev_id);
+   cmd->trigger_cmd = __cpu_to_le32(trigger);
+   cmd->enable_cmd = __cpu_to_le32(enable);
+
+   return skb;
+}
+
 //
 /* TLV mappings */
 //
@@ -3542,6 +3612,8 @@ static const struct wmi_ops wmi_tlv_ops = {
.fw_stats_fill = ath10k_wmi_main_op_fw_stats_fill,
.get_vdev_subtype = ath10k_wmi_op_get_vdev_subtype,
.gen_echo = ath10k_wmi_tlv_op_gen_echo,
+   .gen_vdev_spectral_conf = ath10k_wmi_tlv_op_gen_vdev_spectral_conf,
+   .gen_vdev_spectral_enable = ath10k_wmi_tlv_op_gen_vdev_spectral_enable,
 };
 
 static const struct wmi_peer_flags_map wmi_tlv_peer_flags_map = {
-- 
2.1.4


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

[PATCH] ath10k: fix null deref on wmi-tlv when trying spectral scan

[Michal Kazior]

WMI ops wrappers did not properly check for null
function pointers for spectral scan. This caused
null dereference crash with WMI-TLV based firmware
which doesn't implement spectral scan.

The crash could be triggered with:

  ip link set dev wlan0 up
  echo background > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl

The crash looked like this:

  [  168.031989] BUG: unable to handle kernel NULL pointer dereference at   
(null)
  [  168.037406] IP: [<  (null)>]   (null)
  [  168.040395] PGD cdd4067 PUD fa0f067 PMD 0
  [  168.043303] Oops: 0010 [#1] SMP
  [  168.045377] Modules linked in: ath10k_pci(O) ath10k_core(O) ath mac80211 
cfg80211 [last unloaded: cfg80211]
  [  168.051560] CPU: 1 PID: 1380 Comm: bash Tainted: GW  O4.8.0 #78
  [  168.054336] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
  [  168.059183] task: 88000c460c00 task.stack: 88000d4bc000
  [  168.061736] RIP: 0010:[<>]  [<  (null)>]   
(null)
  ...
  [  168.100620] Call Trace:
  [  168.101910]  [] ? ath10k_spectral_scan_config+0x96/0x200 
[ath10k_core]
  [  168.104871]  [] ? filemap_fault+0xb2/0x4a0
  [  168.106696]  [] write_file_spec_scan_ctl+0x116/0x280 
[ath10k_core]
  [  168.109618]  [] full_proxy_write+0x51/0x80
  [  168.111443]  [] __vfs_write+0x28/0x120
  [  168.113090]  [] ? security_file_permission+0x3d/0xc0
  [  168.114932]  [] ? percpu_down_read+0x12/0x60
  [  168.116680]  [] vfs_write+0xb8/0x1a0
  [  168.118293]  [] SyS_write+0x46/0xa0
  [  168.119912]  [] entry_SYSCALL_64_fastpath+0x1a/0xa4
  [  168.121737] Code:  Bad RIP value.
  [  168.123318] RIP  [<  (null)>]   (null)

Signed-off-by: Michal Kazior <michal.kaz...@tieto.com>
---
 drivers/net/wireless/ath/ath10k/wmi-ops.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h 
b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index c9a8bb1186f2..c7956e181f80 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -660,6 +660,9 @@ ath10k_wmi_vdev_spectral_conf(struct ath10k *ar,
struct sk_buff *skb;
u32 cmd_id;
 
+   if (!ar->wmi.ops->gen_vdev_spectral_conf)
+   return -EOPNOTSUPP;
+
skb = ar->wmi.ops->gen_vdev_spectral_conf(ar, arg);
if (IS_ERR(skb))
return PTR_ERR(skb);
@@ -675,6 +678,9 @@ ath10k_wmi_vdev_spectral_enable(struct ath10k *ar, u32 
vdev_id, u32 trigger,
struct sk_buff *skb;
u32 cmd_id;
 
+   if (!ar->wmi.ops->gen_vdev_spectral_enable)
+   return -EOPNOTSUPP;
+
skb = ar->wmi.ops->gen_vdev_spectral_enable(ar, vdev_id, trigger,
enable);
if (IS_ERR(skb))
-- 
2.1.4


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

Re: Connection problems with Qualcomm Atheros QCA6174

[Michal Kazior]

On 13 November 2016 at 06:57, Henrý Þór Baldursson
 wrote:
> Hello
>
> I have a Lenovo Ideapad Yoga 910 running Athergos, kernel version 4.8.7.
>
> My problem is that intermittently my wifi will just grind to a halt
> and even stop working.
>
> The driver reports the firmware as being WLAN.RM.2.0-00180-QCARMSWPZ-1
>
> Here's the initialization in dmesg:
>
> [1.900033] ath10k_pci :01:00.0: pci irq msi oper_irq_mode 2
> irq_mode 0 reset_mode 0
> [2.173039] ath10k_pci :01:00.0: Direct firmware load for
> ath10k/pre-cal-pci-:01:00.0.bin failed with error -2
> [2.173054] ath10k_pci :01:00.0: Direct firmware load for
> ath10k/cal-pci-:01:00.0.bin failed with error -2
> [2.174217] ath10k_pci :01:00.0: Direct firmware load for
> ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2
> [2.174218] ath10k_pci :01:00.0: could not fetch firmware file
> 'ath10k/QCA6174/hw3.0/firmware-5.bin': -2
> [2.175485] ath10k_pci :01:00.0: qca6174 hw3.2 target
> 0x0503 chip_id 0x00340aff sub 17aa:0827
> [2.175487] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1
> tracing 0 dfs 0 testmode 0
> [2.175876] ath10k_pci :01:00.0: firmware ver
> WLAN.RM.2.0-00180-QCARMSWPZ-1 api 4 features
> wowlan,ignore-otp,no-4addr-pad crc32 75dee6c5
> [2.240312] ath10k_pci :01:00.0: board_file api 2 bmi_id N/A
> crc32 6fc88fe7
> [4.405741] ath10k_pci :01:00.0: htt-ver 3.26 wmi-op 4 htt-op 3
> cal otp max-sta 32 raw 0 hwcrypto 1
> [4.485362] ath10k_pci :01:00.0 wlp1s0: renamed from wlan0
>
>
> Here's what dmesg shows during the errors:
>
> [ 1238.710899] pcieport :00:1c.0: AER: Corrected error received: id=00e0
> [ 1238.710920] pcieport :00:1c.0: PCIe Bus Error:
> severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
> [ 1238.710935] pcieport :00:1c.0:   device [8086:9d14] error
> status/mask=1000/
> [ 1238.710945] pcieport :00:1c.0:[12] Replay Timer Timeout
> [ 1243.855456] pcieport :00:1c.0: AER: Corrected error received: id=00e0
> [ 1243.855472] pcieport :00:1c.0: PCIe Bus Error:
> severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
> [ 1243.855484] pcieport :00:1c.0:   device [8086:9d14] error
> status/mask=1000/
> [ 1243.855491] pcieport :00:1c.0:[12] Replay Timer Timeout
> [ 1296.095437] pcieport :00:1c.0: AER: Corrected error received: id=00e0
> [ 1296.095452] pcieport :00:1c.0: PCIe Bus Error:
> severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
> [ 1296.095464] pcieport :00:1c.0:   device [8086:9d14] error
> status/mask=1000/
> [ 1296.095472] pcieport :00:1c.0:[12] Replay Timer Timeout
> [ 1305.877547] pcieport :00:1c.0: AER: Corrected error received: id=00e0
> [ 1305.877562] pcieport :00:1c.0: PCIe Bus Error:
> severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
> [ 1305.877574] pcieport :00:1c.0:   device [8086:9d14] error
> status/mask=1000/
> [ 1305.877581] pcieport :00:1c.0:[12] Replay Timer Timeout
> [ 1556.596092] pcieport :00:1c.0: AER: Corrected error received: id=00e0
> [ 1556.596107] pcieport :00:1c.0: PCIe Bus Error:
> severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
> [ 1556.596115] pcieport :00:1c.0:   device [8086:9d14] error
> status/mask=1000/
> [ 1556.596122] pcieport :00:1c.0:[12] Replay Timer Timeout
> [ 1612.764108] pcieport :00:1c.0: AER: Corrected error received: id=00e0
> [ 1612.764124] pcieport :00:1c.0: PCIe Bus Error:
> severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
> [ 1612.764135] pcieport :00:1c.0:   device [8086:9d14] error
> status/mask=1000/
> [ 1612.764143] pcieport :00:1c.0:[12] Replay Timer Timeout

Can you try to override ar_pci->pci_ps to false in ath10k_pci_probe()
and see if it helps? Something along the diff:

--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3236,7 +3236,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
ar_pci->dev = >dev;
ar_pci->ar = ar;
ar->dev_id = pci_dev->device;
-   ar_pci->pci_ps = pci_ps;
+   ar_pci->pci_ps = false;
ar_pci->bus_ops = _pci_bus_ops;
ar_pci->pci_soft_reset = pci_soft_reset;
ar_pci->pci_hard_reset = pci_hard_reset;

Another thing which could be happening is ACPI S0ix states which - to
the best of my knowledge - Linux does not support. I've seen at least
i915 not being able to wake-up DSI displays properly when S0ix states
are enabled on some 10 inch 2-in-1 devices. I wouldn't be surprised if
other PCI-E (such as wifi/network devices) can be affected adversely
as well.

Therefore, can you check UEFI/BIOS (you may need to enable "expert
settings") if there are any mentions about S0x or S0ix ACPI modes
there and - if found - try disabling them and checking back 

Re: Getting ATH10K to work with Linksys WUSB6100M

[Michal Kazior]

On 11 November 2016 at 00:56, Johan Lindström
 wrote:
> This device is running  QCA9377 chipset with the usb.id 13b1:0042
>
> Any ideas on how to add this device to the working devices? Does ath10k even 
> work with USB devices?
>
> See info: http://askubuntu.com/questions/799104/linksys-wusb6100m

USB transport is not implemented in ath10k. Adding it will require a
slight HTC/HTT rework and implementing the transport code itself. I'm
pretty sure qcacld[1] can used as reference.

[1]: 
https://github.com/sktjdgns1189/qcacld-2.0/tree/master/CORE/SERVICES/HIF/USB


Michał

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

Re: Connection Problems with on QCA9880-BR4A

[Michal Kazior]

On 11 November 2016 at 13:07, Felix  wrote:
> Hello,
>
> I am running a Debian Jessie server on the backports kernel
> 4.7.0-0.bpo.1-amd64. An Ubiquiti SR71 with its AR928X is working just fine
> under ath9k.
>
> The mikrotik R11e-5HacT with its  QCA9880-BR4A is recognized after some
> errors trying to load inexistent files with the standard firmware-5.bin from
> the Jessie Backports (10.2.4.70.54):
> ...ath10k_pci :02:00.0: firmware: failed to load
> ath10k/pre-cal-pci-:02:00.0.bin (-2)
> ...ath10k_pci :02:00.0: Direct firmware load for
> ath10k/pre-cal-pci-:02:00.0.bin failed with error -2
> ...ath10k_pci :02:00.0: firmware: failed to load
> ath10k/cal-pci-:02:00.0.bin (-2)
> ...ath10k_pci :02:00.0: Direct firmware load for
> ath10k/cal-pci-:02:00.0.bin failed with error -2
> ...ath10k_pci :02:00.0: firmware: failed to load
> ath10k/QCA988X/hw2.0/board-2.bin (-2)
> ...ath10k_pci :02:00.0: Direct firmware load for
> ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
> There are many reports on working devices with these errors on the web so I
> suppose they can be ignored.

Correct. These are just overly verbose messages from the kernel as
ath10k probes latest-to-oldest firmware files in fallback fashion.


> The device seems to work (iw scan shows better results than the SR71), but
> after connection to the AP via wpa_supplicant, dhclient is unable to
> retrieve an IP-adress.

Did you check tcpdump on the interface to see if it is getting any
traffic? Did you try ping6 ff02::1%wlanX ? Are you using WPA, WEP,
8021X? VLANs? 4addr mode?


> I have tried the newer firmware (10.2.4.70.58) and
> the older ones as well as those from candela without success. On older
> firmwares additional errors up to firmware crash on iw set bitrates appear.

Interesting. Are you using multiple interfaces on ath10k? Is the
interface you're running "set bitrates" on really associated?

What is the AP saying about the client association state? Is it
running hostapd? Does it receive any traffic from the client
(tcpdump)?


Michał

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

Re: QCA988X firmware crash when sending in monitor mode

[Michal Kazior]

On 7 November 2016 at 15:22, Ouri Lipner  wrote:
> Hi all,
> I’m consistently encountering issues with raw wifi packet injection.
>
> Sending a raw packet in monitor mode keeps crashing the firmware.
> This happens consistently with every firmware that supports raw mode.
> Currently on kernel 4.9-rc2 but older drivers behave the same.
> Is this an issues with a missing parameter (e.g. in RadioTap) or a real 
> problem with the firmware?

To the best of my knowledge firmware does not support frame injection
on monitor vdev. Therefore this is expected. Moreover this limitation
is mentioned on ath10k wiki:
https://wireless.wiki.kernel.org/en/users/drivers/ath10k


> Any ideas?

You could probably hack up the driver to create and use AP or STA vdev
alongside monitor vdev to use it's vdev_id for frame injection. I'm
not aware of anyone trying that out so far though.


Michał

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

Re: Re[2]: Linux freezes after a time while running

[Michal Kazior]

On 7 November 2016 at 06:38, Conrad Kostecki <ck+ath...@bl4ckb0x.de> wrote:
> Hello Michal,
>
>> Michal Kazior <michal.kaz...@tieto.com> hat am 2. November 2016 um 16:27 
>> geschrieben:
>
>> Were the cards working with this particular microATX mainboard before though?
>
> i was now able to borrow a Soekris net6501, the same model, which I used to 
> have. I've now inserted there also those two Compex cards.
>
> Interestingly, it's not working. The Soekris net6501 shows the same behavior. 
> After a WiFi client connects, atk10k firmware crashed. As this mainboard does 
> not have AER, I can't see the exact cause.
>
> But what I can say, my Soekris net6501, which I used to have, was for years 
> working fine, before it started to freeze. As the same now happens with my 
> borrowed Soekris net6501 (It does not freeze with reboot_mode=1), I am 
> unsure, if this is really a hardware problem.. maybe you have a clou?

I assume you used a different kernel in the past compared to the
recent test you did. You could try re-testing the older kernel
(assuming you remember which one it was) and if it works you could
bisect your way to find the commit that breaks it for you.


Michal

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

Re: Re[2]: Linux freezes after a time while running

[Michal Kazior]

On 2 November 2016 at 10:00, Conrad Kostecki <ck+ath...@bl4ckb0x.de> wrote:
> Hi!
>
>> Michal Kazior <michal.kaz...@tieto.com> hat am 2. November 2016 um 04:31 
>> geschrieben:
>> I suspect the pcie link gets broken one direction because attempting a
>> cold reset did crash the host even harder.
>
> What I can see, the WiFi runs stable, if nobody connects to it. The failure 
> starts, when somebody connects and does some throughput.
>
>> Looks like the device went into a very confused state due to pcie link
>> failure starting from:
>
> Well, I did a test and removed the Mikrotik RB14e, as it has a PLX chip and 
> provides an extra pcie switch. Instead, I took a simple passive 
> miniPCIe->PCIe adapter and build only one card into it. The problem still 
> exists. So, the RB14e is not the cause at least.
>
>>   [ 691.609836] pcieport :00:02.0: AER: Multiple Uncorrected
>> (Non-Fatal) error received: id=0800
>
> I see, so the firmware crash it not the cause, but the error reported by AER. 
> Thanks for clarify!
>
>> I'm not really familiar with these. Perhaps there's a pcie bridge
>> problem on your host platform or maybe an electrical issue (e.g.
>> insufficient power supply to handle short bursts?).
>
> Well, the mainboard is microATX. So its powered by a Seasonic 400W passive 
> PSU, but the whole system takes about 40-50w. So the PSU itself should be 
> enough? ;-) IIRC PCIe should provide up to 75W?
>
> I am out of ideas.. I know, a year ago, that cards were perfectly working. 
> Even a test replacement shows the same errors, so it's not a defective card.

Were the cards working with this particular microATX mainboard before though?

Maybe the adapter is to blame? Or maybe it's a faulty mobo? You could
try reducing txpower of the card with "iw" and see if it makes a
difference.


Michal

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

Re: Re[2]: Linux freezes after a time while running

[Michal Kazior]

On 31 October 2016 at 17:48, Conrad Kostecki <ck+ath...@bl4ckb0x.de> wrote:
> Hello Michał,
>
> Am 31.10.2016 11:12:03, "Michal Kazior" <michal.kaz...@tieto.com> schrieb:
>
>>  You could try loading ath10k_pci with reset_mode=1 parameter.
>>
>> Cold reset is known to cause some problems after firmware certain
>> crashes and I've personally experienced system freezes on x86 (MIPS
>> tends to spit "data bus error" and doesn't lock up).
>
> thank you very much for your answer. I've now set reset_mode=1,
> which seems to be now active, as I can see in dmesg:
> [8.471659] ath10k_pci :08:00.0: pci irq msi oper_irq_mode 2 irq_mode
> 0 reset_mode 1
> [8.587267] ath10k_pci :09:00.0: pci irq msi oper_irq_mode 2 irq_mode
> 0 reset_mode 1
>
> After starting HostAPd, I powered up my Squeezebox Radio to connect via
> WiFi.
> Just after a few minutes, it crashed, as expected, but it did not restart
> the whole server.
> It this due reset_mode=1? I was now able to capture a lot of information
> from dmesg.
> You can clearly see, that the firmware crashed. The HostAPd process is still
> running,
> but the WiFi can be detected anymore.
>
> As it's very much, I've put this on pastebin: http://pastebin.com/83WZktp6
>
> You can see at mark 250, WiFi1 (2.4GHz) comes up and at mark 356 WIFI2
> (5GHz) comes up.
> By mark 691, ath10k_pci crashed and WiFi stopped working. Normally, at this
> point the whole server would reboot.
>
> I've also now tried the newest firmware 10.2.4.70.58 which nuso luck.
>
> Any Ideas?

The driver is unable to retrieve register dump and there's a lot of
failures happening. This doesn't look like a firmware crash per se.
More like device failure caused by host refusing pcie access or
something (very similar to when x86 iommu refuses dma access on
use-after-free) being reported as one (target cpu catches the fault,
runs the handler which is treated as an uncaught assert and is
reported to host same way an assert would, but with a different
register dump).

I suspect the pcie link gets broken one direction because attempting a
cold reset did crash the host even harder.

Looks like the device went into a very confused state due to pcie link
failure starting from:

  [  691.609836] pcieport :00:02.0: AER: Multiple Uncorrected
(Non-Fatal) error received: id=0800

I'm not really familiar with these. Perhaps there's a pcie bridge
problem on your host platform or maybe an electrical issue (e.g.
insufficient power supply to handle short bursts?).


Michal

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

Re: Question on 10.4 firmware and fetch-indication logic.

[Michal Kazior]

On 1 November 2016 at 19:12, Adrian Chadd  wrote:
> On 1 November 2016 at 11:04, Ben Greear  wrote:
>
>>
>> I do not know the code well around the fetch-ind logic:  This is how the
>> firmware tells the driver that it has fully transmitted a frame and is
>> reporting
>> tx status?  Can it be anything else?
>
> Isn't this the newish stuff added so per-peer queues can be managed and 
> drained?

Yes. 10.4 can support operational mode where it doesn't expect host to
be pushing frames at its own discretion and instead issues
fetch-indication events to ask host to submit frames from given
station/tid within given packet/byte constraints.

After looking at the code I guess this could happen because
tx_fetch_ind_q is processed in a separate tasklet. You'd probably need
to flush the tasklet/event queues to prevent this problem from
happening.


Michał

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

Re: Question on 10.4 firmware and fetch-indication logic.

[Michal Kazior]

On 1 November 2016 at 18:21, Ben Greear  wrote:
> I am testing on modified 4.7 kernel and modified firmware with QCA9984 NIC
> and lots of virtual station vdevs.
>
> The issue I am looking at currently is that I am seeing floods of these
> messages
> in some cases:
>
> Nov 01 09:43:38 ath-9984 kernel: ath10k_pci :05:00.0: fetch-ind: failed
> to lookup txq for peer_id 56 tid 7
> Nov 01 09:43:38 ath-9984 kernel: ath10k_pci :05:00.0: fetch-ind: failed
> to lookup txq for peer_id 56 tid 7
> Nov 01 09:43:38 ath-9984 kernel: ath10k_pci :05:00.0: fetch-ind: failed
> to lookup txq for peer_id 56 tid 7
> Nov 01 09:43:38 ath-9984 kernel: ath10k_pci :05:00.0: fetch-ind: failed
> to lookup txq for peer_id 56 tid 7
>
> From this code in htt_rx.c:
>
> static void ath10k_htt_rx_tx_fetch_ind(struct ath10k *ar, struct sk_buff
> *skb)
> ...
>
> /* It is okay to release the lock and use txq because RCU
> read
>  * lock is held.
>  */
>
> if (unlikely(!txq)) {
> if (net_ratelimit())
> ath10k_warn(ar, "fetch-ind: failed to lookup
> txq for peer_id %hu tid %hhu\n",
> peer_id, tid);
> continue;
> }
>
>
> I am getting these after the vdev in question (and its peers) have been
> removed.  I guess these
> must be stale buffers that are finally transmitted or cleaned up by the
> firmware after
> vdev has been deleted?
>
> I am curious if anyone else sees something similar, and if this is expected
> behaviour.

Hmm, WMI and HTT do use independent CE ring buffers but peer_ids are
unmapped in response to HTT events so it should be properly serialized
by firmware itself.

Did you happen to not remove peers prior to deleting vdev? Perhaps
that's the cause that triggers the !txq condition.

Perhaps it would make sense to flush (i.e. put up a barrier) HTT rx
after stopping vdev.


Michał

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

Re: Linux freezes after a time while running

[Michal Kazior]

On 28 October 2016 at 21:05, Conrad Kostecki  wrote:
> Hi!
> In order to create a dual band AP, I've bought two Compex LE900VX cards.
> As the mainboard has only one PCIe slot, I also bought a Mikrotik RB14e 
> miniPCIe->PCIe adapter, which can carry up to 4 miniPCIe cards.
>
> Currently, I am running HostAPd 2.6 and Kernel 4.8.4 with 10.2.4.70.56 
> ath10k-firmware.
> Both cards are being detected fine and working.
>
> When I do start HostAPd, the whole server just freezes after a time, usally 
> after 30-120 minutes. Until it freezes, HostAPd is working perfectly fine. 
> When I do not start HostAPd, no freeze occurs and the whole system is running 
> stable.
>
> No errors were logged in dmesg.
>
> Any Ideas, how to debug this?
> Are the cards maybe faulty?
> I already asked on the HostAPd-mailinglist and was asked, to ask here ;-)

You could try loading ath10k_pci with reset_mode=1 parameter.

Cold reset is known to cause some problems after firmware certain
crashes and I've personally experienced system freezes on x86 (MIPS
tends to spit "data bus error" and doesn't lock up).


Michał

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

Re: qca6174 missing firmware or subsystem id?

[Michal Kazior]

On 14 October 2016 at 10:05, Jiří Prchal  wrote:
[...]
>> What channel is your AP in? Are there multiple APs in the area? This
>> could be also a channel problem, 'iw list' helps to investigate that (or
>> changing the channel on AP).
>>
>
> As I wrote the problem was channel. However it should work cause I set
> country to CZ.
> May be I should open new thread?

You typically need to do an intersection between 2 regulatory domains:
the one that the chip was certified/calibrated (baked into eeprom)
against and the one of your system (which is supposed to be tied to
your current geolocation).

If the chip's eeprom implies you can't use ch13 and your system says
you can then you still can't use ch13.

`iw list` will output list of channels that are available and their
flags (e.g. "disabled", or "no-ir").


Michał

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

Re: ath10k: about packet injection

[Michal Kazior]

On 6 October 2016 at 04:11, Xuebing Wang <xbi...@gmail.com> wrote:
> On 2016年09月19日 19:13, Michal Kazior wrote:
>>
>> On 19 September 2016 at 01:27, Xuebing Wang <xbi...@gmail.com> wrote:
>>>
>>> Hi Community,
>>>
>>> ath10k wiki says packet injection isn't supported yet. Is it difficult to
>>> add packet injection for chip like QCA6174 hw 2.1 in Killer 1525? Thanks.
>>
>> This would require some tricks:
>>   - monitor vdev can't tx so you'll need other vdev type allocated
>> side-by-sdie
>>   - tx often may require peer entries (see offchan code in mac.c)
>>   - getting raw mode to work may be a problem and may require some
>> length-encoding hacks
>>   - injecting protected (software encrypted) frames might be a problem
>>
>> Either way you're at the mercy of firmware blob :)
>>
>>
>> Michal
>
> Hi Michal,
>
> It seems QCA6174A hw2.1 firmware-5 does not support rawmode, dmesg shows
> firmware features "ignore-otp,no-4addr-pad". Is rawmode necessary for packet
> injection Tx? Thanks.

It's not strictly necessary if you want to hack it up. Raw tx encap
will be very likely (at least) borked as far as offsets/lengths are
concerned and some hacks/workarounds will be necessary to make it send
out correct frames on the air.


Michal

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

Re: Beacon sending information

[Michal Kazior]

On 3 October 2016 at 15:47, Ricardo Santos  wrote:
> Hi,
>
> I recently started to go through the ath10k driver and mac80211 source to 
> understand where events happen in the code. Currently I'm trying to find 
> where the beacon
> generation and their tx is being handled, but so far without being 
> successful. Can anyone indicate me where I can find that?

There are 2 designs:
 - one where FW generates SWBA event for each beacon (see ath10k's wmi.c),
 - the other uploads beacon template (look for TMPL_CMDID in ath10k)
when starting.

Both call ieee80211_beacon_get().


Michał

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

Re: [PATCH] ath10k: cache calibration data when the core is stopped.

[Michal Kazior]

On 13 September 2016 at 23:11, Marty Faltesek  wrote:
[...]
> +int
> +ath10k_cal_data_alloc(struct ath10k *ar, void **buf)
> +{
> +   u32 hi_addr;
> +   __le32 addr;
> +   int ret;
> +
> +   vfree(*buf);
> +   *buf = vmalloc(QCA988X_CAL_DATA_LEN);

Shouldn't you use ar->hw_params to get hw-specific caldata length?


[...]
> @@ -1714,6 +1750,12 @@ int ath10k_core_start(struct ath10k *ar, enum 
> ath10k_firmware_mode mode)
>
> INIT_LIST_HEAD(>arvifs);
>
> +   /*
> +* We are up now, so no need to cache calibration data.
> +*/

The comment style is:

 /* comment */

If it's multi-line it should be:

 /* comment
  * comment
  */

Ditto for other instances.


[...]
> @@ -1757,6 +1799,11 @@ void ath10k_core_stop(struct ath10k *ar)
> lockdep_assert_held(>conf_mutex);
> ath10k_debug_stop(ar);
>
> +   /*
> +* Cache caclibration data while stopped.

typo. "calibration"


Michał

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

Re: ath10k: about packet injection

[Michal Kazior]

On 19 September 2016 at 01:27, Xuebing Wang  wrote:
> Hi Community,
>
> ath10k wiki says packet injection isn't supported yet. Is it difficult to
> add packet injection for chip like QCA6174 hw 2.1 in Killer 1525? Thanks.

This would require some tricks:
 - monitor vdev can't tx so you'll need other vdev type allocated side-by-sdie
 - tx often may require peer entries (see offchan code in mac.c)
 - getting raw mode to work may be a problem and may require some
length-encoding hacks
 - injecting protected (software encrypted) frames might be a problem

Either way you're at the mercy of firmware blob :)


Michal

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

Re: [PATCH 4/4] ath10k: fix spurious tx/rx during boot

[Michal Kazior]

On 17 September 2016 at 00:37, Hsu, Ryan  wrote:
[...]
>> + /* WMI and HTT may use separate HIF pipes and are not guaranteed to be
>> +  * serialized properly implicitly.
>> +  *
>> +  * Moreover (most) WMI commands have no explicit acknowledges. It is
>> +  * possible to infer it implicitly by poking firmware with echo
>> +  * command - getting a reply means all preceding comments have been
>> +  * (mostly) processed.
>> +  *
>> +  * In case of vdev create/delete this is sufficient.
>> +  *
>> +  * Without this it's possible to end up with a race when HTT Rx ring is
>> +  * started before vdev create/delete hack is complete allowing a short
>> +  * window of opportunity to receive (and Tx ACK) a bunch of frames.
>> +  */
>> + ret = ath10k_wmi_barrier(ar);
> QCA6174 UTF firmware seems doesn't support the WMI_ECHO command.
>
> [16460.274822] ath10k_pci :04:00.0: wmi tlv echo value 0x0ba991e9
> ...
> [16463.461970] ath10k_pci :04:00.0: failed to ping firmware: -110
> [16463.461975] ath10k_pci :04:00.0: failed to reset rx filter: -110
>
> Has anyone verified any AP solution to see if UTF mode is still working
> with after this patch?
>
> Anyway, I would like to exclude the workaround from all solution's UTF mode.
>
> Michal any concerns? (or maybe just for QCA61x4 if any...)

I didn't expect UTF wouldn't support echo.. Sorry!

If you skip this workaround for UTF I guess the device will (again) be
able to generate some bogus traffic on boot for UTF case. Not sure how
much of a problem that is (assuming it is at all).


Michal

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

Re: accessing ath10k calibration data

[Michal Kazior]

On 15 September 2016 at 01:54, Marty Faltesek  wrote:
> I sent out the patch.
>
> I ran into another related issue. Let me explain what we are trying to do:
>
> We want to examine cal_data for a possibly mis-calibrated OTP, and if
> so, patch it and store
> the result in /tmp (creating a symlink from
> /ilb/firmware/ath10k/cal-pci-0001:01:00.0.bin to /tmp).
>
> But ath10k_fetch_cal_file() is only read once at load time, so I've
> modified the code to call this function from
> ath10k_download_cal_file()
> so that the driver catches the modified cal_data. This seems to work
> based on the read back of the patched cal_data, but is it the right
> approach, or is there a better or cleaner way?

The reason why firmware files (including cal, et al) in memory is to
guarantee firmware reloads result in the same set of hw capabilities
which can be advertised during mac80211 register time. Changing them
in runtime is not really clean.

I don't really have a clean answer for you.

Do you really need to keep given driver instance running without
interruption? At what point do you verify caldata? If it's before
upping interfaces you could either unload/load the driver or
unbind/bind the device itself to force it to read firmware files anew.


Michał

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

Re: accessing ath10k calibration data

[Michal Kazior]

On 9 September 2016 at 19:42, Marty Faltesek  wrote:
> It's blocked by the code below which I tried to ifdef out, but then it
> returns all 0's.
>
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c
> b/drivers/net/wireless/ath/ath10k/debug.c
> index 8b01e3e..bb8b7ec 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -1433,12 +1433,13 @@ static int ath10k_debug_cal_data_open(struct
> inode *inode, struct file *file)
> int ret;
>
> mutex_lock(>conf_mutex);
> -
> +#if 0
> if (ar->state != ATH10K_STATE_ON &&
> ar->state != ATH10K_STATE_UTF) {
> ret = -ENETDOWN;
> goto err;
> }
> +#endif

This won't work. The driver needs to go through ath10k_start(), i.e.
firmware must be loaded. Cal data is cooked as part of that.

You could get away with just `ifconfig wlan0 up`. You don't need to
connect or anything.

I guess the driver *could* cache the end resulting cal data when the
device is probed and re-use it in subsequent firmware boot-up attempts
(instead of re-computing it) making it available when the device is
stopped as well. Any volunteers to try *and* test if it doesn't break
anything? :)


> On Fri, Sep 9, 2016 at 1:39 PM, Adrian Chadd  wrote:
>> Hi,
>>
>> It's just in OTP? You should be able to read the OTP data without
>> needing a STA/AP up?

I would argue with the "just OTP" at least from the driver-device
protocol point of view.


Michał

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

Re: Ath10k probe response error related to mac80211 commit.

[Michal Kazior]

On 1 September 2016 at 22:52, Ben Greear  wrote:
> On 09/01/2016 11:53 AM, Johannes Berg wrote:
>> On Thu, 2016-09-01 at 11:23 -0700, Ben Greear wrote:
>>>
>>> Could easily be that others are corrupted too, but since probe resp
>>> is bad, the association will not proceed.
>>
>> makes sense.
>>
>>> Heh, I spent 4 days tracking this down, so I wanted to be precise in
>>> my bug report :)
>>
>> Ahrg, ouch. Sorry about that. I really didn't think the flag would
>> cause any issues for anyone.
>>
>>> The result I see is that there is an extra 10 bytes at the end of the
>>> frame on air.  But, it looks like the exact same pkt is sent to the
>>> firmware both with and without this patch.  Maybe the firmware is
>>> using the wrong tid or something like that due to how the station is
>>> created differently with this patch.
>>
>> That makes no sense though, unless this only happens on say the second
>> station that connects? Until the first station sends an authentication
>> frame, that patch really should have no impact whatsoever.
>
> Ok, I found the problem.
>
> In the 10.1 firmware (at least), it will force the TID to be NON-QOS-TID
> if the peer object does not have the qos_enabled flag set.  This is probably
> a work-around for some other thing lost in antiquity.
>
> When using my firmware that puts mgt frames over HTT, the TID for mgt
> frames was being over-ridden and set to non-qos TID.  Due to other
> hackery and work-arounds, mgt frames cannot be sent on the non-qos
> TID because they will be put on-air 10 bytes too long.  They must be
> sent on the mgt-tid or non-pause tid.

Sounds like 802.11 header vs 802.3 header length problem (24 - 14 =
10). You can hit this if you start playing around tx encap mode as
well.

You could try fooling firmware into thinking the frame has a different
length either in htt TX_FRM or tx fragment list (or both) but since
this seems to be related to RA/DA peer state at xmit time it's
probably not going to be reliable unless you introduce extra tx
flushing barriers in the driver.


Michał

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

Re: Questions for ath10k rate control, bandwidth, and channel sensing

[Michal Kazior]

On 26 August 2016 at 11:00, Changmok Yang  wrote:
> Hi.
> We are trying to change transmission bandwidth and data rate.
>
> 1. We found that we can only control per-station channel width, and
> rate control, like Minstrel, is not controlled by ath10k and in
> firmware. Then, can ath10k select the transmission data rate manually?
> If so, how? We cannot find the part the data rate is determined.

It's possible to re-program given station's ratemask or you can force
a global tx rate. See set_bitrate_mask implementation in ath10k for
details.


> 2. Is it possible to change operating bandwidth per station while
> maintaining association?

Yes, either via wmi_peer_assoc command or via set_peer_param command
and one of peer_param attributes (chwidth). This stuff is mostly
upper-cased as far as naming is concerned.


> 3. We also want to use parameters related to channel sensing. Although
> we found that CCA related parameters are in firmware, we alternatively
> want to use parameters related to Ethtool in survey_info structure (in
> include/net/cfg80211.h, the structure below). However, when we read
> this variable in the log after Ethtrool running, the value does not
> seem to reflect channel sensing. Where and how can we use channel
> sensing parameters in ath10k? Is it possible?

CCA thresholds would need to be overwritten by ath10k after each hw
reset / channel change I think. You could probably look at the
coverage_class work Benjamin and Sebastian have been doing recently as
you'd need to do something similar.

As for survey: some recent firmware builds supposedly have a on-bss
64-bit survey events. Not sure about the details though.

Actual cycle counters used to generate/maintain survey data can be
found at wlan_mac_base (0x2) + same offsets as ath9k. FWIW You can
even read them from userspace via /dev/mem + mmap() (it'll be a bit
racy though; freezing mib counters is not a good idea with firmware
running concurrently).


Michał

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

Re: [PATCH 4/4] ath10k: fix spurious tx/rx during boot

[Michal Kazior]

On 24 August 2016 at 19:20, Ben Greear <gree...@candelatech.com> wrote:
> On 07/19/2016 03:34 AM, Michal Kazior wrote:
>>
>> HW Rx filters and masks are not configured
>> properly by firmware during boot sequences. The
>> MAC_PCU_ADDR1 is set to 0s instead of 1s which
>> allows the HW to ACK any frame that passes through
>> MAC_PCU_RX_FILTER. The MAC_PCU_RX_FILTER itself
>> is misconfigured on boot as well.
>>
>> The combination of these bugs ended up with the
>> following manifestations:
>>  - "no channel configured; ignoring frame(s)!"
>>warnings in the driver
>>  - spurious ACKs (transmission) on the air during
>>firmware bootup sequences
>>
>> The former was a long standing and known bug
>> originally though mostly harmless.
>>
>> However Marek recently discovered that this
>> problem also involves ACKing *all* frames the HW
>> receives (including beacons ;). Such frames
>> are delivered to host and generate the former
>> warning as well.
>>
>> This could be a problem with regulatory compliance
>> in some rare cases (e.g. Taiwan which forbids
>> transmissions on channel 36 which is the default
>> bootup channel on 5Ghz band cards). The good news
>> is that it'd require someone else to violate
>> regulatory first to coerce our device to generate
>> and transmit an ACK.
>>
>> The problem could be reproduced in a rather busy
>> environment that has a lot of APs. The likelihood
>> could be increased by injecting an msleep() of
>> 5000 or longer immediately after
>> ath10k_htt_setup() in ath10k_core_start().
>>
>> The reason why the former warnings were only
>> showing up seldom is because the device was either
>> quickly reset again (i.e. during firmware probing)
>> or wmi vdev was created (which fixes hw and fw
>> states).
>>
>> It is technically possible for host driver to
>> override adequate hw registers however this can't
>> work reliably because the bug root cause lies in
>> incorrect firmware state on boot (internal
>> structure used to program MAC_PCU_ADDR1 is not
>> properly initialized) and only vdev create/delete
>> events can fix it. This is why the patch takes
>> dummy vdev approach.
>>
>> This could be fixed in firmware as well but having
>> this fixed in driver is more robust, most notably
>> when thinking of users of older firmware such as
>> 999.999.0.636.
>>
>> Reported-by: Marek Puzyniak <marek.puzyn...@tieto.com>
>> Signed-off-by: Michal Kazior <michal.kaz...@tieto.com>
>
>
> I was looking at firmware to make sure that I fixed what I could there
>
> From what I can tell, 10.4 should not have this bug.  Did you see this only
> on 10.1/10.2 firmware?  It is of course possible that I am mis-understanding
> 10.4

I did see it on 10.1 and 10.2. Don't recall seeing it on 10.4 though.
If you didn't see warnings on 10.4 even after adding msleep() as per
commit log then I guess it doesn't suffer from the bug.


Michał

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

Re: ath10k: qca6174 firmware: difference between hw2.1/firmware-5 and hw3.0/firmware-4

[Michal Kazior]

On 24 August 2016 at 05:57, Xuebing Wang  wrote:
> Hi Kalle,
>
> I cloned your ath10k-firmware from your github. Would you please advise what
> are the differences of hw2.1/firmware-5 and hw3.0/firmware-4 for qca6174?
> Does hw3.0/firmware-4 support Monitor Mode?
>
> I have a wlan card with BMI version (QCA6174_HW_2_1_VERSION 0x0501) and
> Monitor Mode works no problem with latest kernel v4.8-rc2.
>
> I have another wlan card with (QCA6174_HW_3_2_VERSION 0x0503). I am
> trying to back-port ath10k from v4.8-rc2 to 3.10.73 for this HW_3_2 QCA6174
> wlan card. Virtual interface (mon0) can be added and brought-up, but tcpdump
> can not capture any packets. I am wondering if it could be related to
> (hw2.1/firmware-5 vs hw3.0/firmware-4)?

Official hw3.x's firmware supports full rx offload. Rx event used to
deliver frames is very specialized effectively preventing sniffing /
monitor operation.

I don't know if there's any way around it without getting your hands
on firmware build that doesn't have the full rx offload compiled in
(assuming such a build even exists).


Michał

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

Re: [PATCH 1/3] ath10k: Ensure there are no stale ar->txqs entries.

[Michal Kazior]

On 19 August 2016 at 03:26,   wrote:
> From: Ben Greear 
>
> 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.
>
> Signed-off-by: Ben Greear 
> ---
>  drivers/net/wireless/ath/ath10k/mac.c | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 5659ef1..916119c 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -4172,8 +4172,10 @@ static void ath10k_mac_txq_init(struct ieee80211_txq 
> *txq)
>  static void ath10k_mac_txq_unref(struct ath10k *ar, struct ieee80211_txq 
> *txq)
>  {
> struct ath10k_txq *artxq = (void *)txq->drv_priv;
> +   struct ath10k_txq *tmp, *walker;
> struct ath10k_skb_cb *cb;
> struct sk_buff *msdu;
> +   struct ieee80211_txq *txq_tmp;
> int msdu_id;
>
> if (!txq)
> @@ -4182,6 +4184,14 @@ static void ath10k_mac_txq_unref(struct ath10k *ar, 
> struct ieee80211_txq *txq)
> spin_lock_bh(>txqs_lock);
> if (!list_empty(>list))
> list_del_init(>list);
> +
> +   /* Remove from ar->txqs in case it still exists there. */
> +   list_for_each_entry_safe(walker, tmp, >txqs, list) {
> +   txq_tmp = container_of((void *)walker, struct ieee80211_txq,
> +  drv_priv);
> +   if (txq_tmp == txq)
> +   list_del(>list);
> +   }

How could this even happen? All artxq->list accesses (add/del) are
protected by txqs_lock so this shouldn't happen, no?

Do you perhaps have the logic around txqs reworked in your tree?


Michał

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

Re: [PATCHv2 2/2] ath10k: Allow setting coverage class

[Michal Kazior]

On 3 August 2016 at 17:37, Sebastian Gottschall  wrote:
>
>>> +   if (value < 0)
>>> +   value = ar->fw_coverage.coverage_class;
>>> +
>>> +   /* Break out if the coverage class and registers have the
>>> expected
>>> +* value.
>>> +*/
>>> +   if (value == ar->fw_coverage.coverage_class &&
>>> +   slottime_reg == ar->fw_coverage.reg_slottime_conf &&
>>> +   timeout_reg == ar->fw_coverage.reg_ack_cts_timeout_conf)
>>> +   goto unlock;
>>
>> I would move this part to the caller and keep the hardware-specific
>> function just compute and set registers, e.g. have
>> ath10k_mac_set_coverage_class (as opposed to
>> ath10k_mac_op_set_coverage_class). It should also reduce some code
>> duplication.
>
> doesnt make sense. i already enhanced this code to support beeliner (99xx)
> and newers.
> the code is that much different that this check need to be treaded in a
> indivudual way
> reg_slottime_conf is hardware defacto specific since the value is taken from
> a hardware specific register.
> you cannot handle this outside this function since other chips have
> different registers.

Ah, you're right, my bad :)


Michał

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

Re: [PATCHv2 2/2] ath10k: Allow setting coverage class

[Michal Kazior]

On 1 August 2016 at 12:21, Benjamin Berg  wrote:
> Unfortunately ath10k does not generally allow modifying the coverage class
> with the stock firmware and Qualcomm has so far refused to implement this
> feature so that it can be properly supported in ath10k. If we however know
> the registers that need to be modified for proper operation with a higher
> coverage class, then we can do these modifications from the driver.
>
> This patch implements this hack for first generation cards which are based
> on a core that is similar to ath9k. The registers are modified in place and
> need to be re-written every time the firmware sets them. To achieve this
> the register status is verified after any WMI event from the firmware.
>
> The coverage class may not be modified temporarily right after the card
> re-initializes the registers. This is for example the case during scanning.
>
> Thanks to Sebastian Gottschall  for initially
> working on a userspace support for this. This patch wouldn't have been
> possible without this documentation.
>
> Signed-off-by: Benjamin Berg 
> Signed-off-by: Simon Wunderlich 
> Signed-off-by: Mathias Kretschmer 
> ---
>  drivers/net/wireless/ath/ath10k/core.h |  10 +++
>  drivers/net/wireless/ath/ath10k/hw.c   | 112 
> +
>  drivers/net/wireless/ath/ath10k/hw.h   |  22 ++-
>  drivers/net/wireless/ath/ath10k/mac.c  |  19 ++
>  drivers/net/wireless/ath/ath10k/wmi.c  |  29 +
>  5 files changed, 191 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.h 
> b/drivers/net/wireless/ath/ath10k/core.h
> index 5ace413..4ae730b 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -890,6 +890,16 @@ struct ath10k {
> struct ath10k_thermal thermal;
> struct ath10k_wow wow;
>
> +   /* protected by data_lock */
> +   struct {
> +   s16 coverage_class;
> +
> +   u32 reg_slottime_conf;
> +   u32 reg_slottime_orig;
> +   u32 reg_ack_cts_timeout_conf;
> +   u32 reg_ack_cts_timeout_orig;
> +   } fw_coverage;
> +
> /* must be last */
> u8 drv_priv[0] __aligned(sizeof(void *));
>  };
> diff --git a/drivers/net/wireless/ath/ath10k/hw.c 
> b/drivers/net/wireless/ath/ath10k/hw.c
> index c2ecb9b..f1278ad 100644
> --- a/drivers/net/wireless/ath/ath10k/hw.c
> +++ b/drivers/net/wireless/ath/ath10k/hw.c
> @@ -17,11 +17,13 @@
>  #include 
>  #include "core.h"
>  #include "hw.h"
> +#include "hif.h"
>
>  const struct ath10k_hw_regs qca988x_regs = {
> .rtc_soc_base_address   = 0x4000,
> .rtc_wmac_base_address  = 0x5000,
> .soc_core_base_address  = 0x9000,
> +   .wlan_mac_base_address  = 0x0002,
> .ce_wrapper_base_address= 0x00057000,
> .ce0_base_address   = 0x00057400,
> .ce1_base_address   = 0x00057800,
> @@ -48,6 +50,7 @@ const struct ath10k_hw_regs qca6174_regs = {
> .rtc_soc_base_address   = 0x0800,
> .rtc_wmac_base_address  = 0x1000,
> .soc_core_base_address  = 0x0003a000,
> +   .wlan_mac_base_address  = 0x0002,
> .ce_wrapper_base_address= 0x00034000,
> .ce0_base_address   = 0x00034400,
> .ce1_base_address   = 0x00034800,
> @@ -74,6 +77,7 @@ const struct ath10k_hw_regs qca99x0_regs = {
> .rtc_soc_base_address   = 0x0008,
> .rtc_wmac_base_address  = 0x,
> .soc_core_base_address  = 0x00082000,
> +   .wlan_mac_base_address  = 0x0003,
> .ce_wrapper_base_address= 0x0004d000,
> .ce0_base_address   = 0x0004a000,
> .ce1_base_address   = 0x0004a400,
> @@ -109,6 +113,7 @@ const struct ath10k_hw_regs qca99x0_regs = {
>  const struct ath10k_hw_regs qca4019_regs = {
> .rtc_soc_base_address   = 0x0008,
> .soc_core_base_address  = 0x00082000,
> +   .wlan_mac_base_address  = 0x0003,
> .ce_wrapper_base_address= 0x0004d000,
> .ce0_base_address   = 0x0004a000,
> .ce1_base_address   = 0x0004a400,
> @@ -220,7 +225,114 @@ void ath10k_hw_fill_survey_time(struct ath10k *ar, 
> struct survey_info *survey,
> survey->time_busy = CCNT_TO_MSEC(ar, rcc);
>  }
>
> +static void ath10k_qca988x_mac_op_set_coverage_class(struct ath10k *ar,
> +s16 value)

The naming is 

Re: [PATCH] ath10k: Allow setting coverage class

[Michal Kazior]

On 29 July 2016 at 17:09, Ben Greear  wrote:
> On 07/29/2016 07:52 AM, Benjamin Berg wrote:
[...]
>> Yeah, I am aware of the fact that the firmware may do internal resets
>> from time to time. The interesting question (and one for which I do not
>> know the answer) is whether we get a wmi or other event under all
>> conditions where the register may be rewritten due to a reset.
>>
>> The current code will re-set the register value after any wmi event
>> including debug messages. If this is not enough, then the only solution
>> might be to periodically poll the register values instead of relying on
>> a received event.
>
> You will get a dbglog event at least most of the time, so maybe that
> will be good enough.

But you need to remember you need to enable dbglog first to get these
events. I guess when coverage class is set the driver could,
internally, override dbglog mask so that these events are guaranteed
to be reported for the purpose of properly refreshing registers on
channel programming.

At that point I guess the update hook could be just placed in dbglog
handler alone instead of all over wmi_rx variants.


Michał

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

Re: ath10k fail to load firmware

[Michal Kazior]

On 2 August 2016 at 14:10, Valo, Kalle <kv...@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kaz...@tieto.com> writes:
>
>> On 19 July 2016 at 09:09, Stanislaw Gruszka <sgrus...@redhat.com> wrote:
>>> Perry from Dell has ath10k device, which do not work with current
>>> linux-firmware. It's on RHEL kernel, however wirelss stack and drivers
>>> are from 4.7-rc1 (I did not update to 4.7 final yet, since I do not see
>>> ath10k fix, which could possibly help here). Partial dmesg is in
>>> the attachment.
>>
>> hw.3 qca6174 chips tend to require very specific board data for proper
>> calibration.
>>
>>   [ 3838.601884] ath10k_pci :01:00.0: failed to fetch board data
>> for 
>> bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,subsystem-device=0310
>> from ath10k/QCA6174/hw3.0/board-2.bin
>>   [ 3838.601920] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A
>> crc32 ed5f849a
>>
>> Your board-2.bin doesn't contain the matching board data and the
>> driver then falls back to the older board API1 which is pretty much
>> doomed to fail on qca6174 hw.3.
>>
>> @Kalle: Perhaps ath10k needs to fail early with an adequate message
>> for qca6174 hw.3 if board API2 lookup fails (e.g. hw_params flag
>> because this seems to be quite closely coupled with hardware itself).
>
> Sounds like a good idea. Or maybe we should always fail when using
> board-2.bin (no matter what hw version is used)? Dunno.

Hmm, failing if no matching entry is found in board-2.bin sounds good
but doesn't cover the case when user doesn't even have board-2.bin in
the first place.

The downside of forcing board-2.bin for qca6174 hw3.2+ would be more
difficult one-shot testing via board.bin (it's easier to copy eeprom*
file from windows driver as board.bin than to re-generate board-2.bin)
- but maybe this isn't really something we should care about so much
to allow board.bin for hw that normally can't work with it.


Michał

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

Re: Use Channel Switch Announcement (CSA) without DFS

[Michal Kazior]

On 28 July 2016 at 00:42, Gaurang Ramesh Naik  wrote:
> Hi All,
>
> Is it possible to use CSA when the AP operates on channel that do not
> require DFS? Can I trigget CSA from the AP in some way?

You can ask hostapd via hostapd_cli to:

 chan_switch 5 5180

This will start CSA with CS count=5 to frequency 5180. If you type
chan_switch without argument I believe you should get help/usage on
the command.


Michał

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

Re: [PATCH 2/4] ath10k: Add provision for Rx descriptor abstraction

[Michal Kazior]

On 27 July 2016 at 14:59, Thiagarajan, Vasanthakumar
<vthia...@qti.qualcomm.com> wrote:
> On Wednesday 27 July 2016 06:13 PM, Michal Kazior wrote:
>> On 27 July 2016 at 14:36, Vasanthakumar Thiagarajan
[...]
>>> --- a/drivers/net/wireless/ath/ath10k/core.c
>>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>>> @@ -68,6 +68,7 @@ static const struct ath10k_hw_params 
>>> ath10k_hw_params_list[] = {
>>>  .board_size = QCA988X_BOARD_DATA_SZ,
>>>  .board_ext_size = QCA988X_BOARD_EXT_DATA_SZ,
>>>  },
>>> +   .hw_rx_desc_ops = _rx_desc_ops,
>> [...]
>>> +struct ath10k_hw_rx_desc_ops {
>>> +   int (*rx_desc_get_l3_pad_bytes)(struct htt_rx_desc *rxd);
>>> +};
>>
>> Benjamin is trying to implement coverage class by poking hw registers
>> over firmware's head [1]. I'm thinking the hw_rx_desc_ops could be
>> generalized to hw_ops so it can be used for doing hw-specific hacks as
>> well. What do you think?
>
> Sure. Instead of reworking this patch set, can this be done in a separate 
> patch?.

I don't really mind especially since there's not much comments on his work yet.


Michał

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

Re: [PATCH 2/4] ath10k: Add provision for Rx descriptor abstraction

[Michal Kazior]

On 27 July 2016 at 14:36, Vasanthakumar Thiagarajan
 wrote:
> There are slight differences in Rx hw descriptor information
> among different chips. So far driver does not use those new
> information for any functionalities, but there is one important
> information which is available from QCA99X0 onwards to indicate
> the number of bytes that hw padded at the begining of the rx
> payload and this information is needed to undecap the rx
> packet. Add an abstraction for Rx desc to make use of the
> new desc information available. The callback that this patch
> defines to retrieve the padding bytes will be used in follow-up
> patch.
>
> Signed-off-by: Vasanthakumar Thiagarajan 
> ---
>  drivers/net/wireless/ath/ath10k/core.c | 12 
>  drivers/net/wireless/ath/ath10k/hw.c   | 13 +
>  drivers/net/wireless/ath/ath10k/hw.h   | 12 
>  3 files changed, 37 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> b/drivers/net/wireless/ath/ath10k/core.c
> index e889829..9c5e93b 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -68,6 +68,7 @@ static const struct ath10k_hw_params 
> ath10k_hw_params_list[] = {
> .board_size = QCA988X_BOARD_DATA_SZ,
> .board_ext_size = QCA988X_BOARD_EXT_DATA_SZ,
> },
> +   .hw_rx_desc_ops = _rx_desc_ops,
[...]
> +struct ath10k_hw_rx_desc_ops {
> +   int (*rx_desc_get_l3_pad_bytes)(struct htt_rx_desc *rxd);
> +};

Benjamin is trying to implement coverage class by poking hw registers
over firmware's head [1]. I'm thinking the hw_rx_desc_ops could be
generalized to hw_ops so it can be used for doing hw-specific hacks as
well. What do you think?

[1]: http://lists.infradead.org/pipermail/ath10k/2016-July/008107.html


Michał

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

Re: [PATCH] ath10k: Allow setting coverage class

[Michal Kazior]

On 27 July 2016 at 10:33, Benjamin Berg  wrote:
> Unfortunately ath10k does not generally allow modifying the coverage class
> with the stock firmware and Qualcomm has so far refused to implement this
> feature so that it can be properly supported in ath10k. If we however know
> the registers that need to be modified for proper operation with a higher
> coverage class, then we can do these modifications from the driver.
>
> This patch implements this hack for first generation cards which are based
> on a core that is similar to ath9k. The registers are modified in place and
> need to be re-written every time the firmware sets them. To achieve this
> the register status is verified after any event from the firmware.

"After any event from firmware" would also need to include HTT events
which your patch doesn't consider.


> The coverage class may not be modified temporarily right after the card
> re-initializes the registers. This is for example the case during scanning.
>
> A warning will be generated if the hack is not supported on the card or
> unexpected values are hit. There is no error reporting for userspace
> applications though (this is a limitation in the mac80211 driver
> interface).

With a recent change in ath10k the ieee80211_ops can be updated in
ar->ops so you can NULL-ify .set_coverage_class before registering to
mac80211. See how wake_tx_queue() is masked. You could use this to
mask it for WAVE2 devices that haven't been verified.


[...]
> @@ -257,6 +258,12 @@ extern const struct ath10k_hw_regs qca6174_regs;
>  extern const struct ath10k_hw_regs qca99x0_regs;
>  extern const struct ath10k_hw_regs qca4019_regs;
>
> +enum ath10k_hw_mac_core_rev {
> +   ATH10K_HW_MAC_CORE_UNKNOWN = 0,
> +   ATH10K_HW_MAC_CORE_ATH9K,

WAVE1 would be more appropriate.


> +   ATH10K_HW_MAC_CORE_WAVE2,
> +};
> +
[...]
> +#define ATH9K_MAC_TIME_OUT 0x8014
> +#define ATH9K_MAC_TIME_OUT_MAX 0x3FFF
> +#define ATH9K_MAC_TIME_OUT_ACK 0x3FFF
> +#define ATH9K_MAC_TIME_OUT_ACK_S   0
> +#define ATH9K_MAC_TIME_OUT_CTS 0x3FFF
> +#define ATH9K_MAC_TIME_OUT_CTS_S   16
> +
> +#define ATH9K_MAC_IFS_SLOT 0x1070
> +#define ATH9K_MAC_IFS_SLOT_M   0x
> +#define ATH9K_MAC_IFS_SLOT_RESV0   0x

The prefix is wrong. It shouldn't be ATH9K.

Moreover FW refers to these register as PCU_ACK_CTS_TIMEOUT and
PCU_GBL_IFS_SLOT.


> +
>  #endif /* _HW_H_ */
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 55c823f..a9b587e 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -5372,6 +5372,15 @@ static void ath10k_bss_info_changed(struct 
> ieee80211_hw *hw,
> mutex_unlock(>conf_mutex);
>  }
>
> +static void ath10k_set_coverage_class(struct ieee80211_hw *hw,
> + s16 value)

Wrong function prefix/name. Should be: ath10k_mac_op_set_coverage_class


> +{
> +   struct ath10k *ar = hw->priv;
> +
> +   if (ath10k_wmi_pdev_set_coverage_class(ar, value) == -EOPNOTSUPP)
> +   ath10k_warn(ar, "Modification of coverage class is not 
> supported!\n");

Warning doesn't match the style used in ath10k. "failed to set
coverage class: not supported\n".


[...]
> diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h 
> b/drivers/net/wireless/ath/ath10k/wmi-ops.h
> index 64ebd30..3ebc57e 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
> @@ -52,6 +52,8 @@ struct wmi_ops {
> int (*pull_wow_event)(struct ath10k *ar, struct sk_buff *skb,
>   struct wmi_wow_ev_arg *arg);
> enum wmi_txbf_conf (*get_txbf_conf_scheme)(struct ath10k *ar);
> +   void (*set_pdev_coverage_class)(struct ath10k *ar,
> +   s16 value);

WMI ops are used to generate and process events and command buffers.
These ops are not supposed to have side-effects but
"set_pdev_coverage_class" implies it does.


[...]
>  /* MAIN WMI cmd track */
>  static struct wmi_cmd_map wmi_cmd_map = {
> @@ -3096,6 +3097,121 @@ ath10k_wmi_op_pull_peer_kick_ev(struct ath10k *ar, 
> struct sk_buff *skb,
> return 0;
>  }
>
> +static void
> +ath10k_ath9k_set_pdev_coverage_class(struct ath10k *ar, s16 value)

The prefix is wrong. "ath9k" should be used here.

ath10k_wmi_ is appropriate for stuff in wmi.c


[...]
> +   /* Do some sanity checks on the slottime register. */
> +   if (unlikely(slottime_reg % counters_freq_mhz)) {
> +   ath10k_warn(ar,
> +   "Not adjusting coverage class timeouts, expected 
> an integer microsecond slot time in HW register\n");

Wrong message style.


> +
> +   goto store_regs;
> +   }
> +
> +   slottime = (slottime_reg & ATH9K_MAC_IFS_SLOT_M) / counters_freq_mhz;
> +   if 

Re: 9984 issues solution

[Michal Kazior]

On 26 July 2016 at 11:31, Sebastian Gottschall  wrote:
> i found the reason and the solution. i disabled all beamforming vht caps.
> this will prevent the firmware of beeing crashing.
> so it seems, beamforming is responsible for it
> could the firmware be fixed?

This sounds awfully familiar. qca6174 hw.2 firmware had this kind of
problem at one point - it would advertise txbf support even though it
lacked it. It caused firmware crashes whenever you tried to associate
to a txbf capable AP. However qca6174 firmware is very distinct from
qca9xxx.

But maybe it's just a silly out-of-bounds or deref bug in firmware
txbf code. Or maybe the txbf vdev/peer param ABI has changed and
ath10k sets something else thinking it is configuring txbf. Beats me.


Michał

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

Re: Not able to capture qos data packets - QCA988x

[Michal Kazior]

On 26 July 2016 at 05:06, sudheer thota  wrote:
> wireless interface(ath10k) monitor failing to capture data packets when
> WMM enabled on AP.
>
> AP Status reflects in following state: (when no QOS data Packets. MGMT and 
> CTRL Packets are able to captured)
> 1) 0x03 (3) - Secondary channel is below Primary
> 2) 1 - any Channel width in secondary channel width
> 3) 1 - Use of RIFS permitted
> 4) 0x02 - Only HT STAs in the BSS, however there exists at least on 20Mhz STA
> 5) 0 - all Associated HT STAs are greenfield capable

You didn't really explain your topology. Are you using ath10k to sniff
only or to run AP *and* sniff at the same time?

FWIW It's kind of a problem to sniff your own transmission with QoS
because of NWifi vs 802.11 headers problem so regular packet
dissection won't recognize them properly.


Michał

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

Re: ath10k fail to load firmware

[Michal Kazior]

On 21 July 2016 at 03:24,   wrote:
> HI All:
>
> I got two board files for subsystem id 0310 .
>
> eeprom_ar6320_3p0_NFA344A_power1213_DE_5459.bin
> eeprom_ar6320_3p0_NFA344A_power1213.bin
>
> But  I am not sure which files should be used , and I  want know which board
> file should be replaced.
>
> In the /lib/firmware/ath10k/QCA6174/hw3.0/  directory ,  I found two file
> named “ board.bin” and ” board-2.bin “

Remove board-2.bin and copy eeprom_ar6320_3p0_NFA344A_power1213.bin as
board.bin. If it doesn't work try
eeprom_ar6320_3p0_NFA344A_power1213_DE_5459.bin as board.bin.


Michał

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

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

[Michal Kazior]

On 20 July 2016 at 13:43, Shajakhan, Mohammed Shafi (Mohammed Shafi)
 wrote:
> Michal,
>
> Can you please let me know if this change is fine or not ?
> I am waiting infinitely for  your reply long time

Sorry. I was absent for a while and this email slipped by.

Quoting your other email:

> is this patch is good to go (or) should i re-work  ?
> I had replied to Michal's comment of introducing a new firmware
> feature flag will not address the issue in older firmware / code.
> Let me know if i had missed something very obvious.

I couldn't really find any conclusion to this thread in my inbox.

The hw_params approach is definitely wrong. The ACK problem is
firmware-specific, not hardware-specific.

I'm fine with removing the workaround completely if 636 is guaranteed
to not be broken, including AP and P2P GO operation. The client
operation will probably work since wmi-roam event is used for HW
connection monitoring.

Nullfunc tx-status ack/noack reports could be probably fixed up using
sta kickout events (with short timeouts) as a fallback. This would
make it easier for users because otherwise they'd need to enable
disassoc_low_ack in hostapd (which is probably impossible with
wpa_supplicant for p2p, no?).


Michał

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

Re: rx rate issue

[Michal Kazior]

On 20 July 2016 at 13:10, Sebastian Gottschall <s.gottsch...@dd-wrt.com> wrote:
> Am 20.07.2016 um 13:03 schrieb Michal Kazior:
>>
>> On 20 July 2016 at 12:50, Sebastian Gottschall <s.gottsch...@dd-wrt.com>
>> wrote:
>>>
>>> Am 20.07.2016 um 12:23 schrieb Michal Kazior:
>>>>
>>>> On 20 July 2016 at 10:51, Sebastian Gottschall <s.gottsch...@dd-wrt.com>
>>>> wrote:
>>>>>
>>>>> Hello
>>>>>
>>>>> while hunting a link stability (packet transmission stop) issue i
>>>>> discovered
>>>>> a maybe cosmetic, but maybe als serious issue.
>>>>> AP is a QCA9880 3x3 card configured as WDS AP
>>>>> Station is a QCA9880 2x2 card configured as WDS STA
>>>>>
>>>>> the TX rate of the station matches to the rx rate of the AP.
>>>>> but the RX rate of the station is wrong as it seems which may be a
>>>>> cause
>>>>> of
>>>>> the issue.
>>>>> could this be a firmware bug on QCA9880?
>>>>>
>>>>> output of fw_stats
>>>>>
>>>>> WDS AP:
>>>>>Peer MAC address 40:a5:ef:85:4d:6f
>>>>>Peer RSSI 12
>>>>> Peer TX rate 175500
>>>>> Peer RX rate 175500
>>>>> Peer RX duration 0
>>>>>
>>>>>
>>>>> WDS STA:
>>>>>   Peer MAC address 40:a5:ef:51:49:db
>>>>>Peer RSSI 13
>>>>> Peer TX rate 175500
>>>>> Peer RX rate 351000
>>>>> Peer RX duration 0
>>
>> [...]
>>>>
>>>> Is this reproducible? Can you try setting a fixed tx bitrate (`iw
>>>> wlanX set bitrates legacy-5 ht-mcs vht-mcs 1:4` to force vht mcs=4,
>>>> nss=1) to see if it makes any difference? Perhaps rate-control and tx
>>>> try-list/status are not parsed properly (for statistical purposes) in
>>>> firmware which ends up with invalid peer-tx-rate on WDS AP.
>>>
>>> lets try. can you correct the syntax? the following is not correct
>>> iw dev ath1 set bitrates legacy-5 ht-mcs vht-mcs 1:4
>>>
>>> Usage:  iw [options] dev  set bitrates [legacy-<2.4|5> >> rate
>>> in Mbps>*] [ht-mcs-<2.4|5> *] [v
>>> ht-mcs-<2.4|5> <NSS:MCSx,MCSy... | NSS:MCSx-MCSy>*] [sgi-2.4|lgi-2.4]
>>> [sgi-5|lgi-5]
>>>
>>> Sets up the specified rate masks.
>>> Not passing any arguments would clear the existing mask (if any).
>>
>> Ah, sorry, my bad.
>>
>>iw dev ath1 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:4
>>
>> (ht-mcs and vht-mcs were missing "-5" suffix)
>>
>> As a sidenote: The logic here is that you need to explicitly tell that
>> you want empty set of legacy rates and empty set of HT rates and only
>> a single VHT rate to be set (all explicitly for 5ghz band). This makes
>> sure that FW rate control is ignored and a fixed rate is used for all
>> data transmissions (and this should also build tx try-lists without
>> any fancy retries/fallbacks to different rates).
>
> after setting this setting on ap. i get the following results:
>
> sta:
> rx bitrate: 175.5 MBit/s VHT-MCS 4 80MHz VHT-NSS 1
>  Peer TX rate 234000
>   Peer RX rate 175500
>
>
> AP:
> rx bitrate: 175.5 MBit/s VHT-MCS 4 80MHz VHT-NSS 1
>   Peer TX rate 263300
>   Peer RX rate 175500
>
> this looks even more curious

Thanks for checking.

Looks like firmware reports garbage for peer-tx-rate.. 234mbps and
263.3mbps were probably values that rate control tried before and
since firmware reuses memory hunks for tx descriptors it probably ends
up reading stale data and reports it as peer-tx-rate.

I did a quick look at firmware code that collects peer-tx-rate. It
does seem to have some logic flaws but I couldn't imagine how it can
report the values you're seeing.

On the plus side it's probably harmless.


Michał

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

Re: rx rate issue

[Michal Kazior]

On 20 July 2016 at 12:50, Sebastian Gottschall <s.gottsch...@dd-wrt.com> wrote:
> Am 20.07.2016 um 12:23 schrieb Michal Kazior:
>>
>> On 20 July 2016 at 10:51, Sebastian Gottschall <s.gottsch...@dd-wrt.com>
>> wrote:
>>>
>>> Hello
>>>
>>> while hunting a link stability (packet transmission stop) issue i
>>> discovered
>>> a maybe cosmetic, but maybe als serious issue.
>>> AP is a QCA9880 3x3 card configured as WDS AP
>>> Station is a QCA9880 2x2 card configured as WDS STA
>>>
>>> the TX rate of the station matches to the rx rate of the AP.
>>> but the RX rate of the station is wrong as it seems which may be a cause
>>> of
>>> the issue.
>>> could this be a firmware bug on QCA9880?
>>>
>>> output of fw_stats
>>>
>>> WDS AP:
>>>   Peer MAC address 40:a5:ef:85:4d:6f
>>>   Peer RSSI 12
>>>Peer TX rate 175500
>>>Peer RX rate 175500
>>>Peer RX duration 0
>>>
>>>
>>> WDS STA:
>>>  Peer MAC address 40:a5:ef:51:49:db
>>>   Peer RSSI 13
>>>Peer TX rate 175500
>>>Peer RX rate 351000
>>>Peer RX duration 0
[...]
>> Is this reproducible? Can you try setting a fixed tx bitrate (`iw
>> wlanX set bitrates legacy-5 ht-mcs vht-mcs 1:4` to force vht mcs=4,
>> nss=1) to see if it makes any difference? Perhaps rate-control and tx
>> try-list/status are not parsed properly (for statistical purposes) in
>> firmware which ends up with invalid peer-tx-rate on WDS AP.
>
> lets try. can you correct the syntax? the following is not correct
> iw dev ath1 set bitrates legacy-5 ht-mcs vht-mcs 1:4
>
> Usage:  iw [options] dev  set bitrates [legacy-<2.4|5>  in Mbps>*] [ht-mcs-<2.4|5> *] [v
> ht-mcs-<2.4|5> <NSS:MCSx,MCSy... | NSS:MCSx-MCSy>*] [sgi-2.4|lgi-2.4]
> [sgi-5|lgi-5]
>
> Sets up the specified rate masks.
> Not passing any arguments would clear the existing mask (if any).

Ah, sorry, my bad.

  iw dev ath1 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:4

(ht-mcs and vht-mcs were missing "-5" suffix)

As a sidenote: The logic here is that you need to explicitly tell that
you want empty set of legacy rates and empty set of HT rates and only
a single VHT rate to be set (all explicitly for 5ghz band). This makes
sure that FW rate control is ignored and a fixed rate is used for all
data transmissions (and this should also build tx try-lists without
any fancy retries/fallbacks to different rates).


Michał

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

Re: rx rate issue

[Michal Kazior]

On 20 July 2016 at 10:51, Sebastian Gottschall  wrote:
> Hello
>
> while hunting a link stability (packet transmission stop) issue i discovered
> a maybe cosmetic, but maybe als serious issue.
> AP is a QCA9880 3x3 card configured as WDS AP
> Station is a QCA9880 2x2 card configured as WDS STA
>
> the TX rate of the station matches to the rx rate of the AP.
> but the RX rate of the station is wrong as it seems which may be a cause of
> the issue.
> could this be a firmware bug on QCA9880?
>
> output of fw_stats
>
> WDS AP:
>  Peer MAC address 40:a5:ef:85:4d:6f
>  Peer RSSI 12
>   Peer TX rate 175500
>   Peer RX rate 175500
>   Peer RX duration 0
>
>
> WDS STA:
> Peer MAC address 40:a5:ef:51:49:db
>  Peer RSSI 13
>   Peer TX rate 175500
>   Peer RX rate 351000
>   Peer RX duration 0

Hmm.. Interesting. FWIW these are "last tx/rx rate". This isn't
average nor anything fancy like that.

Can you compare that to `iw wlanX station dump`, please? It should
report last rx bitrate at least (tx bitrate is broken so don't rely on
that). The 175.5 and 351 seem to be both vht mcs index=4 but with
differet nss values (1 or 2 spatial streams).

I do wonder at what rate frames are actually transmitted OTA.

Is this reproducible? Can you try setting a fixed tx bitrate (`iw
wlanX set bitrates legacy-5 ht-mcs vht-mcs 1:4` to force vht mcs=4,
nss=1) to see if it makes any difference? Perhaps rate-control and tx
try-list/status are not parsed properly (for statistical purposes) in
firmware which ends up with invalid peer-tx-rate on WDS AP.


Michał

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

Re: ath10k fail to load firmware

[Michal Kazior]

Hi Perry,

I've been told that Dell apparently maintains their subsystem ids
independently (from QCA). You should probably ask your Windows driver
team (or whoever is responsible for the subsystem id stuff at Dell)
for subsystem ids and board/eeprom files associated with them and then
provide them on ath10k mailing list so Kalle can add them to
board-2.bin.


Michał

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

Re: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform

[Michal Kazior]

On 20 July 2016 at 08:11, Adrian Chadd  wrote:
> Hi,
>
> The ath10k on-chip DMA engine only knows how to address the low 32
> bits of physical address space. It can't do DMA elsewhere without a
> hardware IOMMU in the system. Even then, as far as the device is
> concerned, it's being given < 32 bit physical memory addresses to DMA
> around.

Sure. ath10k even makes sure to use 32bit mask for dma (which is
redundant because it's already the default in linux pci subsystem
anyway).


> The local/host memory designation is different; IIRC when the CE is
> doing transfers between local/host memory it's explicitly setup to do
> so when you setup the ring/transfer. But those are all 32 bit
> addresses anyway.

Is CE involved in direct DMA accesses as well? Anyway my current
suspicion stems from this code hunk in ath10k:

static u32 ath10k_pci_targ_cpu_to_ce_addr(struct ath10k *ar, u32 addr)
{
u32 val = 0;

switch (ar->hw_rev) {
case ATH10K_HW_QCA988X:
case ATH10K_HW_QCA9887:
case ATH10K_HW_QCA6174:
case ATH10K_HW_QCA9377:
val = (ath10k_pci_read32(ar, SOC_CORE_BASE_ADDRESS +
  CORE_CTRL_ADDRESS) &
   0x7ff) << 21;
break;
case ATH10K_HW_QCA9888:
case ATH10K_HW_QCA99X0:
case ATH10K_HW_QCA9984:
case ATH10K_HW_QCA4019:
val = ath10k_pci_read32(ar, PCIE_BAR_REG_ADDRESS);
break;
}

val |= 0x10 | (addr & 0xf);
return val;
}

This is used for CE diagnostic window in ath10k. However there seems
to be a counterpart (A_DMA_ADDR/A_CPU_ADDR) in firmware that does
something similar and dma_local_bits seem to be constructed in a
similar manner (at least on QCA9880), i.e. ((x >> 21) & 0x7ff) << 21.

The QCA99X0 seems to do it slightly differently (in firmware code as
well). Perhaps there's some kind of bug or an unexpected overlap that
cause addressing problems?


Michał

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

Re: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform

[Michal Kazior]

On 20 July 2016 at 07:44, Adrian Chadd  wrote:
> Hi,
>
> dma coherent doesn't /have/ to mean "low 32 bits". It's just supposed
> to mean "try really hard to use uncached memory on platforms that
> support it."

Good point. Maybe it does on x86, or at least some machines.

@Ben: Can you verify if that's the case for you? Can you see what
address ranges hostmem chunks get with and without the GFP_DMA32 (and
maybe compare it against a revert to compare to dma-coherent as well)?


> The ath10k hardware (at least what I've played with thus far) is all
> 32 bit DMA hardware, not 64 bit, so it can't be handed 64 bit memory -
> contiguous or otherwise.
>
> So, if dma coherent on linux means 32 bit only physmem, great.
>
> Now, it also turns out that various platforms that say they do
> coherent memory these days do "mostly coherent", and you still need
> some flush/sync ops..

Yeah, but since the device has it's own CPU and RAM it has to have a
way to distinguish local and host memory in some way using these 32
bits, no? (think about firmware generating local 802.11 frames vs
pushing frames coming from host driver)


Michał

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

Re: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform

[Michal Kazior]

On 19 July 2016 at 18:53, Ben Greear  wrote:
> On 07/19/2016 09:13 AM, Adrian Chadd wrote:
[...]
>> Try allocating WMI memory with GFP_DMA32. The way it currently is
>> working in linux is that caling dma map ends up allocating iommu slots
>> to map that 64 bit memory back into 32 bit space, /or/ it will end up
>> allocating bounce buffers.
>>
>> The WMI memory alloc routine is being used for the swap space too,
>> which ends up with 700kbyte or more allocated twice - once for the
>> initial alloc, and another for the dma map call.
>>
>> You should try GFP_DMA32 and see if that fixes it. You need contig, <
>> 32 bit physical memory allocated, and bounce buffers are really
>> supposed to be ephemeral.
>
>
> I briefly tested with the GFP_DMA32 and it worked on my 9984 test rig.

Doesn't GFP_DMA32 alter the address space your pointers refer to in a
similar way dma-coherent allocations do (compared to regular
kmalloc+dma-map-single)? This would support my theory about
firmware/hardware getting confused if host mem chunks have some MSBs
set.


Michał

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

Re: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform

[Michal Kazior]

On 19 July 2016 at 17:25, Manoharan, Rajkumar <rmano...@qti.qualcomm.com> wrote:
> On June 30, 2016 12:39 PM, Michal Kazior <michal.kaz...@tieto.com> wrote:
>> On 29 June 2016 at 18:35, Manoharan, Rajkumar <rmano...@qti.qualcomm.com> 
>> wrote:
>>>>> Am 29.06.2016 um 16:04 schrieb Sebastian Gottschall:
>>>>> this fix will crash QCA9980 on QCA IPQ8064 cpu based systems.
>>>>> so please rework it, or leave it out.
>>>>> note:
>>>>> maybe the limit of 256kb is too low for that card
>>>>>
>>>> by the way. 512 works
>>
>> I think this suggests the problem isn't about memory chunk size limit
>> per se but some kind of bug in address/offset logic in fw or hw.
>>
>> DMA coherent and single-map addresses use completely different ranges
>> in many cases. Perhaps some MSBs are not properly handled in fw or hw.
>> I recall there is a magic macro through which target device accesses
>> host memory so maybe that's a good place to look to better understand
>> the problem?
>>
> Michał,
>
> Could you please shed some light on this issue? It seems this issue is 
> popping up
> more frequently and there are multiple threads for this issue.
>
> "Anyone brought up 9984 NIC on x86-64?"
> "AR9882 IOMMU faults"

I think IOMMU faults were solved by using DMA_BIDIRECTIONAL, no?

Anyway, FWIW there's this concept in firmware called dma_local_bits
and A_DMA_ADDR()/A_CPU_ADDR(). Not sure if it's relevant but may be
worth checking out in detail.


>> I recall Ben mentioned he worked around the problem by enabling
>> IOMMU/VT-d on his system. This could either prevent the device from
>> doing bad things or maybe changed DMA address ranges that are handed
>> out to the driver effectively or changed PCI controller behavior in
>> some way.
>>
>>> Thanks a lot Sebastian. Let me confirm the same on x86 and will update the 
>>> change.
>>
>> Just changing the memory chunk size limit blindly is bad and
>> Sebastian's crash has proven it. 512 may seem to work now but it may
>> fail with a other 10.4 firmware revisions or make x86 hang in other
>> cases.
>>
> Even with current logic, If the memory chunk allocation fails for bigger 
> size, then it tries
> to allocate smaller chunks. So If smaller chunks causes unexpected behaviour, 
> it is even
> applicable to existing logic. no?

We still don't know *why* using non-coherent memory causes problems.
Changing chunk size limit seems to alter the behavior in some
unpredictable ways, yes, but it's really hard to tell if the "try
smaller chunk sizes" *itself* introduces any problems.


Michał

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

[RFC] ath10k: silence firmware file probing warnings

[Michal Kazior]

Firmware files are versioned to prevent older
driver instances to load unsupported firmware
blobs. This is reflected with a fallback logic
which attempts to load several firmware files.

This however produced a lot of unnecessary
warnings sometimes confusing users and leading
them to rename firmware files making things even
more confusing.

Hence use request_firmware_direct() which does not
produce extra warnings. This shouldn't really
break anything because most modern systems don't
rely on udev/hotplug helpers to load firmware
files anymore.

Signed-off-by: Michal Kazior <michal.kaz...@tieto.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 11 +--
 drivers/net/wireless/ath/ath10k/testmode.c |  5 -
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index e88982921aa3..81bfb71fe876 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -431,7 +431,10 @@ static const struct firmware *ath10k_fetch_fw_file(struct 
ath10k *ar,
dir = ".";
 
snprintf(filename, sizeof(filename), "%s/%s", dir, file);
-   ret = request_firmware(, filename, ar->dev);
+   ret = request_firmware_direct(, filename, ar->dev);
+   ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot fw request '%s': %d\n",
+  filename, ret);
+
if (ret)
return ERR_PTR(ret);
 
@@ -1089,12 +1092,8 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, 
const char *name,
/* first fetch the firmware file (firmware-*.bin) */
fw_file->firmware = ath10k_fetch_fw_file(ar, ar->hw_params.fw.dir,
 name);
-   if (IS_ERR(fw_file->firmware)) {
-   ath10k_err(ar, "could not fetch firmware file '%s/%s': %ld\n",
-  ar->hw_params.fw.dir, name,
-  PTR_ERR(fw_file->firmware));
+   if (IS_ERR(fw_file->firmware))
return PTR_ERR(fw_file->firmware);
-   }
 
data = fw_file->firmware->data;
len = fw_file->firmware->size;
diff --git a/drivers/net/wireless/ath/ath10k/testmode.c 
b/drivers/net/wireless/ath/ath10k/testmode.c
index 120f4234d3b0..fe49e7a83d00 100644
--- a/drivers/net/wireless/ath/ath10k/testmode.c
+++ b/drivers/net/wireless/ath/ath10k/testmode.c
@@ -149,7 +149,10 @@ static int ath10k_tm_fetch_utf_firmware_api_1(struct 
ath10k *ar,
 ar->hw_params.fw.dir, ATH10K_FW_UTF_FILE);
 
/* load utf firmware image */
-   ret = request_firmware(_file->firmware, filename, ar->dev);
+   ret = request_firmware_direct(_file->firmware, filename, ar->dev);
+   ath10k_dbg(ar, ATH10K_DBG_TESTMODE, "testmode fw request '%s': %d\n",
+  filename, ret);
+
if (ret) {
ath10k_warn(ar, "failed to retrieve utf firmware '%s': %d\n",
filename, ret);
-- 
2.1.4


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

[PATCH 3/4] ath10k: add wmi command barrier utility

[Michal Kazior]

This allows placing command barriers for explicit
serializing and synchronizing state.

Useful for future driver development.

Signed-off-by: Michal Kazior <michal.kaz...@tieto.com>
---
 drivers/net/wireless/ath/ath10k/core.h |  1 +
 drivers/net/wireless/ath/ath10k/wmi.c  | 31 +++
 drivers/net/wireless/ath/ath10k/wmi.h  |  1 +
 3 files changed, 33 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 9374bcde3d35..bf385052b168 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -142,6 +142,7 @@ struct ath10k_wmi {
enum ath10k_htc_ep_id eid;
struct completion service_ready;
struct completion unified_ready;
+   struct completion barrier;
wait_queue_head_t tx_credits_wq;
DECLARE_BITMAP(svc_map, WMI_SERVICE_MAX);
struct wmi_cmd_map *cmd;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 8ca76ecd7e9b..2bd9f2d0f186 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -29,6 +29,9 @@
 #include "p2p.h"
 #include "hw.h"
 
+#define ATH10K_WMI_BARRIER_ECHO_ID 0xBA991E9
+#define ATH10K_WMI_BARRIER_TIMEOUT_HZ (3 * HZ)
+
 /* MAIN WMI cmd track */
 static struct wmi_cmd_map wmi_cmd_map = {
.init_cmdid = WMI_INIT_CMDID,
@@ -2507,6 +2510,9 @@ void ath10k_wmi_event_echo(struct ath10k *ar, struct 
sk_buff *skb)
ath10k_dbg(ar, ATH10K_DBG_WMI,
   "wmi event echo value 0x%08x\n",
   le32_to_cpu(arg.value));
+
+   if (le32_to_cpu(arg.value) == ATH10K_WMI_BARRIER_ECHO_ID)
+   complete(>wmi.barrier);
 }
 
 int ath10k_wmi_event_debug_mesg(struct ath10k *ar, struct sk_buff *skb)
@@ -7689,6 +7695,30 @@ ath10k_wmi_op_gen_echo(struct ath10k *ar, u32 value)
return skb;
 }
 
+int
+ath10k_wmi_barrier(struct ath10k *ar)
+{
+   int ret;
+   int time_left;
+
+   spin_lock_bh(>data_lock);
+   reinit_completion(>wmi.barrier);
+   spin_unlock_bh(>data_lock);
+
+   ret = ath10k_wmi_echo(ar, ATH10K_WMI_BARRIER_ECHO_ID);
+   if (ret) {
+   ath10k_warn(ar, "failed to submit wmi echo: %d\n", ret);
+   return ret;
+   }
+
+   time_left = wait_for_completion_timeout(>wmi.barrier,
+   ATH10K_WMI_BARRIER_TIMEOUT_HZ);
+   if (!time_left)
+   return -ETIMEDOUT;
+
+   return 0;
+}
+
 static const struct wmi_ops wmi_ops = {
.rx = ath10k_wmi_op_rx,
.map_svc = wmi_main_svc_map,
@@ -8086,6 +8116,7 @@ int ath10k_wmi_attach(struct ath10k *ar)
 
init_completion(>wmi.service_ready);
init_completion(>wmi.unified_ready);
+   init_completion(>wmi.barrier);
 
INIT_WORK(>svc_rdy_work, ath10k_wmi_event_service_ready_work);
 
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 086d78807d2f..89adfa90ee8d 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6628,5 +6628,6 @@ void ath10k_wmi_10_4_op_fw_stats_fill(struct ath10k *ar,
  char *buf);
 int ath10k_wmi_op_get_vdev_subtype(struct ath10k *ar,
   enum wmi_vdev_subtype subtype);
+int ath10k_wmi_barrier(struct ath10k *ar);
 
 #endif /* _WMI_H_ */
-- 
2.1.4


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

[PATCH 1/4] ath10k: implement wmi echo command

[Michal Kazior]

Will be useful for implementing command barriers.

Signed-off-by: Michal Kazior <michal.kaz...@tieto.com>
---
 drivers/net/wireless/ath/ath10k/wmi-ops.h | 17 +
 drivers/net/wireless/ath/ath10k/wmi-tlv.c | 29 +
 drivers/net/wireless/ath/ath10k/wmi.c | 23 +++
 3 files changed, 69 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h 
b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index 64ebd304f907..b1d88fa60d11 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -194,6 +194,7 @@ struct wmi_ops {
struct sk_buff *(*gen_pdev_bss_chan_info_req)
(struct ath10k *ar,
 enum wmi_bss_survey_req_type type);
+   struct sk_buff *(*gen_echo)(struct ath10k *ar, u32 value);
 };
 
 int ath10k_wmi_cmd_send(struct ath10k *ar, struct sk_buff *skb, u32 cmd_id);
@@ -1382,4 +1383,20 @@ ath10k_wmi_pdev_bss_chan_info_request(struct ath10k *ar,
   wmi->cmd->pdev_bss_chan_info_request_cmdid);
 }
 
+static inline int
+ath10k_wmi_echo(struct ath10k *ar, u32 value)
+{
+   struct ath10k_wmi *wmi = >wmi;
+   struct sk_buff *skb;
+
+   if (!wmi->ops->gen_echo)
+   return -EOPNOTSUPP;
+
+   skb = wmi->ops->gen_echo(ar, value);
+   if (IS_ERR(skb))
+   return PTR_ERR(skb);
+
+   return ath10k_wmi_cmd_send(ar, skb, wmi->cmd->echo_cmdid);
+}
+
 #endif
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c 
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index e09337ee7c96..cd595855af36 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -3081,6 +3081,34 @@ ath10k_wmi_tlv_op_gen_adaptive_qcs(struct ath10k *ar, 
bool enable)
return skb;
 }
 
+static struct sk_buff *
+ath10k_wmi_tlv_op_gen_echo(struct ath10k *ar, u32 value)
+{
+   struct wmi_echo_cmd *cmd;
+   struct wmi_tlv *tlv;
+   struct sk_buff *skb;
+   void *ptr;
+   size_t len;
+
+   len = sizeof(*tlv) + sizeof(*cmd);
+   skb = ath10k_wmi_alloc_skb(ar, len);
+   if (!skb)
+   return ERR_PTR(-ENOMEM);
+
+   ptr = (void *)skb->data;
+   tlv = ptr;
+   tlv->tag = __cpu_to_le16(WMI_TLV_TAG_STRUCT_ECHO_CMD);
+   tlv->len = __cpu_to_le16(sizeof(*cmd));
+   cmd = (void *)tlv->value;
+   cmd->value = cpu_to_le32(value);
+
+   ptr += sizeof(*tlv);
+   ptr += sizeof(*cmd);
+
+   ath10k_dbg(ar, ATH10K_DBG_WMI, "wmi tlv echo value 0x%08x\n", value);
+   return skb;
+}
+
 //
 /* TLV mappings */
 //
@@ -3485,6 +3513,7 @@ static const struct wmi_ops wmi_tlv_ops = {
.gen_adaptive_qcs = ath10k_wmi_tlv_op_gen_adaptive_qcs,
.fw_stats_fill = ath10k_wmi_main_op_fw_stats_fill,
.get_vdev_subtype = ath10k_wmi_op_get_vdev_subtype,
+   .gen_echo = ath10k_wmi_tlv_op_gen_echo,
 };
 
 static const struct wmi_peer_flags_map wmi_tlv_peer_flags_map = {
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 169cd2e783eb..9ae4aacadb38 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -7649,6 +7649,24 @@ ath10k_wmi_10_4_ext_resource_config(struct ath10k *ar,
return skb;
 }
 
+static struct sk_buff *
+ath10k_wmi_op_gen_echo(struct ath10k *ar, u32 value)
+{
+   struct wmi_echo_cmd *cmd;
+   struct sk_buff *skb;
+
+   skb = ath10k_wmi_alloc_skb(ar, sizeof(*cmd));
+   if (!skb)
+   return ERR_PTR(-ENOMEM);
+
+   cmd = (struct wmi_echo_cmd *)skb->data;
+   cmd->value = cpu_to_le32(value);
+
+   ath10k_dbg(ar, ATH10K_DBG_WMI,
+  "wmi echo value 0x%08x\n", value);
+   return skb;
+}
+
 static const struct wmi_ops wmi_ops = {
.rx = ath10k_wmi_op_rx,
.map_svc = wmi_main_svc_map,
@@ -7709,6 +7727,7 @@ static const struct wmi_ops wmi_ops = {
.gen_delba_send = ath10k_wmi_op_gen_delba_send,
.fw_stats_fill = ath10k_wmi_main_op_fw_stats_fill,
.get_vdev_subtype = ath10k_wmi_op_get_vdev_subtype,
+   .gen_echo = ath10k_wmi_op_gen_echo,
/* .gen_bcn_tmpl not implemented */
/* .gen_prb_tmpl not implemented */
/* .gen_p2p_go_bcn_ie not implemented */
@@ -,6 +7796,7 @@ static const struct wmi_ops wmi_10_1_ops = {
.gen_delba_send = ath10k_wmi_op_gen_delba_send,
.fw_stats_fill = ath10k_wmi_10x_op_fw_stats_fill,
.get_vdev_subtype = ath10k_wmi_op_get_vdev_subtype,
+   .gen_echo = ath10k_wmi_op_gen_echo,
/* .gen_bcn_tmpl not implemented */
/* .gen_prb_tmpl not implemented */
/* .gen_p2p_go_bcn_ie not implemented */
@@ -7796,6 +7816,7 @@ static const struct wmi_ops wmi_10_2_ops = {
.

[PATCH 2/4] ath10k: implement wmi echo event

[Michal Kazior]

Will be useful for implementing command barriers.

Signed-off-by: Michal Kazior <michal.kaz...@tieto.com>
---
 drivers/net/wireless/ath/ath10k/wmi-ops.h | 12 
 drivers/net/wireless/ath/ath10k/wmi-tlv.c | 28 
 drivers/net/wireless/ath/ath10k/wmi.c | 29 -
 drivers/net/wireless/ath/ath10k/wmi.h |  4 
 4 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h 
b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index b1d88fa60d11..c67eda78b69e 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -51,6 +51,8 @@ struct wmi_ops {
struct wmi_roam_ev_arg *arg);
int (*pull_wow_event)(struct ath10k *ar, struct sk_buff *skb,
  struct wmi_wow_ev_arg *arg);
+   int (*pull_echo_ev)(struct ath10k *ar, struct sk_buff *skb,
+   struct wmi_echo_ev_arg *arg);
enum wmi_txbf_conf (*get_txbf_conf_scheme)(struct ath10k *ar);
 
struct sk_buff *(*gen_pdev_suspend)(struct ath10k *ar, u32 suspend_opt);
@@ -350,6 +352,16 @@ ath10k_wmi_pull_wow_event(struct ath10k *ar, struct 
sk_buff *skb,
return ar->wmi.ops->pull_wow_event(ar, skb, arg);
 }
 
+static inline int
+ath10k_wmi_pull_echo_ev(struct ath10k *ar, struct sk_buff *skb,
+   struct wmi_echo_ev_arg *arg)
+{
+   if (!ar->wmi.ops->pull_echo_ev)
+   return -EOPNOTSUPP;
+
+   return ar->wmi.ops->pull_echo_ev(ar, skb, arg);
+}
+
 static inline enum wmi_txbf_conf
 ath10k_wmi_get_txbf_conf_scheme(struct ath10k *ar)
 {
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c 
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index cd595855af36..a42f52dd9a36 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -1223,6 +1223,33 @@ ath10k_wmi_tlv_op_pull_wow_ev(struct ath10k *ar, struct 
sk_buff *skb,
return 0;
 }
 
+static int ath10k_wmi_tlv_op_pull_echo_ev(struct ath10k *ar,
+ struct sk_buff *skb,
+ struct wmi_echo_ev_arg *arg)
+{
+   const void **tb;
+   const struct wmi_echo_event *ev;
+   int ret;
+
+   tb = ath10k_wmi_tlv_parse_alloc(ar, skb->data, skb->len, GFP_ATOMIC);
+   if (IS_ERR(tb)) {
+   ret = PTR_ERR(tb);
+   ath10k_warn(ar, "failed to parse tlv: %d\n", ret);
+   return ret;
+   }
+
+   ev = tb[WMI_TLV_TAG_STRUCT_ECHO_EVENT];
+   if (!ev) {
+   kfree(tb);
+   return -EPROTO;
+   }
+
+   arg->value = ev->value;
+
+   kfree(tb);
+   return 0;
+}
+
 static struct sk_buff *
 ath10k_wmi_tlv_op_gen_pdev_suspend(struct ath10k *ar, u32 opt)
 {
@@ -3457,6 +3484,7 @@ static const struct wmi_ops wmi_tlv_ops = {
.pull_fw_stats = ath10k_wmi_tlv_op_pull_fw_stats,
.pull_roam_ev = ath10k_wmi_tlv_op_pull_roam_ev,
.pull_wow_event = ath10k_wmi_tlv_op_pull_wow_ev,
+   .pull_echo_ev = ath10k_wmi_tlv_op_pull_echo_ev,
.get_txbf_conf_scheme = ath10k_wmi_tlv_txbf_conf_scheme,
 
.gen_pdev_suspend = ath10k_wmi_tlv_op_gen_pdev_suspend,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 9ae4aacadb38..8ca76ecd7e9b 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2495,7 +2495,18 @@ exit:
 
 void ath10k_wmi_event_echo(struct ath10k *ar, struct sk_buff *skb)
 {
-   ath10k_dbg(ar, ATH10K_DBG_WMI, "WMI_ECHO_EVENTID\n");
+   struct wmi_echo_ev_arg arg = {};
+   int ret;
+
+   ret = ath10k_wmi_pull_echo_ev(ar, skb, );
+   if (ret) {
+   ath10k_warn(ar, "failed to parse echo: %d\n", ret);
+   return;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_WMI,
+  "wmi event echo value 0x%08x\n",
+  le32_to_cpu(arg.value));
 }
 
 int ath10k_wmi_event_debug_mesg(struct ath10k *ar, struct sk_buff *skb)
@@ -4792,6 +4803,17 @@ static int ath10k_wmi_op_pull_roam_ev(struct ath10k *ar, 
struct sk_buff *skb,
return 0;
 }
 
+static int ath10k_wmi_op_pull_echo_ev(struct ath10k *ar,
+ struct sk_buff *skb,
+ struct wmi_echo_ev_arg *arg)
+{
+   struct wmi_echo_event *ev = (void *)skb->data;
+
+   arg->value = ev->value;
+
+   return 0;
+}
+
 int ath10k_wmi_event_ready(struct ath10k *ar, struct sk_buff *skb)
 {
struct wmi_rdy_ev_arg arg = {};
@@ -7683,6 +7705,7 @@ static const struct wmi_ops wmi_ops = {
.pull_rdy = ath10k_wmi_op_pull_rdy_ev,
.pull_fw_stats = ath10k_wmi_main_op_pull_fw_stats,
.pull_roam_ev = ath10k_wmi_op_pull_roa

[PATCH 4/4] ath10k: fix spurious tx/rx during boot

[Michal Kazior]

HW Rx filters and masks are not configured
properly by firmware during boot sequences. The
MAC_PCU_ADDR1 is set to 0s instead of 1s which
allows the HW to ACK any frame that passes through
MAC_PCU_RX_FILTER. The MAC_PCU_RX_FILTER itself
is misconfigured on boot as well.

The combination of these bugs ended up with the
following manifestations:
 - "no channel configured; ignoring frame(s)!"
   warnings in the driver
 - spurious ACKs (transmission) on the air during
   firmware bootup sequences

The former was a long standing and known bug
originally though mostly harmless.

However Marek recently discovered that this
problem also involves ACKing *all* frames the HW
receives (including beacons ;). Such frames
are delivered to host and generate the former
warning as well.

This could be a problem with regulatory compliance
in some rare cases (e.g. Taiwan which forbids
transmissions on channel 36 which is the default
bootup channel on 5Ghz band cards). The good news
is that it'd require someone else to violate
regulatory first to coerce our device to generate
and transmit an ACK.

The problem could be reproduced in a rather busy
environment that has a lot of APs. The likelihood
could be increased by injecting an msleep() of
5000 or longer immediately after
ath10k_htt_setup() in ath10k_core_start().

The reason why the former warnings were only
showing up seldom is because the device was either
quickly reset again (i.e. during firmware probing)
or wmi vdev was created (which fixes hw and fw
states).

It is technically possible for host driver to
override adequate hw registers however this can't
work reliably because the bug root cause lies in
incorrect firmware state on boot (internal
structure used to program MAC_PCU_ADDR1 is not
properly initialized) and only vdev create/delete
events can fix it. This is why the patch takes
dummy vdev approach.

This could be fixed in firmware as well but having
this fixed in driver is more robust, most notably
when thinking of users of older firmware such as
999.999.0.636.

Reported-by: Marek Puzyniak <marek.puzyn...@tieto.com>
Signed-off-by: Michal Kazior <michal.kaz...@tieto.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 68 ++
 1 file changed, 68 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index e88982921aa3..d2e255418d1b 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1705,6 +1705,55 @@ static int ath10k_core_init_firmware_features(struct 
ath10k *ar)
return 0;
 }
 
+static int ath10k_core_reset_rx_filter(struct ath10k *ar)
+{
+   int ret;
+   int vdev_id;
+   int vdev_type;
+   int vdev_subtype;
+   const u8 *vdev_addr;
+
+   vdev_id = 0;
+   vdev_type = WMI_VDEV_TYPE_STA;
+   vdev_subtype = ath10k_wmi_get_vdev_subtype(ar, WMI_VDEV_SUBTYPE_NONE);
+   vdev_addr = ar->mac_addr;
+
+   ret = ath10k_wmi_vdev_create(ar, vdev_id, vdev_type, vdev_subtype,
+vdev_addr);
+   if (ret) {
+   ath10k_err(ar, "failed to create dummy vdev: %d\n", ret);
+   return ret;
+   }
+
+   ret = ath10k_wmi_vdev_delete(ar, vdev_id);
+   if (ret) {
+   ath10k_err(ar, "failed to delete dummy vdev: %d\n", ret);
+   return ret;
+   }
+
+   /* WMI and HTT may use separate HIF pipes and are not guaranteed to be
+* serialized properly implicitly.
+*
+* Moreover (most) WMI commands have no explicit acknowledges. It is
+* possible to infer it implicitly by poking firmware with echo
+* command - getting a reply means all preceding comments have been
+* (mostly) processed.
+*
+* In case of vdev create/delete this is sufficient.
+*
+* Without this it's possible to end up with a race when HTT Rx ring is
+* started before vdev create/delete hack is complete allowing a short
+* window of opportunity to receive (and Tx ACK) a bunch of frames.
+*/
+   ret = ath10k_wmi_barrier(ar);
+   if (ret) {
+   ath10k_err(ar, "failed to ping firmware: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
  const struct ath10k_fw_components *fw)
 {
@@ -1872,6 +1921,25 @@ int ath10k_core_start(struct ath10k *ar, enum 
ath10k_firmware_mode mode,
goto err_hif_stop;
}
 
+   /* Some firmware revisions do not properly set up hardware rx filter
+* registers.
+*
+* A known example from QCA9880 and 10.2.4 is that MAC_PCU_ADDR1_MASK
+* is filled with 0s instead of 1s allowing HW to respond with ACKs to
+* any frames that matches MAC_PCU_RX_FILTER wh

[PATCH 0/4] ath10k: fix spurious tx/rx during boot

[Michal Kazior]

Hi,

Recently Marek discovered the device transmits
"stuff" during device/driver boot.

The problem is related with the long known "no
channel" warning and it's a consequence of the
same bug - rx filters not being programmed
properly by firmware.

See last patch for more details.

I didn't do extensive testing but I can confirm
that I am no longer able to reroduce "no channel"
warnings and Marek tells me he no longer sees any
signal bumps on oscilloscope with his QCA9882.



Michal Kazior (4):
  ath10k: implement wmi echo command
  ath10k: implement wmi echo event
  ath10k: add wmi command barrier utility
  ath10k: fix spurious tx/rx during boot

 drivers/net/wireless/ath/ath10k/core.c| 68 +
 drivers/net/wireless/ath/ath10k/core.h|  1 +
 drivers/net/wireless/ath/ath10k/wmi-ops.h | 29 +++
 drivers/net/wireless/ath/ath10k/wmi-tlv.c | 57 +
 drivers/net/wireless/ath/ath10k/wmi.c | 83 ++-
 drivers/net/wireless/ath/ath10k/wmi.h |  5 ++
 6 files changed, 242 insertions(+), 1 deletion(-)

-- 
2.1.4


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

Re: ath10k fail to load firmware

[Michal Kazior]

On 19 July 2016 at 11:02,   wrote:
> Dell - Internal Use - Confidential
>
> I rename the bin file  . and capture new full logs from booting to firmware 
> error .
> The error still happened. Please help to check it .
> I want to know whether the new firmware bin are updated  the right one  in 
> this git ?
> If the firmware is good , the errors should be gone .

Thanks for checking!

Apparently the available board-2.bin doesn't contain any subsystem
vendor=1028 board data (just checked).

Also, you guys (i.e. Perry & Stanislaw) seem to be using 2 slightly
different devices. One reports its subsystem ids as 1028:0310 (in the
original log Stanislaw provided) and 1028:0410 (found in logs attached
by Perry).


Michał

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

Re: ath10k fail to load firmware

[Michal Kazior]

On 19 July 2016 at 10:24,   wrote:
> Dell - Internal Use - Confidential
>
> HI  All:
> I have replaced the new firmware files to old one. And I build new 
> ath10k_pci.ko ,ath10k_core.ko to get some
> debug info.
>
> The new firmware is still not loaded by ath10k driver .
> And I compare the driver codes with 4.7 -rc7 , the codes are almost same.
> So the issue should be in  firmware scope.
>
> [ 590.486970] ath10k_pci :02:00.0: Hardware name qca6174 hw3.2 version 
> 0x503
> [  590.487158] ath10k_pci :02:00.0: Direct firmware load failed with 
> error -2
> [  590.487159] ath10k_pci :02:00.0: Falling back to user helper

You didn't attach a complete log so it's hard to tell. ath10k tends to
print a few messages that may look like an error but aren't (there's a
fallback mechanism for finding firmware files which is overly
verbose).

@Perry: You need to rename the
firmware-4.bin_WLAN.RM.2.0-00180-QCARMSWPZ-1 to firmware-4.bin in case
you merely mirrored the github repo.

@Kalle: I think it'd be very useful to maintain ath10k-firmware in a
way so that it is easier to the uninitiated to `git clone` it into
/lib/firmware, e.g. maintain firmware-X.bin symlinks in each
QCAxxx/hw.y/ to the latest one. Thoughts?


Michał

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

Re: ath10k fail to load firmware

[Michal Kazior]

On 19 July 2016 at 09:09, Stanislaw Gruszka  wrote:
> Perry from Dell has ath10k device, which do not work with current
> linux-firmware. It's on RHEL kernel, however wirelss stack and drivers
> are from 4.7-rc1 (I did not update to 4.7 final yet, since I do not see
> ath10k fix, which could possibly help here). Partial dmesg is in
> the attachment.

hw.3 qca6174 chips tend to require very specific board data for proper
calibration.

  [ 3838.601884] ath10k_pci :01:00.0: failed to fetch board data
for bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,subsystem-device=0310
from ath10k/QCA6174/hw3.0/board-2.bin
  [ 3838.601920] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A
crc32 ed5f849a

Your board-2.bin doesn't contain the matching board data and the
driver then falls back to the older board API1 which is pretty much
doomed to fail on qca6174 hw.3.

@Kalle: Perhaps ath10k needs to fail early with an adequate message
for qca6174 hw.3 if board API2 lookup fails (e.g. hw_params flag
because this seems to be quite closely coupled with hardware itself).

@Stanislaw: You either need to grab a more recent board-2.bin
(https://github.com/kvalo/ath10k-firmware/tree/master/QCA6174/hw3.0),
ask Kalle & wait, or cook up your own (if you really need it working
*now*) by getting Windows driver and dissecting it (the .inf file
contains enough information for you to map board data also referred to
as eeprom-something in the Windows blob).


Michał

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

Re: ath10k usb support

[Michal Kazior]

On 29 June 2016 at 20:10, Francois Gervais
 wrote:
> Hi,
>
> We are evaluating the new WUSB6100M wireless adapter for use with our 
> embedded platform. This is a wireless usb dongle based on the QCA9377 chipset.
>
> At first glance it seems that the current ath10k driver does not support this 
> adapter.

Correct. ath10k supports PCI and AHB buses only.


> We'd like to know how far is the current driver from supporting this usb 
> adapter?

Probably quite some work - extra HTT abstraction, new USB hif/bus
implementation, some HTC changes and probably some tx/rx path
readjustments.


Michał

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

Re: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform

[Michal Kazior]

On 29 June 2016 at 18:35, Manoharan, Rajkumar  wrote:
>>> Am 29.06.2016 um 16:04 schrieb Sebastian Gottschall:
>>> this fix will crash QCA9980 on QCA IPQ8064 cpu based systems.
>>> so please rework it, or leave it out.
>>> note:
>>> maybe the limit of 256kb is too low for that card
>>>
>> by the way. 512 works

I think this suggests the problem isn't about memory chunk size limit
per se but some kind of bug in address/offset logic in fw or hw.

DMA coherent and single-map addresses use completely different ranges
in many cases. Perhaps some MSBs are not properly handled in fw or hw.
I recall there is a magic macro through which target device accesses
host memory so maybe that's a good place to look to better understand
the problem?

I recall Ben mentioned he worked around the problem by enabling
IOMMU/VT-d on his system. This could either prevent the device from
doing bad things or maybe changed DMA address ranges that are handed
out to the driver effectively or changed PCI controller behavior in
some way.


> Thanks a lot Sebastian. Let me confirm the same on x86 and will update the 
> change.

Just changing the memory chunk size limit blindly is bad and
Sebastian's crash has proven it. 512 may seem to work now but it may
fail with a other 10.4 firmware revisions or make x86 hang in other
cases.


Michał

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

[PATCH] mac80211: fix fq lockdep warnings

[Michal Kazior]

Some lockdep assertions were not fulfilled and
resulted in a kernel warning/call trace if driver
used intermediate software queues (e.g. ath10k).

Existing code sequences should've guranteed safety
but it's always good to be extra careful.

The call trace could look like this:

 [ 237.335805] [ cut here ]
 [ 237.335852] WARNING: CPU: 3 PID: 1921 at include/net/fq_impl.h:22 
fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.335855] Modules linked in: ath10k_pci(E-) ath10k_core(E) ath(E) 
mac80211(E) cfg80211(E)
 [ 237.335913] CPU: 3 PID: 1921 Comm: rmmod Tainted: GW   E   
4.7.0-rc4-wt-ath+ #1377
 [ 237.335916] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD 
Ver. F.04 01/27/2010
 [ 237.335918]  00200286 00200286 eff85dac c14151e2 f901574e  eff85de0 
c1081075
 [ 237.335928]  c1ab91f0 0003 0781 f901574e 0016 f8fbabad f8fbabad 
0016
 [ 237.335938]  eb24ff60  ef3886c0 eff85df4 c10810ba 0009  

 [ 237.335948] Call Trace:
 [ 237.335953]  [] dump_stack+0x76/0xb4
 [ 237.335957]  [] __warn+0xe5/0x100
 [ 237.336002]  [] ? fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.336046]  [] ? fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.336053]  [] warn_slowpath_null+0x2a/0x30
 [ 237.336095]  [] fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.336137]  [] fq_flow_reset.constprop.56+0x2a/0x90 [mac80211]
 [ 237.336180]  [] fq_reset.constprop.59+0x2a/0x50 [mac80211]
 [ 237.336222]  [] ieee80211_txq_teardown_flows+0x38/0x40 [mac80211]
 [ 237.336258]  [] ieee80211_unregister_hw+0xe4/0x120 [mac80211]
 [ 237.336275]  [] ath10k_mac_unregister+0x16/0x50 [ath10k_core]
 [ 237.336292]  [] ath10k_core_unregister+0x3d/0x90 [ath10k_core]
 [ 237.336301]  [] ath10k_pci_remove+0x36/0xa0 [ath10k_pci]
 [ 237.336307]  [] pci_device_remove+0x38/0xb0
 ...

Fixes: 5caa328e3811 ("mac80211: implement codel on fair queuing flows")
Fixes: fa962b92120b ("mac80211: implement fair queueing per txq")
Tested-by: Kalle Valo <kv...@qca.qualcomm.com>
Reported-by: Kalle Valo <kv...@qca.qualcomm.com>
Signed-off-by: Michal Kazior <michal.kaz...@tieto.com>
---

Notes:
v1:
 - added Tested-by [Kalle]
 - swapped first/last name in Reported-by to match Tested-by
 - improve commit log

 net/mac80211/tx.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index fa8d38eb9236..91461c415525 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1449,7 +1449,9 @@ int ieee80211_txq_setup_flows(struct ieee80211_local 
*local)
local->cvars = kcalloc(fq->flows_cnt, sizeof(local->cvars[0]),
   GFP_KERNEL);
if (!local->cvars) {
+   spin_lock_bh(>lock);
fq_reset(fq, fq_skb_free_func);
+   spin_unlock_bh(>lock);
return -ENOMEM;
}
 
@@ -1469,7 +1471,9 @@ void ieee80211_txq_teardown_flows(struct ieee80211_local 
*local)
kfree(local->cvars);
local->cvars = NULL;
 
+   spin_lock_bh(>lock);
fq_reset(fq, fq_skb_free_func);
+   spin_unlock_bh(>lock);
 }
 
 struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
-- 
2.1.4


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

[PATCH] ath10k: disable wake_tx_queue for older devices

[Michal Kazior]

Ideally wake_tx_queue should be used regardless as
it is a requirement for reducing bufferbloat and
implementing airtime fairness in the future.

However some setups (typically low-end platforms
hosting QCA988X) suffer performance regressions
with the current wake_tx_queue implementation.
Therefore disable it unless it is really
beneficial with current codebase (which is when
firmware supports smart pull-push tx scheduling).

Signed-off-by: Michal Kazior <michal.kaz...@tieto.com>
---

Notes:
v1:
 - improve commit log

 drivers/net/wireless/ath/ath10k/core.h |  1 +
 drivers/net/wireless/ath/ath10k/mac.c  | 24 ++--
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 3da18c9dbd7a..de580af2e5ef 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -667,6 +667,7 @@ struct ath10k_fw_components {
 struct ath10k {
struct ath_common ath_common;
struct ieee80211_hw *hw;
+   struct ieee80211_ops *ops;
struct device *dev;
u8 mac_addr[ETH_ALEN];
 
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index d4b7a168f7c0..958bc6c91aac 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7471,21 +7471,32 @@ static const struct ieee80211_channel 
ath10k_5ghz_channels[] = {
 struct ath10k *ath10k_mac_create(size_t priv_size)
 {
struct ieee80211_hw *hw;
+   struct ieee80211_ops *ops;
struct ath10k *ar;
 
-   hw = ieee80211_alloc_hw(sizeof(struct ath10k) + priv_size, _ops);
-   if (!hw)
+   ops = kmemdup(_ops, sizeof(ath10k_ops), GFP_KERNEL);
+   if (!ops)
return NULL;
 
+   hw = ieee80211_alloc_hw(sizeof(struct ath10k) + priv_size, ops);
+   if (!hw) {
+   kfree(ops);
+   return NULL;
+   }
+
ar = hw->priv;
ar->hw = hw;
+   ar->ops = ops;
 
return ar;
 }
 
 void ath10k_mac_destroy(struct ath10k *ar)
 {
+   struct ieee80211_ops *ops = ar->ops;
+
ieee80211_free_hw(ar->hw);
+   kfree(ops);
 }
 
 static const struct ieee80211_iface_limit ath10k_if_limits[] = {
@@ -7919,6 +7930,15 @@ int ath10k_mac_register(struct ath10k *ar)
ath10k_warn(ar, "failed to initialise DFS pattern 
detector\n");
}
 
+   /* Current wake_tx_queue implementation imposes a significant
+* performance penalty in some setups. The tx scheduling code needs
+* more work anyway so disable the wake_tx_queue unless firmware
+* supports the pull-push mechanism.
+*/
+   if (!test_bit(ATH10K_FW_FEATURE_PEER_FLOW_CONTROL,
+ ar->running_fw->fw_file.fw_features))
+   ar->ops->wake_tx_queue = NULL;
+
ret = ath_regd_init(>ath_common.regulatory, ar->hw->wiphy,
ath10k_reg_notifier);
if (ret) {
-- 
2.1.4


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

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

[Michal Kazior]

On 27 June 2016 at 16:36, Mohammed Shafi Shajakhan
<moham...@codeaurora.org> wrote:
> Hi Michal,
>
> thanks for the review ..
>
> On Mon, Jun 27, 2016 at 11:27:27AM +0200, Michal Kazior wrote:
>> On 23 June 2016 at 18:40, Mohammed Shafi Shajakhan
>> <moham...@qti.qualcomm.com> wrote:
>> > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
>> >
>> > For chipsets like QCA99X0, IPQ4019 and later we are not getting proper
>> > NULL func status (always acked/successs !!) when hostapd does a
>> > PROBE_CLIENT via nullfunc frames when the station is powered off
>> > abruptly (inactive timer probes client via null func after the inactive
>> > time reaches beyond the threshold). Fix this by disabling the workaround
>> > (getting the ACK status of NULL func frames by sending via HTT mgmt-tx
>> >  path) introduced by the change ("ath10k: fix beacon loss handling ")
>> > for QCA99X0 and later chipsets. The normal tx path provides the proper
>> > ACK status for NULL data frames. As of now disable this workaround for
>> > chipsets QCA99X0 and later, once the 10.1 firmware is obselete we can
>> > completely get rid of this workaround for all the chipsets
>> >
>> > Signed-off-by: Tamizh chelvam <c_tr...@qti.qualcomm.com>
>> > Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com>
>> > ---
>> >  drivers/net/wireless/ath/ath10k/core.c | 3 +++
>> >  drivers/net/wireless/ath/ath10k/core.h | 6 ++
>> >  drivers/net/wireless/ath/ath10k/mac.c  | 1 +
>> >  3 files changed, 10 insertions(+)
>> >
>> > diff --git a/drivers/net/wireless/ath/ath10k/core.c 
>> > b/drivers/net/wireless/ath/ath10k/core.c
>> > index 689d6ce..9978e4a 100644
>> > --- a/drivers/net/wireless/ath/ath10k/core.c
>> > +++ b/drivers/net/wireless/ath/ath10k/core.c
>> > @@ -181,6 +181,7 @@ static const struct ath10k_hw_params 
>> > ath10k_hw_params_list[] = {
>> > .board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
>> > .board_size = QCA99X0_BOARD_DATA_SZ,
>> > .board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
>> > +   .disable_null_func_workaround = true,
>>
>> Tx completion (bugs) are firmware specific, not hardware. This should
>> be expressed via features bits in ath10k FW API, no?
>>
>>
> [shafi] Are you suggesting me to introduce something like
> "ATH10K_FW_FEATURE_SUPPORTS_SKIP_CLOCK_INIT" ? Kalle any suggestions ?
>
> Also how about getting this workaround completely if Ben had fixed this in 
> his tree,
> will this affect older 10.2.4 ?

There's still 636.

We could probably get rid of this as long as:
 - ath10k can express the need to use Probe Requests for AP probing
(in client mode) and beacon loss handling purposes instead of NullFunc
to mac80211
 - everyone uses hostapd with disassoc_low_ack=1 with affected
firmware revisions
 - supplicant uses disassoc_low_ack=1 for p2p go
 - I have no idea about mesh/ibss but they might require some work as well

Otherwise you'll introduce regressions.


Michał

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

Re: Cannot initialize Compex WLE600VX for 802.11ac?

[Michal Kazior]

On 24 June 2016 at 05:27, Tom Marble  wrote:
> Tomasz Skapski  writes:
>> In your config file set 'fragm_threshold=-1', or comment it.
>
> Indeed this was the last critical configuration change...
> Now I'm able to bring up the interface!
>
> Then I was getting errors when 'ifup'-ing the interface
>   RTNETLINK answers: File exists
> which were resolved by ensuring that
> 1. The interface was flushed prior to being up'ed
>ip addr flush dev wlan0
> 2. The interface was *not* configured to add an (additional) gateway
>
> Following this the interface would not stay up due to avahi-daemon
> decideding it didn't like something and removing the address
>   avahi-daemon[2925]: Withdrawing address record for 10.6.8.1 on wlan0.
>
> The solution here was just removing avahi-daemon (and mDNS services).
>
> Then the interface wasn't happy about IPv6
>   IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not read

This is normal. Try down/up your ethernet interface and you'll see the
same thing.


> Even with setting (in /etc/hostapd/wlan0.conf ) this problem still occurred.
>   ipaddr_type_availability=32
>
> The solution was disabling IPv6 (at least for now.. I do want IPv6
> eventually), in /etc/sysctl.conf
> # NO IPV6 
>net.ipv6.conf.all.disable_ipv6 = 1
> net.ipv6.conf.default.disable_ipv6 = 1
> net.ipv6.conf.lo.disable_ipv6 = 1
> net.ipv6.conf.eth0.disable_ipv6 = 1
> net.ipv6.conf.wan0.disable_ipv6 = 1

Do you really need to disable ipv6?


> I also rebuilt hostapd because it seems to have a version locked
> dependency of libssl (for some reason?).
>
> With the addition of dnsmasq (for DHCP and DNS proxying) and
> simple nftables rules for nat/masquerade I now have a functioning AP!
>
> Certain clients seemed to get "kicked off" the network which has
> been mitigated by setting:
>   ap_max_inactivity=600
>   disassoc_low_ack=0

Try using disassoc_low_ack=1 which enables station inactivity
detection up to firmware/driver (there are some bugs with sending
nullfunc frames depending on fw/hw/driver combo).


[...]
> One strange thing I've noticed is that if I configure the wlan0 (5 GHz)
> channel=52 on boot up it doesn't work... However if I have once
> done channel=0 then on subsequent bounces of the interface I can have
> it come up on a specific channel.

(haven't followed the entire thread, so sorry if I re-iterate something).

Channel availability can get messy and quirky (unless that has changed
in recent kernels?) with multiple wireless cards on the same system.
So there's that.


Michal

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

[RFT] mac80211: fix fq lockdep warnings

[Michal Kazior]

Some lockdep assertions were not fulfilled and
resulted in a kernel warning/call trace.

Existing code sequences should've guranteed safety
but it's always good to be extra careful.

The call trace could look like this:

 [ 237.335805] [ cut here ]
 [ 237.335852] WARNING: CPU: 3 PID: 1921 at include/net/fq_impl.h:22 
fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.335855] Modules linked in: ath10k_pci(E-) ath10k_core(E) ath(E) 
mac80211(E) cfg80211(E)
 [ 237.335913] CPU: 3 PID: 1921 Comm: rmmod Tainted: GW   E   
4.7.0-rc4-wt-ath+ #1377
 [ 237.335916] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD 
Ver. F.04 01/27/2010
 [ 237.335918]  00200286 00200286 eff85dac c14151e2 f901574e  eff85de0 
c1081075
 [ 237.335928]  c1ab91f0 0003 0781 f901574e 0016 f8fbabad f8fbabad 
0016
 [ 237.335938]  eb24ff60  ef3886c0 eff85df4 c10810ba 0009  

 [ 237.335948] Call Trace:
 [ 237.335953]  [] dump_stack+0x76/0xb4
 [ 237.335957]  [] __warn+0xe5/0x100
 [ 237.336002]  [] ? fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.336046]  [] ? fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.336053]  [] warn_slowpath_null+0x2a/0x30
 [ 237.336095]  [] fq_flow_dequeue+0xed/0x140 [mac80211]
 [ 237.336137]  [] fq_flow_reset.constprop.56+0x2a/0x90 [mac80211]
 [ 237.336180]  [] fq_reset.constprop.59+0x2a/0x50 [mac80211]
 [ 237.336222]  [] ieee80211_txq_teardown_flows+0x38/0x40 [mac80211]
 [ 237.336258]  [] ieee80211_unregister_hw+0xe4/0x120 [mac80211]
 [ 237.336275]  [] ath10k_mac_unregister+0x16/0x50 [ath10k_core]
 [ 237.336292]  [] ath10k_core_unregister+0x3d/0x90 [ath10k_core]
 [ 237.336301]  [] ath10k_pci_remove+0x36/0xa0 [ath10k_pci]
 [ 237.336307]  [] pci_device_remove+0x38/0xb0
 ...

Fixes: 5caa328e3811 ("mac80211: implement codel on fair queuing flows")
Fixes: fa962b92120b ("mac80211: implement fair queueing per txq")
Reported-by: Valo, Kalle <kv...@qca.qualcomm.com>
Signed-off-by: Michal Kazior <michal.kaz...@tieto.com>
---

Hi Kalle,

Can you verify this fixes call traces you're
seeing, please?


 net/mac80211/tx.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 44ec605a5682..1975c22132c6 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1445,7 +1445,9 @@ int ieee80211_txq_setup_flows(struct ieee80211_local 
*local)
local->cvars = kcalloc(fq->flows_cnt, sizeof(local->cvars[0]),
   GFP_KERNEL);
if (!local->cvars) {
+   spin_lock_bh(>lock);
fq_reset(fq, fq_skb_free_func);
+   spin_unlock_bh(>lock);
return -ENOMEM;
}
 
@@ -1465,7 +1467,9 @@ void ieee80211_txq_teardown_flows(struct ieee80211_local 
*local)
kfree(local->cvars);
local->cvars = NULL;
 
+   spin_lock_bh(>lock);
fq_reset(fq, fq_skb_free_func);
+   spin_unlock_bh(>lock);
 }
 
 struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
-- 
2.1.4


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

Re: ath10k firmware version - 10.4

[Michal Kazior]

On 22 June 2016 at 08:13, sunder Kumaresan  wrote:
> Hello all,
[...]
> But, When boardData_AR900B_CUS239_5G_v2_001.bin  and 
> boardData_AR900B_CUS260_2G_v2_002.bin  have been renamed as board xxx. bin 
> files.  It shows up as mismatch in the magic number.

I'm *guessing* you've renamed these files to board-2.bin. This will
not work becuase board-2.bin is a TLV wrapper.

I don't see board-2.bin for qca99x0 in Kalle's firmware github repo.
You can try using one from
https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/tree/ath10k/QCA99X0/hw2.0


Michał

PS. Please fix your email client. It inserts a lot of empty newlines
making it really difficult to read.

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

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

[Michal Kazior]

On 23 June 2016 at 18:40, Mohammed Shafi Shajakhan
 wrote:
> From: Mohammed Shafi Shajakhan 
>
> For chipsets like QCA99X0, IPQ4019 and later we are not getting proper
> NULL func status (always acked/successs !!) when hostapd does a
> PROBE_CLIENT via nullfunc frames when the station is powered off
> abruptly (inactive timer probes client via null func after the inactive
> time reaches beyond the threshold). Fix this by disabling the workaround
> (getting the ACK status of NULL func frames by sending via HTT mgmt-tx
>  path) introduced by the change ("ath10k: fix beacon loss handling ")
> for QCA99X0 and later chipsets. The normal tx path provides the proper
> ACK status for NULL data frames. As of now disable this workaround for
> chipsets QCA99X0 and later, once the 10.1 firmware is obselete we can
> completely get rid of this workaround for all the chipsets
>
> Signed-off-by: Tamizh chelvam 
> Signed-off-by: Mohammed Shafi Shajakhan 
> ---
>  drivers/net/wireless/ath/ath10k/core.c | 3 +++
>  drivers/net/wireless/ath/ath10k/core.h | 6 ++
>  drivers/net/wireless/ath/ath10k/mac.c  | 1 +
>  3 files changed, 10 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> b/drivers/net/wireless/ath/ath10k/core.c
> index 689d6ce..9978e4a 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -181,6 +181,7 @@ static const struct ath10k_hw_params 
> ath10k_hw_params_list[] = {
> .board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
> .board_size = QCA99X0_BOARD_DATA_SZ,
> .board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> +   .disable_null_func_workaround = true,

Tx completion (bugs) are firmware specific, not hardware. This should
be expressed via features bits in ath10k FW API, no?


Michał

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

Re: [PATCH] ath10k: fix potential null dereference bugs

[Michal Kazior]

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

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


Michał

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

Re: Number of Transmission retries

[Michal Kazior]

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

ath10k does not honour it.

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

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


Michał

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

Re: Question on "ath10k: document ofdm/5ghz rate offset with a macro"

[Michal Kazior]

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

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


Michał

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

Re: Any tips on where per-packet antenna selection could be pushed?

[Michal Kazior]

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

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

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

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

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

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


Michał

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

Re: Question on "ath10k: document ofdm/5ghz rate offset with a macro"

[Michal Kazior]

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

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


Michał

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

Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values

[Michal Kazior]

On 31 May 2016 at 10:44, jpo  wrote:
> Hello all,
> to implement a "Stealth feature", e.g. the WLAN network does not show up in
> normal Scans, we modified the Frame version, Beacon and Probe-Response
> values for an old ATH5K card running on the now dormant Madwifi driver.
> Question: Is the same thing even POSSIBLE with ath10k? My main concern is,
> that the firmware just won't handle non-standard values.
>
> Can somebody who understands the division of labor between mac80211, ath10k,
> the firmware and the hardware suppress his or her gag reflex long enough to
> think about this?

First and foremost you'll need to use firmware with "raw-mode" support
- otherwise firmware just craps over frame headers. Some 10.2.4
support it - you can look into the mailing list archive for some
discussions.

Not sure if Rx will work though as firmware-controlled Rx filters may
prevent you from receiving frames with crazy frame_control values.
You'll need to check this out yourself. Some firmware revisions might
have RX_FILTER wmi command support but this isn't used/documented
anywhere and it's questionable how much it allows you to override.

Whatever you find it'd be nice if you post whatever you find out (for
posterity :)


Michał

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

Re: DFS fails with QCA6174 and QCA9377

[Michal Kazior]

On 21 May 2016 at 16:19, The Dark Avenger  wrote:
> Hello,
>
> I'm currently trying to set-up an AP in the 5 GHz band. I have a QCA6174
> (Killer 1525) and a QCA9377 adapter at hand.
>
> Unfortunately, while both cards work otherwise well, e.g. I can create an AP
> in the 2.4 GHz range, ACS works,  anything requiring DFS fails:
[...]
> The only thing that worries me is that "iw list" does not report any "radar
> detect widths".|.
> |So, I am somewhat clueless where the problem lies.  Is it driver, firmware,
> or something else?

I suspect hardware does not support it. Firmware already advertises no
support for AP_DFS service and driver follows suit and does not define
any radar_detect_widths in interface combinations for these chips.


Michał

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

[RFC/RFT] ath10k: disable wake_tx_queue for older devices

[Michal Kazior]

Some setups suffer performance regressions with
current wake_tx_queue implementation.

Signed-off-by: Michal Kazior <michal.kaz...@tieto.com>
---
Hi Roman,

Can you give this patch a try and see if it helps
with your performance problems, please?


 drivers/net/wireless/ath/ath10k/core.h |  1 +
 drivers/net/wireless/ath/ath10k/mac.c  | 24 ++--
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 1379054000f9..44e7c2cd2e9b 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -657,6 +657,7 @@ struct ath10k_fw_components {
 struct ath10k {
struct ath_common ath_common;
struct ieee80211_hw *hw;
+   struct ieee80211_ops *ops;
struct device *dev;
u8 mac_addr[ETH_ALEN];
 
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 0e24f9ee8bff..5fa3888afa41 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7396,21 +7396,32 @@ static const struct ieee80211_channel 
ath10k_5ghz_channels[] = {
 struct ath10k *ath10k_mac_create(size_t priv_size)
 {
struct ieee80211_hw *hw;
+   struct ieee80211_ops *ops;
struct ath10k *ar;
 
-   hw = ieee80211_alloc_hw(sizeof(struct ath10k) + priv_size, _ops);
-   if (!hw)
+   ops = kmemdup(_ops, sizeof(ath10k_ops), GFP_KERNEL);
+   if (!ops)
return NULL;
 
+   hw = ieee80211_alloc_hw(sizeof(struct ath10k) + priv_size, ops);
+   if (!hw) {
+   kfree(ops);
+   return NULL;
+   }
+
ar = hw->priv;
ar->hw = hw;
+   ar->ops = ops;
 
return ar;
 }
 
 void ath10k_mac_destroy(struct ath10k *ar)
 {
+   struct ieee80211_ops *ops = ar->ops;
+
ieee80211_free_hw(ar->hw);
+   kfree(ops);
 }
 
 static const struct ieee80211_iface_limit ath10k_if_limits[] = {
@@ -7838,6 +7849,15 @@ int ath10k_mac_register(struct ath10k *ar)
ath10k_warn(ar, "failed to initialise DFS pattern 
detector\n");
}
 
+   /* Current wake_tx_queue implementation imposes a significant
+* performance penalty in some setups. The tx scheduling code needs
+* more work anyway so disable the wake_tx_queue unless firmware
+* supports the pull-push mechanism.
+*/
+   if (!test_bit(ATH10K_FW_FEATURE_PEER_FLOW_CONTROL,
+ ar->running_fw->fw_file.fw_features))
+   ar->ops->wake_tx_queue = NULL;
+
ret = ath_regd_init(>ath_common.regulatory, ar->hw->wiphy,
ath10k_reg_notifier);
if (ret) {
-- 
2.1.4


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

Re: QCA9984 VHT160 support

[Michal Kazior]

+ re-adding ath10k list


On 17 May 2016 at 14:05, Sebastian Gottschall <s.gottsch...@dd-wrt.com> wrote:
>Am 17.05.2016 um 14:00 schrieb Michal Kazior:
>> On 17 May 2016 at 13:43, Sebastian Gottschall <s.gottsch...@dd-wrt.com> 
>> wrote:
>>> Attached you will find a testing patch for VHT160 support. i tested it today
>>> on a QCA9984 device and it seems to work.
>>> feel free to make any corrections
>> Hi,
>>
>> Send patches inline, please. Preferably via git send-email. It's a lot
>> easier to review them this way.
> unfortunaty i dont work with git right now and i wanted to send it to
> the list first for getting comments.
> since the patch is also very small, it should be that complicated
>>
>>  From a quick glance vht capabilities setup looks weird:
>>
>>> if (ar->vht_cap_info &  IEEE80211_VHT_CAP_SHORT_GI_160) {
>>>vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
>>>vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ;
>>> }
>> Why? Is this really necessary?
> the firmware does not report correct flags. just SHORT_GI_160.
> i reviewed the firmware sourcecodes and found out that this is maybe a
> misstake of the QCA developers.
> so we need to add the 160MHZ support flags locally using the
> SHORT_GI_160 which is always set on QCA9984.
> otherwise mac80211 will not be capable of running vht160.

I'm not sure if SGI160 implies 80+80.


>> I would expect IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ and
>> IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ to be already set in
>> ar->vht_cap_info if the chip supports 160 or 80+80.
>me too. but it isnt :-)

Sigh. A comment explaining that would be really nice.


>> You also don't seem to handle 80+80 because you just as phymode to 160
>> regardless of center frequencies:
>>
>>> !ath10k_peer_assoc_h_vht_masked(vht_mcs_mask)) {
>>> if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
>>>   phymode = MODE_11AC_VHT80;
>>> else if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
>>>   phymode = MODE_11AC_VHT160;
>>> else if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
>>>   phymode = MODE_11AC_VHT40;
>>> else if (sta->bandwidth == IEEE80211_STA_RX_BW_20)
> there is no 80+80 STA_RX_BW flag. i dont know how to handle this. and
> yes, just 160 mhz is tested right now. right now it looks like mac80211
> is not 80+80 ready.

Hmm.. I wouldn't advertise 80+80 support then. All the more since
there's no way of telling whether hw/fw actually supports it in the
first place.


Michal

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