QCA9887 firmware and WDS question

2017-11-09 Thread Andy Finkel
I'm trying to get an ath10k QCA9887 based radio working with WDS
stations.  Does anyone know if  firmware-5.bin_10.2.4-1.0-00029
supports WDS ?

The driver works fine using the QCA9887 card as an AP;

The same driver, running a QCA9882 based radio card works as a WDS
station, as well as an AP.

Is there a firmware version for the QCA9887 known to support WDS ?  If
so, I could test with that, and know any problems are in the driver.

Thanks,

Andy

--
Andy Finkel
Rajant Corp.

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


ath10k targaddrs issue

2017-11-09 Thread Ben Greear

While poking around in the firmware, I noticed what appears to be
an ath10k driver issue, which came in with this commit below.

commit 01d6fd6965eaf8d4b3aab681d30e77c53a834162
Author: Erik Stromdahl 
Date:   Wed Apr 26 12:17:55 2017 +0300

ath10k: various sdio related definitions

Debug masks for SDIO HIF layer.
Address definitions for SDIO/mbox based chipsets.
Augmented struct host_interest with more members.

Signed-off-by: Erik Stromdahl 
Signed-off-by: Kalle Valo 

...

diff --git a/drivers/net/wireless/ath/ath10k/targaddrs.h 
b/drivers/net/wireless/ath/ath10k/targaddrs.h
index cbac9e42..8bded5d 100644
--- a/drivers/net/wireless/ath/ath10k/targaddrs.h
+++ b/drivers/net/wireless/ath/ath10k/targaddrs.h
@@ -205,6 +205,24 @@ struct host_interest {
 */
/* Bit 1 - unused */
u32 hi_fw_swap; /* 0x104 */
+
+   /* global arenas pointer address, used by host driver debug */
+   u32 hi_dynamic_mem_arenas_addr; /* 0x108 */
+
+   /* allocated bytes of DRAM use by allocated */
+   u32 hi_dynamic_mem_allocated;   /* 0x10C */
+
+   /* remaining bytes of DRAM */
+   u32 hi_dynamic_mem_remaining;   /* 0x110 */
+
+   /* memory track count, configured by host */
+   u32 hi_dynamic_mem_track_max;   /* 0x114 */
+
+   /* minidump buffer */
+   u32 hi_minidump;/* 0x118 */
+
+   /* bdata's sig and key addr */
+   u32 hi_bd_sig_key;  /* 0x11c */
 } __packed;


Those variables above may be correct for some firmware, but they are not
correct for at least some versions of 10.4, which have this instead:

...
A_UINT32   hi_fw_swap;   /* 0x104 */

/* host side need to support tx/rx data packet swap */
A_UINT32   hi_txrx_dataswap;   /* 0x108 */  

/* enable allocram statistics gathering (set to an integer, which
 * is the number of tracking records that allocram will allocate).
 */
A_UINT32   hi_allocram_track_max; /* 0x108 
*/
}

I guess this may not be an issue as long as zero'd values are sent to the
10.4 nics, but it is confusing at best.

Eric, where did you get these values from?

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


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


[PATCH v2] ath10k: Re-enable TXQs for all devices

2017-11-09 Thread Toke Høiland-Jørgensen
Commit 4ca1807815aa6801aaced7fdefa9edacc2521767 disables the use of the
mac80211 TXQs for some devices because of a theoretical throughput
regression. The original regression report[1] was related to fq_codel
qdisc drop performance, which was fixed in
9d18562a227874289fda8ca5d117d8f503f1dcca. Since then, we have not seen
the TXQ-related regression, so it should be safe to re-enable TXQs.

[1] http://lists.infradead.org/pipermail/ath10k/2016-April/007266.html

Signed-off-by: Toke Høiland-Jørgensen 
---
This has been in LEDE trunk for a couple of months now with good
results.

Changes since v1:
- Update commit message to refer to original report and the fix for it.
- Add ath10k list to cc

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

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 0a947eef348d..ca596ecd2d64 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -8329,15 +8329,6 @@ 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 = ath10k_mac_init_rd(ar);
if (ret) {
ath10k_err(ar, "failed to derive regdom: %d\n", ret);
-- 
2.15.0


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


Re: [Make-wifi-fast] [PATCH] ath10k: Re-enable TXQs for all devices

2017-11-09 Thread Kalle Valo
Adding ath10k list to get this discussion to the list archive.

Dave Taht  writes:

> On Thu, Nov 9, 2017 at 4:10 PM, Toke Høiland-Jørgensen  wrote:
>> Rajkumar Manoharan  writes:
>>
 Commit 4ca1807815aa6801aaced7fdefa9edacc2521767 disables the use of the
 mac80211 TXQs for some devices because of a theoretical throughput
 regression. We have not seen this regression for a while now, so it should 
 be
 safe to re-enable TXQs.

 Signed-off-by: Toke Høiland-Jørgensen 
 ---
 This has been in LEDE trunk for a couple of months now with good results.

>>> Toke,
>>>
>>> Good to know that the performance drop is not seen with the chips that does 
>>> not
>>> have push-pull support. The issue was originally reported with ap152 + 
>>> qca988x
>>> by community [1]. Hope this combination is also considered in LEDE.
>>
>> Ah, was that the original bug report? Thank you, I have not been able to
>> find that anywhere!
>>
>> The issue that seems to point to has been fixed a while ago; I'll send
>> and updated patch with a better commit message (also forgot to cc the
>> ath10k list, I see).
>>
>> -Toke
>
> Hmm. I remember that thread. I thought we'd basically resolved that
> issue (45% of the time spent in fq_codel_drop under udp flood),
> back then, with eric adding the batch drop fix to fq_codel itself:
>
> See commit: 
> https://osdn.net/projects/android-x86/scm/git/kernel/commits/9d18562a227874289fda8ca5d117d8f503f1dcca
>
> which fixed up the problem beautifully:
>
> https://lists.bufferbloat.net/pipermail/make-wifi-fast/2016-May/000590.html
>
> So if we've been carrying this darn patch for the ath10k vs something
> that we'd actually fixed elsewhere in the stack, for over a year,
> sigh.

-- 
Kalle Valo

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


RE: [Make-wifi-fast] [PATCH] ath10k: Re-enable TXQs for all devices

2017-11-09 Thread Rajkumar Manoharan
> >
> > The issue that seems to point to has been fixed a while ago; I'll send
> > and updated patch with a better commit message (also forgot to cc the
> > ath10k list, I see).
> >
> > -Toke
> 
> Hmm. I remember that thread. I thought we'd basically resolved that issue (45%
> of the time spent in fq_codel_drop under udp flood), back then, with eric 
> adding
> the batch drop fix to fq_codel itself:
> 
> See commit: https://osdn.net/projects/android-
> x86/scm/git/kernel/commits/9d18562a227874289fda8ca5d117d8f503f1dcca
> 
> which fixed up the problem beautifully:
> 
> https://lists.bufferbloat.net/pipermail/make-wifi-fast/2016-May/000590.html
> 
> So if we've been carrying this darn patch for the ath10k vs something that 
> we'd
> actually fixed elsewhere in the stack, for over a year, sigh.
>
Dave,

Agree.. Even I am not fan of that patch in ath10k. IIRC Michal pushed this
change as temp one and planned to revert it once it is fixed in stack or in 
driver.

I thought Eric change in fq_codel is meant only for fatty udp flows. Forgive my 
ignorance.

-Rajkumar

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


RE: [Make-wifi-fast] [PATCH] ath10k: Re-enable TXQs for all devices

2017-11-09 Thread Toke Høiland-Jørgensen
Rajkumar Manoharan  writes:

> Agree.. Even I am not fan of that patch in ath10k. IIRC Michal pushed
> this change as temp one and planned to revert it once it is fixed in
> stack or in driver.
>
> I thought Eric change in fq_codel is meant only for fatty udp flows.
> Forgive my ignorance.

It is, mostly. There's a separate possible issue with TCP performance
that we're looking into, but that is unrelated to TXQs.

-Toke

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


QCA9984 ap mode with ath10k backport cannot be connect

2017-11-09 Thread 吳重毅
Hi:
Currently i am using latest backport git and linux-stable git tag
v4.13 to backport to my old linux4.2.8.
I am successfully enable the ap mode(with hostapd). Then i bridge(by
command brctl) the ap with wired port and i test connectivity with my
cell phone and laptop.

But unfortunately it stop at getting ip.

Is there any hint for me to do next?

Here is my dmesg log:
[  265.243823] Loading modules backported from Linux version v4.13.12-0-g0da7475
[  265.251009] Backport generated by backports.git v4.14-rc2-1-27-g75fadbc
[  265.322001] DMAR: 32bit :09:00.0 uses non-identity mapping
[  265.328015] ath10k_pci :09:00.0: enabling device ( -> 0002)
[  265.334794] ath10k_pci :09:00.0: pci irq msi oper_irq_mode 2
irq_mode 0 reset_mode 0
[  265.384951] DMAR: 32bit :0a:00.0 uses non-identity mapping
[  265.390950] ath10k_pci :0a:00.0: enabling device ( -> 0002)
[  265.397700] ath10k_pci :0a:00.0: pci irq msi oper_irq_mode 2
irq_mode 0 reset_mode 0
[  265.438563] ath10k_pci :09:00.0: qca9984/qca9994 hw1.0 target
0x0100 chip_id 0x sub 168c:cafe
[  265.448575] ath10k_pci :09:00.0: kconfig debug 1 debugfs 1
tracing 0 dfs 1 testmode 0
[  265.457469] ath10k_pci :09:00.0: firmware ver 10.4-3.4-00082
api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast
crc32 f301de65
[  265.501269] ath10k_pci :0a:00.0: qca9984/qca9994 hw1.0 target
0x0100 chip_id 0x sub 168c:cafe
[  265.511244] ath10k_pci :0a:00.0: kconfig debug 1 debugfs 1
tracing 0 dfs 1 testmode 0
[  265.520132] ath10k_pci :0a:00.0: firmware ver 10.4-3.4-00082
api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast
crc32 f301de65
[  266.233865] flashcache flashcache_ioctl 21297
[  266.238671] flashcache flashcache_ioctl 21297
[  266.893232] ath10k_pci :09:00.0: board_file api 2 bmi_id 0:1
crc32 751efba1
[  266.956378] ath10k_pci :0a:00.0: board_file api 2 bmi_id 0:2
crc32 751efba1
[  269.668870] ath10k_pci :09:00.0: htt-ver 2.2 wmi-op 6 htt-op 4
cal otp max-sta 512 raw 0 hwcrypto 1
[  269.725879] ath10k_pci :0a:00.0: htt-ver 2.2 wmi-op 6 htt-op 4
cal otp max-sta 512 raw 0 hwcrypto 1
[  269.738776] ath: EEPROM regdomain: 0x0
[  269.738783] ath: EEPROM indicates default country code should be used
[  269.738786] ath: doing EEPROM country->regdmn map search
[  269.738789] ath: country maps to regdmn code: 0x3a
[  269.738791] ath: Country alpha2 being used: US
[  269.738793] ath: Regpair used: 0x3a
[  269.787536] ath: EEPROM regdomain: 0x0
[  269.787543] ath: EEPROM indicates default country code should be used
[  269.787546] ath: doing EEPROM country->regdmn map search
[  269.787548] ath: country maps to regdmn code: 0x3a
[  269.787551] ath: Country alpha2 being used: US
[  269.787553] ath: Regpair used: 0x3a
[  270.576232] ath10k_pci :09:00.0 wifiap0: renamed from wlan0
[  270.614875] ath10k_pci :0a:00.0 wifiap1: renamed from wlan1
[  282.787675] cgroup: docker-runc (29079) created nested cgroup for
controller "memory" which has incomplete hierarchy support. Nested
cgroups may change behavior in the future.
[  282.803390] cgroup: "memory" requires setting use_hierarchy to 1 on the root
[  283.043295] init: Console is alive
[  284.047641] init: - preinit -
[  286.340061] mount_root: mounting /dev/root
[  286.377912] procd: - early -
[  287.045634] usbcore: registered new interface driver cdc_acm
[  287.051343] cdc_acm: USB Abstract Control Model driver for USB
modems and ISDN adapters
[  287.124529] procd: - ubus -
[  288.128172] procd: - init -
[  288.763949] systemd-udevd[31508]: starting version 204
[  289.503887] flashcache flashcache_ioctl 21297
[  289.508729] flashcache flashcache_ioctl 21297
[  298.770414] input: uinput-remotepad-rel_x_y as /devices/virtual/input/input7
[  301.199201] mce: [Hardware Error]: Machine check events logged
[  324.801796] flashcache flashcache_ioctl 21297
[  324.807034] flashcache flashcache_ioctl 21297
[  481.873314] device wifiap0 entered promiscuous mode
[  481.878335] wifibr0: port 2(wifiap0) entered forwarding state
[  481.884189] wifibr0: port 2(wifiap0) entered forwarding state
[  494.075176] flashcache flashcache_ioctl 21297
[  494.079927] flashcache flashcache_ioctl 21297
[  496.923462] wifibr0: port 2(wifiap0) entered forwarding state

Hostapd config:
wmm_enabled=1
ieee80211d=1
vht_capab=[MAX-MPDU-11454][RXLDPC][SHORT-GI-160][VHT160-80PLUS80][SHORT-GI-80][TX-STBC-2BY1][RX-STBC-1][MAX-A-MPDU-LEN-EXP7][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][SU-BEAMFORMER][SU-BEAMFORMEE][MU-BEAMFORMER][MU-BEAMFORMEE][BF-ANTENNA-4][SOUNDING-DIMENSION-4]
ssid=ath10k
ieee80211n=1
vht_oper_chwidth=1
driver=nl80211
ieee80211ac=1
ht_capab=[HT40+][SHORT-GI-20][SHORT-GI-40][RX-STBC1][DSSS_CCK-40][MAX-AMSDU-3839]
hw_mode=a
country_code=TW
uapsd_advertisement_enabled=1
interface=wifiap0
preamble=1
channel=0

Then, i use iw connect command with PC to connect ap and get
dmesg as below:

[2355824.803400] wlp1s0: authenti

Re: QCA9887 firmware and WDS question

2017-11-09 Thread Sebastian Gottschall

Am 09.11.2017 um 16:54 schrieb Andy Finkel:

I'm trying to get an ath10k QCA9887 based radio working with WDS
stations.  Does anyone know if  firmware-5.bin_10.2.4-1.0-00029
supports WDS ?

The driver works fine using the QCA9887 card as an AP;

The same driver, running a QCA9882 based radio card works as a WDS
station, as well as an AP.

Is there a firmware version for the QCA9887 known to support WDS ?  If
so, I could test with that, and know any problems are in the driver.
the firmware does support WDS. the QCA9887 is not different from the 
QCA9882. just different antenna count


Thanks,

Andy

--
Andy Finkel
Rajant Corp.

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



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


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


Re: QCA9984 ap mode with ath10k backport cannot be connect

2017-11-09 Thread Sebastian Gottschall
your hostapd config does not contain the bridge. beside this i wont see 
much details about your network  configuration.
the hostapd log shows the the client is leaving by itself. (local 
reason).  so the ap is working.
so check if your dhcp server is configured properly and fix yôur hostapd 
config to handle the bridged interface


bridge=wifibr0 is missing

your vht flags are wrong too.

vht_capab=[RXLDPC][SHORT-GI-80][SHORT-GI-160][TX-STBC-2BY1][RX-STBC-1][SU-BEAMFORMER][MU-BEAMFORMER][SU-BEAMFORMEE][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][MAX-MPDU-11454][VHT160-80PLUS80][MAX-A-MPDU-LEN-EXP7][BF-ANTENNA-2][SOUNDING-DIMENSION-2][BF-ANTENNA-3][SOUNDING-DIMENSION-3] 



would be correct for 9984 with full features (taken from my config)

so BF-ANTENNA-4 and SOUNDING-DIMENSION-4 is wrong


i have 9984 working without issues





Am 10.11.2017 um 04:46 schrieb 吳重毅:

Hi:
Currently i am using latest backport git and linux-stable git tag
v4.13 to backport to my old linux4.2.8.
I am successfully enable the ap mode(with hostapd). Then i bridge(by
command brctl) the ap with wired port and i test connectivity with my
cell phone and laptop.

But unfortunately it stop at getting ip.

Is there any hint for me to do next?

Here is my dmesg log:
[  265.243823] Loading modules backported from Linux version v4.13.12-0-g0da7475
[  265.251009] Backport generated by backports.git v4.14-rc2-1-27-g75fadbc
[  265.322001] DMAR: 32bit :09:00.0 uses non-identity mapping
[  265.328015] ath10k_pci :09:00.0: enabling device ( -> 0002)
[  265.334794] ath10k_pci :09:00.0: pci irq msi oper_irq_mode 2
irq_mode 0 reset_mode 0
[  265.384951] DMAR: 32bit :0a:00.0 uses non-identity mapping
[  265.390950] ath10k_pci :0a:00.0: enabling device ( -> 0002)
[  265.397700] ath10k_pci :0a:00.0: pci irq msi oper_irq_mode 2
irq_mode 0 reset_mode 0
[  265.438563] ath10k_pci :09:00.0: qca9984/qca9994 hw1.0 target
0x0100 chip_id 0x sub 168c:cafe
[  265.448575] ath10k_pci :09:00.0: kconfig debug 1 debugfs 1
tracing 0 dfs 1 testmode 0
[  265.457469] ath10k_pci :09:00.0: firmware ver 10.4-3.4-00082
api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast
crc32 f301de65
[  265.501269] ath10k_pci :0a:00.0: qca9984/qca9994 hw1.0 target
0x0100 chip_id 0x sub 168c:cafe
[  265.511244] ath10k_pci :0a:00.0: kconfig debug 1 debugfs 1
tracing 0 dfs 1 testmode 0
[  265.520132] ath10k_pci :0a:00.0: firmware ver 10.4-3.4-00082
api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast
crc32 f301de65
[  266.233865] flashcache flashcache_ioctl 21297
[  266.238671] flashcache flashcache_ioctl 21297
[  266.893232] ath10k_pci :09:00.0: board_file api 2 bmi_id 0:1
crc32 751efba1
[  266.956378] ath10k_pci :0a:00.0: board_file api 2 bmi_id 0:2
crc32 751efba1
[  269.668870] ath10k_pci :09:00.0: htt-ver 2.2 wmi-op 6 htt-op 4
cal otp max-sta 512 raw 0 hwcrypto 1
[  269.725879] ath10k_pci :0a:00.0: htt-ver 2.2 wmi-op 6 htt-op 4
cal otp max-sta 512 raw 0 hwcrypto 1
[  269.738776] ath: EEPROM regdomain: 0x0
[  269.738783] ath: EEPROM indicates default country code should be used
[  269.738786] ath: doing EEPROM country->regdmn map search
[  269.738789] ath: country maps to regdmn code: 0x3a
[  269.738791] ath: Country alpha2 being used: US
[  269.738793] ath: Regpair used: 0x3a
[  269.787536] ath: EEPROM regdomain: 0x0
[  269.787543] ath: EEPROM indicates default country code should be used
[  269.787546] ath: doing EEPROM country->regdmn map search
[  269.787548] ath: country maps to regdmn code: 0x3a
[  269.787551] ath: Country alpha2 being used: US
[  269.787553] ath: Regpair used: 0x3a
[  270.576232] ath10k_pci :09:00.0 wifiap0: renamed from wlan0
[  270.614875] ath10k_pci :0a:00.0 wifiap1: renamed from wlan1
[  282.787675] cgroup: docker-runc (29079) created nested cgroup for
controller "memory" which has incomplete hierarchy support. Nested
cgroups may change behavior in the future.
[  282.803390] cgroup: "memory" requires setting use_hierarchy to 1 on the root
[  283.043295] init: Console is alive
[  284.047641] init: - preinit -
[  286.340061] mount_root: mounting /dev/root
[  286.377912] procd: - early -
[  287.045634] usbcore: registered new interface driver cdc_acm
[  287.051343] cdc_acm: USB Abstract Control Model driver for USB
modems and ISDN adapters
[  287.124529] procd: - ubus -
[  288.128172] procd: - init -
[  288.763949] systemd-udevd[31508]: starting version 204
[  289.503887] flashcache flashcache_ioctl 21297
[  289.508729] flashcache flashcache_ioctl 21297
[  298.770414] input: uinput-remotepad-rel_x_y as /devices/virtual/input/input7
[  301.199201] mce: [Hardware Error]: Machine check events logged
[  324.801796] flashcache flashcache_ioctl 21297
[  324.807034] flashcache flashcache_ioctl 21297
[  481.873314] device wifiap0 entered promiscuous mode
[  481.878335] wifibr0: port 2(wifiap0) entered forwarding state
[  481.884189] wif