Re: [PATCH] mac80211: allow AP_VLAN operation on crypto controlled devices

[Sebastian Gottschall]

yes you just missed that ap_vlan is used for 4addr ap's / wds too so 
that might be related to the weired handling


Sebastian

Am 02.12.2018 um 14:02 schrieb Alexander Wetzel:

Hello,


From: Manikanta Pubbisetty 

In the current implementation, mac80211 advertises the support of
AP_VLANs based on the driver's support for AP mode; it also
blocks encrypted AP_VLAN operation on devices advertising
SW_CRYPTO_CONTROL.

The implementation seems weird in it's current form and could be
often confusing, this is because there can be drivers advertising
both SW_CRYPTO_CONTROL and AP mode support (ex: ath10k) in which case
AP_VLAN will still be supported but only in open BSS and not in
secured BSS.

When SW_CRYPTO_CONTROL is enabled, it makes more sense if the decision
to support AP_VLANs is left to the driver. Mac80211 can then allow
AP_VLAN operations depending on the driver support.


This first part of the patch contradicts my current understanding of 
how Software crypto fallback can be triggered: We have a driver 
actively telling us to only fall back to sw crypto when it returns 1 
on set_key, BUT we ignore that when the interface is set to 
@NL80211_IFTYPE_AP_VLAN and allow software encryption unconditionally?


Here the code:
    case WLAN_CIPHER_SUITE_GCMP:
    case WLAN_CIPHER_SUITE_GCMP_256:
    /* all of these we can do in software - if driver can */
    if (ret == 1)
    return 0;
    if (ieee80211_hw_check(>local->hw,
   SW_CRYPTO_CONTROL)) {
    if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
    return 0;
    return -EINVAL;
    }
    return 0;
    default:
    return -EINVAL;
    }


Wouldn't it be preferable to just return "ret" or "-EINVAL" instead of 
"0" when the interface has @NL80211_IFTYPE_AP_VLAN set?

As it is this basically overrides SW_CRYPTO_CONTROL in AP Vlan mode!

For me it looks like the old behavior in this section was already fine 
and does not hurt the intention of this patch: A driver setting 
SW_CRYPTO_CONTROL won't get support for AP VLANs as long as the driver 
is not opting in to it.


Therefore I would like to undo this part of the patch again:

-    if (ieee80211_hw_check(>local->hw,
   SW_CRYPTO_CONTROL))
+    if (ieee80211_hw_check(>local->hw,
   SW_CRYPTO_CONTROL)) {
+    if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+    return 0;
 return -EINVAL;
+    }


Do I miss something here and would anyone have issues when I revert 
that in another patch?


Alexander

Re: Netgear R7800 - ath10k QCA 9984 firmware crash

[Sebastian Gottschall]

btw. you can do the backup also with openwrt of course. i just need a 
backup of the flash memory. ben already wrote that my guess about a 
different location for the calibration data storage might be true. so 
find out the correct location i need to analyse the flash dump


Am 21.09.2018 um 11:35 schrieb Sebastian Gottschall:
you may use the backup function at Administration->backup which 
creates a file for download


or from commandline use "nvram backup /tmp/mybackup.bin"

for full flash backup on the r7800 do

cat /proc/mtd which shows

mtd0: 00c8 0002 "qcadata"
mtd1: 0050 0002 "APPSBL"
mtd2: 0008 0002 "APPSBLENV"
mtd3: 0014 0002 "art"
mtd4: 0014 0002 "artbak"
mtd5: 01e0 0002 "linux"
mtd6: 01be 0002 "rootfs"
mtd7: 0020 0002 "nvram"
mtd8: 0200 0002 "ddwrt"
mtd9: 0064 0002 "reserved"


then do a backup of all partitions with

cat /dev/mtdblock0 > /tmp/mtdblock0.bin and so on

then copy them with scp to your local computer. you may need to enable 
ssh server first at services->ssh


Am 20.09.2018 um 14:02 schrieb Bruno Rosset:

Hi Sebastian,

OK no problem. I can do that.
Can you just tell me what you need ; I mean which commands to export 
data ?

For nvram I guess you need 'nvram show' results ?

How I can do a "full flash transfer" ?

As you're dd-wrt dev,  I add that I try last dd-wrt build  (this one :
https://download1.dd-wrt.com/dd-wrtv2/downloads/betas/2018/08-22-2018-r36698/netgear-r7800/factory-to-ddwrt.img) 


which not even boot. Same with kong one (this one :
http://www.desipro.de/ddwrt/K3-AC-IPQ806X/Test/R7800-factory-to-ddwrt.img) 



thats not the latest

ftp://ftp.dd-wrt.com/betas/2018/09-19-2018-r36995/netgear-r7800/factory-to-ddwrt.img 



i tested this also on my devices

so if these other versions you mentioned wont boot on your device it 
already looks strange since i test the r7800 always with each released 
build. the builds from desipro.de are external and not watched by me


these are test builds by a contributor




What I made is that I extract the board-2.bin & fiurmware-5.bin from
the ddwrt's squashfs image and try them on the openWRT install, but
without success also.


the board-2.bin is not the one you need. the real board data is 
generated at /tmp folder from flash partition content and named 
/tmp/board1.bin and /tmp/board2.bin for each of both wireless devices





Best regards,
Bruno
Le jeu. 20 sept. 2018 à 13:07, Sebastian Gottschall
 a écrit :
since i'm mainly the dd-wrt developer and you tested it as well with 
the

same reproduceable crash it would be nice if you could provide me a
nvram backup with a reproduceable crash (you should change passwords of
course) to my private email. so i can apply it to my device and to see
whats happen. if you have a beta device i just can guess that the
calibration data which is stored in flash memory has maybe a different
location, so openwrt as well as dd-wrt uses crap to initialize the
hardware. this is just a guess. but i have 2 r7800 factory models. you
can also send me a full flash backup of your device using 
wetransfer, so

i can compare the content with my device and check if there is a flash
layout specific different. this would help to track down the problem
cause and maybe find a specific workaround for such devices by 
detecting

them well

Sebastian

Am 20.09.2018 um 09:44 schrieb Bruno Rosset:

HI Sebastian,

I just flash the r7800 with the openwrt 18.06.1 factory image (here :
https://downloads.openwrt.org/releases/18.06.1/targets/ipq806x/generic/openwrt-18.06.1-ipq806x-netgear_r7800-squashfs-factory.img) 



I forgot to mention that I get a beta hardware of the R7800, perhaps
there is something different in my hardware compared to the released
one.

Regards,
Bruno
Le jeu. 20 sept. 2018 à 08:36, Sebastian Gottschall
 a écrit :
can you tell me how to reproduce this crash? i have 2 r7800 
running with

dd-wrt but no crashes

Am 19.09.2018 um 22:37 schrieb Bruno Rosset:

Hi all,

I get a firmware crash using latest openwrt 18.06.1 on the Netgear
R7800 with stock firmware
Dmesg is :
[   13.804366] ath10k_pci :01:00.0: assign IRQ: got 67
[   13.804805] ath10k_pci :01:00.0: enabling device (0140 -> 
0142)

[   13.804887] ath10k_pci :01:00.0: enabling bus mastering
[   13.805346] ath10k_pci :01:00.0: pci irq msi oper_irq_mode 2
irq_mode 0 reset_mode 0
[   13.974787] ath10k_pci :01:00.0: Direct firmware load for
ath10k/pre-cal-pci-:01:00.0.bin failed with error -2
[   13.974827] ath10k_pci :01:00.0: Falling back to user helper
[   14.304794] ath10k_pci :01:00.0: Direct firmware load for
ath10k/QCA9984/hw1.0/firmware-6.bin failed with error -2
[   14.304857] ath10k_pci :01:00.0: Falling back to user helper
[   14.337111] firmware ath10k!QCA9984!hw1.0!firmware-6.bin:
firmwar

Re: Netgear R7800 - ath10k QCA 9984 firmware crash

[Sebastian Gottschall]

you may use the backup function at Administration->backup which creates 
a file for download


or from commandline use "nvram backup /tmp/mybackup.bin"

for full flash backup on the r7800 do

cat /proc/mtd which shows

mtd0: 00c8 0002 "qcadata"
mtd1: 0050 0002 "APPSBL"
mtd2: 0008 0002 "APPSBLENV"
mtd3: 0014 0002 "art"
mtd4: 0014 0002 "artbak"
mtd5: 01e0 0002 "linux"
mtd6: 01be 0002 "rootfs"
mtd7: 0020 0002 "nvram"
mtd8: 0200 0002 "ddwrt"
mtd9: 0064 0002 "reserved"


then do a backup of all partitions with

cat /dev/mtdblock0 > /tmp/mtdblock0.bin and so on

then copy them with scp to your local computer. you may need to enable 
ssh server first at services->ssh


Am 20.09.2018 um 14:02 schrieb Bruno Rosset:

Hi Sebastian,

OK no problem. I can do that.
Can you just tell me what you need ; I mean which commands to export data ?
For nvram I guess you need 'nvram show' results ?

How I can do a "full flash transfer" ?

As you're dd-wrt dev,  I add that I try last dd-wrt build  (this one :
https://download1.dd-wrt.com/dd-wrtv2/downloads/betas/2018/08-22-2018-r36698/netgear-r7800/factory-to-ddwrt.img)
which not even boot. Same with kong one (this one :
http://www.desipro.de/ddwrt/K3-AC-IPQ806X/Test/R7800-factory-to-ddwrt.img)


thats not the latest

ftp://ftp.dd-wrt.com/betas/2018/09-19-2018-r36995/netgear-r7800/factory-to-ddwrt.img

i tested this also on my devices

so if these other versions you mentioned wont boot on your device it 
already looks strange since i test the r7800 always with each released 
build. the builds from desipro.de are external and not watched by me


these are test builds by a contributor




What I made is that I extract the board-2.bin & fiurmware-5.bin from
the ddwrt's squashfs image and try them on the openWRT install, but
without success also.


the board-2.bin is not the one you need. the real board data is 
generated at /tmp folder from flash partition content and named 
/tmp/board1.bin and /tmp/board2.bin for each of both wireless devices





Best regards,
Bruno
Le jeu. 20 sept. 2018 à 13:07, Sebastian Gottschall
 a écrit :

since i'm mainly the dd-wrt developer and you tested it as well with the
same reproduceable crash it would be nice if you could provide me a
nvram backup with a reproduceable crash (you should change passwords of
course) to my private email. so i can apply it to my device and to see
whats happen. if you have a beta device i just can guess that the
calibration data which is stored in flash memory has maybe a different
location, so openwrt as well as dd-wrt uses crap to initialize the
hardware. this is just a guess. but i have 2 r7800 factory models. you
can also send me a full flash backup of your device using wetransfer, so
i can compare the content with my device and check if there is a flash
layout specific different. this would help to track down the problem
cause and maybe find a specific workaround for such devices by detecting
them well

Sebastian

Am 20.09.2018 um 09:44 schrieb Bruno Rosset:

HI Sebastian,

I just flash the r7800 with the openwrt 18.06.1 factory image (here :
https://downloads.openwrt.org/releases/18.06.1/targets/ipq806x/generic/openwrt-18.06.1-ipq806x-netgear_r7800-squashfs-factory.img)

I forgot to mention that I get a beta hardware of the R7800, perhaps
there is something different in my hardware compared to the released
one.

Regards,
Bruno
Le jeu. 20 sept. 2018 à 08:36, Sebastian Gottschall
 a écrit :

can you tell me how to reproduce this crash? i have 2 r7800 running with
dd-wrt but no crashes

Am 19.09.2018 um 22:37 schrieb Bruno Rosset:

Hi all,

I get a firmware crash using latest openwrt 18.06.1 on the Netgear
R7800 with stock firmware
Dmesg is :
[   13.804366] ath10k_pci :01:00.0: assign IRQ: got 67
[   13.804805] ath10k_pci :01:00.0: enabling device (0140 -> 0142)
[   13.804887] ath10k_pci :01:00.0: enabling bus mastering
[   13.805346] ath10k_pci :01:00.0: pci irq msi oper_irq_mode 2
irq_mode 0 reset_mode 0
[   13.974787] ath10k_pci :01:00.0: Direct firmware load for
ath10k/pre-cal-pci-:01:00.0.bin failed with error -2
[   13.974827] ath10k_pci :01:00.0: Falling back to user helper
[   14.304794] ath10k_pci :01:00.0: Direct firmware load for
ath10k/QCA9984/hw1.0/firmware-6.bin failed with error -2
[   14.304857] ath10k_pci :01:00.0: Falling back to user helper
[   14.337111] firmware ath10k!QCA9984!hw1.0!firmware-6.bin:
firmware_loading_store: map pages failed
[   14.702947] ath10k_pci :01:00.0: qca9984/qca9994 hw1.0 target
0x0100 chip_id 0x sub 168c:cafe
[   14.702997] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1
tracing 0 dfs 1 testmode 1
[   14.716459] ath10k_pci :01:00.0: firmware ver 10.4-3.5.3-00053
api 5 features no-p2p,mfp,peer-flow-ctrl

Re: Netgear R7800 - ath10k QCA 9984 firmware crash

[Sebastian Gottschall]

since i'm mainly the dd-wrt developer and you tested it as well with the 
same reproduceable crash it would be nice if you could provide me a 
nvram backup with a reproduceable crash (you should change passwords of 
course) to my private email. so i can apply it to my device and to see 
whats happen. if you have a beta device i just can guess that the 
calibration data which is stored in flash memory has maybe a different 
location, so openwrt as well as dd-wrt uses crap to initialize the 
hardware. this is just a guess. but i have 2 r7800 factory models. you 
can also send me a full flash backup of your device using wetransfer, so 
i can compare the content with my device and check if there is a flash 
layout specific different. this would help to track down the problem 
cause and maybe find a specific workaround for such devices by detecting 
them well


Sebastian

Am 20.09.2018 um 09:44 schrieb Bruno Rosset:

HI Sebastian,

I just flash the r7800 with the openwrt 18.06.1 factory image (here :
https://downloads.openwrt.org/releases/18.06.1/targets/ipq806x/generic/openwrt-18.06.1-ipq806x-netgear_r7800-squashfs-factory.img)

I forgot to mention that I get a beta hardware of the R7800, perhaps
there is something different in my hardware compared to the released
one.

Regards,
Bruno
Le jeu. 20 sept. 2018 à 08:36, Sebastian Gottschall
 a écrit :

can you tell me how to reproduce this crash? i have 2 r7800 running with
dd-wrt but no crashes

Am 19.09.2018 um 22:37 schrieb Bruno Rosset:

Hi all,

I get a firmware crash using latest openwrt 18.06.1 on the Netgear
R7800 with stock firmware
Dmesg is :
[   13.804366] ath10k_pci :01:00.0: assign IRQ: got 67
[   13.804805] ath10k_pci :01:00.0: enabling device (0140 -> 0142)
[   13.804887] ath10k_pci :01:00.0: enabling bus mastering
[   13.805346] ath10k_pci :01:00.0: pci irq msi oper_irq_mode 2
irq_mode 0 reset_mode 0
[   13.974787] ath10k_pci :01:00.0: Direct firmware load for
ath10k/pre-cal-pci-:01:00.0.bin failed with error -2
[   13.974827] ath10k_pci :01:00.0: Falling back to user helper
[   14.304794] ath10k_pci :01:00.0: Direct firmware load for
ath10k/QCA9984/hw1.0/firmware-6.bin failed with error -2
[   14.304857] ath10k_pci :01:00.0: Falling back to user helper
[   14.337111] firmware ath10k!QCA9984!hw1.0!firmware-6.bin:
firmware_loading_store: map pages failed
[   14.702947] ath10k_pci :01:00.0: qca9984/qca9994 hw1.0 target
0x0100 chip_id 0x sub 168c:cafe
[   14.702997] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1
tracing 0 dfs 1 testmode 1
[   14.716459] ath10k_pci :01:00.0: firmware ver 10.4-3.5.3-00053
api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps
crc32 4c56a386
[   15.973104] ath10k_pci :01:00.0: board_file api 2 bmi_id 0:31
crc32 dd6d039c
[   19.753460] ath10k_pci :01:00.0: firmware crashed! (guid
ca7089d2-df9a-4f9d-8fa6-d1b908cf3220)
[   19.753494] ath10k_pci :01:00.0: qca9984/qca9994 hw1.0 target
0x0100 chip_id 0x sub 168c:cafe
[   19.761307] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1
tracing 0 dfs 1 testmode 1
[   19.773202] ath10k_pci :01:00.0: firmware ver 10.4-3.5.3-00053
api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps
crc32 4c56a386
[   19.779887] ath10k_pci :01:00.0: board_file api 2 bmi_id 0:31
crc32 dd6d039c
[   19.793511] ath10k_pci :01:00.0: htt-ver 0.0 wmi-op 6 htt-op 4
cal pre-cal-file max-sta 32 raw 0 hwcrypto 1
[   19.803176] ath10k_pci :01:00.0: firmware register dump:
[   19.810956] ath10k_pci :01:00.0: [00]: 0x0100 0x15B3
0x009CBB38 0x00975B31
[   19.816861] ath10k_pci :01:00.0: [04]: 0x009CBB38 0x00060530
0x0011 0x00415760
[   19.824587] ath10k_pci :01:00.0: [08]: 0x00417E6C 0x0040
0x0001 0x00422990
[   19.832485] ath10k_pci :01:00.0: [12]: 0x0009 0x
0x00973B25 0x00973B47
[   19.840384] ath10k_pci :01:00.0: [16]: 0x009CBB38 0x000CEEA7
0x 0x
[   19.848284] ath10k_pci :01:00.0: [20]: 0x409CBB38 0x004068DC
0x0001 0x00403628
[   19.856183] ath10k_pci :01:00.0: [24]: 0x809814EF 0x0040693C
0x0049 0xC09CBB38
[   19.864083] ath10k_pci :01:00.0: [28]: 0x800DF216 0x004069AC
0x0004 0x00415300
[   19.871983] ath10k_pci :01:00.0: [32]: 0x800C383A 0x004069DC
0x00415160 0x0040
[   19.879881] ath10k_pci :01:00.0: [36]: 0x809800A3 0x00406A0C
0x00415170 0x009C41F8
[   19.887781] ath10k_pci :01:00.0: [40]: 0x8098003A 0x00406A5C
0x0040 0x00400600
[   19.895680] ath10k_pci :01:00.0: [44]: 0x809607C1 0x00406A8C
0xD8400100 0x00406A9C
[   19.903579] ath10k_pci :01:00.0: [48]: 0x80960892 0x00406AAC
0x 0x0008
[   19.911479] ath10k_pci :01:00.0: [52]: 0x80960E39 0x00406ACC
0x0040 0x00400600
[   19.919378] ath10k_pci :01:00.0: [56]: 0x80960E9D 0x00406AEC
0x 0x00400600
[   19.927277] ath10k_pci :01:00.0: Copy Engine register d

Re: Netgear R7800 - ath10k QCA 9984 firmware crash

[Sebastian Gottschall]

can you tell me how to reproduce this crash? i have 2 r7800 running with 
dd-wrt but no crashes


Am 19.09.2018 um 22:37 schrieb Bruno Rosset:

Hi all,

I get a firmware crash using latest openwrt 18.06.1 on the Netgear
R7800 with stock firmware
Dmesg is :
[   13.804366] ath10k_pci :01:00.0: assign IRQ: got 67
[   13.804805] ath10k_pci :01:00.0: enabling device (0140 -> 0142)
[   13.804887] ath10k_pci :01:00.0: enabling bus mastering
[   13.805346] ath10k_pci :01:00.0: pci irq msi oper_irq_mode 2
irq_mode 0 reset_mode 0
[   13.974787] ath10k_pci :01:00.0: Direct firmware load for
ath10k/pre-cal-pci-:01:00.0.bin failed with error -2
[   13.974827] ath10k_pci :01:00.0: Falling back to user helper
[   14.304794] ath10k_pci :01:00.0: Direct firmware load for
ath10k/QCA9984/hw1.0/firmware-6.bin failed with error -2
[   14.304857] ath10k_pci :01:00.0: Falling back to user helper
[   14.337111] firmware ath10k!QCA9984!hw1.0!firmware-6.bin:
firmware_loading_store: map pages failed
[   14.702947] ath10k_pci :01:00.0: qca9984/qca9994 hw1.0 target
0x0100 chip_id 0x sub 168c:cafe
[   14.702997] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1
tracing 0 dfs 1 testmode 1
[   14.716459] ath10k_pci :01:00.0: firmware ver 10.4-3.5.3-00053
api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps
crc32 4c56a386
[   15.973104] ath10k_pci :01:00.0: board_file api 2 bmi_id 0:31
crc32 dd6d039c
[   19.753460] ath10k_pci :01:00.0: firmware crashed! (guid
ca7089d2-df9a-4f9d-8fa6-d1b908cf3220)
[   19.753494] ath10k_pci :01:00.0: qca9984/qca9994 hw1.0 target
0x0100 chip_id 0x sub 168c:cafe
[   19.761307] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1
tracing 0 dfs 1 testmode 1
[   19.773202] ath10k_pci :01:00.0: firmware ver 10.4-3.5.3-00053
api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps
crc32 4c56a386
[   19.779887] ath10k_pci :01:00.0: board_file api 2 bmi_id 0:31
crc32 dd6d039c
[   19.793511] ath10k_pci :01:00.0: htt-ver 0.0 wmi-op 6 htt-op 4
cal pre-cal-file max-sta 32 raw 0 hwcrypto 1
[   19.803176] ath10k_pci :01:00.0: firmware register dump:
[   19.810956] ath10k_pci :01:00.0: [00]: 0x0100 0x15B3
0x009CBB38 0x00975B31
[   19.816861] ath10k_pci :01:00.0: [04]: 0x009CBB38 0x00060530
0x0011 0x00415760
[   19.824587] ath10k_pci :01:00.0: [08]: 0x00417E6C 0x0040
0x0001 0x00422990
[   19.832485] ath10k_pci :01:00.0: [12]: 0x0009 0x
0x00973B25 0x00973B47
[   19.840384] ath10k_pci :01:00.0: [16]: 0x009CBB38 0x000CEEA7
0x 0x
[   19.848284] ath10k_pci :01:00.0: [20]: 0x409CBB38 0x004068DC
0x0001 0x00403628
[   19.856183] ath10k_pci :01:00.0: [24]: 0x809814EF 0x0040693C
0x0049 0xC09CBB38
[   19.864083] ath10k_pci :01:00.0: [28]: 0x800DF216 0x004069AC
0x0004 0x00415300
[   19.871983] ath10k_pci :01:00.0: [32]: 0x800C383A 0x004069DC
0x00415160 0x0040
[   19.879881] ath10k_pci :01:00.0: [36]: 0x809800A3 0x00406A0C
0x00415170 0x009C41F8
[   19.887781] ath10k_pci :01:00.0: [40]: 0x8098003A 0x00406A5C
0x0040 0x00400600
[   19.895680] ath10k_pci :01:00.0: [44]: 0x809607C1 0x00406A8C
0xD8400100 0x00406A9C
[   19.903579] ath10k_pci :01:00.0: [48]: 0x80960892 0x00406AAC
0x 0x0008
[   19.911479] ath10k_pci :01:00.0: [52]: 0x80960E39 0x00406ACC
0x0040 0x00400600
[   19.919378] ath10k_pci :01:00.0: [56]: 0x80960E9D 0x00406AEC
0x 0x00400600
[   19.927277] ath10k_pci :01:00.0: Copy Engine register dump:
[   19.935181] ath10k_pci :01:00.0: [00]: 0x0004a000  11  11  12  11
[   19.940994] ath10k_pci :01:00.0: [01]: 0x0004a400  11  11  10  11
[   19.947590] ath10k_pci :01:00.0: [02]: 0x0004a800   0   0  63   0
[   19.954014] ath10k_pci :01:00.0: [03]: 0x0004ac00   0   0   0   0
[   19.960439] ath10k_pci :01:00.0: [04]: 0x0004b000   0   0   0   0
[   19.966862] ath10k_pci :01:00.0: [05]: 0x0004b400   0   0   0   0
[   19.973285] ath10k_pci :01:00.0: [06]: 0x0004b800   0   0   0   0
[   19.979709] ath10k_pci :01:00.0: [07]: 0x0004bc00   1   1   1   1
[   19.986132] ath10k_pci :01:00.0: [08]: 0x0004c000   0   0 127   0
[   19.992556] ath10k_pci :01:00.0: [09]: 0x0004c400   1   1   1   1
[   19.998980] ath10k_pci :01:00.0: [10]: 0x0004c800   0   0   0   0
[   20.005403] ath10k_pci :01:00.0: [11]: 0x0004cc00   0   0   0   0
[   20.795948] ath10k_pci :01:00.0: failed to receive control
response completion, polling..
[   21.835766] ath10k_pci :01:00.0: ctl_resp never came in (-110)
[   21.835810] ath10k_pci :01:00.0: failed to connect to HTC: -110
[   21.915174] ath10k_pci :01:00.0: could not init core (-110)
[   21.915620] ath10k_pci :01:00.0: could not probe fw (-110)
[   21.920266] ath10k_pci 0001:01:00.0: assign IRQ: got 100
[   21.921197] ath10k_pci 0001:01:00.0: enabling device (0140 

Re: ath9k and 16 VAP interfaces?

[Sebastian Gottschall]

for standard ath9k. (non htc) the following is just enough

Index: init.c
===
--- init.c  (revision 4145)
+++ init.c  (working copy)
@@ -735,7 +735,7 @@

 static const struct ieee80211_iface_limit if_limits[] = {
    { .max = 2048,  .types = BIT(NL80211_IFTYPE_STATION) },
-   { .max = 8, .types =
+   { .max = 16,    .types =
 #ifdef CPTCFG_MAC80211_MESH
 BIT(NL80211_IFTYPE_MESH_POINT) |
 #endif



but for sure i havent tested it


Am 30.07.2018 um 22:04 schrieb Tom Psyborg:
this is how i enabled it on htc target: 
https://github.com/torvalds/linux/pull/574


On 30 July 2018 at 16:34, Ben Greear > wrote:




On 07/30/2018 04:13 AM, Matthias May wrote:

On 30/07/18 11:40, michael-...@fami-braun.de
 wrote:

Do you mean AP interfaces as required for multiple BSS/SSIDs?

I'm running a patched ath9k to have hostapd run >8 BSS on
a single radio.
It works fine since years.


Yes, I'd love to see any patches you can share on this as well.

Thanks,
Ben



Regards,
M. Braun


Am 27. Juli 2018 15:35:28 MESZ schrieb Ben Greear
mailto:gree...@candelatech.com>>:

Hello,

Has anyone tried making ath9k able to support 16 vAP
interfaces on a
single
radio?  I seem to recall that there were limitations
regarding beacon
timers and such, and that is why the current limit is 8?

Thanks,
Ben

--
Ben Greear mailto:gree...@candelatech.com>>
Candela Technologies Inc http://www.candelatech.com



Are these patches available somewhere?
I'm interested to play with them :)

BR
Matthias


-- 
Ben Greear mailto:gree...@candelatech.com>>

Candela Technologies Inc http://www.candelatech.com

Re: [PATCH v1] ath10k: fix band_center_freq handling for VHT160 in recent firmwares

[Sebastian Gottschall]

Am 25.05.2018 um 16:52 schrieb Ben Greear:

On 05/25/2018 07:44 AM, Kalle Valo wrote:

Sebastian Gottschall <s.gottsch...@dd-wrt.com> writes:


Am 26.04.2018 um 15:44 schrieb Ben Greear:



On 04/26/2018 02:43 AM, s.gottsch...@dd-wrt.com wrote:

From: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

starting with firmware 10.4.3.4.x series QCA changed the handling
of the channel property band_center_freq1 and band_center_freq2 in
vht160 operation mode
likelly for backward compatiblity with vht80 only capable clients.
this patch adjusts the handling to get vht160 to work again with
official qca firmwares newer than 3.3
consider that this patch will not work with older firmwares
anymore. to avoid undefined behaviour this we disable vht160
capability for outdated firmwares


We should be able to use a feature-flag or otherwise determine if
the firmware needs the old or new
API and make the driver able to handle both.


the new firmware must be used as is and it works. the old firmware can
be detected on the missing vht cap flag.
but thats not my task. i can only use feature flags if they are
included within the qca firmwares. but they arent
the old pre 3.3 firmwares should be treated as obsolete. they are more
than 2 years old and do not announce vht160 capability
even if it works with some ignorance, but on the other side the it has
backward incompatiblies with older vht80 only clients.
this is why the new way was introduced


I was told ath10k could check for WMI_SERVICE_EXTENDED_NSS_SUPPORT flag.
Can someone test and verify that?



I do see that my firmware source based on older upstream QCA FW does 
not advertise
that flag, and newer QCA firmware does, so it would appear that test 
might

work.
but your sourcebase is new enough that this new handling is required.  
if i remember correct this handling is required starting with 10.4-3.4 
source base
if a 3.4 original firmware is not providing that flag, it cannot be used 
for correct handling and yours is 3.4 based


Thanks,
Ben

Re: [PATCH] ath10k: add dynamic vlan support

[Sebastian Gottschall]

Am 23.05.2018 um 12:39 schrieb Johannes Berg:

On Wed, 2018-05-23 at 16:09 +0530, Manikanta Pubbisetty wrote:

+ * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting
+ * frames encrypted in software, only valid when SW_CRYPTO_CONTROL
+ * is enabled. Based on this flag, mac80211 can allow/disallow VLAN
+ * operations in the BSS.

Based on the name and initial description, this sounds equivalent to
just turning off SW_CRYPTO_CONTROL. I think that's not the intent, but
would need some renaming.

I can rename it to something which is very specific to VLAN support on
sw crypto controlled devices if that is okay.

I don't think that makes sense. If we split the capability of AP_VLAN
and AP_VLAN_FOR_4ADDR at the "root", then we don't need to play with all
these things. Yes, this is slightly awkward for userspace, and perhaps
with the interface combination checks, but I'd like you to look at that.


Makes sense, I had this thought to split the VLAN and 4-addr
functionality, but since we need to fiddle with userspace, I refrained.
Anyways, I will check all the possibilities of splitting these
functionalities.

I'm not sure we really have to - it's likely that wpa_s/hostapd don't
check the capabilities?
mmh not sure. it might not check the capabilitiy, but it sets the 
interface type to IFTYPE_AP_VLAN

for wds sta interfaces. that might collide

see the following snippet taken from hostapd code

static int i802_set_wds_sta(void *priv, const u8 *addr, int aid, int val,
    const char *bridge_ifname, char *ifname_wds)
{
    struct i802_bss *bss = priv;
    struct wpa_driver_nl80211_data *drv = bss->drv;
    char name[IFNAMSIZ + 1];

    os_snprintf(name, sizeof(name), "%s.sta%d", bss->ifname, aid);
    if (ifname_wds)
    os_strlcpy(ifname_wds, name, IFNAMSIZ + 1);

    wpa_printf(MSG_DEBUG, "nl80211: Set WDS STA addr=" MACSTR
   " aid=%d val=%d name=%s", MAC2STR(addr), aid, val, 
name);

    if (val) {
    if (!if_nametoindex(name)) {
    if (nl80211_create_iface(drv, name,
NL80211_IFTYPE_AP_VLAN,
 bss->addr, 1, NULL, 
NULL, 0) <

    0)
    return -1;
    if (bridge_ifname &&
linux_br_add_if(drv->global->ioctl_sock,
    bridge_ifname, name) < 0)
    return -1;
    }
    if (linux_set_iface_flags(drv->global->ioctl_sock, 
name, 1)) {
    wpa_printf(MSG_ERROR, "nl80211: Failed to set 
WDS STA "

   "interface %s up", name);
    }
    return i802_set_sta_vlan(priv, addr, name, 0);
    } else {
    if (bridge_ifname)
linux_br_del_if(drv->global->ioctl_sock, bridge_ifname,
    name);

    i802_set_sta_vlan(priv, addr, bss->ifname, 0);
    nl80211_remove_iface(drv, if_nametoindex(name));
    return 0;
    }
}




johannes

Re: [PATCH] ath10k: add dynamic vlan support

[Sebastian Gottschall]

Am 18.05.2018 um 11:54 schrieb Johannes Berg:

On Fri, 2018-05-04 at 12:20 +0530, Manikanta Pubbisetty wrote:

Johannes,

It seems like commit db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on
crypto controlled devices") has broken 4-addr operation on crypto
controlled devices as reported by sebastian.
The commit was mainly focused in addressing the problem in supporting
VLANs on crypto controlled devices but since 4-addr mode is also
dependent on AP_VLAN interface, this commit breaks the 4-addr AP mode.

Ok.

Do you know why it actually broke it? I mean, we should've turned off
the strict requirement for sw crypto control only for the GTK, and that
shouldn't matter so much?


I have couple of ideas on how to address the problem,

1) Add a new hw_flag and based on the hardware flag, allow/disallow the
creation of AP_VLAN interface.

+ * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting
+ * frames encrypted in software, only valid when SW_CRYPTO_CONTROL
+ * is enabled. Based on this flag, mac80211 can allow/disallow VLAN
+ * operations in the BSS.

Based on the name and initial description, this sounds equivalent to
just turning off SW_CRYPTO_CONTROL. I think that's not the intent, but
would need some renaming.


2) Allow mac80211 to call set_key for GTKs on AP_VLAN interfaces for
crypto controlled devices, let the driver decide whether to return '1'
or some error code based on their support for transmitting sw encrypted
frames. I am little skeptical with this approach as drivers are totally
unaware of AP_VLAN interfaces.

No, that won't work.

I'm unsure how 4-addr VLAN can work with ath10k either way?

Maybe it just doesn't normally need a GTK, so nothing broke before, but
your other patch changed things to remove VLAN and then of course it's
no longer available?

But then I don't understand the complaint that

So maybe the solution should be to add a separate flag for whether or
not 4-addr VLAN is supported?

johannes


let me explain. the vlan mode is used to create local interfaces in 
4addr mode


like wlan0.sta0, wlan0.sta1 per peer. this is required to put these 
peers into the local linux bridge since the local ap interface cannot


handle the bridging capabilities like correct forwarding, stp or even 
filtering. this is a long term behaviour since the beginning of ath9k.


so the ap_vlan feature is used to pass the frames per peer in a 
indepenened way. you may ask felix fietkau, since he developed it 
originally in madwifi


and later in mac80211 / ath9k. so ap_vlan capability is a requiredment 
for all 4addr capable wireless drivers.



example of a 4addr capable ap in ath10k with 2 connected 4addr stations

root@apreithalle:~# brctl show
bridge name bridge id   STP enabled interfaces
br0 8000.dcef09e4ce07   no  ath0
    ath0.1
    ath0.2
    ath0.sta1
    ath0.sta4
    ath1
    ath1.2
    eth0
    eth1

Re: [PATCH] ath10k: add dynamic vlan support

[Sebastian Gottschall]

Am 18.05.2018 um 11:53 schrieb Johannes Berg:

On Mon, 2018-04-23 at 21:18 +0200, Sebastian Gottschall wrote:

this patch makes no sense at some points. AP_VLAN must be enabled always
(it is enabled by mac80211 by default, but is now disabled in very
latest git version for drivers which announce sw_crypto support)
if its disabled wds ap / wds sta operation will not work anymore since
mac80211 uses AP_VLAN for the local wds sta interfaces

You'd do you well to learn the correct terminology used in Linux if you
try to communicate with us...

What you say there makes no sense, WDS is a separate mode. Maybe you
mean 4-addr mode?
yes 4-addr mode which is common known as WDS mode. (terminology used by 
all sorts of vendors)


Sebastian


johannes

Re: [PATCH v2] ath10k: support for multicast rate control

[Sebastian Gottschall]

Am 09.05.2018 um 08:15 schrieb Sven Eckelmann:

On Montag, 7. Mai 2018 18:34:51 CEST Pradeep Kumar Chitrapu wrote:

Issues wmi command to firmwre when multicast rate change is received
with the new BSS_CHANGED_MCAST_RATE flag.
Also fixes the incorrect fixed_rate setting for CCK rates which got
introduced with addition of ath10k_rates_rev2 enum.

Tested on QCA9984 with firmware ver 10.4-3.6-00104

Signed-off-by: Pradeep Kumar Chitrapu 
---
v2:
  - fixed the CCK rates setting for mcast_rate and fixed_rate paths.
  - set broadcast rate along with multicast rate setting.

These things are only modified in ath10k_bss_info_changed and not saved/
restored. What happens when the HW needs to be reset (there are are couple of
firmware crashes which can be seen in the wild and are handled by ath10k)? I
would guess that not all of them automatically cause an .bss_info_changed.

i have never seen a card properly recovering after a firmware crash, all 
firmware crashes i have seen
are caused by bugs in firmware handling or the firmware itself. so if it 
recovers it crashes immediatly again
ending in a endless crashloop since the cause for the crash hasnt been 
fixed. they are often triggered by extern clients for instance which 
still remain in the field.
i think firmware crashes should not be hidden by recovering. this would 
also force users to report problems more frequently, than they do

since they dont even take notice of such problems

Sebastian

Re: [PATCH] ath10k: add dynamic vlan support

[Sebastian Gottschall]

did someone notice that GTK rekeying is broken in 4addr mode for 10.4. 
firmwares since a long time.
i have a test with 2 9984 devices. one is 4addr ap, the second 4addr 
sta. it disconnects on rekeying and reauthenticates. (reproducable with 
99x0 as well)
this does not occur on 10.2 based chipsets like 988x. it seems to be a 
internal firmware problem since the beginning. i wrote already a long 
time ago about it,
but no solution was provided. maybe its also finally time to take care 
about this issue (cause unknown)


Sebastian

Am 04.05.2018 um 08:50 schrieb Manikanta Pubbisetty:

Johannes,

It seems like commit db3bdcb9c3ff ("mac80211: allow AP_VLAN operation 
on crypto controlled devices") has broken 4-addr operation on crypto 
controlled devices as reported by sebastian.
The commit was mainly focused in addressing the problem in supporting 
VLANs on crypto controlled devices but since 4-addr mode is also 
dependent on AP_VLAN interface, this commit breaks the 4-addr AP mode.


I have couple of ideas on how to address the problem,

1) Add a new hw_flag and based on the hardware flag, allow/disallow 
the creation of AP_VLAN interface.


diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d2279b2..301d9c38 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2084,6 +2084,11 @@ struct ieee80211_txq {
  * @IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP: The driver (or firmware) 
doesn't

  * support QoS NDP for AP probing - that's most likely a driver bug.
  *
+ * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting
+ * frames encrypted in software, only valid when SW_CRYPTO_CONTROL
+ * is enabled. Based on this flag, mac80211 can allow/disallow VLAN
+ * operations in the BSS.
+ *
  * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing 
arrays

  */
 enum ieee80211_hw_flags {
@@ -2129,6 +2134,7 @@ enum ieee80211_hw_flags {
    IEEE80211_HW_SUPPORTS_TDLS_BUFFER_STA,
    IEEE80211_HW_DEAUTH_NEED_MGD_TX_PREP,
    IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP,
+   IEEE80211_HW_SUPPORTS_SW_ENCRYPT,

    /* keep last, obviously */
    NUM_IEEE80211_HW_FLAGS
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 555e389..c825d27 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1736,6 +1736,11 @@ int ieee80211_if_add(struct ieee80211_local 
*local, const char *name,


    ASSERT_RTNL();

+   if ((type == NL80211_IFTYPE_AP_VLAN) && !params->use_4addr &&
+   ieee80211_hw_check(local->hw, SW_CRYPTO_CONTROL) &&
+   !ieee80211_hw_check(local->hw, SUPPORTS_SW_ENCRYPT))
+  return -EOPNOTSUPP;
+
    if (type == NL80211_IFTYPE_P2P_DEVICE || type == 
NL80211_IFTYPE_NAN) {

    struct wireless_dev *wdev;

2) Allow mac80211 to call set_key for GTKs on AP_VLAN interfaces for 
crypto controlled devices, let the driver decide whether to return '1' 
or some error code based on their support for transmitting sw 
encrypted frames. I am little skeptical with this approach as drivers 
are totally unaware of AP_VLAN interfaces.


diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index ee0d0cc..0ff5597 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -167,7 +167,8 @@ static int ieee80211_key_enable_hw_accel(struct 
ieee80211_key *key)
 * The driver doesn't know anything about VLAN 
interfaces.
 * Hence, don't send GTKs for VLAN interfaces to the 
driver.

 */
-   if (!(key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE))
+   if ((!(key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE) &&
+   !ieee80211_hw_check(>local->hw, 
SW_CRYPTO_CONTROL)))

    goto out_unsupported;
    }

Please let me know which is the better way to deal the problem.

Thanks,
Manikanta


On 2018-04-24 14:39, Sebastian Gottschall wrote:

consider my comment regarding vlan_ap.
this patch will break wds ap / wds sta support with latest mac80211
(see also my post on the wireless mailing list about the breaking
patch in mac80211)
so AP_VLAN must be masked always for all chipsets. otherwise wds
breaks and this is not just a guess. i tested it yesterday using this
patch and found
the cause of the issue

the following lines

  +    if (test_bit(WMI_SERVICE_PER_PACKET_SW_ENCRYPT, 
ar->wmi.svc_map)) {

+    ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_AP_VLAN);
+    ar->hw->wiphy->software_iftypes |= BIT(NL80211_IFTYPE_AP_VLAN);
+    }


must be just

+    ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_AP_VLAN);
+    ar->hw->wiphy->software_iftypes |= BIT(NL80211_IFTYPE_AP_VLAN);

everthing else will cause a regression

Am 24.04.2018 um 10:09 schrieb Kalle Valo:

Manikanta Pubbisetty <mpubb...@codeaurora.org> writes:


Mutlicast/broadcast traffic destined f

Re: [PATCH 2/2] ath10k: DFS Host Confirmation

[Sebastian Gottschall]

Am 02.05.2018 um 13:27 schrieb Kalle Valo:

Peter Oh <peter...@bowerswilkins.com> writes:


On 04/30/2018 10:45 AM, Sriram R wrote:

In the 10.4-3.6 firmware branch there's a new DFS Host confirmation
feature which is advertised using WMI_SERVICE_HOST_DFS_CHECK_SUPPORT flag.

This new features enables the ath10k host to send information to the
firmware on the specifications of detected radar type. This allows the
firmware to validate if the host's radar pattern detector unit is
operational and check if the radar information shared by host matches
the radar pulses sent as phy error events from firmware. If the check
fails the firmware won't allow use of DFS channels on AP mode when using
FCC regulatory region.

What's the main reason you introduce this feature?
What are you trying to solve with this change?

Otherwise one cannot use DFS channels on FCC regions with a firmware
from 10.4-3.6 branch.


@@ -3765,25 +3834,46 @@ static void ath10k_dfs_radar_report(struct ath10k *ar,
ATH10K_DFS_STAT_INC(ar, pulses_detected);
   -if (!ar->dfs_detector->add_pulse(ar->dfs_detector, , NULL))
{
+   if (!ar->dfs_detector->add_pulse(ar->dfs_detector, , )) {
ath10k_dbg(ar, ATH10K_DBG_REGULATORY,
   "dfs no pulse pattern detected, yet\n");
return;
}
   -radar_detected:
-   ath10k_dbg(ar, ATH10K_DBG_REGULATORY, "dfs radar detected\n");
-   ATH10K_DFS_STAT_INC(ar, radar_detected);
+   if ((test_bit(WMI_SERVICE_HOST_DFS_CHECK_SUPPORT, ar->wmi.svc_map)) &&
+   ar->dfs_detector->region == NL80211_DFS_FCC) {

I feel risky that host drivers have no way to control this new feature
and totally rely on FW feature mask. We should have a host drivers'
feature mask such as module param and set it false (don't use) by
default until it proves safe to use.

This is for regulatory enforcement so it's not possible to disable the
feature from host.
mmh from what i see it is possible to disable it from host since the 
firmware seem to be sensitive on the regdomain set by the host
so if host sets anything else than a FCC regdomain, it will still work 
in the old way. so its more a pseudo enforcement. dont know if this is
usefull and it also will it make impossible to fix radar detection 
issues for certification as mentioned by peter and adrian.


Sebastian




--
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

Re: [PATCH v7] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

[Sebastian Gottschall]

+    /* only 4x4 configuration do support 2x2 for VHT160, everything 
else must use 1x1 */

+    if (ar->cfg_rx_chainmask == 15)
+    nss160 = arg->peer_num_spatial_streams <= 2 ? 
arg->peer_num_spatial_streams : 2;


If peer nss == 3, then nss160 must be 1x1.  That is why I previously 
suggested the code that set nss160 to equal nss / 2

(with special case to bump nss160 to 1x1 if nss == 1.
btw. it doesnt matter if the peer sends with 3x3 or even 4x4, i still 
can receive with 2x2. thats no conflict. switching back to 1x1 of the 
peer sends vht160 with 3x3 makes no real sense
i dont have to turn off a chain, if i'm able todo 2x2, no matter what 
the peer does. i just have to limit the maximum




A 9984 peer with chainmask configured to 0x7 would hit this case I think.

Overall this looks better than previous patches though.

Thanks,
Ben


+
+    /* in case if peer is connected with vht160 or vht80+80, we need 
to properly adjust rxnss parameters otherwise firmware will raise a 
assert */

+    switch(arg->peer_phymode) {
+    case MODE_11AC_VHT80_80:
+    arg->peer_bw_rxnss_override = BW_NSS_FWCONF_80_80(nss160);
+    /* fall through */
+    case MODE_11AC_VHT160:
+    arg->peer_bw_rxnss_override |= BW_NSS_FWCONF_160(nss160);
+    break;
+    default:
+    break;
  }
+
+    ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d 
flags 0x%x peer_bw_rxnss_override 0x%x\n",
+   sta->addr, arg->peer_max_mpdu, arg->peer_flags, 
arg->peer_bw_rxnss_override);

  }

  static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
@@ -2696,9 +2700,9 @@ static int ath10k_peer_assoc_prepare(struct 
ath10k *ar,

  ath10k_peer_assoc_h_crypto(ar, vif, sta, arg);
  ath10k_peer_assoc_h_rates(ar, vif, sta, arg);
  ath10k_peer_assoc_h_ht(ar, vif, sta, arg);
+    ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
  ath10k_peer_assoc_h_vht(ar, vif, sta, arg);
  ath10k_peer_assoc_h_qos(ar, vif, sta, arg);
-    ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);

  return 0;
  }
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c

index 2c36256a441d..3797dca317ff 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -7211,12 +7211,7 @@ ath10k_wmi_peer_assoc_fill_10_4(struct ath10k 
*ar, void *buf,

  struct wmi_10_4_peer_assoc_complete_cmd *cmd = buf;

  ath10k_wmi_peer_assoc_fill_10_2(ar, buf, arg);
-    if (arg->peer_bw_rxnss_override)
-    cmd->peer_bw_rxnss_override =
-    __cpu_to_le32((arg->peer_bw_rxnss_override - 1) |
-  BIT(PEER_BW_RXNSS_OVERRIDE_OFFSET));
-    else
-    cmd->peer_bw_rxnss_override = 0;
+    cmd->peer_bw_rxnss_override = 
__cpu_to_le32(arg->peer_bw_rxnss_override);

  }

  static int
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h

index 46ae19bb2c92..1fe0aa5523a6 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6380,7 +6380,19 @@ struct wmi_10_2_peer_assoc_complete_cmd {
  __le32 info0; /* WMI_PEER_ASSOC_INFO0_ */
  } __packed;

-#define PEER_BW_RXNSS_OVERRIDE_OFFSET  31
+#define BW_NSS_FWCONF_MAP_ENABLE (1 << 31)
+#define BW_NSS_FWCONF_MAP_160MHZ_S   (0)
+#define BW_NSS_FWCONF_MAP_160MHZ_M   (0x0007)
+#define BW_NSS_FWCONF_MAP_80_80MHZ_S (3)
+#define BW_NSS_FWCONF_MAP_80_80MHZ_M (0x0038)
+#define BW_NSS_FWCONF_MAP_M  (0x003F)
+
+#define GET_BW_NSS_FWCONF_160(x) x) & 
BW_NSS_FWCONF_MAP_160MHZ_M) >> BW_NSS_FWCONF_MAP_160MHZ_S) + 1)
+#define GET_BW_NSS_FWCONF_80_80(x)   x) & 
BW_NSS_FWCONF_MAP_80_80MHZ_M) >> BW_NSS_FWCONF_MAP_80_80MHZ_S) + 1)

+
+/* Values defined to set 160 MHz Bandwidth NSS Mapping into FW*/
+#define BW_NSS_FWCONF_160(x)  (BW_NSS_FWCONF_MAP_ENABLE | 
(((x - 1) << BW_NSS_FWCONF_MAP_160MHZ_S) & BW_NSS_FWCONF_MAP_160MHZ_M))
+#define BW_NSS_FWCONF_80_80(x)    (BW_NSS_FWCONF_MAP_ENABLE | 
(((x - 1) << BW_NSS_FWCONF_MAP_80_80MHZ_S) & 
BW_NSS_FWCONF_MAP_80_80MHZ_M))


  struct wmi_10_4_peer_assoc_complete_cmd {
  struct wmi_10_2_peer_assoc_complete_cmd cmd;






--
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

Re: [PATCH v4] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

[Sebastian Gottschall]

btw 4019 doesnt support vht160 in ath10k see vht160_mcs_rx_highest in 
core params

if it does support vht160, ath10k must be adjusted here

Am 28.04.2018 um 17:37 schrieb Ben Greear:



On 04/28/2018 08:26 AM, Sebastian Gottschall wrote:

Am 28.04.2018 um 17:01 schrieb Ben Greear:



On 04/27/2018 05:47 PM, s.gottsch...@dd-wrt.com wrote:

From: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

current handling of peer_bw_rxnss_override parameter is based on 
guessing the VHT160/8080 capability by rx rate. this is wrong and 
may lead
to a non initialized peer_bw_rxnss_override parameter which is 
required since VHT160 operation mode only supports 2x2 chainmasks 
in addition the original code

initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for 
correct initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the 
parameter by minimum nss which is suggested by QCA as temporary 
workaround according

to the QCA sourcecodes.

Signed-off-by: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

v2: remove debug messages
v3: apply some cosmetics, update documentation
v4: fix compile warning and truncate nss to maximum of 2x2 since 
current chipsets only support 2x2 at vht160

---
 drivers/net/wireless/ath/ath10k/mac.c | 44 
++-

 drivers/net/wireless/ath/ath10k/wmi.c |  7 +
 drivers/net/wireless/ath/ath10k/wmi.h | 14 -
 3 files changed, 43 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c

index 5be6386ede8f..de8a099c9f5a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2528,23 +2528,37 @@ static void ath10k_peer_assoc_h_vht(struct 
ath10k *ar,

 __le16_to_cpu(vht_cap->vht_mcs.tx_highest);
 arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
 __le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);
+    arg->peer_bw_rxnss_override = 0;
+
+    if (arg->peer_num_spatial_streams) {


Check for the 80+80 or 160 instead of num-spatial-streams, if if 
something has
nss == 0, then act like it is 1 instead since it is obviously 
configured incorrect.
this check is bellow. see the switch statement for the VHT160, 80_80 
case.
if nss 0, it must fail here since we cannot handle nss = 0, in that 
case just bit 31 is masked





+    int nss160 = arg->peer_num_spatial_streams;


I think this line should be:
    int nss160 = arg->peer_num_spatial_streams / 2;

no. makes no sense. 2 would get 1 and 1 turns to zero. makes no sense
read the macro BW_NSS_FWCONF_160 first. it already does nss160-1
this would lead to -1 if spatial_streams is 1


Well, nss160 should be the number of streams we can use at 160 Mhz.  
The macro
can convert to zero-based api that the firmware wants.  A 9984 will 
have nss == 4,
but you want nss160 to be 2.  A 4019 will have nss == 2, but nss160 
should be 1.



    if (nss160 == 0) { nss160 = 1; } /* deal with 
mis-configured nss */

no
if peer_num_spatial_stream is 0 (so nss160 too), the code is not 
triggered. but another code. same as above


If NSS was 1, and you do 1/2, you get zero.



if (!arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT80_80 || arg->peer_phymode == MODE_11AC_VHT160)) {

   arg->peer_bw_rxnss_override = BW_NSS_FWCONF_MAP_ENABLE;
 }


If you have a 4019 client, it will have 
arg->peer_num_spatial_streams == 2, but

it can only do 1x1 at 160Mhz.
peer_num_spatial_streams is calculated from mcs rate set. so why 
should 4019 announce 2x2 if it just can to 1x1.

have you checked the mcs set at assoc management frame?


You are confused about nss vs the 160nss.  They are different.  I do 
not know how to explain
this better.  Dig through the firmware source and look at how they are 
used.  Basically, if
rate-ctrl decides 80Mhz is best, it can send at the normal 80Mhz NSS 
(so, 4 for 9984, 2 for 4019),
but if rate-ctrl uses 160, it uses the different nss max (2 for 9984, 
one for 4019).





+    /* truncate vht160 nss value to 2x2 since all known 
chipsets do not support more than 2x2 in vht160 modes */

+    if (nss160 > 2)
+    nss160 = 2;
+    /* in case if peer is connected with vht160 or vht80+80, 
we need to properly adjust rxnss parameters */

+    switch(arg->peer_phymode) {
+    case MODE_11AC_VHT80_80:
+    arg->peer_bw_rxnss_override = 
BW_NSS_FWCONF_80_80(nss160);

+    /* fall through */
+    case MODE_11AC_VHT160:
+    arg->peer_bw_rxnss_override |= BW_NSS_FWCONF_160(nss160);


From looking at firmware, it will just ignore the bits it does not 
need, so you do not need
to special case adding the 80_80 fields, you can do more like my 
patch and just always add

those bits.
i'm following the reference c

Re: [PATCH v4] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

[Sebastian Gottschall]

Am 28.04.2018 um 17:01 schrieb Ben Greear:



On 04/27/2018 05:47 PM, s.gottsch...@dd-wrt.com wrote:

From: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

current handling of peer_bw_rxnss_override parameter is based on 
guessing the VHT160/8080 capability by rx rate. this is wrong and may 
lead
to a non initialized peer_bw_rxnss_override parameter which is 
required since VHT160 operation mode only supports 2x2 chainmasks in 
addition the original code

initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for correct 
initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the 
parameter by minimum nss which is suggested by QCA as temporary 
workaround according

to the QCA sourcecodes.

Signed-off-by: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

v2: remove debug messages
v3: apply some cosmetics, update documentation
v4: fix compile warning and truncate nss to maximum of 2x2 since 
current chipsets only support 2x2 at vht160

---
 drivers/net/wireless/ath/ath10k/mac.c | 44 ++-
 drivers/net/wireless/ath/ath10k/wmi.c |  7 +
 drivers/net/wireless/ath/ath10k/wmi.h | 14 -
 3 files changed, 43 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c

index 5be6386ede8f..de8a099c9f5a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2528,23 +2528,37 @@ static void ath10k_peer_assoc_h_vht(struct 
ath10k *ar,

 __le16_to_cpu(vht_cap->vht_mcs.tx_highest);
 arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
 __le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);
+    arg->peer_bw_rxnss_override = 0;
+
+    if (arg->peer_num_spatial_streams) {


Check for the 80+80 or 160 instead of num-spatial-streams, if if 
something has
nss == 0, then act like it is 1 instead since it is obviously 
configured incorrect.

this check is bellow. see the switch statement for the VHT160, 80_80 case.
if nss 0, it must fail here since we cannot handle nss = 0, in that case 
just bit 31 is masked





+    int nss160 = arg->peer_num_spatial_streams;


I think this line should be:
    int nss160 = arg->peer_num_spatial_streams / 2;

no. makes no sense. 2 would get 1 and 1 turns to zero. makes no sense
read the macro BW_NSS_FWCONF_160 first. it already does nss160-1
this would lead to -1 if spatial_streams is 1




    if (nss160 == 0) { nss160 = 1; } /* deal with 
mis-configured nss */

no
if peer_num_spatial_stream is 0 (so nss160 too), the code is not 
triggered. but another code. same as above


if (!arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT80_80 || arg->peer_phymode == MODE_11AC_VHT160)) {

   arg->peer_bw_rxnss_override = BW_NSS_FWCONF_MAP_ENABLE;
 }


If you have a 4019 client, it will have arg->peer_num_spatial_streams 
== 2, but

it can only do 1x1 at 160Mhz.
peer_num_spatial_streams is calculated from mcs rate set. so why should 
4019 announce 2x2 if it just can to 1x1.

have you checked the mcs set at assoc management frame?



+    /* truncate vht160 nss value to 2x2 since all known chipsets 
do not support more than 2x2 in vht160 modes */

+    if (nss160 > 2)
+    nss160 = 2;
+    /* in case if peer is connected with vht160 or vht80+80, we 
need to properly adjust rxnss parameters */

+    switch(arg->peer_phymode) {
+    case MODE_11AC_VHT80_80:
+    arg->peer_bw_rxnss_override = BW_NSS_FWCONF_80_80(nss160);
+    /* fall through */
+    case MODE_11AC_VHT160:
+    arg->peer_bw_rxnss_override |= BW_NSS_FWCONF_160(nss160);


From looking at firmware, it will just ignore the bits it does not 
need, so you do not need
to special case adding the 80_80 fields, you can do more like my patch 
and just always add

those bits.
i'm following the reference code. in case 80_80 only is configure vht160 
nd 80_80 must be masked. for everything else vht160 only must be masked.
thats the meaning. there are 2 override masks. independend for vht160 
and 80_80. for sure i can do always both, but the reference code does not
and who knows what else changed in the firmware. consider that the crash 
bug first occured on 3.5.3. your CT codebase is older as far as i know



+    break;
+    default:
+    break;
+    }
+    }

-    ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d 
flags 0x%x\n",

-   sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+    /* in case peer has no nss properties for some reasons, we set 
local nss to minimum (1x1) to avoid a
+ * firmware assert / crash. this applies only to VHT160 or 
VHT80+80 and is a WAR for clients breaking

+ * the spec.
+ */

-    if (arg->peer_vh

Re: [PATCH v2] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

[Sebastian Gottschall]

er_assoc_h_phymode(ar, vif, sta, arg);
 ath10k_peer_assoc_h_vht(ar, vif, sta, arg);
 ath10k_peer_assoc_h_qos(ar, vif, sta, arg);
-    ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);

 ath10k_peer_assoc_h_rate_overrides(ar, vif, sta, arg);


diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c

index 8eeeab0..365d509 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -7442,12 +7442,8 @@ ath10k_wmi_peer_assoc_fill_10_4(struct ath10k 
*ar, void *buf,

 struct wmi_10_4_peer_assoc_complete_cmd *cmd = buf;

 ath10k_wmi_peer_assoc_fill_10_2(ar, buf, arg);
-    if (arg->peer_bw_rxnss_override)
-    cmd->peer_bw_rxnss_override =
-    __cpu_to_le32((arg->peer_bw_rxnss_override - 1) |
-  BIT(PEER_BW_RXNSS_OVERRIDE_OFFSET));
-    else
-    cmd->peer_bw_rxnss_override = 0;
+
+    cmd->peer_bw_rxnss_override = 
__cpu_to_le32(arg->peer_bw_rxnss_override);

 }

 static int



Thanks,
Ben



--
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

Re: [PATCH v2] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

[Sebastian Gottschall]

Am 27.04.2018 um 23:57 schrieb Ben Greear:

On 04/27/2018 11:54 AM, Sebastian Gottschall wrote:

Am 27.04.2018 um 18:07 schrieb Ben Greear:

On 04/26/2018 09:40 PM, Sebastian Gottschall wrote:

Am 26.04.2018 um 22:35 schrieb Ben Greear:

On 04/26/2018 01:21 PM, Sebastian Gottschall wrote:

Am 26.04.2018 um 17:30 schrieb Ben Greear:

On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote:

From: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

current handling of peer_bw_rxnss_override parameter is based 
on guessing the VHT160/8080 capability by rx rate. this is 
wrong and may lead
to a non initialized peer_bw_rxnss_override parameter which is 
required since VHT160 operation mode only supports 2x2 
chainmasks in addition the original

code
initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for 
correct initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the 
parameter by minimum nss which is suggested by QCA as temporary 
workaround according

to the QCA sourcecodes.

Signed-off-by: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

v2: remove debug messages
---
 drivers/net/wireless/ath/ath10k/mac.c | 36 
+++

 drivers/net/wireless/ath/ath10k/wmi.c |  4 +---
 drivers/net/wireless/ath/ath10k/wmi.h | 14 +-
 3 files changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c

index 5be6386ede8f..df79af89ee71 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2505,8 +2505,9 @@ static void 
ath10k_peer_assoc_h_vht(struct ath10k *ar,

 if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
 arg->peer_flags |= ar->wmi.peer_flags->bw80;

-    if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+    if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
 arg->peer_flags |= ar->wmi.peer_flags->bw160;
+    }

 /* Calculate peer NSS capability from VHT capabilities if STA
  * supports VHT.
@@ -2529,22 +2530,25 @@ static void 
ath10k_peer_assoc_h_vht(struct ath10k *ar,
 arg->peer_vht_rates.tx_mcs_set = 
ath10k_peer_assoc_h_vht_limit(

__le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);

-    ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu 
%d flags 0x%x\n",

-   sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+    if (arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT160 || arg->peer_phymode == MODE_11AC_VHT80_80)) {
+    arg->peer_bw_rxnss_override = 
BW_NSS_FWCONF_160(arg->peer_num_spatial_streams);

+    }


So, an 80Mhz peer could be 4x4 and could connect to a VHT-160 
AP. From what I can tell,
the VHT-160 AP can talk 4x4 @ 80Mhz to the peer in this case, 
but if peer is VHT-160,

then of course it can only talk at 2x2.

So, I don't think you can just look at the 
peer_num_spatial_streams here.
no? rxnss_override is only taked if peer phymode is vht160 or 
vht80_80. vht80 is not considered in that code PEER phy_mode, not 
HOST phy_mode
this parameter is a assoc per peer parameter as far as i can say 
here.
consider that the firmware will accept anything except 0 for 
peer_bw_rxnss_override in vht160 operation mode

if a peer is 80 mhz, the code will be skipped here.


From what I can tell, this feature is supposed to configure the 
rate-ctrl in the firmware to know that
it can only send 1x1 or 2x2 when sending at 160Mhz, but that it 
can send at higher NSS if it sends

at 80Mhz or lower.
right. but thats exactly what it should does in case that a peer is 
connecting with vht160 / 80_80
and the peer itself does also send his own nss capabilities which 
is used if available. if not ,it uses the fallback.


If a 2x2 peer connects to the AP, will it have 
peer_num_spatial_streams set to 2?
yes. i had some debug code in my initial early versions. the peer 
does transmit his own nss capabilities.

If so,
then your code will configure the peer_bw_rxnss_override to 
indicate it can send at 160Mhz

2x2 as well, right?  And if so, then that is incorrect.

no. since nss_override is only set if peer phymode is 160 mhz as well


The peer can run at 2x2 80Mhz and 1x1 160Mhz at the same time, so it 
can advertise
2x2 nss and phy-mode of 160Mhz when associating to the 160Mhz AP, 
but the peer can only do 1x1 at 160Mhz.  There
is no standard way I know of for the peer to tell you specifically 
that it can only do

1x1 at 160Mhz and also 2x2 at 80Mhz in this case.
per specification the peer is able to provide max nss to the ap. the 
rx_nss property is calculated
from the mcs rateset provided by the peer by mac80211. this is mcs 
set provided on on assoc is mandatory.
so there is a way the peer can tell you what it supports and this is 
what is used.
if a peer does not provide the mcs rateset (which i h

Re: [PATCH v2] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

[Sebastian Gottschall]

Am 27.04.2018 um 18:07 schrieb Ben Greear:

On 04/26/2018 09:40 PM, Sebastian Gottschall wrote:

Am 26.04.2018 um 22:35 schrieb Ben Greear:

On 04/26/2018 01:21 PM, Sebastian Gottschall wrote:

Am 26.04.2018 um 17:30 schrieb Ben Greear:

On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote:

From: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

current handling of peer_bw_rxnss_override parameter is based on 
guessing the VHT160/8080 capability by rx rate. this is wrong and 
may lead
to a non initialized peer_bw_rxnss_override parameter which is 
required since VHT160 operation mode only supports 2x2 chainmasks 
in addition the original code

initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for 
correct initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the 
parameter by minimum nss which is suggested by QCA as temporary 
workaround according

to the QCA sourcecodes.

Signed-off-by: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

v2: remove debug messages
---
 drivers/net/wireless/ath/ath10k/mac.c | 36 
+++

 drivers/net/wireless/ath/ath10k/wmi.c |  4 +---
 drivers/net/wireless/ath/ath10k/wmi.h | 14 +-
 3 files changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c

index 5be6386ede8f..df79af89ee71 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2505,8 +2505,9 @@ static void ath10k_peer_assoc_h_vht(struct 
ath10k *ar,

 if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
 arg->peer_flags |= ar->wmi.peer_flags->bw80;

-    if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+    if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
 arg->peer_flags |= ar->wmi.peer_flags->bw160;
+    }

 /* Calculate peer NSS capability from VHT capabilities if STA
  * supports VHT.
@@ -2529,22 +2530,25 @@ static void 
ath10k_peer_assoc_h_vht(struct ath10k *ar,

 arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
 __le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);

-    ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d 
flags 0x%x\n",

-   sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+    if (arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT160 || arg->peer_phymode == MODE_11AC_VHT80_80)) {
+    arg->peer_bw_rxnss_override = 
BW_NSS_FWCONF_160(arg->peer_num_spatial_streams);

+    }


So, an 80Mhz peer could be 4x4 and could connect to a VHT-160 AP. 
From what I can tell,
the VHT-160 AP can talk 4x4 @ 80Mhz to the peer in this case, but 
if peer is VHT-160,

then of course it can only talk at 2x2.

So, I don't think you can just look at the 
peer_num_spatial_streams here.
no? rxnss_override is only taked if peer phymode is vht160 or 
vht80_80. vht80 is not considered in that code PEER phy_mode, not 
HOST phy_mode

this parameter is a assoc per peer parameter as far as i can say here.
consider that the firmware will accept anything except 0 for 
peer_bw_rxnss_override in vht160 operation mode

if a peer is 80 mhz, the code will be skipped here.


From what I can tell, this feature is supposed to configure the 
rate-ctrl in the firmware to know that
it can only send 1x1 or 2x2 when sending at 160Mhz, but that it can 
send at higher NSS if it sends

at 80Mhz or lower.
right. but thats exactly what it should does in case that a peer is 
connecting with vht160 / 80_80
and the peer itself does also send his own nss capabilities which is 
used if available. if not ,it uses the fallback.


If a 2x2 peer connects to the AP, will it have 
peer_num_spatial_streams set to 2?
yes. i had some debug code in my initial early versions. the peer 
does transmit his own nss capabilities.

If so,
then your code will configure the peer_bw_rxnss_override to indicate 
it can send at 160Mhz

2x2 as well, right?  And if so, then that is incorrect.

no. since nss_override is only set if peer phymode is 160 mhz as well


The peer can run at 2x2 80Mhz and 1x1 160Mhz at the same time, so it 
can advertise
2x2 nss and phy-mode of 160Mhz when associating to the 160Mhz AP, but 
the peer can only do 1x1 at 160Mhz.  There
is no standard way I know of for the peer to tell you specifically 
that it can only do

1x1 at 160Mhz and also 2x2 at 80Mhz in this case.
per specification the peer is able to provide max nss to the ap. the 
rx_nss property is calculated
from the mcs rateset provided by the peer by mac80211. this is mcs set 
provided on on assoc is mandatory.
so there is a way the peer can tell you what it supports and this is 
what is used.
if a peer does not provide the mcs rateset (which i have seen for a 
single marvell client)
the fallback mechanism will still work, but

Re: [PATCH v2] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

[Sebastian Gottschall]

Am 26.04.2018 um 22:35 schrieb Ben Greear:

On 04/26/2018 01:21 PM, Sebastian Gottschall wrote:

Am 26.04.2018 um 17:30 schrieb Ben Greear:

On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote:

From: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

current handling of peer_bw_rxnss_override parameter is based on 
guessing the VHT160/8080 capability by rx rate. this is wrong and 
may lead
to a non initialized peer_bw_rxnss_override parameter which is 
required since VHT160 operation mode only supports 2x2 chainmasks 
in addition the original code

initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for 
correct initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the 
parameter by minimum nss which is suggested by QCA as temporary 
workaround according

to the QCA sourcecodes.

Signed-off-by: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

v2: remove debug messages
---
 drivers/net/wireless/ath/ath10k/mac.c | 36 
+++

 drivers/net/wireless/ath/ath10k/wmi.c |  4 +---
 drivers/net/wireless/ath/ath10k/wmi.h | 14 +-
 3 files changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c

index 5be6386ede8f..df79af89ee71 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2505,8 +2505,9 @@ static void ath10k_peer_assoc_h_vht(struct 
ath10k *ar,

 if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
 arg->peer_flags |= ar->wmi.peer_flags->bw80;

-    if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+    if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
 arg->peer_flags |= ar->wmi.peer_flags->bw160;
+    }

 /* Calculate peer NSS capability from VHT capabilities if STA
  * supports VHT.
@@ -2529,22 +2530,25 @@ static void ath10k_peer_assoc_h_vht(struct 
ath10k *ar,

 arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
 __le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);

-    ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d 
flags 0x%x\n",

-   sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+    if (arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT160 || arg->peer_phymode == MODE_11AC_VHT80_80)) {
+    arg->peer_bw_rxnss_override = 
BW_NSS_FWCONF_160(arg->peer_num_spatial_streams);

+    }


So, an 80Mhz peer could be 4x4 and could connect to a VHT-160 AP. 
From what I can tell,
the VHT-160 AP can talk 4x4 @ 80Mhz to the peer in this case, but if 
peer is VHT-160,

then of course it can only talk at 2x2.

So, I don't think you can just look at the peer_num_spatial_streams 
here.
no? rxnss_override is only taked if peer phymode is vht160 or 
vht80_80. vht80 is not considered in that code PEER phy_mode, not 
HOST phy_mode

this parameter is a assoc per peer parameter as far as i can say here.
consider that the firmware will accept anything except 0 for 
peer_bw_rxnss_override in vht160 operation mode

if a peer is 80 mhz, the code will be skipped here.


From what I can tell, this feature is supposed to configure the 
rate-ctrl in the firmware to know that
it can only send 1x1 or 2x2 when sending at 160Mhz, but that it can 
send at higher NSS if it sends

at 80Mhz or lower.
right. but thats exactly what it should does in case that a peer is 
connecting with vht160 / 80_80
and the peer itself does also send his own nss capabilities which is 
used if available. if not ,it uses the fallback.


If a 2x2 peer connects to the AP, will it have 
peer_num_spatial_streams set to 2?
yes. i had some debug code in my initial early versions. the peer does 
transmit his own nss capabilities.

If so,
then your code will configure the peer_bw_rxnss_override to indicate 
it can send at 160Mhz

2x2 as well, right?  And if so, then that is incorrect.

no. since nss_override is only set if peer phymode is 160 mhz as well


Probably if you connected something like a IPQ4019 station to a 9984 
AP configured for 160Mhz,

the peer_bw_rxnss_override would be set to 2x2 instead of 1x1?
depends how the ipq4019 chipset is configured. if it itself is 
configured to 160 mhz and configured to 2x2, yes
but the peer itself can also send with 1x1, then the ap will also send 
just 1x1
but as i said. this all is just used if the peer is configured to vht160 
and if num_spatial_stream is set by peer.
of not this is all ignored and only 1<<31 is masked. this way has been 
taken from qca's propertiery code

or lets say not taken but the behaviour has been translated




-    if (arg->peer_vht_rates.rx_max_rate &&
-    (sta->vht_cap.cap & 
IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK)) {

-    switch (arg->peer_vht_rates.rx_max_rate) {
-    case 1560:
-

Re: [PATCH v2] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

[Sebastian Gottschall]

Am 26.04.2018 um 17:30 schrieb Ben Greear:

On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote:

From: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

current handling of peer_bw_rxnss_override parameter is based on 
guessing the VHT160/8080 capability by rx rate. this is wrong and may 
lead
to a non initialized peer_bw_rxnss_override parameter which is 
required since VHT160 operation mode only supports 2x2 chainmasks in 
addition the original code

initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for correct 
initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the 
parameter by minimum nss which is suggested by QCA as temporary 
workaround according

to the QCA sourcecodes.

Signed-off-by: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

v2: remove debug messages
---
 drivers/net/wireless/ath/ath10k/mac.c | 36 
+++

 drivers/net/wireless/ath/ath10k/wmi.c |  4 +---
 drivers/net/wireless/ath/ath10k/wmi.h | 14 +-
 3 files changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c

index 5be6386ede8f..df79af89ee71 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2505,8 +2505,9 @@ static void ath10k_peer_assoc_h_vht(struct 
ath10k *ar,

 if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
 arg->peer_flags |= ar->wmi.peer_flags->bw80;

-    if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+    if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
 arg->peer_flags |= ar->wmi.peer_flags->bw160;
+    }

 /* Calculate peer NSS capability from VHT capabilities if STA
  * supports VHT.
@@ -2529,22 +2530,25 @@ static void ath10k_peer_assoc_h_vht(struct 
ath10k *ar,

 arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
 __le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);

-    ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d 
flags 0x%x\n",

-   sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+    if (arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT160 || arg->peer_phymode == MODE_11AC_VHT80_80)) {
+    arg->peer_bw_rxnss_override = 
BW_NSS_FWCONF_160(arg->peer_num_spatial_streams);

+    }


So, an 80Mhz peer could be 4x4 and could connect to a VHT-160 AP. From 
what I can tell,
the VHT-160 AP can talk 4x4 @ 80Mhz to the peer in this case, but if 
peer is VHT-160,

then of course it can only talk at 2x2.

So, I don't think you can just look at the peer_num_spatial_streams here.
no? rxnss_override is only taked if peer phymode is vht160 or vht80_80. 
vht80 is not considered in that code PEER phy_mode, not HOST phy_mode

this parameter is a assoc per peer parameter as far as i can say here.
consider that the firmware will accept anything except 0 for 
peer_bw_rxnss_override in vht160 operation mode

if a peer is 80 mhz, the code will be skipped here.





-    if (arg->peer_vht_rates.rx_max_rate &&
-    (sta->vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK)) {
-    switch (arg->peer_vht_rates.rx_max_rate) {
-    case 1560:
-    /* Must be 2x2 at 160Mhz is all it can do. */
-    arg->peer_bw_rxnss_override = 2;
-    break;
-    case 780:
-    /* Can only do 1x1 at 160Mhz (Long Guard Interval) */
-    arg->peer_bw_rxnss_override = 1;
-    break;
-    }


This old code does look wrong, the firmware is using zero-based, so 
override-0 == nss-1, override-1 == nss-2.

0 = crash

and 1 and 2 is wrong.

+#define BW_NSS_FWCONF_MAP_ENABLE (1 << 31)
+#define BW_NSS_FWCONF_MAP_160MHZ_S   (0)
+#define BW_NSS_FWCONF_MAP_160MHZ_M   (0x0007)
+#define BW_NSS_FWCONF_MAP_80_80MHZ_S (3)
+#define BW_NSS_FWCONF_MAP_80_80MHZ_M (0x0038)


This is confusing enough that it deserves a comment in the code I 
think
the removal doesnt deserve a comment. i dont know how to explain that 
its simply wrong. it uses the wrong

bit masks and this has been written in the initial patch description


+    if (arg->peer_num_spatial_streams && arg->peer_phymode == 
MODE_11AC_VHT80_80) {
+    arg->peer_bw_rxnss_override |= 
BW_NSS_FWCONF_80_80(arg->peer_num_spatial_streams);

 }
+
+    /* In very exceptional  conditions it is observed  that
+ * firmware was receiving bw_rxnss_override as 0 for peer from 
host, and resulting in Target Assert.
+ * Changing the rxnss_override to minimum nss. This is a 
temporary WAR. Needs to be fixed

+ * properly.
+ */
+    if (!arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT80_80 || arg->peer_phymode == MODE_11AC_VHT160

Re: [PATCH v1] ath10k: fix band_center_freq handling for VHT160 in recent firmwares

[Sebastian Gottschall]

Am 26.04.2018 um 15:44 schrieb Ben Greear:



On 04/26/2018 02:43 AM, s.gottsch...@dd-wrt.com wrote:

From: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

starting with firmware 10.4.3.4.x series QCA changed the handling of 
the channel property band_center_freq1 and band_center_freq2 in 
vht160 operation mode

likelly for backward compatiblity with vht80 only capable clients.
this patch adjusts the handling to get vht160 to work again with 
official qca firmwares newer than 3.3
consider that this patch will not work with older firmwares anymore. 
to avoid undefined behaviour this we disable vht160 capability for 
outdated firmwares


We should be able to use a feature-flag or otherwise determine if the 
firmware needs the old or new

API and make the driver able to handle both.
the new firmware must be used as is and it works. the old firmware can 
be detected on the missing vht cap flag.
but thats not my task. i can only use feature flags if they are included 
within the qca firmwares. but they arent
the old pre 3.3 firmwares should be treated as obsolete. they are more 
than 2 years old and do not announce vht160 capability
even if it works with some ignorance, but on the other side the it has 
backward incompatiblies with older vht80 only clients.

this is why the new way was introduced


Thanks,
Ben


---
 drivers/net/wireless/ath/ath10k/mac.c |  7 ---
 drivers/net/wireless/ath/ath10k/wmi.c | 11 ---
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c

index 5be6386ede8f..d1239d40ac19 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4449,13 +4449,6 @@ static struct ieee80211_sta_vht_cap 
ath10k_create_vht_cap(struct ath10k *ar)

 vht_cap.cap |= val;
 }

-    /* Currently the firmware seems to be buggy, don't enable 80+80
- * mode until that's resolved.
- */
-    if ((ar->vht_cap_info & IEEE80211_VHT_CAP_SHORT_GI_160) &&
-    (ar->vht_cap_info & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK) 
== 0)

-    vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
-
 mcs_map = 0;
 for (i = 0; i < 8; i++) {
 if ((i < ar->num_rf_chains) && (ar->cfg_tx_chainmask & BIT(i)))
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c

index 2c36256a441d..d78b8857a513 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1671,13 +1671,18 @@ void ath10k_wmi_put_wmi_channel(struct 
wmi_channel *ch,

 flags |= WMI_CHAN_FLAG_HT40_PLUS;
 if (arg->chan_radar)
 flags |= WMI_CHAN_FLAG_DFS;
-
+    ch->band_center_freq2 = 0;
 ch->mhz = __cpu_to_le32(arg->freq);
 ch->band_center_freq1 = __cpu_to_le32(arg->band_center_freq1);
 if (arg->mode == MODE_11AC_VHT80_80)
 ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq2);
-    else
-    ch->band_center_freq2 = 0;
+    if (arg->mode == MODE_11AC_VHT160)  {
+    if (arg->freq < arg->band_center_freq1)
+    ch->band_center_freq1 = 
__cpu_to_le32(arg->band_center_freq1 - 40);

+    else
+    ch->band_center_freq1 = 
__cpu_to_le32(arg->band_center_freq1 + 40);

+    ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq1);
+    }
 ch->min_power = arg->min_power;
 ch->max_power = arg->max_power;
 ch->reg_power = arg->max_reg_power;





--
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

Re: [PATCH] ath10k: add dynamic vlan support

[Sebastian Gottschall]

Am 24.04.2018 um 11:52 schrieb Kalle Valo:

Sebastian Gottschall <s.gottsch...@dd-wrt.com> writes:


consider my comment regarding vlan_ap.

I am considering comment, I just go one issue at a time and haven't had
a time to look at your comment. But PLEASE do not top post, it's very
annoying and creates a mess in patchwork.

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#do_not_top_post_and_edit_your_quotes
i almost do top posts for a single reason. you have to scroll down a 
long time sometimes to get the essential information.
i dont know why most people in my country prefer top posting. i will try 
to remember and change it in future




--
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

Re: [PATCH] ath10k: add dynamic vlan support

[Sebastian Gottschall]

consider my comment regarding vlan_ap.
this patch will break wds ap / wds sta support with latest mac80211 (see 
also my post on the wireless mailing list about the breaking patch in 
mac80211)
so AP_VLAN must be masked always for all chipsets. otherwise wds breaks 
and this is not just a guess. i tested it yesterday using this patch and 
found

the cause of the issue

the following lines

  +    if (test_bit(WMI_SERVICE_PER_PACKET_SW_ENCRYPT, ar->wmi.svc_map)) {
+    ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_AP_VLAN);
+    ar->hw->wiphy->software_iftypes |= BIT(NL80211_IFTYPE_AP_VLAN);
+    }


must be just

+    ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_AP_VLAN);
+    ar->hw->wiphy->software_iftypes |= BIT(NL80211_IFTYPE_AP_VLAN);

everthing else will cause a regression

Am 24.04.2018 um 10:09 schrieb Kalle Valo:

Manikanta Pubbisetty <mpubb...@codeaurora.org> writes:


Mutlicast/broadcast traffic destined for a particular vlan group will
always be encrypted in software. To enable dynamic VLANs, it requires
driver support for sending software encrypted packets.

In ath10k, sending sw encrypted frames is allowed only when we insmod
the driver with cryptmode param set to 1, this configuration disables
hardware crypto and enables RAW mode implicitly. Since, enabling raw
mode has performance impact, this cannot be considered as an ideal
solution for supporting VLANs in the driver.

As an alternative take, in this approach, cryptographic keys for
unicast traffic(per peer PTKs) and keys for non-vlan group traffic
will be configured in hardware, allowing hardware encryption for unicast
and non-vlan group traffic. Only vlan group traffic will be encrypted in
software and pushed to the target with encap mode set to RAW in the TX
descriptors.

Not all firmwares can support this type of key configuration(having few
keys installed in hardware and few only in software); for this purpose a
new WMI service flag "WMI_SERVICE_PER_PACKET_SW_ENCRYPT" is introduced to
advertise this support.

Also, adding the logic required to send sw encrypted frames in raw mode.

Tested this change on QCA9984(firmware version 10.4-3.5.3-00057).

Signed-off-by: Manikanta Pubbisetty <mpubb...@codeaurora.org>

Your name in patchwork is wrong and hence my script uses the wrong
name. Please fix it by registering to patchwork[1] where it's possible
to change your name during registration, but only one time. If that
doesn't work then send a request to helpd...@kernel.org and the admins
can fix it.

[1] https://patchwork.kernel.org/register/



--
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

Re: [PATCH] ath10k: add dynamic vlan support

[Sebastian Gottschall]

struct ath10k *ar,
ath10k_tx_h_8023(skb);
break;
case ATH10K_HW_TXRX_RAW:
-   if (!test_bit(ATH10K_FLAG_RAW_MODE, >dev_flags)) {
+   if (!test_bit(ATH10K_FLAG_RAW_MODE, >dev_flags) &&
+   !(skb_cb->flags & ATH10K_SKB_F_RAW_TX)) {
WARN_ON_ONCE(1);
ieee80211_free_txskb(hw, skb);
return -ENOTSUPP;
@@ -8455,6 +8472,11 @@ int ath10k_mac_register(struct ath10k *ar)
goto err_dfs_detector_exit;
}
  
+	if (test_bit(WMI_SERVICE_PER_PACKET_SW_ENCRYPT, ar->wmi.svc_map)) {

+   ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_AP_VLAN);
+   ar->hw->wiphy->software_iftypes |= BIT(NL80211_IFTYPE_AP_VLAN);
+   }
+
if (!ath_is_world_regd(>ath_common.regulatory)) {
ret = regulatory_hint(ar->hw->wiphy,
  ar->ath_common.regulatory.alpha2);
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 3cc129d..e359b6af 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -202,6 +202,10 @@ enum wmi_service {
WMI_SERVICE_HOST_DFS_CHECK_SUPPORT,
WMI_SERVICE_TPC_STATS_FINAL,
WMI_SERVICE_RESET_CHIP,
+   WMI_SERVICE_CFR_CAPTURE_SUPPORT,
+   WMI_SERVICE_TX_DATA_ACK_RSSI,
+   WMI_SERVICE_CFR_CAPTURE_IND_MSG_TYPE_1,
+   WMI_SERVICE_PER_PACKET_SW_ENCRYPT,
  
  	/* keep last */

WMI_SERVICE_MAX,
@@ -349,6 +353,10 @@ enum wmi_10_4_service {
WMI_10_4_SERVICE_HTT_MGMT_TX_COMP_VALID_FLAGS,
WMI_10_4_SERVICE_HOST_DFS_CHECK_SUPPORT,
WMI_10_4_SERVICE_TPC_STATS_FINAL,
+   WMI_10_4_SERVICE_CFR_CAPTURE_SUPPORT,
+   WMI_10_4_SERVICE_TX_DATA_ACK_RSSI,
+   WMI_10_4_SERVICE_CFR_CAPTURE_IND_MSG_TYPE_1,
+   WMI_10_4_SERVICE_PER_PACKET_SW_ENCRYPT,
  };
  
  static inline char *wmi_service_name(int service_id)

@@ -461,6 +469,11 @@ static inline char *wmi_service_name(int service_id)
SVCSTR(WMI_SERVICE_HTT_MGMT_TX_COMP_VALID_FLAGS);
SVCSTR(WMI_SERVICE_HOST_DFS_CHECK_SUPPORT);
SVCSTR(WMI_SERVICE_TPC_STATS_FINAL);
+   SVCSTR(WMI_SERVICE_CFR_CAPTURE_SUPPORT);
+   SVCSTR(WMI_SERVICE_TX_DATA_ACK_RSSI);
+   SVCSTR(WMI_SERVICE_CFR_CAPTURE_IND_MSG_TYPE_1);
+   SVCSTR(WMI_SERVICE_PER_PACKET_SW_ENCRYPT);
+
default:
return NULL;
}
@@ -769,6 +782,14 @@ static inline void wmi_10_4_svc_map(const __le32 *in, 
unsigned long *out,
   WMI_SERVICE_HOST_DFS_CHECK_SUPPORT, len);
SVCMAP(WMI_10_4_SERVICE_TPC_STATS_FINAL,
   WMI_SERVICE_TPC_STATS_FINAL, len);
+   SVCMAP(WMI_10_4_SERVICE_CFR_CAPTURE_SUPPORT,
+  WMI_SERVICE_CFR_CAPTURE_SUPPORT, len);
+   SVCMAP(WMI_10_4_SERVICE_TX_DATA_ACK_RSSI,
+  WMI_SERVICE_TX_DATA_ACK_RSSI, len);
+   SVCMAP(WMI_10_4_SERVICE_CFR_CAPTURE_IND_MSG_TYPE_1,
+  WMI_SERVICE_CFR_CAPTURE_IND_MSG_TYPE_1, len);
+   SVCMAP(WMI_10_4_SERVICE_PER_PACKET_SW_ENCRYPT,
+  WMI_SERVICE_PER_PACKET_SW_ENCRYPT, len);
  }
  
  #undef SVCMAP



--
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

mac80211: db3bdcb9c3ffc628c5284d7ed03a704295ba1214 breaks wds operation

[Sebastian Gottschall]

just for your information. while testing your latest mac80211 tree i 
found out that

db3bdcb9c3ffc628c5284d7ed03a704295ba1214
will break wds sta / ap support (tested in ath10k)
i understand what this patch does. but this patch should not find its 
way into mac80211 without a patch to all affected drivers
i'm pretty sure that problem will not just belong to ath10k. basicly all 
SW_CRYPTO_CONTROL enabled devices wont support wds anymore with that patch
beside this your patch description is wrong. ap_vlan which is used for 
wds sta / ap operation works with encryption in ath10k and is not 
related in any way to sw_crypto support


Sebastian



Am 20.04.2018 um 08:55 schrieb Johannes Berg:

On Fri, 2018-04-20 at 00:32 +0200, Bernhard Gabler wrote:


looking at the patch, I see more occurences of the outdated "IE" in a
constant name and function name:

  case NL80211_REGDOM_SET_BY_COUNTRY_IE:
or
  reg_process_hint_country_ie()


Right. I searched for further strings that would show up to the user,
but didn't see any, but the code still refers to it in many places.


Would it make sense to likewise fix these (and possibly more)
occurrences too, to match the spec from 2016?
For the sake of readability and consistency of code ...

I dunno. Country IE isn't the only place where "IE" is used, it's even
used in struct names (struct ieee80211_tim_ie, and many others), so I
would think that people who actually work on the code will have to be
aware of the previous wording of "Information Element" (and the
abbreviation IE) anyway. Changing *everything* here to be just _element
instead of _ie or then probably the shorter _elem would IMHO be too much
code churn.

johannes



--
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

Re: [PATCH v2 4/4] ath10k: Enable sta idle power save

[Sebastian Gottschall]

Yes this is WIFI chip set level power-save(based on idleness) and not
related to protocol power save. FW will turn off/scale down the
resources(clock/rails) based on opportunity(when ever idle mode is
detected). This power save is mostly done in disconnected state. I am
not really sure when framework/user-space triggers power-save
config(iw dev  set power_save on/off). Then doing this from
user-space will be unnecessarily toggling this config or may not be
setting at disconnected state.

I think that 'set power_save' commands affects struct
ieee80211_bss_conf::ps parameter and I don't think it should be used in
this case. We already have ath10k_config_ps() for 802.11 level of power
saving.

Arend again proposed runtime-pm with which I'm not very familiar. But
why would we want to disable this? Doesn't it make sense to have this
feature always enabled to save power? wcn3990 is a chip for a mobile
device anyway.
it might be made for mobile devices but who knows how it is used by the 
market.


Sebastian




--
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

Re: [PATCH v2 4/4] ath10k: Enable sta idle power save

[Sebastian Gottschall]

from my point of view powersave should be optional and not forced.

consider :
iw dev  set power_save on/off

so there is already a config option made for that purpose,

Sebastian

Am 17.04.2018 um 14:07 schrieb pill...@codeaurora.org:

From: Govind Singh <govi...@codeaurora.org>

Enable sta power save in fw for the targets that
supports idle power save. The idle ps enable command
will be ignored by the firmware which does not support
this feature.

Signed-off-by: Govind Singh <govi...@codeaurora.org>
Signed-off-by: Rakesh Pillai <pill...@codeaurora.org>
---
  drivers/net/wireless/ath/ath10k/mac.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 7e02ca02b28e..1d9222af1bb2 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4679,6 +4679,13 @@ static int ath10k_start(struct ieee80211_hw *hw)
}
}
  
+	param = ar->wmi.pdev_param->idle_ps_config;

+   ret = ath10k_wmi_pdev_set_param(ar, param, 1);
+   if (ret && ret != -EOPNOTSUPP) {
+   ath10k_warn(ar, "failed to enable idle_ps_config: %d\n", ret);
+   goto err_core_stop;
+   }
+
__ath10k_set_antenna(ar, ar->cfg_tx_chainmask, ar->cfg_rx_chainmask);
  
  	/*



--
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

Re: [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 09.04.2018 um 17:49 schrieb Kalle Valo:

Sebastian Gottschall <s.gottsch...@dd-wrt.com> writes:


you removed the call to leds_start from certain locations but you seem
to have ignored the comment i wrote above the function call.

IIRC I moved the comment to ath10k_leds_start().


there is a reason why i reinitialize the gpio output state in these
locations. the firmware for 9984 and 99xx resets the gpio registers
at certain points. this will lead to a non working led code.

What are the certain points exactly? I tried to be careful that from
firmware's point of view the functionality is the same, even if I moved
the call to a different location. Did you test the patch? Is it broken
now?
i reviewed the firmware code as well, but havent found the reason. can 
be core/chipset specific and not firmware software related.

i just can say it doesnt happen on 988x, just newer chipsets are affected

The naming refers to phases of ath10k initialisation which are:

create() - destroy()
register() - unregister()
start() - stop()

So the naming doesn't mean that every ath10k_foo_start() has to start
something, it just describes the phase of driver initialisation it's
called in.
yes, but its not a initialisation too. its just a gpio pin reset. the 
initialisation is

the trigger code itself from my point of view

Is this really so frequently called that we need to think about CPU
time? How often are we expecting the LED state to change?

But I'm not really following you, from firmware point of view the
functionality should be the same as with your patch.
a typical tpt trigger as used in openwrt for instance may trigger it 
several times per second.
i mean it might be really just a micro effect, but i just save cpu time 
whereever i can since i'm focused in

embedded development



so if you want to follow this up. remove ath10k_leds_start
and insert

ath10k_wmi_gpio_config(ar, ar->hw_params.led_pin, 0,
   WMI_GPIO_PULL_NONE, WMI_GPIO_INTTYPE_DISABLE);

in ath10k_leds_set_brightness_blocking

Calling ath10k_wmi_gpio_config() every time sounds like quite odd to me
and your patch didn't do that either. Are you sure this is really
needed?
yes. i tested this. you must set the gpio to output before setting it to 
any value, in case the output state was resetted back to input or any 
other default value. (which it does on 9984 at certain events)
i tested this on a netgear r7800 which is ipq8064 based with 2 9984 
chipsets.

but i cannot reproduce this on mips routers with 988x chipsets.

but as you say. its odd to call it every time. so i just call it with 
the reset method when neccessary. in our case, when interface operation 
starts.



--
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

Re: [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Hello Kalle

you removed the call to leds_start from certain locations but you seem 
to have ignored the comment i wrote above the function call.
there is a reason why i reinitialize the gpio output state in these 
locations. the firmware for 9984 and 99xx resets the gpio registers
at certain points. this will lead to a non working led code. so you must 
set the gpio output to high again and this is the reason why the 
function is called "reset_led_pin" and not led_start

because it doesnt start the led in any way. it just resets the output state
there is only one work around you may do.
you set the gpio out register to high on every led trigger, but this is 
what i wanted to avoid to save cpu time since a wmi call is more 
expensive than just a register write.


so if you want to follow this up. remove ath10k_leds_start
and insert

ath10k_wmi_gpio_config(ar, ar->hw_params.led_pin, 0,
   WMI_GPIO_PULL_NONE, WMI_GPIO_INTTYPE_DISABLE);

in ath10k_leds_set_brightness_blocking

but in any way the function name ath10k_leds_start is wrong. it doesnt 
describe the behaviour of the function



Am 06.04.2018 um 17:17 schrieb Kalle Valo:

From: Sebastian Gottschall <s.gottsch...@newmedia-net.de>

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based
chipsets with on chipset connected led's using WMI Firmware API.  The LED
device will get available named as "ath10k-phyX" at sysfs and can be controlled
with various triggers.  adds also debugfs interface for gpio control.

Signed-off-by: Sebastian Gottschall <s.gottsch...@dd-wrt.com>
Reviewed-by: Steve deRosier <deros...@cal-sierra.com>
[kvalo: major reorg and cleanup]
Signed-off-by: Kalle Valo <kv...@codeaurora.org>
---

v13:

* only compile tested!

* fix all checkpatch warnings

* fix commit log

* sizeof(struct ath10k_gpiocontrol) -> sizeof(*gpio)

* unsigned -> unsigned int

* remove GPIOLIB code, that should be added in a separate patch

* rename gpio.c to leds.c

* add leds.h

* rename some functions:

   ath10k_attach_led() -> ath10k_leds_register()
   ath10k_unregister_led() -> ath10k_leds_unregister()
   ath10k_reset_led_pin() -> ath10k_leds_start()

* call ath10k_leds_unregister() before ath10k_thermal_unregister() to preserve 
ordering

* call ath10k_leds_start() only from ath10k_core_start() and not from mac.c

* rename struct ath10k_gpiocontrol as anonymous function under struct
   ath10k::leds, no need for memory allocation

* merge ath10k_add_led() to ath10k_attach_led(), which is it's only caller

* remove #if IS_ENABLED() checks from most of places, memory savings from those 
were not worth it

* Kconfig help text improvement and move it lower in the menu, also don't 
enable it by default

* switch to set_brightness_blocking() so that the callback can sleep,
   then no need to use ath10k_wmi_cmd_send_nowait() and can take mutex
   to access ar->state

* don't touch ath10k_wmi_pdev_get_temperature()

* as QCA6174/QCA9377 are not (yet) supported don't add the command to WMI-TLV 
interface

* remove debugfs interface, that should be added in another patch

* cleanup includes


  drivers/net/wireless/ath/ath10k/Kconfig   |  10 +++
  drivers/net/wireless/ath/ath10k/Makefile  |   1 +
  drivers/net/wireless/ath/ath10k/core.c|  22 +++
  drivers/net/wireless/ath/ath10k/core.h|   9 ++-
  drivers/net/wireless/ath/ath10k/hw.h  |   1 +
  drivers/net/wireless/ath/ath10k/leds.c| 103 ++
  drivers/net/wireless/ath/ath10k/leds.h|  45 +
  drivers/net/wireless/ath/ath10k/mac.c |   1 +
  drivers/net/wireless/ath/ath10k/wmi-ops.h |  32 ++
  drivers/net/wireless/ath/ath10k/wmi-tlv.c |   2 +
  drivers/net/wireless/ath/ath10k/wmi.c |  54 
  drivers/net/wireless/ath/ath10k/wmi.h |  35 ++
  12 files changed, 314 insertions(+), 1 deletion(-)
  create mode 100644 drivers/net/wireless/ath/ath10k/leds.c
  create mode 100644 drivers/net/wireless/ath/ath10k/leds.h

diff --git a/drivers/net/wireless/ath/ath10k/Kconfig 
b/drivers/net/wireless/ath/ath10k/Kconfig
index deb5ae21a559..c4108c1bbe92 100644
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -52,6 +52,16 @@ config ATH10K_DEBUGFS
  
  	  If unsure, say Y to make it easier to debug problems.
  
+config ATH10K_LEDS

+   bool "Atheros ath10k LED support"
+   depends on ATH10K
+   select MAC80211_LEDS
+   select LEDS_CLASS
+   select NEW_LEDS
+   default y
+   help
+ This option is necessary, if you want LED support for chipset 
connected led pins. If unsure, say N.
+
  config ATH10K_SPECTRAL
bool "Atheros ath10k spectral scan support"
depends on ATH10K_DEBUGFS
diff --git a/drivers/net/wireless/ath/ath10k/Makefile 
b/drivers/net/wireless/ath/ath10k/Makefile
index 6739ac26fd29..16c822421c39 100644

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 06.04.2018 um 10:09 schrieb Kalle Valo:

(adding back the lists, please don't top post and trim your quotes)

Sebastian Gottschall <s.gottsch...@dd-wrt.com> writes:


okay. ath10k-check is buggy and doesnt work. so it doesnt help much
with code styles

root@seg-desktop:/xfs/ath10k/ath.gpio# ./ath10k-check
global: 'drivers/net/wireless/ath/ath10k/Kconfig' is not a source file.
Traceback (most recent call last):
   File "./ath10k-check", line 461, in 
     main()
   File "./ath10k-check", line 455, in main
     ret = run_checkpatch(args)
   File "./ath10k-check", line 275, in run_checkpatch
     output = subprocess.check_output(cmd, shell=True)
   File "/usr/lib/python2.7/subprocess.py", line 219, in check_output
     raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command 'global -f
drivers/net/wireless/ath/ath10k/Kconfig' returned non-zero exit status 1

You are missing gtags, see 'ath10k-check --help' for how to install:

Requirements (all available in $PATH):

* gcc
* sparse
* checkpatch.pl
* gtags (from package global)
ahm i did read this and this was all installed. but ath10k-check refuses 
to work


root@seg-desktop:/home/seg/DEV# gtags --version
gtags (GNU GLOBAL) 6.5.7
Copyright (c) 1996-2017 Tama Communications Corporation
License GPLv3+: GNU GPL version 3 or later 
<http://www.gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.





--
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

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 06.04.2018 um 10:07 schrieb Kalle Valo:

Sebastian Gottschall <s.gottsch...@dd-wrt.com> writes:


i have some comments about your check warnings.
some of them are bogus. for instance they advise to use "unsigned int"
instead of "unsigned". this might be better, but
the original kernel header uses "unsigned" as api definition. so i
decided to use the same declarations here.

Sure, but using "unsigned int" won't create any harm either.


for the rest like whitespaces i will make a new version and remove them

You missed my comment in my earlier mail that I'll send the next
version. I have already fixed all the warnings so let me submit it. I'll
do also some other changes.


oh okay. thank you. then forget all the rest. i will take care of these 
issues with the next patch i submit






--
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

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

i have some comments about your check warnings.
some of them are bogus. for instance they advise to use "unsigned int" 
instead of "unsigned". this might be better, but
the original kernel header uses "unsigned" as api definition. so i 
decided to use the same declarations here.

for the rest like whitespaces i will make a new version and remove them

Am 05.04.2018 um 20:01 schrieb Sebastian Gottschall:

Am 05.04.2018 um 16:44 schrieb Kalle Valo:

s.gottsch...@dd-wrt.com writes:


Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984
based chipsets with on chipset connected led's using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and
can be controlled with various triggers. adds also debugfs interface
for gpio control.

Signed-off-by: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

[...]

@@ -1034,7 +1068,7 @@ ath10k_wmi_pdev_get_temperature(struct ath10k 
*ar)

  if (IS_ERR(skb))
  return PTR_ERR(skb);
  -    return ath10k_wmi_cmd_send(ar, skb,
+    return ath10k_wmi_cmd_send_nowait(ar, skb,
ar->wmi.cmd->pdev_get_temperature_cmdid);
  }

This looks odd, I don't think it belongs to this patch.
thats true. but due the nature of this function i found it better to 
use nowait here. better if i split it up?


Also you made a some sort of record, your patch had 181 checkpatch
warnings! Do you use Word as your editor or what? But please do check
your editor settings and read the coding style documents.

no? i use midnight commander for all of my code since more than 20 years
and its the first time that i see such warnings. is there any special 
coding rule for ath10k which differs from the kernel rules?

and where is ath10k-check located?


https://wireless.wiki.kernel.org/en/users/drivers/ath10k/codingstyle

I'll send v13.

Here are the warnings from ath10k-check:

drivers/net/wireless/ath/ath10k/gpio.c:19: Please don't use multiple 
blank lines
drivers/net/wireless/ath/ath10k/gpio.c:30: Please don't use multiple 
blank lines
drivers/net/wireless/ath/ath10k/gpio.c:36: Prefer 'unsigned int' to 
bare use of 'unsigned'

drivers/net/wireless/ath/ath10k/gpio.c:38: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:39: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:39: Missing a blank line after 
declarations
drivers/net/wireless/ath/ath10k/gpio.c:45: Prefer 'unsigned int' to 
bare use of 'unsigned'
drivers/net/wireless/ath/ath10k/gpio.c:46: Alignment should match 
open parenthesis

drivers/net/wireless/ath/ath10k/gpio.c:48: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:50: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:58: Prefer 'unsigned int' to 
bare use of 'unsigned'

drivers/net/wireless/ath/ath10k/gpio.c:60: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:66: Prefer 'unsigned int' to 
bare use of 'unsigned'

drivers/net/wireless/ath/ath10k/gpio.c:68: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:74: Prefer 'unsigned int' to 
bare use of 'unsigned'
drivers/net/wireless/ath/ath10k/gpio.c:75: Alignment should match 
open parenthesis

drivers/net/wireless/ath/ath10k/gpio.c:77: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:86: trailing whitespace
drivers/net/wireless/ath/ath10k/gpio.c:86: please, no spaces at the 
start of a line
drivers/net/wireless/ath/ath10k/gpio.c:86: Blank lines aren't 
necessary after an open brace '{'
drivers/net/wireless/ath/ath10k/gpio.c:88: Missing a blank line after 
declarations
drivers/net/wireless/ath/ath10k/gpio.c:88: braces {} are not 
necessary for single statement blocks

drivers/net/wireless/ath/ath10k/gpio.c:113: trailing whitespace
drivers/net/wireless/ath/ath10k/gpio.c:114: Missing a blank line 
after declarations
drivers/net/wireless/ath/ath10k/gpio.c:114: braces {} are not 
necessary for single statement blocks

drivers/net/wireless/ath/ath10k/gpio.c:121: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:130: Please don't use multiple 
blank lines
drivers/net/wireless/ath/ath10k/gpio.c:132: Alignment should match 
open parenthesis

drivers/net/wireless/ath/ath10k/gpio.c:134: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:136: Missing a blank line 
after declarations

drivers/net/wireless/ath/ath10k/gpio.c:145: trailing whitespace
drivers/net/wireless/ath/ath10k/gpio.c:146: Missing a blank line 
after declarations

drivers/net/wireless/ath/ath10k/gpio.c:159: trailing whitespace
drivers/net/wireless/ath/ath10k/gpio.c:160: Missing a blank line 
after declarations

drivers/net/wireless/ath/ath10k/gpio.c:166: trailing whitespace
drivers/net/wireless/ath/ath10k/gpio.c:169: trailing whitespace
drivers/net/wireless/ath/ath10k/gpio.c:170: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:178: Missing a blank line 
after declarations
drivers/net/wireless/ath/ath10k/gpio.c:181: Prefer 
kzalloc(sizeof(*gpio)...) over kz

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 05.04.2018 um 16:44 schrieb Kalle Valo:

s.gottsch...@dd-wrt.com writes:


Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984
based chipsets with on chipset connected led's using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and
can be controlled with various triggers. adds also debugfs interface
for gpio control.

Signed-off-by: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

[...]


@@ -1034,7 +1068,7 @@ ath10k_wmi_pdev_get_temperature(struct ath10k *ar)
  if (IS_ERR(skb))
  return PTR_ERR(skb);
  -    return ath10k_wmi_cmd_send(ar, skb,
+    return ath10k_wmi_cmd_send_nowait(ar, skb,
ar->wmi.cmd->pdev_get_temperature_cmdid);
  }

This looks odd, I don't think it belongs to this patch.
thats true. but due the nature of this function i found it better to use 
nowait here. better if i split it up?


Also you made a some sort of record, your patch had 181 checkpatch
warnings! Do you use Word as your editor or what? But please do check
your editor settings and read the coding style documents.

no? i use midnight commander for all of my code since more than 20 years
and its the first time that i see such warnings. is there any special 
coding rule for ath10k which differs from the kernel rules?

and where is ath10k-check located?


https://wireless.wiki.kernel.org/en/users/drivers/ath10k/codingstyle

I'll send v13.

Here are the warnings from ath10k-check:

drivers/net/wireless/ath/ath10k/gpio.c:19: Please don't use multiple 
blank lines
drivers/net/wireless/ath/ath10k/gpio.c:30: Please don't use multiple 
blank lines
drivers/net/wireless/ath/ath10k/gpio.c:36: Prefer 'unsigned int' to 
bare use of 'unsigned'

drivers/net/wireless/ath/ath10k/gpio.c:38: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:39: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:39: Missing a blank line after 
declarations
drivers/net/wireless/ath/ath10k/gpio.c:45: Prefer 'unsigned int' to 
bare use of 'unsigned'
drivers/net/wireless/ath/ath10k/gpio.c:46: Alignment should match open 
parenthesis

drivers/net/wireless/ath/ath10k/gpio.c:48: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:50: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:58: Prefer 'unsigned int' to 
bare use of 'unsigned'

drivers/net/wireless/ath/ath10k/gpio.c:60: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:66: Prefer 'unsigned int' to 
bare use of 'unsigned'

drivers/net/wireless/ath/ath10k/gpio.c:68: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:74: Prefer 'unsigned int' to 
bare use of 'unsigned'
drivers/net/wireless/ath/ath10k/gpio.c:75: Alignment should match open 
parenthesis

drivers/net/wireless/ath/ath10k/gpio.c:77: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:86: trailing whitespace
drivers/net/wireless/ath/ath10k/gpio.c:86: please, no spaces at the 
start of a line
drivers/net/wireless/ath/ath10k/gpio.c:86: Blank lines aren't 
necessary after an open brace '{'
drivers/net/wireless/ath/ath10k/gpio.c:88: Missing a blank line after 
declarations
drivers/net/wireless/ath/ath10k/gpio.c:88: braces {} are not necessary 
for single statement blocks

drivers/net/wireless/ath/ath10k/gpio.c:113: trailing whitespace
drivers/net/wireless/ath/ath10k/gpio.c:114: Missing a blank line after 
declarations
drivers/net/wireless/ath/ath10k/gpio.c:114: braces {} are not 
necessary for single statement blocks

drivers/net/wireless/ath/ath10k/gpio.c:121: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:130: Please don't use multiple 
blank lines
drivers/net/wireless/ath/ath10k/gpio.c:132: Alignment should match 
open parenthesis

drivers/net/wireless/ath/ath10k/gpio.c:134: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:136: Missing a blank line after 
declarations

drivers/net/wireless/ath/ath10k/gpio.c:145: trailing whitespace
drivers/net/wireless/ath/ath10k/gpio.c:146: Missing a blank line after 
declarations

drivers/net/wireless/ath/ath10k/gpio.c:159: trailing whitespace
drivers/net/wireless/ath/ath10k/gpio.c:160: Missing a blank line after 
declarations

drivers/net/wireless/ath/ath10k/gpio.c:166: trailing whitespace
drivers/net/wireless/ath/ath10k/gpio.c:169: trailing whitespace
drivers/net/wireless/ath/ath10k/gpio.c:170: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:178: Missing a blank line after 
declarations
drivers/net/wireless/ath/ath10k/gpio.c:181: Prefer 
kzalloc(sizeof(*gpio)...) over kzalloc(sizeof(struct 
ath10k_gpiocontrol)...)
drivers/net/wireless/ath/ath10k/gpio.c:182: braces {} are not 
necessary for single statement blocks

drivers/net/wireless/ath/ath10k/gpio.c:192: trailing whitespace
drivers/net/wireless/ath/ath10k/gpio.c:194: line over 90 characters
drivers/net/wireless/ath/ath10k/gpio.c:196: trailing whitespace
drivers/net/wireless/ath/ath10k/core.h:865: trailing whitespace
drivers/net/wireless/ath/ath10k/co

Re: [PATCH v3] ath9k: fix crash in spectral scan

[Sebastian Gottschall]

Am 28.03.2018 um 13:21 schrieb Kalle Valo:

Sebastian Gottschall <s.gottsch...@dd-wrt.com> writes:


Apparently the automatic email was not sent, no idea why. But this was
applied to ath-next few days ago:

221b6ec69ed9 ath9k: fix crash in spectral scan

i have seen it. thx

any idea about my led code for ath10k?

I should get to it this or next week.
thank you. i have other usefull enhancements in my local pipeline which 
i start to rewrite for

latest next tree once its merged

Sebastian




--
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

Re: [PATCH v3] ath9k: fix crash in spectral scan

[Sebastian Gottschall]

Apparently the automatic email was not sent, no idea why. But this was
applied to ath-next few days ago:

221b6ec69ed9 ath9k: fix crash in spectral scan

i have seen it. thx
any idea about my led code for ath10k?

Sebastian


--
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

Re: [PATCH] mac80211: Fix wlan freezes under load at rekey

[Sebastian Gottschall]

so far i see no regressions with 9984 with that patch

except that 9984 has a rekeying problem at all. with wds ap -> wds sta 
mode rekeying will fail and it will reauthenticate at each interval. (it 
disconnects and reconnects)
but this is a long term issue qca never fixed for years. 988x doesnt 
suffer from that issue


Am 25.03.2018 um 23:59 schrieb Ben Greear:



On 03/25/2018 12:45 PM, Alexander Wetzel wrote:



What will happen to drivers like ath10k that cannot do software

encrypt/decrypt?


ath10k can support multiple key-ids as far as I can tell,
so maybe it would just never hit this code?


Still learning how that all fits together, but I'm sure any card using
mac80211 will also use ieee80211_key_replace, including ath10k.

We are in a race with the remote station there is no chance that we can
switch over exactly at the same time. If we can't fall pack to software
encryption we'll just have to drop some more packets.

I'm pretty sure mac80211 will just encrypt a frame in software and
send it to ath10 for processing once we have removed the key from the hw
in the same way as for any other card.


I don't think ath10k can handle sending already-encrypted data packets,
but possibly it works with newer upstream firmware/driver.

Either way, as long as it does not fundamentally break something (like
a non-recoverable data stall), then maybe your patch is fine anyway
and ath10k may just drop a few extra frames.


My expectation here would be, that the driver detects and drops the
pre-encrypted frames it no longer has a hw key for.

Unfortunately this is just an assumption, since I haven't found the code
handling this case in ath10k. And even if true this could well cause
some undesired warning messages.

I guess we should therefore make sure we do not send out any packets in
the critical time window.

Now stopping and flushing the queues seems to be bad idea which could
cause a real performance impact for on a busy AP with many stations and
rekeys enabled...
Luckily it looks like we can instead just set KEY_FLAG_TAINTED for the
old key to make sure we stop sending packets till the rekey is done.

That should cause ieee80211_tx_h_select_key to drop all packets without
a new per-packet check and also should cover potential undesired side
effects, isn't it?


I get lost in the weeds when trying to understand all of this, and some
previous attempts of mine to fix some of this evidently wasn't correct
enough to accept upstream:

https://www.spinics.net/lists/hostap/msg03677.html

So I really don't know enough to properly review
your patch.  Just be aware that ath10k is weird about sw-crypt, maybe 
make
sure your patch is tested on it to make sure it doesn't out-right 
break something.


Thanks,
Ben




--
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

Re: [PATCH] mac80211: Fix wlan freezes under load at rekey

[Sebastian Gottschall]

So I really don't know enough to properly review
your patch.  Just be aware that ath10k is weird about sw-crypt, maybe 
make
sure your patch is tested on it to make sure it doesn't out-right 
break something.
i will test it today in sta and ap mode. lets see whats the result after 
some hours


Sebastian


--
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

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 12.03.2018 um 08:53 schrieb Mathias Kresin:

10.03.2018 08:56, Sebastian Gottschall:



taken a look at the specific code, and from my point of view the code
that sets up the LED (including callback) is so trivial that it's 
simply

not worth dealing with adding the leds-gpio driver to the mix.
It adds extra complexity and an extra dependency for no reason at all.
There's no extra functionality to be gained by using it.

Stupid question: If the LED driver isn't using the GPIO subsystem
(when enabled), what happens if the user uses the GPIO subsystem to
fiddle with the pin the LED is connected to?


in our case here it can coexist and will not have a negative effect 
since the led will still run. (except if you reconfigure the gpio to 
input)

for sure it makes no sense.


Well, it will have negative effects as I noticed in OpenWrt. If the 
same GPIO is controlled by the internal LED function it can't be 
really used via the GPIO controller as there will be "bogus" changes 
of the GPIO pin state.
yes, it will have bogus changes, but it will not raise any other issues 
than the bogus changes your forcefully triggered. why disallowing 
something, if there is no reason for.

but i give you a example for a use.
if the wifi interface is down or not used, you can still take control 
about the led. so set the led to any state you want, no matter if the 
trigger is still installed


but however i can block the gpio for beeing reused if the led driver 
took it. this has been made in ath9k for instance.


Most likely I'm not aware of the upstream code you are talking about. 
But OpenWrt has a custom patch which registers the ath9k pins as GPIO 
controller.
thats the code i'm talking about, but as far as i know this code is 
upstream.


As soon as there are pins, manufactures will use them and the 
assumption about a default led connected to a specific pin will fail.
nope. manufactures are mainly using the qca propertiery driver and this 
qca driver uses fixed hardcoded led pins.
1 for qca988x and 17 for everything else. the led pins i assigned are 
following the qca specification for this chipsets and not to forget

i tested it on many devices


I've seen (home)routers routers using the "default" ath9k LED pin as 
button or for LEDs with a different purpose than "wireless". I never 
was able to find any kind of information which explains why exactly 
this specific pin is used for the ath9k-led. But that's another story.
i know. but thats not the case for ath10k so far and i'm following exact 
the same way qca is doing by themself.
i just know 2 cases. vendors to use the led pin of the chipset or they 
dont and use standard system leds with any assignment

and in all cases with no exception the default led pin was used.


My solution for OpenWrt was a patch which prevents the creation of the 
ath9k-led if the "default" pin is used as GPIO.
i have seen that code, but decided no to follow it since any developer 
is responsible for configuring whatever he wants. if it doesnt lead to a 
crash i see no reason for preventing it.

but thats my philosophy.


If mach files are used, the ath9k led isn't created (ath9k led pin is 
set to -1) in case the platform data have a button or led using the 
same pin. If the device tree is used, the ath9k led isn't created 
(ath9k led pin is set to -1) if the devicetree node for the ath9k 
device has the gpio-controller property. I'm not really proud of the 
code and it can be most likely done better, but it fixes the issue 
outlined above.
sounds very inflexible or better "intransparent". from the black box 
view its hard to understand how its handled without reading the code. 
its has no clean logic.
and your issue above is no issue. if a dev wants to make stupid things, 
let him do. he learns from his misstakes and he does not harm the 
hardware nor the stability.
there is no reason for extra hyper security barriers to guide someone 
how todo it. but here are samples to reuse a gpio from 2 points as i 
explained at the beginning.
i could imagine todo a manual error blinking or something if a interface 
is down. not sure, but other people might be more creative here.


I've done it this way since the use of the GPIO controller should 
always override any kind of default LEDs.


In the end ath[0|10]k-led is only required for hardware configurations 
where the wireless isn't fixed like with miniPCIe, USB ... wireless 
cards. If the configuration is fixed - like it is for most of the 
(home)routers - the GPIO controller can be registered via the 
devicetree and gpio-leds can be used. Something similar can be most 
likely done via mach files (I barely touch mach files).

ath79 uses mach files and no dts yet. qca ipq platforms are using dts.
and i have a mikrotik minipcie cards with wireless leds :-)

all 3 ways are valid.
and i have to note that i wrote that patch for embedded devices like 
openwrt does.
this code is a requirement to 

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

taken a look at the specific code, and from my point of view the code
that sets up the LED (including callback) is so trivial that it's simply
not worth dealing with adding the leds-gpio driver to the mix.
It adds extra complexity and an extra dependency for no reason at all.
There's no extra functionality to be gained by using it.

Stupid question: If the LED driver isn't using the GPIO subsystem
(when enabled), what happens if the user uses the GPIO subsystem to
fiddle with the pin the LED is connected to?


in our case here it can coexist and will not have a negative effect 
since the led will still run. (except if you reconfigure the gpio to input)

for sure it makes no sense.
but however i can block the gpio for beeing reused if the led driver 
took it. this has been made in ath9k for instance.

in ath10k i did not do it, since there is no technical requirement for it.
but that might not be the case for all gpio controllers, so there is no 
generic answer. for ath10k. harmless


Sebastian


Thanks,



--
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

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 08.03.2018 um 16:04 schrieb Pavel Machek:

Hi!


show me a proof that its copy & paste. because its not

I don't have to prove you anything. Sorry.

then i will deny your argument because its false.


But you said:


see ath9k. its exact the same implementation.

We don't want to have exact same code multiple times in the tree.
it isnt the exact same code, its just the way its done. i mean 
registering a led driver function happens multiple times in the kernel
you cannot say that calling led_classdev_register with the required 
parameters and function implementation is a case of code duplication.

then i would just say using of "printk" is a case of code duplication.
registering a led driver is nothing unusual, the implementation of the 
led driver is different each time. the implementation for led_brightness 
is very different

there are many led drivers in the kernel. all are going the same way.

i checked the kernel drivers just right now. almost all major wireless 
drivers are comming with a led driver without using gpiolib
your way is a case of codebloating since a registering gpio-leds 
requires a gpio driver for each wireless driver, even if its sometimes 
just a single register write for a led  and no real gpio.
a gpio driver is more complex and bigger than just a led driver. i just 
wrote a optional gpio driver to get access to all gpios available on the 
card. some vendors are using these in a unusual way
i have seen that vendors used them for reset button input etc. this is 
why i made it. so dont take this as a argument for going a impossible 
way (again. the kernel does not support multiple platform datas with the 
same name
THE KERNEL not leds-gpio. so once a leds-gpio platform data is 
registered, no other driver can register a new one.
in addition the kernel must have gpiolib support which increases the 
kernel size. the best way is always the most simple way and the smallest 
performant way.


and again. i did not duplicate the code of ath9k, i just used it as 
documentation to write a own led driver in a simple way


now a list of wireless drivers with a led driver
intersil
carl9170
ath5k
rt2x00
b43legacy
b43
iwlegacy
rtl8187
brcmsmac
iwlwifi

Sebastian

  
	Pavel



--
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

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 08.03.2018 um 15:29 schrieb Kalle Valo:

Pavel Machek <pa...@ucw.cz> writes:


ath10k_leds.gpio = ar->hw_params.led_pin;
gpio_led_register_device(0, _leds);

the problem are other architectures which have already registered gpio_led
at system start like ar71xx
you cannot register a second one. so a independend led driver is a
requirement for direct control

If the limitation indeed exists, please fix the limitation rather than
working around it in each and every driver.

see ath9k. its exact the same implementation.

Ok, so one more driver to fix.


in addition my variant does also work without gpiolib support. so it
can be used even if the kernel is configured without gpio support.
and not to forget, using a own led driver is more ligthweight from
the call path for each led on / off event which is important for low
performance embedded devices

We are not going to copy code because such code works without
libraries, and we are not going to copy code because that uses
less cache during calls. Sorry.

NAK. Please fix your patch.

To me it's not that black and white, sometimes copying code is simpler
than trying to bring up complicated or restricting frameworks (talking
in general here).

I haven't been able to review this patch in detail yet but from a quick
look most of the code is about standard ath10k infrastructure code. How
many lines of code would using leds-gpio save?
nothing. the led driver code is already very small. (see gpio.c in the 
patch) i had a leds-gpio implementation but it will not work since a 
platform data with the name "leds-gpio" does already exist on various 
platforms (ath79 for instance)
so a second leds-gpio can't be registered. so this solution does simply 
not work and asking me for fixing the kernel generic platform data 
handling like pavel did, is really out of mind
and a own led driver has also better performance than using the 
leds-gpio->gpiolib->ath10k gpio driver callpath.
if someone is still complaining that i added a gpio feature driver as 
well to my patch, i can simply remove that usefull feature and all would 
be happy. but i think having access to all gpios of the card
instead of just the led gpio makes sense to. thats why i implemented a 
gpiolib driver as well


Sebastian


--
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

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 08.03.2018 um 15:05 schrieb Pavel Machek:

On Thu 2018-03-08 13:33:29, Sebastian Gottschall wrote:

Am 08.03.2018 um 10:02 schrieb Pavel Machek:

On Wed 2018-03-07 18:54:41, Sebastian Gottschall wrote:

Am 07.03.2018 um 17:22 schrieb Rafał Miłecki:

On 2 March 2018 at 10:22, Sebastian Gottschall <s.gottsch...@dd-wrt.com> wrote:

leds-gpio is crap and limited. you can just register one platform data at
kernel runtime since its identified by its object name "led-gpio" but the
kernel forbidds to register 2 platform datas with the same name
consider the ar71xx devices with qca988x wifi chipsets. they all have
already a led platform data registered
at boottime. a second can't be registered anymore so gpio_led is useless
at
all for most developers on such platforms. its mainly used for early
kernel
platform data initialisation for system leds.

If leds-gpio has limitations, please fix those, rather then
introducing duplicated code.

there is no duplicated code introduced and there is no solution for it.
consider that all wifi drivers with softled support
are going that way with registering a own led driver. see ath9k for
instance. gpio-led cannot be used for it and there is no way to
support multiple platform datas with the same name. its a kernel limitation

I just reviewed some mips arch patch adding support for more LEDs for
selected devices:
[PATCH] MIPS: BCM47XX: Add Luxul XAP1500/XWR1750 WiFi LEDs
https://patchwork.linux-mips.org/patch/18681/

It seems to be simply adding another call to the
gpio_led_register_device(). It seems to me you can call that function
multiple times and register multiple structs with LEDs.

Isn't all you need something like this?

static const struct gpio_led ath10k_leds[] = {
 {
 .name = "ath10k:color:function",
 .active_low = 1,
 .default_state = LEDS_GPIO_DEFSTATE_KEEP,
 }
};

static struct gpio_led_platform_data bcm47xx_leds_pdata_extra = {
 leds = ath10k_leds;
 num_leds = ARRAY_SIZE(ath10k_leds);
};

ath10k_leds.gpio = ar->hw_params.led_pin;
gpio_led_register_device(0, _leds);

the problem are other architectures which have already registered gpio_led
at system start like ar71xx
you cannot register a second one. so a independend led driver is a
requirement for direct control

If the limitation indeed exists, please fix the limitation rather than
working around it in each and every driver.

see ath9k. its exact the same implementation.

Ok, so one more driver to fix.


in addition my variant does also work without gpiolib support. so it can be
used even if the kernel is configured
without gpio support.
and not to forget, using a own led driver is more ligthweight from the call
path for each led on / off event which is important for
low performance embedded devices

We are not going to copy code because such code works without
libraries, and we are not going to copy code because that uses
less cache during calls. Sorry.

NAK. Please fix your patch.

show me a proof that its copy & paste. because its not


Pavel



--
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

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 08.03.2018 um 10:02 schrieb Pavel Machek:

On Wed 2018-03-07 18:54:41, Sebastian Gottschall wrote:

Am 07.03.2018 um 17:22 schrieb Rafał Miłecki:

On 2 March 2018 at 10:22, Sebastian Gottschall <s.gottsch...@dd-wrt.com> wrote:

leds-gpio is crap and limited. you can just register one platform data at
kernel runtime since its identified by its object name "led-gpio" but the
kernel forbidds to register 2 platform datas with the same name
consider the ar71xx devices with qca988x wifi chipsets. they all have
already a led platform data registered
at boottime. a second can't be registered anymore so gpio_led is useless
at
all for most developers on such platforms. its mainly used for early
kernel
platform data initialisation for system leds.

If leds-gpio has limitations, please fix those, rather then
introducing duplicated code.

there is no duplicated code introduced and there is no solution for it.
consider that all wifi drivers with softled support
are going that way with registering a own led driver. see ath9k for
instance. gpio-led cannot be used for it and there is no way to
support multiple platform datas with the same name. its a kernel limitation

I just reviewed some mips arch patch adding support for more LEDs for
selected devices:
[PATCH] MIPS: BCM47XX: Add Luxul XAP1500/XWR1750 WiFi LEDs
https://patchwork.linux-mips.org/patch/18681/

It seems to be simply adding another call to the
gpio_led_register_device(). It seems to me you can call that function
multiple times and register multiple structs with LEDs.

Isn't all you need something like this?

static const struct gpio_led ath10k_leds[] = {
 {
 .name = "ath10k:color:function",
 .active_low = 1,
 .default_state = LEDS_GPIO_DEFSTATE_KEEP,
 }
};

static struct gpio_led_platform_data bcm47xx_leds_pdata_extra = {
 leds = ath10k_leds;
 num_leds = ARRAY_SIZE(ath10k_leds);
};

ath10k_leds.gpio = ar->hw_params.led_pin;
gpio_led_register_device(0, _leds);

the problem are other architectures which have already registered gpio_led
at system start like ar71xx
you cannot register a second one. so a independend led driver is a
requirement for direct control

If the limitation indeed exists, please fix the limitation rather than
working around it in each and every driver.

see ath9k. its exact the same implementation.
in addition my variant does also work without gpiolib support. so it can 
be used even if the kernel is configured

without gpio support.
and not to forget, using a own led driver is more ligthweight from the 
call path for each led on / off event which is important for

low performance embedded devices


Sebastian

Pavel



--
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

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 07.03.2018 um 17:22 schrieb Rafał Miłecki:

On 2 March 2018 at 10:22, Sebastian Gottschall <s.gottsch...@dd-wrt.com> wrote:

leds-gpio is crap and limited. you can just register one platform data at
kernel runtime since its identified by its object name "led-gpio" but the
kernel forbidds to register 2 platform datas with the same name
consider the ar71xx devices with qca988x wifi chipsets. they all have
already a led platform data registered
at boottime. a second can't be registered anymore so gpio_led is useless
at
all for most developers on such platforms. its mainly used for early
kernel
platform data initialisation for system leds.

If leds-gpio has limitations, please fix those, rather then
introducing duplicated code.

there is no duplicated code introduced and there is no solution for it.
consider that all wifi drivers with softled support
are going that way with registering a own led driver. see ath9k for
instance. gpio-led cannot be used for it and there is no way to
support multiple platform datas with the same name. its a kernel limitation

I just reviewed some mips arch patch adding support for more LEDs for
selected devices:
[PATCH] MIPS: BCM47XX: Add Luxul XAP1500/XWR1750 WiFi LEDs
https://patchwork.linux-mips.org/patch/18681/

It seems to be simply adding another call to the
gpio_led_register_device(). It seems to me you can call that function
multiple times and register multiple structs with LEDs.

Isn't all you need something like this?

static const struct gpio_led ath10k_leds[] = {
 {
 .name = "ath10k:color:function",
 .active_low = 1,
 .default_state = LEDS_GPIO_DEFSTATE_KEEP,
 }
};

static struct gpio_led_platform_data bcm47xx_leds_pdata_extra = {
 leds = ath10k_leds;
 num_leds = ARRAY_SIZE(ath10k_leds);
};

ath10k_leds.gpio = ar->hw_params.led_pin;
gpio_led_register_device(0, _leds);
the problem are other architectures which have already registered 
gpio_led at system start like ar71xx
you cannot register a second one. so a independend led driver is a 
requirement for direct control


Sebastian




--
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

Re: [PATCH 1/2] ath10k: Add WMI FWTEST command support

[Sebastian Gottschall]

Am 05.03.2018 um 19:48 schrieb Peter Oh:

From: Sathishkumar Muruganandam <murug...@codeaurora.org>

This patch adds support for WMI_FWTEST_CMD.
This command is used for setting the wifi parameters.


It's too lack of information in commit message.
You should add such what values are acceptable for which purpose by 
each param_id and param_value to make this changes meaningful to 
community.
i agree. i reviewed the firmware sourcecode to find out what its doing, 
but also within the firmware is almost undocumented. its a bunch of 
undocumented

numeric parameters with undocumented behaviour.
if qca is willig to document this feature it might be included.

Sebastian


--
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

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

leds-gpio is crap and limited. you can just register one platform data at
kernel runtime since its identified by its object name "led-gpio" but the
kernel forbidds to register 2 platform datas with the same name
consider the ar71xx devices with qca988x wifi chipsets. they all have
already a led platform data registered
at boottime. a second can't be registered anymore so gpio_led is useless at
all for most developers on such platforms. its mainly used for early kernel
platform data initialisation for system leds.

If leds-gpio has limitations, please fix those, rather then
introducing duplicated code.
there is no duplicated code introduced and there is no solution for it. 
consider that all wifi drivers with softled support
are going that way with registering a own led driver. see ath9k for 
instance. gpio-led cannot be used for it and there is no way to

support multiple platform datas with the same name. its a kernel limitation

Sebastian


NAK.
Pavel



--
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

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 27.02.2018 um 23:08 schrieb Rafał Miłecki:

On 26 February 2018 at 09:44,  <s.gottsch...@dd-wrt.com> wrote:

From: Sebastian Gottschall <s.gottsch...@newmedia-net.de>

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based 
chipsets with on chipset connected led's
using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and can be 
controlled with various triggers.
adds also debugfs interface for gpio control.

Hi Sebastian,

I just noticed this patch and have one question. It seems you register
GPIO chip and that WiFi LED is controller by a GPIO. Shouldn't you use
leds-gpio driver and just register platform device with
gpio_led_platform_data? That way you could avoid some code duplication
I think? It seems to be the purpose of leds-gpio driver.
leds-gpio is crap and limited. you can just register one platform data 
at kernel runtime since its identified by its object name "led-gpio" but 
the kernel forbidds to register 2 platform datas with the same name
consider the ar71xx devices with qca988x wifi chipsets. they all have 
already a led platform data registered
at boottime. a second can't be registered anymore so gpio_led is useless 
at all for most developers on such platforms. its mainly used for early 
kernel platform data initialisation for system leds.
at the beginning of development of this patch i started in that way and 
found out this limitation, so i had to rewrite everything.
the good point now is, it works even without gpiolib support since the 
gpio device is just a option, but not required for led control.


--
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

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 27.02.2018 um 18:03 schrieb Steve deRosier:

On Mon, Feb 26, 2018 at 12:44 AM, <s.gottsch...@dd-wrt.com> wrote:

From: Sebastian Gottschall <s.gottsch...@newmedia-net.de>

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based 
chipsets with on chipset connected led's
using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and can be 
controlled with various triggers.
adds also debugfs interface for gpio control.

Signed-off-by: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

v2  add correct gpio count per chipset and remove IPQ4019 support since this 
chipset does not make use of specific gpios)
v5  fix compiling without LED_CLASS and GPIOLIB support, fix also error by 
kbuild test robot which does not occur in standard builds. curious
v6  correct return values and fix comment style
v7  fix ath10k_unregister_led for compiling without LED_CLASS
v8  fix various code design issues reported by reviewers
v9  move led and led code to separate sourcefile (gpio.c)
v10 compile fix if gpiolib isnt included
v11 make register_gpio_chip static. advise by krobot
v12 fix warning
---
  drivers/net/wireless/ath/ath10k/Kconfig   |  10 ++
  drivers/net/wireless/ath/ath10k/Makefile  |   1 +
  drivers/net/wireless/ath/ath10k/core.c|  28 -
  drivers/net/wireless/ath/ath10k/core.h|  62 +-
  drivers/net/wireless/ath/ath10k/debug.c   | 146 ++
  drivers/net/wireless/ath/ath10k/gpio.c| 196 ++
  drivers/net/wireless/ath/ath10k/hw.h  |   2 +
  drivers/net/wireless/ath/ath10k/mac.c |   5 +
  drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 +-
  drivers/net/wireless/ath/ath10k/wmi-tlv.c |  65 ++
  drivers/net/wireless/ath/ath10k/wmi.c |  46 +++
  drivers/net/wireless/ath/ath10k/wmi.h |  36 ++
  12 files changed, 630 insertions(+), 3 deletions(-)
  create mode 100644 drivers/net/wireless/ath/ath10k/gpio.c


Assuming that kbuild robot doesn't kick back another build-time
warning, it looks OK to me.

:-) seems so


Reviewed-by: Steve deRosier <deros...@cal-sierra.com>

--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/



--
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

Re: [PULL] ath10k firmware 20180219

[Sebastian Gottschall]

what about this?


[   90.164755] ath10k_pci 0001:03:00.0: firmware crashed! (uuid n/a)
[   90.170845] ath10k_pci 0001:03:00.0: qca9984/qca9994 hw1.0 target 
0x0100 chip_id 0x sub 168c:cafe
[   90.180747] ath10k_pci 0001:03:00.0: kconfig debug 1 debugfs 1 
tracing 0 dfs 0 testmode 0
[   90.189767] ath10k_pci 0001:03:00.0: firmware ver 10.4-3.5.3-00053 
api 5 features 
no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 
4c56a386
[   90.204013] ath10k_pci 0001:03:00.0: board_file api 1 bmi_id N/A 
crc32 31ab2fd1
[   90.211307] ath10k_pci 0001:03:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 
cal otp max-sta 512 raw 0 hwcrypto 1

[   90.222712] ath10k_pci 0001:03:00.0: firmware register dump:
[   90.228360] ath10k_pci 0001:03:00.0: [00]: 0x000A 0x15B3 
0x0A0014F9 0x00975B31
[   90.236266] ath10k_pci 0001:03:00.0: [04]: 0x0A0014F9 0x00060730 
0x001D 0x000A
[   90.244171] ath10k_pci 0001:03:00.0: [08]: 0x0042F23C 0x0045E8E0 
0x000EEE00 0x0001
[   90.252075] ath10k_pci 0001:03:00.0: [12]: 0x0009 0x 
0x00973ABC 0x00973AD2
[   90.259974] ath10k_pci 0001:03:00.0: [16]: 0x0A0014F9 0x009C36CB 
0x009606CA 0x
[   90.267879] ath10k_pci 0001:03:00.0: [20]: 0x409CB97D 0x0040673C 
0x0040 0x000E
[   90.275784] ath10k_pci 0001:03:00.0: [24]: 0x809805BF 0x0040679C 
0x 0xC09CB97D
[   90.283688] ath10k_pci 0001:03:00.0: [28]: 0x809C9B59 0x004068BC 
0x 0x9026
[   90.291586] ath10k_pci 0001:03:00.0: [32]: 0x809B72AF 0x004068EC 
0x000EEE00 0x0042C264
[   90.299491] ath10k_pci 0001:03:00.0: [36]: 0x809B39F2 0x0040692C 
0x0002 0x0042C264
[   90.307396] ath10k_pci 0001:03:00.0: [40]: 0x809B30CF 0x0040695C 
0x00406980 0x0042443C
[   90.315300] ath10k_pci 0001:03:00.0: [44]: 0x8096EE0E 0x0040697C 
0x000EEDF4 0x0001
[   90.323204] ath10k_pci 0001:03:00.0: [48]: 0x8096F883 0x00406A2C 
0x0042DE2C 0x00424A64
[   90.331102] ath10k_pci 0001:03:00.0: [52]: 0x80963A26 0x00406A4C 
0x0042DE2C 0x00405528
[   90.339006] ath10k_pci 0001:03:00.0: [56]: 0x80960E80 0x00406A9C 
0x000D 0x0040

[   90.346910] ath10k_pci 0001:03:00.0: Copy Engine register dump:
[   90.352829] ath10k_pci 0001:03:00.0: [00]: 0x0004a000  15  15 3   3
[   90.359262] ath10k_pci 0001:03:00.0: [01]: 0x0004a400   7   7 74  75
[   90.365700] ath10k_pci 0001:03:00.0: [02]: 0x0004a800  47  47 46  47
[   90.372139] ath10k_pci 0001:03:00.0: [03]: 0x0004ac00  31  31 0  31
[   90.378571] ath10k_pci 0001:03:00.0: [04]: 0x0004b000  11  11 51  11
[   90.385008] ath10k_pci 0001:03:00.0: [05]: 0x0004b400   8   8 71  72
[   90.391440] ath10k_pci 0001:03:00.0: [06]: 0x0004b800   3   3 3   3
[   90.397879] ath10k_pci 0001:03:00.0: [07]: 0x0004bc00   1   1 1   1
[   90.404318] ath10k_pci 0001:03:00.0: [08]: 0x0004c000   0   0 127   0
[   90.410748] ath10k_pci 0001:03:00.0: [09]: 0x0004c400   0   0 0   0
[   90.417185] ath10k_pci 0001:03:00.0: [10]: 0x0004c800   0   0 0   0
[   90.423623] ath10k_pci 0001:03:00.0: [11]: 0x0004cc00   0   0 0   0
[   90.430142] ath10k_pci 0001:03:00.0: failed to setup peer SMPS for 
vdev 0: -108
[   90.437452] ath10k_pci 0001:03:00.0: failed to associate station 
14:91:82:b9:16:d4 for vdev 0: -108

[   90.532746] ieee80211 phy0: Hardware restart was requested
[   90.538253] ath10k_pci 0001:03:00.0: failed to delete peer 
14:91:82:b9:16:d4 for vdev 0: -108

[   94.931518] ath10k_pci 0001:03:00.0: device successfully recovered


Am 26.02.2018 um 15:58 schrieb Kalle Valo:

Sebastian Gottschall <s.gottsch...@dd-wrt.com> writes:


on 9984 i see these messages with this firmware from time to time

[272972.950788] ath10k_pci :01:00.0: Unknown eventid: 36925
[272982.868922] ath10k_pci :01:00.0: Unknown eventid: 36925
[335550.123780] ath10k_pci :01:00.0: Unknown eventid: 36925
[335550.156332] ath10k_pci :01:00.0: Unknown eventid: 36925
[335550.158813] ath10k_pci :01:00.0: Unknown eventid: 36925
[335550.193144] ath10k_pci :01:00.0: Unknown eventid: 36925
[365157.869540] ath10k_pci :01:00.0: Unknown eventid: 36925
[365157.902452] ath10k_pci :01:00.0: Unknown eventid: 36925


according to the WMI header this maybe a critical internal error

Thanks for the report. We are working on a fix but just ignore the
warning for now.



--
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

Re: [PATCH] ath9k: introduce endian_check module parameter

[Sebastian Gottschall]

Am 26.02.2018 um 11:07 schrieb Bas Vermeulen:

On 26-02-18 10:54, Kalle Valo wrote:

Bas Vermeulen <bverm...@blackstar.nl> writes:


A random (little endian eeprom'd) ar9278 card didn't work on my
PowerMac G5 without allowing the driver to byte-swap the eeprom.

Introduce a module parameter endian_check to allow this to happen,
and the PCIe card to function correctly on BE powerpc.

Signed-off-by: Bas Vermeulen <bverm...@blackstar.nl>
---
  drivers/net/wireless/ath/ath9k/init.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c

index fa58a32227f5..421039dc060a 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -67,6 +67,9 @@ static int ath9k_ps_enable;
  module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
  MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
  +static int ath9k_endian_check;
+module_param_named(endian_check, ath9k_endian_check, int, 0444);
+MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness 
compatibility");

  #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
    int ath9k_use_chanctx;
@@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc *sc)
  ether_addr_copy(common->macaddr, mac);
    ah->ah_flags &= ~AH_USE_EEPROM;
-    ah->ah_flags |= AH_NO_EEP_SWAP;
+    if (!ath9k_endian_check)
+    ah->ah_flags |= AH_NO_EEP_SWAP;

A bit annoying to have a module parameter, isn't there any automatic way
to detect/try this? But on the other hand I guess this isn't a common
problem as nobody has reported this before?
There is an automatic way to detect this, but that is disabled by the 
AH_NO_EEP_SWAP flag.
The platform initialisation does not set this flag if the endian_check 
member of pdata is set
to true, but there is no way to not set this when using a device tree. 
I used a module
parameter instead of a device tree variable because I don't know of a 
way to modify the

device tree my PowerMac boots with.
have you tried to compile it without device tree support? since its just 
a pcie card, i dont think that devicetree is required here

it should run fine without it.


Bas Vermeulen



--
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

Re: [PATCH] ath9k: introduce endian_check module parameter

[Sebastian Gottschall]

Am 26.02.2018 um 10:54 schrieb Kalle Valo:

Bas Vermeulen <bverm...@blackstar.nl> writes:


A random (little endian eeprom'd) ar9278 card didn't work on my
PowerMac G5 without allowing the driver to byte-swap the eeprom.

Introduce a module parameter endian_check to allow this to happen,
and the PCIe card to function correctly on BE powerpc.

Signed-off-by: Bas Vermeulen <bverm...@blackstar.nl>
---
  drivers/net/wireless/ath/ath9k/init.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index fa58a32227f5..421039dc060a 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -67,6 +67,9 @@ static int ath9k_ps_enable;
  module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
  MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
  
+static int ath9k_endian_check;

+module_param_named(endian_check, ath9k_endian_check, int, 0444);
+MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness compatibility");
  #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
  
  int ath9k_use_chanctx;

@@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc *sc)
ether_addr_copy(common->macaddr, mac);
  
  	ah->ah_flags &= ~AH_USE_EEPROM;

-   ah->ah_flags |= AH_NO_EEP_SWAP;
+   if (!ath9k_endian_check)
+   ah->ah_flags |= AH_NO_EEP_SWAP;

A bit annoying to have a module parameter, isn't there any automatic way
to detect/try this? But on the other hand I guess this isn't a common
problem as nobody has reported this before?

There is a way by simply checking the eeprom magic on this chipset




--
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

Re: [PATCH] Revert "mac80211: use QoS NDP for AP probing"

[Sebastian Gottschall]

md_build_klv_null_data(struct wl1271 *wl,
struct sk_buff *skb = NULL;
int ret = -ENOMEM;
  
-	skb = ieee80211_nullfunc_get(wl->hw, vif, false);

+   skb = ieee80211_nullfunc_get(wl->hw, vif);
if (!skb)
goto out;
  
diff --git a/include/net/mac80211.h b/include/net/mac80211.h

index c96511fa9198..03280be484b2 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -4478,24 +4478,18 @@ struct sk_buff *ieee80211_pspoll_get(struct 
ieee80211_hw *hw,
   * ieee80211_nullfunc_get - retrieve a nullfunc template
   * @hw: pointer obtained from ieee80211_alloc_hw().
   * @vif:  ieee80211_vif pointer from the add_interface callback.
- * @qos_ok: QoS NDP is acceptable to the caller, this should be set
- * if at all possible
   *
   * Creates a Nullfunc template which can, for example, uploaded to
   * hardware. The template must be updated after association so that correct
   * BSSID and address is used.
   *
- * If @qos_ndp is set and the association is to an AP with QoS/WMM, the
- * returned packet will be QoS NDP.
- *
   * Note: Caller (or hardware) is responsible for setting the
   * _FCTL_PM bit as well as Duration and Sequence Control fields.
   *
   * Return: The nullfunc template. %NULL on error.
   */
  struct sk_buff *ieee80211_nullfunc_get(struct ieee80211_hw *hw,
-  struct ieee80211_vif *vif,
-  bool qos_ok);
+  struct ieee80211_vif *vif);
  
  /**

   * ieee80211_probereq_get - retrieve a Probe Request template
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 39b660b9a908..cc55ff8ae979 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -896,7 +896,7 @@ void ieee80211_send_nullfunc(struct ieee80211_local *local,
struct ieee80211_hdr_3addr *nullfunc;
struct ieee80211_if_managed *ifmgd = >u.mgd;
  
-	skb = ieee80211_nullfunc_get(>hw, >vif, true);

+   skb = ieee80211_nullfunc_get(>hw, >vif);
if (!skb)
return;
  
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c

index 25904af38839..16bc1dacf1b3 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -4440,15 +4440,13 @@ struct sk_buff *ieee80211_pspoll_get(struct 
ieee80211_hw *hw,
  EXPORT_SYMBOL(ieee80211_pspoll_get);
  
  struct sk_buff *ieee80211_nullfunc_get(struct ieee80211_hw *hw,

-  struct ieee80211_vif *vif,
-  bool qos_ok)
+  struct ieee80211_vif *vif)
  {
struct ieee80211_hdr_3addr *nullfunc;
struct ieee80211_sub_if_data *sdata;
struct ieee80211_if_managed *ifmgd;
struct ieee80211_local *local;
struct sk_buff *skb;
-   bool qos = false;
  
  	if (WARN_ON(vif->type != NL80211_IFTYPE_STATION))

return NULL;
@@ -4457,17 +4455,7 @@ struct sk_buff *ieee80211_nullfunc_get(struct 
ieee80211_hw *hw,
ifmgd = >u.mgd;
local = sdata->local;
  
-	if (qos_ok) {

-   struct sta_info *sta;
-
-   rcu_read_lock();
-   sta = sta_info_get(sdata, ifmgd->bssid);
-   qos = sta && sta->sta.wme;
-   rcu_read_unlock();
-   }
-
-   skb = dev_alloc_skb(local->hw.extra_tx_headroom +
-   sizeof(*nullfunc) + 2);
+   skb = dev_alloc_skb(local->hw.extra_tx_headroom + sizeof(*nullfunc));
if (!skb)
return NULL;
  
@@ -4477,19 +4465,6 @@ struct sk_buff *ieee80211_nullfunc_get(struct ieee80211_hw *hw,

nullfunc->frame_control = cpu_to_le16(IEEE80211_FTYPE_DATA |
  IEEE80211_STYPE_NULLFUNC |
  IEEE80211_FCTL_TODS);
-   if (qos) {
-   __le16 qos = cpu_to_le16(7);
-
-   BUILD_BUG_ON((IEEE80211_STYPE_QOS_NULLFUNC |
- IEEE80211_STYPE_NULLFUNC) !=
-IEEE80211_STYPE_QOS_NULLFUNC);
-   nullfunc->frame_control |=
-   cpu_to_le16(IEEE80211_STYPE_QOS_NULLFUNC);
-   skb->priority = 7;
-   skb_set_queue_mapping(skb, IEEE80211_AC_VO);
-   skb_put_data(skb, , sizeof(qos));
-   }
-
memcpy(nullfunc->addr1, ifmgd->bssid, ETH_ALEN);
memcpy(nullfunc->addr2, vif->addr, ETH_ALEN);
memcpy(nullfunc->addr3, ifmgd->bssid, ETH_ALEN);



--
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

Re: [PATCH v9] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 22.02.2018 um 23:17 schrieb Steve deRosier:

On Thu, Feb 22, 2018 at 3:15 AM,  <s.gottsch...@dd-wrt.com> wrote:

From: Sebastian Gottschall <s.gottsch...@newmedia-net.de>

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based 
chipsets with on chipset connected led's
using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and can be 
controlled with various triggers.
adds also debugfs interface for gpio control.

Signed-off-by: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

v2  add correct gpio count per chipset and remove IPQ4019 support since this 
chipset does not make use of specific gpios)
v5  fix compiling without LED_CLASS and GPIOLIB support, fix also error by 
kbuild test robot which does not occur in standard builds. curious
v6  correct return values and fix comment style
v7  fix ath10k_unregister_led for compiling without LED_CLASS
v8  fix various code design issues reported by reviewers
v9  move led and led code to separate sourcefile (gpio.c)
---
  drivers/net/wireless/ath/ath10k/Kconfig   |   3 +
  drivers/net/wireless/ath/ath10k/Makefile  |   1 +
  drivers/net/wireless/ath/ath10k/core.c|  28 -
  drivers/net/wireless/ath/ath10k/core.h|  33 -
  drivers/net/wireless/ath/ath10k/debug.c   | 142 ++
  drivers/net/wireless/ath/ath10k/gpio.c| 196 ++
  drivers/net/wireless/ath/ath10k/hw.h  |   2 +
  drivers/net/wireless/ath/ath10k/mac.c |   5 +
  drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 +-
  drivers/net/wireless/ath/ath10k/wmi-tlv.c |  65 ++
  drivers/net/wireless/ath/ath10k/wmi.c |  46 +++
  drivers/net/wireless/ath/ath10k/wmi.h |  36 ++
  12 files changed, 590 insertions(+), 3 deletions(-)
  create mode 100644 drivers/net/wireless/ath/ath10k/gpio.c

diff --git a/drivers/net/wireless/ath/ath10k/Kconfig 
b/drivers/net/wireless/ath/ath10k/Kconfig
index deb5ae21a559..c46b7658a820 100644
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -2,6 +2,9 @@ config ATH10K
  tristate "Atheros 802.11ac wireless cards support"
  depends on MAC80211 && HAS_DMA
 select ATH_COMMON
+select MAC80211_LEDS
+select LEDS_CLASS
+select NEW_LEDS
 select CRC32
 select WANT_DEV_COREDUMP
  ---help---

Pure question: do we require LEDS, or is this an option? I assumed all
along it was an optional thing - ie if GPIOs and/or LEDs were
configured, we added this code. And if not optional, then what happens
if we are on a platform that can't support LEDS_CLASS or NEW_LEDS,
assuming there is such a thing?
i took this behaviour from ath9k/ath5k, both driver auto select 
MAC80211_LEDS and LEDS_CLASS (by the way MAC80211_LEDS auto selects 
LEDS_CLASS too).  only chipsets which are known to have preconfigured 
leds are used
and led will only turn on if you enable it in sysfs by assigning a 
trigger to the led.
for sure this can be removed from the Kconfig. it will compile without 
it as well. so this is optional. i just added it since all other drivers 
behave in the same way.
in addition. LEDS_CLASS  / NEW_LEDS is a kernel api, not a driver. so 
all platforms to support LEDS_CLASS. just enabling LEDS_CLASS will not 
cause any platform specific dependency.




diff --git a/drivers/net/wireless/ath/ath10k/Makefile 
b/drivers/net/wireless/ath/ath10k/Makefile
index 6739ac26fd29..bcb234f0b940 100644
--- a/drivers/net/wireless/ath/ath10k/Makefile
+++ b/drivers/net/wireless/ath/ath10k/Makefile
@@ -20,6 +20,7 @@ ath10k_core-$(CONFIG_NL80211_TESTMODE) += testmode.o
  ath10k_core-$(CONFIG_ATH10K_TRACING) += trace.o
  ath10k_core-$(CONFIG_THERMAL) += thermal.o
  ath10k_core-$(CONFIG_MAC80211_DEBUGFS) += debugfs_sta.o
+ath10k_core-y += gpio.o
  ath10k_core-$(CONFIG_PM) += wow.o
  ath10k_core-$(CONFIG_DEV_COREDUMP) += coredump.o


I'd expect it would be something like `ath10k_core-$(CONFIG_GPIO) +=
gpoi.o`.  Maybe I'm mistaken.
gpio.c contains the MAC80211_LEDS code and has a guard for GPIOLIB 
inside. it can be compiled even if GPIOLIB is disabled in system. (which 
is indeed platform specific)
and leds are still supported without gpio support since it does contain 
a led only driver and a separate gpio driver.

i suggest more somelike like

ath10k_core-$(ATH10K_LEDS) += gpio.o

if you want it totally optional which requires some other small changes as well 
(mainly renaming some ifdefs)


(Note, I didn't look up the actual config option name, I'm guessing.
Assume I wrote something reasonable for my example.)

I only ask the above two questions, not because I think it's wrong,
but because I don't quite know the intention and it makes me wonder.

Other than those questions, which are optional as the code looks
correct to me, the rest of it looks fine to me.
i fully understand your concerns, i just followed other driv

Re: [PULL] ath10k firmware 20180219

[Sebastian Gottschall]

on 9984 i see these messages with this firmware from time to time

[272972.950788] ath10k_pci :01:00.0: Unknown eventid: 36925
[272982.868922] ath10k_pci :01:00.0: Unknown eventid: 36925
[335550.123780] ath10k_pci :01:00.0: Unknown eventid: 36925
[335550.156332] ath10k_pci :01:00.0: Unknown eventid: 36925
[335550.158813] ath10k_pci :01:00.0: Unknown eventid: 36925
[335550.193144] ath10k_pci :01:00.0: Unknown eventid: 36925
[365157.869540] ath10k_pci :01:00.0: Unknown eventid: 36925
[365157.902452] ath10k_pci :01:00.0: Unknown eventid: 36925


according to the WMI header this maybe a critical internal error

Am 22.02.2018 um 11:44 schrieb Kalle Valo:

Hi linux-firmware maintainers,

here's a pull request for updating ath10k firmwares. Earlier I have been
submitting these as patches but as the patches got pretty big I decided
to try using pull requests instead.

Please let me know if there are any problems.

Kalle

The following changes since commit 6d5131107f2ba67a13f469ac770a55f101ba654d:

   rtl_bt: Add firmware and configuration files for the Bluetooth parts of 
RTL8821C and RTL8723D (2018-02-13 13:09:19 -0500)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/linux-firmware.git 
ath10k-20180219

for you to fetch changes up to 9b3d016886a8e365f9493a724bf2945b97bcfe43:

   ath10k: QCA9984 hw1.0: update firmware-5.bin to 10.4-3.5.3-00053 (2018-02-19 
12:03:36 +0200)


Kalle Valo (9):
   ath10k: QCA4019 hw1.0: update firmware-5.bin to 10.4-3.5.3-00053
   ath10k: QCA4019 hw1.0: update board-2.bin
   ath10k: QCA6174 hw3.0: update firmware-6.bin to 
WLAN.RM.4.4.1-00079-QCARMSWPZ-1
   ath10k: QCA6174 hw3.0: update board-2.bin
   ath10k: QCA9377 hw1.0: update firmware-5.bin to 
WLAN.TF.1.0-2-QCATFSWPZ-5
   ath10k: QCA9887 hw1.0: update firmware-5.bin to 10.2.4-1.0-00037
   ath10k: QCA9888 hw2.0: update firmware-5.bin to 10.4-3.5.3-00053
   ath10k: QCA988X hw2.0: update firmware-5.bin to 10.2.4-1.0-00037
   ath10k: QCA9984 hw1.0: update firmware-5.bin to 10.4-3.5.3-00053

  WHENCE|  14 ++--
  ath10k/QCA4019/hw1.0/board-2.bin  | Bin 109172 -> 133452 bytes
  ath10k/QCA4019/hw1.0/firmware-5.bin   | Bin 535412 -> 568636 bytes
  ath10k/QCA6174/hw3.0/board-2.bin  | Bin 501748 -> 551128 bytes
  ath10k/QCA6174/hw3.0/firmware-6.bin   | Bin 727776 -> 730788 bytes
  ath10k/QCA9377/hw1.0/firmware-5.bin   | Bin 605908 -> 783336 bytes
  ath10k/QCA9377/hw1.0/notice_ath10k_firmware-5.txt |   4 ++--
  ath10k/QCA9887/hw1.0/firmware-5.bin   | Bin 235880 -> 237584 bytes
  ath10k/QCA9888/hw2.0/firmware-5.bin   | Bin 647460 -> 659708 bytes
  ath10k/QCA988X/hw2.0/firmware-5.bin   | Bin 248188 -> 248108 bytes
  ath10k/QCA988X/hw2.0/notice_ath10k_firmware-5.txt |  25 ++
  ath10k/QCA9984/hw1.0/firmware-5.bin   | Bin 622060 -> 647380 bytes
  12 files changed, 20 insertions(+), 23 deletions(-)



--
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

Re: [PATCH v7] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Agreed, I am also not a fan of bloat code. I wasn't suggesting you
move it to the .h, just saying that if it were not static, that's how
I'd suggest doing it.

In this case, keep it static, keep it in the .c.  And use the blocking
I suggested. You will get the optimizer friendly result you're looking
for, but make it more readable and more-inline with the dominant style
for these things.

thats what i did already in my sourcetree



true, but consider that required structures like gpio_chip (ar->gpio) and
led_classdev arent defined in the kernel if these CONFIG options arent
configured. so i may move it into a separate function ,but the guards will
remain.
thats not my fault. thats a fault of the kernel api.


Hm. I assumed the names were still valid, even if the functionality
that uses it wasn't.  Understood.

In that case, I suggest moving the code to a separate static function
that can be guarded. It keeps the mess out of the main startup
function, makes it easier to read as it collapses to a single
self-documented function name, and gets rid of the label and jump.

yes but we have 2 guards. GPIOLIB and LED_CLASS
so the mess remaines in the same way with no change. the same unreadable 
code just moved (personally i think its not that unreadable since its small)





The rest of this looks OK to me.

okay. i already changed some code, based on your requests but will wait for
reply of you and for other comments until i send out a new version

I appreciate the extra work you've put in. I hadn't expected my
comments would've generated so much extra work; sorry about that. It's
looking good.
i just want it upstream. i have alot of usefull patches in my backhand 
and its now getting hard to maintain the code with new ath10k patches.
and at the end its not that much work as it seems. just a question of 
some seconds todo that changes. i can live with it.


Sebastian


--
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

Re: [PATCH v7] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

don't need the err_no_led: jump.
true, but consider that required structures like gpio_chip (ar->gpio) 
and led_classdev arent defined in the kernel if these CONFIG options 
arent configured. so i may move it into a separate function ,but the 
guards will remain.

thats not my fault. thats a fault of the kernel api.


The rest of this looks OK to me.
okay. i already changed some code, based on your requests but will wait 
for reply of you and for other comments until i send out a new version


- Steve

--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/



--
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

Re: [PATCH v7] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

+struct ath10k_gpiocontrol {
+    struct ath10k *ar;
+    u32 gpio_set_num, gpio_num, gpio_input, gpio_pull_type, 
gpio_intr_mode, gpio_set; /* since we have no gpio read method, these 
are the state variables for debugfs.  */


I think the checkpatch.pl will complain above defintely.
Best regards,

because of the one liner?


Sebastian


--
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

Re: [PATCH] v5 ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 18.02.2018 um 15:33 schrieb Bo YU:

Hi,
I am just wondering about something.I am a newbies.

On Sun, Feb 18, 2018 at 01:03:00PM +0100, s.gottsch...@dd-wrt.com wrote:



+#ifdef CONFIG_GPIOLIB
+
+static int ath10k_gpio_pin_cfg_input(struct gpio_chip *chip, 
unsigned offset)

+{
+    struct ath10k_gpiocontrol *gpio = container_of(chip, struct 
ath10k_gpiocontrol, gchip);
+    ath10k_wmi_gpio_config(gpio->ar, offset, 1, WMI_GPIO_PULL_NONE, 
WMI_GPIO_INTTYPE_DISABLE); // configure to input

If i remember right,comment style in kernel code would better to use
/* .. */. Same the below comment.

true

+ +/* register GPIO chip */

+static int ath10k_register_gpio_chip(struct ath10k *ar)
+{
+    struct ath10k_gpiocontrol *gpio;
+    gpio = kzalloc(sizeof(struct ath10k_gpiocontrol), GFP_KERNEL);
+    if (!gpio) {
+    return -1;

There is rare value returned after allocing memory from kernel.Maybe
"return -ENOMEM"?
not really relevant since the return check just checks for value present 
and not for value type

but i applied it for next patch version

--
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

Re: [PATCH] v2 ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 16.02.2018 um 17:33 schrieb Steve deRosier:

On Fri, Feb 16, 2018 at 2:30 AM,  <s.gottsch...@dd-wrt.com> wrote:

From: Sebastian Gottschall <s.gottsch...@newmedia-net.de>

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 and ipq4019 
based chipsets with on chipset connected led's
using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and can be 
controlled with various triggers.
adds also debugfs interface for gpio control.


Hi Sebastian,

First off, let me say I love this and the effort to make the gpios
hanging off the wifi chip as proper system gpios. Years ago I had to
do a hack to make some wifi-chip provided pins available to a customer
who needed more GPIOs on our SoM. It would have been nice if provided
hardware functionality had already been properly supported by the
driver.

In looking through, it looks like you're hooking into the standard
gpio-chip driver interface. Which is great. So, why are you providing
a separate out-of-band debugfs access interface for gpio control?
this was developed first before the real gpio interface. that way you 
can poke manually values for testing
like gpio interrupt etc. which isnt exposed by the gpio and led 
interface. its only for diagnostic and is not neccessary, but

it was in my initial code so i did include it in that patch

Seems to me to be a duplicate of the interface in sysfs that provides
gpio access (`/sys/class/gpio`). My preference is we don't duplicate
functionality and that we use the standard provided features. That way
we don't possibly confuse users, and we also reduce our maintenance
effort.
its not a duplicate as i said before it offers more flags which arent 
used by the rest

gpio config has 4 values. gpio num, input/output, pull_type, interrupt mode

but not all is used by the gpio controller driver


Additionally, what happens when the relevant GPIO configuration
options aren't enabled? Do we have a compilation issue?
you mean if led and gpio is not selected. mmh you get a compile error 
for sure. its unlikelly that its not enabled, but i can

take care of it in the next patch version

I'm more
familiar with being a _consumer_ of gpiolib in my drivers and I know
if CONFIG_GPIOLIB isn't checked I end up with problems. I'm unsure
what happens when you're presenting a gpio-chip interface without the
relevant CONFIG_ being enabled. Note that I didn't test this, I'm just
asking the question to be sure we don't forget anything.
you're absolutelly right. i will add these checks. i can say that i 
tested it on 9984, 998x and 988x devices so far
and the gpio and led code gets only registered on known to be working 
chipsets


Sebastian


- Steve



--
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

Re: [PATCH 1/1] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Looks like your mail program has eaten the patch [1]. It is also not clear why
it was posted as reply to the "dt: bindings: add bindings for wcn3990 wifi
block" patch. :)

Kind regards,
Sven
[1] https://www.kernel.org/doc/html/v4.15/process/email-clients.html


trying to fix it right now :-)
i hate the git commands. takes longer to send a email, than just 
developing the patch itself :-)



--
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

[PATCH 1/1] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 and 
ipq4019 based chipsets with on chipset connected led's

using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and 
can be controlled with various triggers.

adds also debugfs interface for gpio control.

Signed-off-by: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

 drivers/net/wireless/ath/ath10k/core.c    | 168 
+-

 drivers/net/wireless/ath/ath10k/core.h    |  15 +++
 drivers/net/wireless/ath/ath10k/debug.c   | 140 +
 drivers/net/wireless/ath/ath10k/hw.h  |   1 +
 drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 ++-
 drivers/net/wireless/ath/ath10k/wmi.c |  43 
 drivers/net/wireless/ath/ath10k/wmi.h |  36 +++
 7 files changed, 436 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c

index f3ec13b80b20..b712bf09ad6f 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -21,6 +21,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+

 #include "core.h"
 #include "mac.h"
@@ -65,6 +68,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA988X_HW_2_0_VERSION,
     .dev_id = QCA988X_2_0_DEVICE_ID,
     .name = "qca988x hw2.0",
+        .led_pin = 1,
     .patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -94,6 +98,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA988X_HW_2_0_VERSION,
     .dev_id = QCA988X_2_0_DEVICE_ID_UBNT,
     .name = "qca988x hw2.0 ubiquiti",
+        .led_pin = 1,
     .patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -123,6 +128,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA9887_HW_1_0_VERSION,
     .dev_id = QCA9887_1_0_DEVICE_ID,
     .name = "qca9887 hw1.0",
+        .led_pin = 1,
     .patch_load_addr = QCA9887_HW_1_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -267,6 +273,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA99X0_HW_2_0_DEV_VERSION,
     .dev_id = QCA99X0_2_0_DEVICE_ID,
     .name = "qca99x0 hw2.0",
+        .led_pin = 17,
     .patch_load_addr = QCA99X0_HW_2_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .otp_exe_param = 0x0700,
@@ -301,6 +308,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA9984_HW_1_0_DEV_VERSION,
     .dev_id = QCA9984_1_0_DEVICE_ID,
     .name = "qca9984/qca9994 hw1.0",
+        .led_pin = 17,
     .patch_load_addr = QCA9984_HW_1_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
@@ -340,6 +348,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA9888_HW_2_0_DEV_VERSION,
     .dev_id = QCA9888_2_0_DEVICE_ID,
     .name = "qca9888 hw2.0",
+        .led_pin = 17,
     .patch_load_addr = QCA9888_HW_2_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
@@ -436,6 +445,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA4019_HW_1_0_DEV_VERSION,
     .dev_id = 0,
     .name = "qca4019 hw1.0",
+        .led_pin = 58,
     .patch_load_addr = QCA4019_HW_1_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
@@ -2132,12 +2142,143 @@ static int ath10k_core_reset_rx_filter(struct 
ath10k *ar)

 return 0;
 }

+static int ath10k_gpio_pin_cfg_input(struct gpio_chip *chip, unsigned 
offset)

+{
+    struct ath10k_gpiocontrol *gpio = container_of(chip, struct 
ath10k_gpiocontrol, gchip);
+    ath10k_wmi_gpio_config(gpio->ar, offset, 1, WMI_GPIO_PULL_NONE, 
WMI_GPIO_INTTYPE_DISABLE); // configure to input

+    gpio->gpio_state_dir = 1;
+    return 0;
+}
+
+/* gpio_chip handler : set GPIO to output */
+static int ath10k_gpio_pin_cfg_output(struct gpio_chip *chip, unsigned 
offset,

+                 int value)
+{
+    struct ath10k_gpiocontrol *gpio = container_of(chip, struct 
ath10k_gpiocontrol, gchip);

+
+    ath10k_wmi_gpio_config(gpio->ar, offset, 0, WMI_GPIO_PULL_NONE, 
WMI_GPIO_INTTYPE_DISABLE); // configure to output

+    ath10k_wmi_gpio_output(gpio->ar, offset, value);
+    gpio->gpio_state_dir = 0;
+    gpio->gpio_state_pin = value;
+    return 0;
+}
+
+/* gpio_chip handler : query GPIO direction (0=out, 1=in) */
+static int ath10k_gpio_pin_get_dir(struct

[PATCH 1/1] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 and 
ipq4019 based chipsets with on chipset connected led's

using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and 
can be controlled with various triggers.

adds also debugfs interface for gpio control.

Signed-off-by: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

 drivers/net/wireless/ath/ath10k/core.c    | 168 
+-

 drivers/net/wireless/ath/ath10k/core.h    |  15 +++
 drivers/net/wireless/ath/ath10k/debug.c   | 140 +
 drivers/net/wireless/ath/ath10k/hw.h  |   1 +
 drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 ++-
 drivers/net/wireless/ath/ath10k/wmi.c |  43 
 drivers/net/wireless/ath/ath10k/wmi.h |  36 +++
 7 files changed, 436 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c

index f3ec13b80b20..b712bf09ad6f 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -21,6 +21,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+

 #include "core.h"
 #include "mac.h"
@@ -65,6 +68,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA988X_HW_2_0_VERSION,
     .dev_id = QCA988X_2_0_DEVICE_ID,
     .name = "qca988x hw2.0",
+        .led_pin = 1,
     .patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -94,6 +98,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA988X_HW_2_0_VERSION,
     .dev_id = QCA988X_2_0_DEVICE_ID_UBNT,
     .name = "qca988x hw2.0 ubiquiti",
+        .led_pin = 1,
     .patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -123,6 +128,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA9887_HW_1_0_VERSION,
     .dev_id = QCA9887_1_0_DEVICE_ID,
     .name = "qca9887 hw1.0",
+        .led_pin = 1,
     .patch_load_addr = QCA9887_HW_1_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -267,6 +273,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA99X0_HW_2_0_DEV_VERSION,
     .dev_id = QCA99X0_2_0_DEVICE_ID,
     .name = "qca99x0 hw2.0",
+        .led_pin = 17,
     .patch_load_addr = QCA99X0_HW_2_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .otp_exe_param = 0x0700,
@@ -301,6 +308,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA9984_HW_1_0_DEV_VERSION,
     .dev_id = QCA9984_1_0_DEVICE_ID,
     .name = "qca9984/qca9994 hw1.0",
+        .led_pin = 17,
     .patch_load_addr = QCA9984_HW_1_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
@@ -340,6 +348,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA9888_HW_2_0_DEV_VERSION,
     .dev_id = QCA9888_2_0_DEVICE_ID,
     .name = "qca9888 hw2.0",
+        .led_pin = 17,
     .patch_load_addr = QCA9888_HW_2_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
@@ -436,6 +445,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA4019_HW_1_0_DEV_VERSION,
     .dev_id = 0,
     .name = "qca4019 hw1.0",
+        .led_pin = 58,
     .patch_load_addr = QCA4019_HW_1_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
@@ -2132,12 +2142,143 @@ static int ath10k_core_reset_rx_filter(struct 
ath10k *ar)

 return 0;
 }

+static int ath10k_gpio_pin_cfg_input(struct gpio_chip *chip, unsigned 
offset)

+{
+    struct ath10k_gpiocontrol *gpio = container_of(chip, struct 
ath10k_gpiocontrol, gchip);
+    ath10k_wmi_gpio_config(gpio->ar, offset, 1, WMI_GPIO_PULL_NONE, 
WMI_GPIO_INTTYPE_DISABLE); // configure to input

+    gpio->gpio_state_dir = 1;
+    return 0;
+}
+
+/* gpio_chip handler : set GPIO to output */
+static int ath10k_gpio_pin_cfg_output(struct gpio_chip *chip, unsigned 
offset,

+                 int value)
+{
+    struct ath10k_gpiocontrol *gpio = container_of(chip, struct 
ath10k_gpiocontrol, gchip);

+
+    ath10k_wmi_gpio_config(gpio->ar, offset, 0, WMI_GPIO_PULL_NONE, 
WMI_GPIO_INTTYPE_DISABLE); // configure to output

+    ath10k_wmi_gpio_output(gpio->ar, offset, value);
+    gpio->gpio_state_dir = 0;
+    gpio->gpio_state_pin = value;
+    return 0;
+}
+
+/* gpio_chip handler : query GPIO direction (0=out, 1=in) */
+static int ath10k_gpio_pin_get_dir(struct

[PATCH 1/1] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 and 
ipq4019 based chipsets with on chipset connected led's

using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and 
can be controlled with various triggers.

adds also debugfs interface for gpio control.

Signed-off-by: Sebastian Gottschall <s.gottsch...@dd-wrt.com>

 drivers/net/wireless/ath/ath10k/core.c    | 168 
+-

 drivers/net/wireless/ath/ath10k/core.h    |  15 +++
 drivers/net/wireless/ath/ath10k/debug.c   | 140 +
 drivers/net/wireless/ath/ath10k/hw.h  |   1 +
 drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 ++-
 drivers/net/wireless/ath/ath10k/wmi.c |  43 
 drivers/net/wireless/ath/ath10k/wmi.h |  36 +++
 7 files changed, 436 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c

index f3ec13b80b20..b712bf09ad6f 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -21,6 +21,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+

 #include "core.h"
 #include "mac.h"
@@ -65,6 +68,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA988X_HW_2_0_VERSION,
     .dev_id = QCA988X_2_0_DEVICE_ID,
     .name = "qca988x hw2.0",
+        .led_pin = 1,
     .patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -94,6 +98,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA988X_HW_2_0_VERSION,
     .dev_id = QCA988X_2_0_DEVICE_ID_UBNT,
     .name = "qca988x hw2.0 ubiquiti",
+        .led_pin = 1,
     .patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -123,6 +128,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA9887_HW_1_0_VERSION,
     .dev_id = QCA9887_1_0_DEVICE_ID,
     .name = "qca9887 hw1.0",
+        .led_pin = 1,
     .patch_load_addr = QCA9887_HW_1_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -267,6 +273,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA99X0_HW_2_0_DEV_VERSION,
     .dev_id = QCA99X0_2_0_DEVICE_ID,
     .name = "qca99x0 hw2.0",
+        .led_pin = 17,
     .patch_load_addr = QCA99X0_HW_2_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .otp_exe_param = 0x0700,
@@ -301,6 +308,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA9984_HW_1_0_DEV_VERSION,
     .dev_id = QCA9984_1_0_DEVICE_ID,
     .name = "qca9984/qca9994 hw1.0",
+        .led_pin = 17,
     .patch_load_addr = QCA9984_HW_1_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
@@ -340,6 +348,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA9888_HW_2_0_DEV_VERSION,
     .dev_id = QCA9888_2_0_DEVICE_ID,
     .name = "qca9888 hw2.0",
+        .led_pin = 17,
     .patch_load_addr = QCA9888_HW_2_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
@@ -436,6 +445,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {

     .id = QCA4019_HW_1_0_DEV_VERSION,
     .dev_id = 0,
     .name = "qca4019 hw1.0",
+        .led_pin = 58,
     .patch_load_addr = QCA4019_HW_1_0_PATCH_LOAD_ADDR,
     .uart_pin = 7,
     .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
@@ -2132,12 +2142,143 @@ static int ath10k_core_reset_rx_filter(struct 
ath10k *ar)

 return 0;
 }

+static int ath10k_gpio_pin_cfg_input(struct gpio_chip *chip, unsigned 
offset)

+{
+    struct ath10k_gpiocontrol *gpio = container_of(chip, struct 
ath10k_gpiocontrol, gchip);
+    ath10k_wmi_gpio_config(gpio->ar, offset, 1, WMI_GPIO_PULL_NONE, 
WMI_GPIO_INTTYPE_DISABLE); // configure to input

+    gpio->gpio_state_dir = 1;
+    return 0;
+}
+
+/* gpio_chip handler : set GPIO to output */
+static int ath10k_gpio_pin_cfg_output(struct gpio_chip *chip, unsigned 
offset,

+                 int value)
+{
+    struct ath10k_gpiocontrol *gpio = container_of(chip, struct 
ath10k_gpiocontrol, gchip);

+
+    ath10k_wmi_gpio_config(gpio->ar, offset, 0, WMI_GPIO_PULL_NONE, 
WMI_GPIO_INTTYPE_DISABLE); // configure to output

+    ath10k_wmi_gpio_output(gpio->ar, offset, value);
+    gpio->gpio_state_dir = 0;
+    gpio->gpio_state_pin = value;
+    return 0;
+}
+
+/* gpio_chip handler : query GPIO direction (0=out, 1=in) */
+static int ath10k_gpio_pin_get_dir(stru

Re: WiFi Aware question

[Sebastian Gottschall]

Am 03.02.2018 um 17:21 schrieb dpr...@deepplum.com:

[I apologize for sending this with an old subject line and with another 
conversation attached. It was a dumb and distracting thing to do to these 
lists. My fault.]

I'm curious about the "WiFi Aware" initiative by the WiFi Alliance.

Does LEDE and/or Linux support this protocol? I know gSupplicant is potentially 
the way such things are supposed to work, at least according to its supporters.

The general NAN (Neighborhood-Aware-Networking) concept makes a lot of sense at 
one level, but as an Internet guy, it troubles me that they decided to split 
from the Internet and go a balkanized direction. To me, the neighborhood is 
interesting only as part of a larger Internet.

It also troubles me that WiFi Aware is a "certification program" rather than a 
real standard, and has serious problems with supporting Internet. But there will be 
devices that  require it.

if i read carefully about wifi-aware i just can say that i hope it will 
never be supported by any party. this is is no service. this is a spy 
application





--
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

Re: ath9k will not tx packets sometimes.

[Sebastian Gottschall]

Am 31.01.2018 um 14:46 schrieb Toke Høiland-Jørgensen:

Sebastian Gottschall <s.gottsch...@dd-wrt.com> writes:


Am 31.01.2018 um 12:50 schrieb Toke Høiland-Jørgensen:

Sebastian Gottschall <s.gottsch...@dd-wrt.com> writes:


Am 30.01.2018 um 19:55 schrieb Toke Høiland-Jørgensen:

Ben Greear <gree...@candelatech.com> writes:


I'm actually working on reworking that whole scheduler logic, and move
some of it into mac80211. Could you test this (WiP) patch and see if
that has the same problem?

It had some serious conflicts in ath10k, due to my local changes, so
I did not actually test this.

Can send you a version without the ath10k changes tomorrow if you'd like
to test - but will try to reproduce myself as well...


But, a revert of the atf patches (a6e56d749 and 63fefa050) appear to
have resolved the issue. I'll test more with these reverted, and maybe
will have time to work more on actually fixing upstream code next time
I move to a newer kernel (and/or after your pending changes get in).

Ah, that narrows it down some. Well, that is the code I'm hacking on
currently anyway, so let's see if we can't get it fixed as part of that
series :)

i have some addition information for you maybe. in the same timeframe i
noticed a increased memory usage for ath9k devices.
maybe that helps. so i hit memory boundaries on embedded devices with
dual interfaces and just 32 mb  ram now which wasnt the case before
is this patch worth to try from my side?

This is probably because of the added queue space. Which is sort of by
design. In 3ff23cd5654b9c8f4d567caa73439b4c39fbeaae we lowered the
default limit for non-VHT devices to 4MB. But if you have several PHYs
on a very memory constrained device you could still run out I guess.

`echo fq_memory_limit 2097152 > /sys/kernel/debug/ieee80211/phy0/aqm`
would limit it to 2MB for that phy...

what if i tried that already? :-)

Hmm, then it's maybe a bug? Changing the limit makes no difference at
all? Does your build include 0bfe649fbb133? What are values of the

maybe it makes a change but i run into oom after a while as well

counters in /sys/kernel/debug/ieee80211/phy0/aqm ?
i will check the current state in the next days. havent checked it over 
the last 2 months on the affected device




-Toke



--
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

Re: ath9k will not tx packets sometimes.

[Sebastian Gottschall]

Am 31.01.2018 um 12:50 schrieb Toke Høiland-Jørgensen:

Sebastian Gottschall <s.gottsch...@dd-wrt.com> writes:


Am 30.01.2018 um 19:55 schrieb Toke Høiland-Jørgensen:

Ben Greear <gree...@candelatech.com> writes:


I'm actually working on reworking that whole scheduler logic, and move
some of it into mac80211. Could you test this (WiP) patch and see if
that has the same problem?

It had some serious conflicts in ath10k, due to my local changes, so
I did not actually test this.

Can send you a version without the ath10k changes tomorrow if you'd like
to test - but will try to reproduce myself as well...


But, a revert of the atf patches (a6e56d749 and 63fefa050) appear to
have resolved the issue. I'll test more with these reverted, and maybe
will have time to work more on actually fixing upstream code next time
I move to a newer kernel (and/or after your pending changes get in).

Ah, that narrows it down some. Well, that is the code I'm hacking on
currently anyway, so let's see if we can't get it fixed as part of that
series :)

i have some addition information for you maybe. in the same timeframe i
noticed a increased memory usage for ath9k devices.
maybe that helps. so i hit memory boundaries on embedded devices with
dual interfaces and just 32 mb  ram now which wasnt the case before
is this patch worth to try from my side?

This is probably because of the added queue space. Which is sort of by
design. In 3ff23cd5654b9c8f4d567caa73439b4c39fbeaae we lowered the
default limit for non-VHT devices to 4MB. But if you have several PHYs
on a very memory constrained device you could still run out I guess.

`echo fq_memory_limit 2097152 > /sys/kernel/debug/ieee80211/phy0/aqm`
would limit it to 2MB for that phy...

what if i tried that already? :-)

Sebastian


-Toke



--
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

Re: ath9k will not tx packets sometimes.

[Sebastian Gottschall]

Am 30.01.2018 um 19:55 schrieb Toke Høiland-Jørgensen:

Ben Greear <gree...@candelatech.com> writes:


I'm actually working on reworking that whole scheduler logic, and move
some of it into mac80211. Could you test this (WiP) patch and see if
that has the same problem?

It had some serious conflicts in ath10k, due to my local changes, so
I did not actually test this.

Can send you a version without the ath10k changes tomorrow if you'd like
to test - but will try to reproduce myself as well...


But, a revert of the atf patches (a6e56d749 and 63fefa050) appear to
have resolved the issue. I'll test more with these reverted, and maybe
will have time to work more on actually fixing upstream code next time
I move to a newer kernel (and/or after your pending changes get in).

Ah, that narrows it down some. Well, that is the code I'm hacking on
currently anyway, so let's see if we can't get it fixed as part of that
series :)
i have some addition information for you maybe. in the same timeframe i 
noticed a increased memory usage for ath9k devices.
maybe that helps. so i hit memory boundaries on embedded devices with 
dual interfaces and just 32 mb  ram now which wasnt the case before

is this patch worth to try from my side?

Sebastian

--
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

Re: [PATCH] ath9k: Fix get channel default noise floor

[Sebastian Gottschall]

the regression has been solved with that patch. so noise floor looks 
normal for me on the 9280 chipset again


Am 26.01.2018 um 15:35 schrieb Kalle Valo:

Wojciech Dubowik <wojciech.dubo...@neratec.com> writes:


Commit 8da58553cc63 ("ath9k: Use calibrated noise floor value
when available") introduced regression in ath9k_hw_getchan_noise
where per chain nominal noise floor has been taken instead default
for channel.
Revert to original default channel noise floor.

Reported-by: Sebastian Gottschall <s.gottsch...@dd-wrt.com>
Signed-off-by: Wojciech Dubowik <wojciech.dubo...@neratec.com>

Fixes: 8da58553cc63 ("ath9k: Use calibrated noise floor value when available")

I can add that if this passes Sebastian's tests.

And I'm planning to queue this for 4.16.



--
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

Re: [PATCH] ath9k: Fix get channel default noise floor

[Sebastian Gottschall]

let me check

Am 26.01.2018 um 15:20 schrieb Wojciech Dubowik:

Commit 8da58553cc63 ("ath9k: Use calibrated noise floor value
when available") introduced regression in ath9k_hw_getchan_noise
where per chain nominal noise floor has been taken instead default
for channel.
Revert to original default channel noise floor.

Reported-by: Sebastian Gottschall <s.gottsch...@dd-wrt.com>
Signed-off-by: Wojciech Dubowik <wojciech.dubo...@neratec.com>
---
  drivers/net/wireless/ath/ath9k/calib.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/calib.c 
b/drivers/net/wireless/ath/ath9k/calib.c
index 3d9447e..695c779 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -72,7 +72,7 @@ static s16 ath9k_hw_get_default_nf(struct ath_hw *ah,
  s16 ath9k_hw_getchan_noise(struct ath_hw *ah, struct ath9k_channel *chan,
   s16 nf)
  {
-   s8 noise = ath9k_hw_get_default_nf(ah, chan, 0);
+   s8 noise = ATH_DEFAULT_NOISE_FLOOR;
  
  	if (nf) {

s8 delta = nf - ATH9K_NF_CAL_NOISE_THRESH -



--
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

Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support

[Sebastian Gottschall]

Am 26.01.2018 um 15:16 schrieb Wojciech Dubowik:



On 26/01/18 12:42, Sebastian Gottschall wrote:

i have a idea what one cause could ne

+    nfval =
+    ath9k_hw_get_nf_limits(ah, chan)->cal[i];
+    if (nfval > -60 || nfval < -127)
+    nfval = default_nf;

This is just a check to make sure we have sane calibrated values. 
Anything above -60 or under -127 will not work so

we take nominal value.
yes. but that means all < -127 and all > -60 catches it. this is the 
full value range. the check is wrong

everything is above -60 and bellow -127 at the same time. OR must ne AND



this code here will allways return the default_nf since all possible 
returned values are within that range
and the || is likelly wrong too and must be replaced with &&. but the 
range itself looks bogus. can't be right


so please do me a favor and test your code against 9280 chipsets too 
and check if its working. right now its a full regression incidence

and should be reverted



Am 26.01.2018 um 12:07 schrieb Wojciech Dubowik:
Are you sure you have applied path 4 in the series. You should see 
calibration piers. Sth like:


Calibration data
Chain 0
Freq     ref    volt    temp    nf_cal    nf_pow    rx_temp
2412    14    0    136    0    0    0
2437    13    0    136    0    0    0
2472    11    0    136    0    0    0
Chain 1
Freq     ref    volt    temp    nf_cal    nf_pow    rx_temp
2412    11    0    137    0    0    0
2437    11    0    139    0    0    0
2472    10    0    137    0    0    0
Chain 2
Freq     ref    volt    temp    nf_cal    nf_pow    rx_temp
2412    13    0    138    0    0    0
2437    14    0    139    0    0    0
2472    14    0    139    0    0    0

I have just done backports from ath.git and I can see these entries 
with my Compex card.


Wojtek


On 26/01/18 11:36, Sebastian Gottschall wrote:

Am 26.01.2018 um 11:27 schrieb Wojciech Dubowik:

I will try it with again with couple of OEM cards.
this is no card. the eeprom is stored in flash memory. so the chip 
is a 9280 pcie chip which is connected on board, but has no own 
flash memory for calibration data. this is stored in system flash 
memory


Is nanostation calibrated for noisefloor? You can see it with 
modal_eeprom in debugfs.

root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat modal_eeprom
   2GHz modal Header :
 Chain0 Ant. Control :  0
 Chain1 Ant. Control :  0
 Chain2 Ant. Control :  0
 Ant. Common Control :  0
    Chain0 Ant. Gain :  0
    Chain1 Ant. Gain :  0
    Chain2 Ant. Gain :  0
   Switch Settle : 45
    Chain0 TxRxAtten : 11
    Chain1 TxRxAtten : 11
    Chain2 TxRxAtten : 11
   Chain0 RxTxMargin : 11
   Chain1 RxTxMargin : 11
   Chain2 RxTxMargin : 11
    ADC Desired size :    224
    PGA Desired size :  0
    Chain0 xlna Gain : 14
    Chain1 xlna Gain : 14
    Chain2 xlna Gain : 14
   txEndToXpaOff :  0
 txEndToRxOn :  2
  txFrameToXpaOn : 14
  CCA Threshold) :  0
 Chain0 NF Threshold :    202
 Chain1 NF Threshold :    202
 Chain2 NF Threshold :    202
 xpdGain :  9
 External PD :  1
Chain0 I Coefficient :  0
Chain1 I Coefficient :  0
Chain2 I Coefficient :  0
Chain0 Q Coefficient :  0
Chain1 Q Coefficient :  0
Chain2 Q Coefficient :  0
   pdGainOverlap :  6
   Chain0 OutputBias :  2
   Chain0 DriverBias :  2
  xPA Bias Level :  0
 2chain pwr decrease :  0
 3chain pwr decrease :  0
  txFrameToDataStart : 14
   txFrameToPaOn : 14
 HT40 Power Inc. :  2
 Chain0 bswAtten : 21
 Chain1 bswAtten : 21
 Chain2 bswAtten :  0
    Chain0 bswMargin : 31
    Chain1 bswMargin : 31
    Chain2 bswMargin :  0
  HT40 Switch Settle : 44
    Chain0 xatten2Db :  0
    Chain1 xatten2Db :  0
    Chain2 xatten2Db :  0
Chain0 xatten2Margin :  0
Chain1 xatten2Margin :  0
Chain2 xatten2Margin :  0
   Chain1 OutputBias :  2
   Chain1 DriverBias :  2
 LNA Control : 13
  XPA Bias Freq0 :  0
  XPA Bias Freq1 :  0
  XPA Bias Freq2 :  0
   5GHz modal Header :
 Chain0 Ant. Control : 16
 Chain1 Ant. Control : 16
 Chain2 Ant. Control :  0
 Ant. Common Control :    288
    Chain0 Ant. Gain :  0
    Chain1 Ant. Gain :  0
    Chain2 Ant. Gain :  0
   Switch Settle : 45
    Chain0 TxRxAtten : 32
    Chain1 TxRxAtten : 32
    Chain2 TxRxAtten : 11
   Chain0 RxTxMargin :  0
   Chain1 RxTxMargin :  0
   Chain2 RxTxMarg

Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support

[Sebastian Gottschall]

i have a idea what one cause could ne

+   nfval =
+   ath9k_hw_get_nf_limits(ah, chan)->cal[i];
+   if (nfval > -60 || nfval < -127)
+   nfval = default_nf;

this code here will allways return the default_nf since all possible returned 
values are within that range
and the || is likelly wrong too and must be replaced with &&. but the range 
itself looks bogus. can't be right

so please do me a favor and test your code against 9280 chipsets too and check 
if its working. right now its a full regression incidence
and should be reverted



Am 26.01.2018 um 12:07 schrieb Wojciech Dubowik:
Are you sure you have applied path 4 in the series. You should see 
calibration piers. Sth like:


Calibration data
Chain 0
Freq     ref    volt    temp    nf_cal    nf_pow    rx_temp
2412    14    0    136    0    0    0
2437    13    0    136    0    0    0
2472    11    0    136    0    0    0
Chain 1
Freq     ref    volt    temp    nf_cal    nf_pow    rx_temp
2412    11    0    137    0    0    0
2437    11    0    139    0    0    0
2472    10    0    137    0    0    0
Chain 2
Freq     ref    volt    temp    nf_cal    nf_pow    rx_temp
2412    13    0    138    0    0    0
2437    14    0    139    0    0    0
2472    14    0    139    0    0    0

I have just done backports from ath.git and I can see these entries 
with my Compex card.


Wojtek


On 26/01/18 11:36, Sebastian Gottschall wrote:

Am 26.01.2018 um 11:27 schrieb Wojciech Dubowik:

I will try it with again with couple of OEM cards.
this is no card. the eeprom is stored in flash memory. so the chip is 
a 9280 pcie chip which is connected on board, but has no own flash 
memory for calibration data. this is stored in system flash memory


Is nanostation calibrated for noisefloor? You can see it with 
modal_eeprom in debugfs.

root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat modal_eeprom
   2GHz modal Header :
 Chain0 Ant. Control :  0
 Chain1 Ant. Control :  0
 Chain2 Ant. Control :  0
 Ant. Common Control :  0
    Chain0 Ant. Gain :  0
    Chain1 Ant. Gain :  0
    Chain2 Ant. Gain :  0
   Switch Settle : 45
    Chain0 TxRxAtten : 11
    Chain1 TxRxAtten : 11
    Chain2 TxRxAtten : 11
   Chain0 RxTxMargin : 11
   Chain1 RxTxMargin : 11
   Chain2 RxTxMargin : 11
    ADC Desired size :    224
    PGA Desired size :  0
    Chain0 xlna Gain : 14
    Chain1 xlna Gain : 14
    Chain2 xlna Gain : 14
   txEndToXpaOff :  0
 txEndToRxOn :  2
  txFrameToXpaOn : 14
  CCA Threshold) :  0
 Chain0 NF Threshold :    202
 Chain1 NF Threshold :    202
 Chain2 NF Threshold :    202
 xpdGain :  9
 External PD :  1
Chain0 I Coefficient :  0
Chain1 I Coefficient :  0
Chain2 I Coefficient :  0
Chain0 Q Coefficient :  0
Chain1 Q Coefficient :  0
Chain2 Q Coefficient :  0
   pdGainOverlap :  6
   Chain0 OutputBias :  2
   Chain0 DriverBias :  2
  xPA Bias Level :  0
 2chain pwr decrease :  0
 3chain pwr decrease :  0
  txFrameToDataStart : 14
   txFrameToPaOn : 14
 HT40 Power Inc. :  2
 Chain0 bswAtten : 21
 Chain1 bswAtten : 21
 Chain2 bswAtten :  0
    Chain0 bswMargin : 31
    Chain1 bswMargin : 31
    Chain2 bswMargin :  0
  HT40 Switch Settle : 44
    Chain0 xatten2Db :  0
    Chain1 xatten2Db :  0
    Chain2 xatten2Db :  0
Chain0 xatten2Margin :  0
Chain1 xatten2Margin :  0
Chain2 xatten2Margin :  0
   Chain1 OutputBias :  2
   Chain1 DriverBias :  2
 LNA Control : 13
  XPA Bias Freq0 :  0
  XPA Bias Freq1 :  0
  XPA Bias Freq2 :  0
   5GHz modal Header :
 Chain0 Ant. Control : 16
 Chain1 Ant. Control : 16
 Chain2 Ant. Control :  0
 Ant. Common Control :    288
    Chain0 Ant. Gain :  0
    Chain1 Ant. Gain :  0
    Chain2 Ant. Gain :  0
   Switch Settle : 45
    Chain0 TxRxAtten : 32
    Chain1 TxRxAtten : 32
    Chain2 TxRxAtten : 11
   Chain0 RxTxMargin :  0
   Chain1 RxTxMargin :  0
   Chain2 RxTxMargin : 16
    ADC Desired size :    226
    PGA Desired size :  0
    Chain0 xlna Gain : 13
    Chain1 xlna Gain : 13
    Chain2 xlna Gain : 13
   txEndToXpaOff :  0
 txEndToRxOn :  2
  txFrameToXpaOn : 14
  CCA Threshold) : 28
 Chain0 NF Threshold :    255
 Chain1 NF Thres

Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support

[Sebastian Gottschall]

Chain 1
Freq     ref    volt    temp    nf_cal    nf_pow    rx_temp
2412    11    0    137    0    0    0
2437    11    0    139    0    0    0
2472    10    0    137    0    0    0
Chain 2
Freq     ref    volt    temp    nf_cal    nf_pow    rx_temp
2412    13    0    138    0    0    0
2437    14    0    139    0    0    0
2472    14    0    139    0    0    0

I have just done backports from ath.git and I can see these entries 
with my Compex card.


Wojtek


On 26/01/18 11:36, Sebastian Gottschall wrote:

Am 26.01.2018 um 11:27 schrieb Wojciech Dubowik:

I will try it with again with couple of OEM cards.
this is no card. the eeprom is stored in flash memory. so the chip is 
a 9280 pcie chip which is connected on board, but has no own flash 
memory for calibration data. this is stored in system flash memory


Is nanostation calibrated for noisefloor? You can see it with 
modal_eeprom in debugfs.

root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat modal_eeprom
   2GHz modal Header :
 Chain0 Ant. Control :  0
 Chain1 Ant. Control :  0
 Chain2 Ant. Control :  0
 Ant. Common Control :  0
    Chain0 Ant. Gain :  0
    Chain1 Ant. Gain :  0
    Chain2 Ant. Gain :  0
   Switch Settle : 45
    Chain0 TxRxAtten : 11
    Chain1 TxRxAtten : 11
    Chain2 TxRxAtten : 11
   Chain0 RxTxMargin : 11
   Chain1 RxTxMargin : 11
   Chain2 RxTxMargin : 11
    ADC Desired size :    224
    PGA Desired size :  0
    Chain0 xlna Gain : 14
    Chain1 xlna Gain : 14
    Chain2 xlna Gain : 14
   txEndToXpaOff :  0
 txEndToRxOn :  2
  txFrameToXpaOn : 14
  CCA Threshold) :  0
 Chain0 NF Threshold :    202
 Chain1 NF Threshold :    202
 Chain2 NF Threshold :    202
 xpdGain :  9
 External PD :  1
Chain0 I Coefficient :  0
Chain1 I Coefficient :  0
Chain2 I Coefficient :  0
Chain0 Q Coefficient :  0
Chain1 Q Coefficient :  0
Chain2 Q Coefficient :  0
   pdGainOverlap :  6
   Chain0 OutputBias :  2
   Chain0 DriverBias :  2
  xPA Bias Level :  0
 2chain pwr decrease :  0
 3chain pwr decrease :  0
  txFrameToDataStart : 14
   txFrameToPaOn : 14
 HT40 Power Inc. :  2
 Chain0 bswAtten : 21
 Chain1 bswAtten : 21
 Chain2 bswAtten :  0
    Chain0 bswMargin : 31
    Chain1 bswMargin : 31
    Chain2 bswMargin :  0
  HT40 Switch Settle : 44
    Chain0 xatten2Db :  0
    Chain1 xatten2Db :  0
    Chain2 xatten2Db :  0
Chain0 xatten2Margin :  0
Chain1 xatten2Margin :  0
Chain2 xatten2Margin :  0
   Chain1 OutputBias :  2
   Chain1 DriverBias :  2
 LNA Control : 13
  XPA Bias Freq0 :  0
  XPA Bias Freq1 :  0
  XPA Bias Freq2 :  0
   5GHz modal Header :
 Chain0 Ant. Control : 16
 Chain1 Ant. Control : 16
 Chain2 Ant. Control :  0
 Ant. Common Control :    288
    Chain0 Ant. Gain :  0
    Chain1 Ant. Gain :  0
    Chain2 Ant. Gain :  0
   Switch Settle : 45
    Chain0 TxRxAtten : 32
    Chain1 TxRxAtten : 32
    Chain2 TxRxAtten : 11
   Chain0 RxTxMargin :  0
   Chain1 RxTxMargin :  0
   Chain2 RxTxMargin : 16
    ADC Desired size :    226
    PGA Desired size :  0
    Chain0 xlna Gain : 13
    Chain1 xlna Gain : 13
    Chain2 xlna Gain : 13
   txEndToXpaOff :  0
 txEndToRxOn :  2
  txFrameToXpaOn : 14
  CCA Threshold) : 28
 Chain0 NF Threshold :    255
 Chain1 NF Threshold :    255
 Chain2 NF Threshold :    255
 xpdGain :  1
 External PD :  1
Chain0 I Coefficient :  0
Chain1 I Coefficient :  0
Chain2 I Coefficient :  0
Chain0 Q Coefficient :  0
Chain1 Q Coefficient :  0
Chain2 Q Coefficient :  0
   pdGainOverlap :  6
   Chain0 OutputBias :  3
   Chain0 DriverBias :  3
  xPA Bias Level :  2
 2chain pwr decrease :  0
 3chain pwr decrease :  0
  txFrameToDataStart : 14
   txFrameToPaOn : 14
 HT40 Power Inc. :  0
 Chain0 bswAtten : 34
 Chain1 bswAtten : 34
 Chain2 bswAtten :  0
    Chain0 bswMargin : 22
    Chain1 bswMargin : 22
    Chain2 bswMargin :  0
  HT40 Switch Settle : 45
    Chain0 xatten2Db :  0
    Chain1 xatten2Db :  0
    Chain2 xatten2Db :  0
Chain0 xatten2Margin :  0
Chain1 xatten2Margin

Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support

[Sebastian Gottschall]

Am 26.01.2018 um 12:07 schrieb Wojciech Dubowik:
Are you sure you have applied path 4 in the series. You should see 
calibration piers. Sth like:

yes. all of them

root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat dump_nfcal
Channel Noise Floor : -112
Chain | privNF | # Readings | NF Readings
 0   -107    5   -107 -107 -107 -108 -108
 1   -106    5   -106 -106 -106 -106 -106

but looks different from yours, but chipset is 9280 as i said.

let me just revert your 4 patches to see if it changes the behaviour


Calibration data
Chain 0
Freq     ref    volt    temp    nf_cal    nf_pow    rx_temp
2412    14    0    136    0    0    0
2437    13    0    136    0    0    0
2472    11    0    136    0    0    0
Chain 1
Freq     ref    volt    temp    nf_cal    nf_pow    rx_temp
2412    11    0    137    0    0    0
2437    11    0    139    0    0    0
2472    10    0    137    0    0    0
Chain 2
Freq     ref    volt    temp    nf_cal    nf_pow    rx_temp
2412    13    0    138    0    0    0
2437    14    0    139    0    0    0
2472    14    0    139    0    0    0

I have just done backports from ath.git and I can see these entries 
with my Compex card.


Wojtek


On 26/01/18 11:36, Sebastian Gottschall wrote:

Am 26.01.2018 um 11:27 schrieb Wojciech Dubowik:

I will try it with again with couple of OEM cards.
this is no card. the eeprom is stored in flash memory. so the chip is 
a 9280 pcie chip which is connected on board, but has no own flash 
memory for calibration data. this is stored in system flash memory


Is nanostation calibrated for noisefloor? You can see it with 
modal_eeprom in debugfs.

root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat modal_eeprom
   2GHz modal Header :
 Chain0 Ant. Control :  0
 Chain1 Ant. Control :  0
 Chain2 Ant. Control :  0
 Ant. Common Control :  0
    Chain0 Ant. Gain :  0
    Chain1 Ant. Gain :  0
    Chain2 Ant. Gain :  0
   Switch Settle : 45
    Chain0 TxRxAtten : 11
    Chain1 TxRxAtten : 11
    Chain2 TxRxAtten : 11
   Chain0 RxTxMargin : 11
   Chain1 RxTxMargin : 11
   Chain2 RxTxMargin : 11
    ADC Desired size :    224
    PGA Desired size :  0
    Chain0 xlna Gain : 14
    Chain1 xlna Gain : 14
    Chain2 xlna Gain : 14
   txEndToXpaOff :  0
 txEndToRxOn :  2
  txFrameToXpaOn : 14
  CCA Threshold) :  0
 Chain0 NF Threshold :    202
 Chain1 NF Threshold :    202
 Chain2 NF Threshold :    202
 xpdGain :  9
 External PD :  1
Chain0 I Coefficient :  0
Chain1 I Coefficient :  0
Chain2 I Coefficient :  0
Chain0 Q Coefficient :  0
Chain1 Q Coefficient :  0
Chain2 Q Coefficient :  0
   pdGainOverlap :  6
   Chain0 OutputBias :  2
   Chain0 DriverBias :  2
  xPA Bias Level :  0
 2chain pwr decrease :  0
 3chain pwr decrease :  0
  txFrameToDataStart : 14
   txFrameToPaOn : 14
 HT40 Power Inc. :  2
 Chain0 bswAtten : 21
 Chain1 bswAtten : 21
 Chain2 bswAtten :  0
    Chain0 bswMargin : 31
    Chain1 bswMargin : 31
    Chain2 bswMargin :  0
  HT40 Switch Settle : 44
    Chain0 xatten2Db :  0
    Chain1 xatten2Db :  0
    Chain2 xatten2Db :  0
Chain0 xatten2Margin :  0
Chain1 xatten2Margin :  0
Chain2 xatten2Margin :  0
   Chain1 OutputBias :  2
   Chain1 DriverBias :  2
 LNA Control : 13
  XPA Bias Freq0 :  0
  XPA Bias Freq1 :  0
  XPA Bias Freq2 :  0
   5GHz modal Header :
 Chain0 Ant. Control : 16
 Chain1 Ant. Control : 16
 Chain2 Ant. Control :  0
 Ant. Common Control :    288
    Chain0 Ant. Gain :  0
    Chain1 Ant. Gain :  0
    Chain2 Ant. Gain :  0
   Switch Settle : 45
    Chain0 TxRxAtten : 32
    Chain1 TxRxAtten : 32
    Chain2 TxRxAtten : 11
   Chain0 RxTxMargin :  0
   Chain1 RxTxMargin :  0
   Chain2 RxTxMargin : 16
    ADC Desired size :    226
    PGA Desired size :  0
    Chain0 xlna Gain : 13
    Chain1 xlna Gain : 13
    Chain2 xlna Gain : 13
   txEndToXpaOff :  0
 txEndToRxOn :  2
  txFrameToXpaOn : 14
  CCA Threshold) : 28
 Chain0 NF Threshold :    255
 Chain1 NF Threshold :    255
 Chain2 NF Threshold :    255
 xpdGain :  1
 External PD :  1
Chain0 I Coefficient :  0
Chain1 I Coefficient :  0
Chain2 I Coefficient :  0
Chain0 Q Coefficient :  0
Chain1 Q Coefficient

Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support

[Sebastian Gottschall]

Am 26.01.2018 um 11:27 schrieb Wojciech Dubowik:

I will try it with again with couple of OEM cards.
this is no card. the eeprom is stored in flash memory. so the chip is a 
9280 pcie chip which is connected on board, but has no own flash memory 
for calibration data. this is stored in system flash memory


Is nanostation calibrated for noisefloor? You can see it with 
modal_eeprom in debugfs.

root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat modal_eeprom
   2GHz modal Header :
 Chain0 Ant. Control :  0
 Chain1 Ant. Control :  0
 Chain2 Ant. Control :  0
 Ant. Common Control :  0
    Chain0 Ant. Gain :  0
    Chain1 Ant. Gain :  0
    Chain2 Ant. Gain :  0
   Switch Settle : 45
    Chain0 TxRxAtten : 11
    Chain1 TxRxAtten : 11
    Chain2 TxRxAtten : 11
   Chain0 RxTxMargin : 11
   Chain1 RxTxMargin : 11
   Chain2 RxTxMargin : 11
    ADC Desired size :    224
    PGA Desired size :  0
    Chain0 xlna Gain : 14
    Chain1 xlna Gain : 14
    Chain2 xlna Gain : 14
   txEndToXpaOff :  0
 txEndToRxOn :  2
  txFrameToXpaOn : 14
  CCA Threshold) :  0
 Chain0 NF Threshold :    202
 Chain1 NF Threshold :    202
 Chain2 NF Threshold :    202
 xpdGain :  9
 External PD :  1
Chain0 I Coefficient :  0
Chain1 I Coefficient :  0
Chain2 I Coefficient :  0
Chain0 Q Coefficient :  0
Chain1 Q Coefficient :  0
Chain2 Q Coefficient :  0
   pdGainOverlap :  6
   Chain0 OutputBias :  2
   Chain0 DriverBias :  2
  xPA Bias Level :  0
 2chain pwr decrease :  0
 3chain pwr decrease :  0
  txFrameToDataStart : 14
   txFrameToPaOn : 14
 HT40 Power Inc. :  2
 Chain0 bswAtten : 21
 Chain1 bswAtten : 21
 Chain2 bswAtten :  0
    Chain0 bswMargin : 31
    Chain1 bswMargin : 31
    Chain2 bswMargin :  0
  HT40 Switch Settle : 44
    Chain0 xatten2Db :  0
    Chain1 xatten2Db :  0
    Chain2 xatten2Db :  0
Chain0 xatten2Margin :  0
Chain1 xatten2Margin :  0
Chain2 xatten2Margin :  0
   Chain1 OutputBias :  2
   Chain1 DriverBias :  2
 LNA Control : 13
  XPA Bias Freq0 :  0
  XPA Bias Freq1 :  0
  XPA Bias Freq2 :  0
   5GHz modal Header :
 Chain0 Ant. Control : 16
 Chain1 Ant. Control : 16
 Chain2 Ant. Control :  0
 Ant. Common Control :    288
    Chain0 Ant. Gain :  0
    Chain1 Ant. Gain :  0
    Chain2 Ant. Gain :  0
   Switch Settle : 45
    Chain0 TxRxAtten : 32
    Chain1 TxRxAtten : 32
    Chain2 TxRxAtten : 11
   Chain0 RxTxMargin :  0
   Chain1 RxTxMargin :  0
   Chain2 RxTxMargin : 16
    ADC Desired size :    226
    PGA Desired size :  0
    Chain0 xlna Gain : 13
    Chain1 xlna Gain : 13
    Chain2 xlna Gain : 13
   txEndToXpaOff :  0
 txEndToRxOn :  2
  txFrameToXpaOn : 14
  CCA Threshold) : 28
 Chain0 NF Threshold :    255
 Chain1 NF Threshold :    255
 Chain2 NF Threshold :    255
 xpdGain :  1
 External PD :  1
Chain0 I Coefficient :  0
Chain1 I Coefficient :  0
Chain2 I Coefficient :  0
Chain0 Q Coefficient :  0
Chain1 Q Coefficient :  0
Chain2 Q Coefficient :  0
   pdGainOverlap :  6
   Chain0 OutputBias :  3
   Chain0 DriverBias :  3
  xPA Bias Level :  2
 2chain pwr decrease :  0
 3chain pwr decrease :  0
  txFrameToDataStart : 14
   txFrameToPaOn : 14
 HT40 Power Inc. :  0
 Chain0 bswAtten : 34
 Chain1 bswAtten : 34
 Chain2 bswAtten :  0
    Chain0 bswMargin : 22
    Chain1 bswMargin : 22
    Chain2 bswMargin :  0
  HT40 Switch Settle : 45
    Chain0 xatten2Db :  0
    Chain1 xatten2Db :  0
    Chain2 xatten2Db :  0
Chain0 xatten2Margin :  0
Chain1 xatten2Margin :  0
Chain2 xatten2Margin :  0
   Chain1 OutputBias :  3
   Chain1 DriverBias :  3
 LNA Control : 13
  XPA Bias Freq0 :  0
  XPA Bias Freq1 :  0
  XPA Bias Freq2 :  0



Wojtek
On 26/01/18 10:59, Sebastian Gottschall wrote:
i dont know if this is a coincidence. but after testing your patch on 
a standard ubiquiti nanostation m2 the noise floor looks wrong.
it will stay on -112 which is clearly impossible in 2.4 (before it 
was around

Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support

[Sebastian Gottschall]

i dont know if this is a coincidence. but after testing your patch on a 
standard ubiquiti nanostation m2 the noise floor looks wrong.
it will stay on -112 which is clearly impossible in 2.4 (before it was 
around -96)


Sebastian

Am 23.01.2018 um 08:56 schrieb Kalle Valo:

Wojciech Dubowik <wojciech.dubo...@neratec.com> writes:


AR9003 series allows to calibrate noise floor for different frequency
bins. Once it's done it's possible to get more accurate rssi/signal
values over whole frequency band at a given temperature.
The RSSI/signal accuracy reported by calibrated RF cards improves
from 6 to up to 2dB.

This could be interesting for application which require good signal
accuracy like roaming or mesh protocols.

This is a very good description of the feature. I think you should copy
it to the patch 3 commit log so that it gets archived to git. (I don't
store cover letters to git.)



--
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

Re: [PATCH 3/4] ath10k: WMI: get wmi init parameter values from hw params

[Sebastian Gottschall]

cipher_suites = 11,
+   .num_peers = TARGET_TLV_NUM_PEERS,
+   .ast_skid_limit = 0x10,
+   .num_wds_entries = 0x20,
},
  };
  
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h

index 05f26e5..fedb6c7 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -553,6 +553,10 @@ struct ath10k_hw_params {
  
  	/* Number of ciphers supported (i.e First N) in cipher_suites array */

int n_cipher_suites;
+
+   u32 num_peers;
+   u32 ast_skid_limit;
+   u32 num_wds_entries;
  };
  
  struct htt_rx_desc;

diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c 
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 452846c..0183d01 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -1440,7 +1440,10 @@ static struct sk_buff *ath10k_wmi_tlv_op_gen_init(struct 
ath10k *ar)
cmd->num_host_mem_chunks = __cpu_to_le32(ar->wmi.num_mem_chunks);
  
  	cfg->num_vdevs = __cpu_to_le32(TARGET_TLV_NUM_VDEVS);

-   cfg->num_peers = __cpu_to_le32(TARGET_TLV_NUM_PEERS);
+
+   cfg->num_peers = ar->hw_params.num_peers;
+   cfg->ast_skid_limit = ar->hw_params.ast_skid_limit;
+   cfg->num_wds_entries = ar->hw_params.num_wds_entries;
  
  	if (test_bit(WMI_SERVICE_RX_FULL_REORDER, ar->wmi.svc_map)) {

cfg->num_offload_peers = __cpu_to_le32(TARGET_TLV_NUM_VDEVS);
@@ -1452,7 +1455,6 @@ static struct sk_buff *ath10k_wmi_tlv_op_gen_init(struct 
ath10k *ar)
  
  	cfg->num_peer_keys = __cpu_to_le32(2);

cfg->num_tids = __cpu_to_le32(TARGET_TLV_NUM_TIDS);
-   cfg->ast_skid_limit = __cpu_to_le32(0x10);
cfg->tx_chain_mask = __cpu_to_le32(0x7);
cfg->rx_chain_mask = __cpu_to_le32(0x7);
cfg->rx_timeout_pri[0] = __cpu_to_le32(0x64);
@@ -1468,7 +1470,6 @@ static struct sk_buff *ath10k_wmi_tlv_op_gen_init(struct 
ath10k *ar)
cfg->num_mcast_table_elems = __cpu_to_le32(0);
cfg->mcast2ucast_mode = __cpu_to_le32(0);
cfg->tx_dbg_log_size = __cpu_to_le32(0x400);
-   cfg->num_wds_entries = __cpu_to_le32(0x20);
cfg->dma_burst_size = __cpu_to_le32(0);
cfg->mac_aggr_delim = __cpu_to_le32(0);
cfg->rx_skip_defrag_timeout_dup_detection_check = __cpu_to_le32(0);



--
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

Re: [PATCH] ath10k: handling qos at STA side based on AP WMM enable/disable

[Sebastian Gottschall]

Am 29.11.2017 um 11:12 schrieb Balaji Pothunoori:

Hi Sebastian,

If I am not wrong you are seeing the issue with WRT3200ACM (Marvell 88W8964) as 
client + QCA9984 (FW : 10.4-3.5.3-00038) as AP with below change you are seeing 
the crash while running traffic between the WRT3200ACM + QCA9984 ?
Do you used  any other client in place of WRT3200ACM ?

there is not much  traffic required. as it seems the firmware crashes 
immediatly after association. the issue is also not present in 10.4-3.4-0082ww

Still my question is not cleared,  firmware crash is due to this patch ? Also 
let me know do you observed same behavior with any other chipset ?


no. its unrelated to this patch but since you're working for qca i 
thought it would make sense to tell you this since saw that you're using 
ath10k firmwares which arent published officiall but based on the


qca firmwares which are published on chipcode. since i was testing  
these firmwares too some weeks ago i found its a good idea to tell you this




  
Regards,

Balaji.


Sebastian



Regards,
Balaji.

-Original Message-
From: Sebastian Gottschall [mailto:s.gottsch...@dd-wrt.com]
Sent: Wednesday, November 29, 2017 2:04 PM
To: Balaji Pothunoori <bpoth...@qti.qualcomm.com>; ath...@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] ath10k: handling qos at STA side based on AP WMM 
enable/disable

Am 29.11.2017 um 07:58 schrieb Balaji Pothunoori:

Hi Sebastian,

If I am not wrong you are seeing the issue with WRT3200ACM (Marvell 88W8964) as 
client + QCA9984 (FW : 10.4-3.5.3-00038) as AP with below change you are seeing 
the crash while running traffic between the WRT3200ACM + QCA9984 ?
Do you used  any other client in place of WRT3200ACM ?

there is not much  traffic required. as it seems the firmware crashes 
immediatly after association. the issue is also not present in 10.4-3.4-0082ww


Can you share the more details on firmware crash ?

so a firmware crashdump from log? i'll try to get it within the next hours. 
just need to resetup the test scenario


Sebastian



Regards,
Balaji.

-Original Message-
From: Sebastian Gottschall [mailto:s.gottsch...@dd-wrt.com]
Sent: Wednesday, November 29, 2017 8:28 AM
To: Balaji Pothunoori <bpoth...@qti.qualcomm.com>; ath...@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] ath10k: handling qos at STA side based on AP WMM 
enable/disable

did you notice  that Marvell 88W8964 based clients will crash 10.4-3.5.3 
firmwares?  (tested with 9984 and 10.4-3.5.3-00038) client device was a linksys 
wrt3200acm running dd-wrt for testing

Am 28.11.2017 um 11:07 schrieb bpoth...@qti.qualcomm.com:

From: Balaji Pothunoori <bpoth...@qti.qualcomm.com>

Data packets are not sent by STA in case of STA joined to non QOS AP
(WMM disabled AP). This is happening because of STA is sending data
packets to firmware from host with qos enabled along with non qos
queue value(TID = 16).
Due to qos enabled, firmware is discarding the packet.

This patch fixes this issue by updating the qos based on station WME
capability field if WMM is disabled in AP.

This patch is required by 10.4 family chipsets like
QCA4019/QCA9888/QCA9884/QCA99X0.
Firmware Versoin : 10.4-3.5.1-00018.

For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch has
no effect.

Signed-off-by: Balaji Pothunoori <bpoth...@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/mac.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 0a947ee..2616b99 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2563,7 +2563,7 @@ static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
}
break;
case WMI_VDEV_TYPE_STA:
-   if (vif->bss_conf.qos)
+   if (sta->wme)
arg->peer_flags |= arvif->ar->wmi.peer_flags->qos;
break;
case WMI_VDEV_TYPE_IBSS:

--
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



--
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

Re: [PATCH] ath10k: handling qos at STA side based on AP WMM enable/disable

[Sebastian Gottschall]

Am 29.11.2017 um 07:58 schrieb Balaji Pothunoori:

Hi Sebastian,

If I am not wrong you are seeing the issue with WRT3200ACM (Marvell 88W8964) as 
client + QCA9984 (FW : 10.4-3.5.3-00038) as AP with below change you are seeing 
the crash while running traffic between the WRT3200ACM + QCA9984 ?
Do you used  any other client in place of WRT3200ACM ?


there is not much  traffic required. as it seems the firmware crashes 
immediatly after association. the issue is also not present in 
10.4-3.4-0082ww



Can you share the more details on firmware crash ?


so a firmware crashdump from log? i'll try to get it within the next 
hours. just need to resetup the test scenario



Sebastian




Regards,
Balaji.

-Original Message-
From: Sebastian Gottschall [mailto:s.gottsch...@dd-wrt.com]
Sent: Wednesday, November 29, 2017 8:28 AM
To: Balaji Pothunoori <bpoth...@qti.qualcomm.com>; ath...@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] ath10k: handling qos at STA side based on AP WMM 
enable/disable

did you notice  that Marvell 88W8964 based clients will crash 10.4-3.5.3 
firmwares?  (tested with 9984 and 10.4-3.5.3-00038) client device was a linksys 
wrt3200acm running dd-wrt for testing

Am 28.11.2017 um 11:07 schrieb bpoth...@qti.qualcomm.com:

From: Balaji Pothunoori <bpoth...@qti.qualcomm.com>

Data packets are not sent by STA in case of STA joined to non QOS AP
(WMM disabled AP). This is happening because of STA is sending data
packets to firmware from host with qos enabled along with non qos
queue value(TID = 16).
Due to qos enabled, firmware is discarding the packet.

This patch fixes this issue by updating the qos based on station WME
capability field if WMM is disabled in AP.

This patch is required by 10.4 family chipsets like
QCA4019/QCA9888/QCA9884/QCA99X0.
Firmware Versoin : 10.4-3.5.1-00018.

For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch has
no effect.

Signed-off-by: Balaji Pothunoori <bpoth...@qti.qualcomm.com>
---
   drivers/net/wireless/ath/ath10k/mac.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 0a947ee..2616b99 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2563,7 +2563,7 @@ static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
}
break;
case WMI_VDEV_TYPE_STA:
-   if (vif->bss_conf.qos)
+   if (sta->wme)
arg->peer_flags |= arvif->ar->wmi.peer_flags->qos;
break;
case WMI_VDEV_TYPE_IBSS:


--
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



--
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

Re: [PATCH] ath10k: handling qos at STA side based on AP WMM enable/disable

[Sebastian Gottschall]

did you notice  that Marvell 88W8964 based clients will crash 10.4-3.5.3 
firmwares?  (tested with 9984 and 10.4-3.5.3-00038)

client device was a linksys wrt3200acm running dd-wrt for testing

Am 28.11.2017 um 11:07 schrieb bpoth...@qti.qualcomm.com:

From: Balaji Pothunoori <bpoth...@qti.qualcomm.com>

Data packets are not sent by STA in case of STA joined to
non QOS AP (WMM disabled AP). This is happening because of STA
is sending data packets to firmware from host with qos enabled
along with non qos queue value(TID = 16).
Due to qos enabled, firmware is discarding the packet.

This patch fixes this issue by updating the qos based on station
WME capability field if WMM is disabled in AP.

This patch is required by 10.4 family chipsets like
QCA4019/QCA9888/QCA9884/QCA99X0.
Firmware Versoin : 10.4-3.5.1-00018.

For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch
has no effect.

Signed-off-by: Balaji Pothunoori <bpoth...@qti.qualcomm.com>
---
  drivers/net/wireless/ath/ath10k/mac.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 0a947ee..2616b99 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2563,7 +2563,7 @@ static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
}
break;
case WMI_VDEV_TYPE_STA:
-   if (vif->bss_conf.qos)
+   if (sta->wme)
arg->peer_flags |= arvif->ar->wmi.peer_flags->qos;
break;
case WMI_VDEV_TYPE_IBSS:



--
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

Re: [PATCHv3 1/2] ath10k: add per peer htt tx stats support for 10.4

[Sebastian Gottschall]

maybe this one?

i have this qca988x supporting tx/rx rate patch in my local tree. just 
need to extract it again


 ath10k: report per-station tx/rate rates to mac80211

Am 21.11.2017 um 09:40 schrieb Kalle Valo:

Sven Eckelmann <sven.eckelm...@openmesh.com> writes:


On Dienstag, 21. November 2017 09:00:54 CET Sebastian Gottschall wrote:
[...]

Why is the support for 10.2.4 firmware not upstreamed? I mean the one which is
using pktlog to transfer the PEER_STATS information.

I'm not sure what you are asking. If you are asking the firmware release
mentioned in the commit log that's in ath10k-firmware:

https://github.com/kvalo/ath10k-firmware/tree/master/QCA4019/hw1.0/3.2.1

But I'm sure you know that already.

i believe he is just talking about a patch which allows to get station
statistics like rx and tx rate on the firmare 10.2 series which is
qca988x mainly

this patch was posted here months ago but never got upstream

Yes, I was talking about that patch (which I didn't find on the
mailing list - so a link would be helpful). QCA is gathering a lot of
patches (a00-*) at
https://source.codeaurora.org/quic/qsdk/oss/system/feeds/wlan-open/tree/mac80211/patches?h=coconut
which are often not upstreamed.

Oh, that. I have always told the team working on that repository that
they should upstream everything but obviously they don't :/


The patch
a00-0075-ath10k-Add-support-to-parse-per-station-tx-stats-for.patch is
the one which is receiving the TX statistics stuff from 10.2.

I tried to find that patch from the ath10k list archives but didn't find
it. I only did a quick search so of course it might be submitted still,
so if anyone finds a link please let me know.



--
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

Re: [PATCHv3 1/2] ath10k: add per peer htt tx stats support for 10.4

[Sebastian Gottschall]

Am 21.11.2017 um 08:58 schrieb Kalle Valo:

Sven Eckelmann <sven.eckelm...@openmesh.com> writes:


On Dienstag, 15. November 2016 22:07:29 CET ako...@qti.qualcomm.com wrote:

From: Anilkumar Kolli <ako...@qti.qualcomm.com>

Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
event, Firmware sends one HTT event for every four PPDUs.
HTT payload has success pkts/bytes, failed pkts/bytes, retry
pkts/bytes and rate info per ppdu.
Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
which are nowadays enabled by default.

Parse peer stats and update the tx rate information per STA.

tx rate, Peer stats are tested on QCA4019 with Firmware version
10.4-3.2.1-00028.

Signed-off-by: Anilkumar Kolli <ako...@qti.qualcomm.com>

Why is the support for 10.2.4 firmware not upstreamed? I mean the one which is
using pktlog to transfer the PEER_STATS information.

I'm not sure what you are asking. If you are asking the firmware release
mentioned in the commit log that's in ath10k-firmware:

https://github.com/kvalo/ath10k-firmware/tree/master/QCA4019/hw1.0/3.2.1

But I'm sure you know that already.


i believe he is just talking about a patch which allows to get station 
statistics like rx and tx rate on the firmare 10.2 series which is 
qca988x mainly


this patch was posted here months ago but never got upstream





--
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

Re: [PATCH] ath10k: Fix invalid STS_CAP_OFFSET_MASK.

[Sebastian Gottschall]

Am 14.11.2017 um 18:16 schrieb gree...@candelatech.com:

From: Ben Greear <gree...@candelatech.com>

The 10.4 firmware defines this as a 3-bit field, as does the
mac80211 stack.  The 4th bit is defined as CONF_IMPLICIT_BF
at least in the firmware header I have seen.  This patch
fixes the ath10k wmi header to match the firmware.

Signed-off-by: Ben Greear <gree...@candelatech.com>
---
  drivers/net/wireless/ath/ath10k/wmi.h | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index ff15c37..9522f22 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -5195,7 +5195,8 @@ enum wmi_10_4_vdev_param {
  #define WMI_VDEV_PARAM_TXBF_MU_TX_BFER BIT(3)
  
  #define WMI_TXBF_STS_CAP_OFFSET_LSB	4

-#define WMI_TXBF_STS_CAP_OFFSET_MASK   0xf0
+#define WMI_TXBF_STS_CAP_OFFSET_MASK   0x70
+#define WMI_TXBF_CONF_IMPLICIT_BF   BIT(7)
  #define WMI_BF_SOUND_DIM_OFFSET_LSB   8
  #define WMI_BF_SOUND_DIM_OFFSET_MASK  0xf00

i can validate this. good finding
  



--
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

Re: ath10k: Fix reported HT MCS rates with NSS > 1

[Sebastian Gottschall]

Am 06.11.2017 um 09:23 schrieb Sven Eckelmann:

On Sonntag, 5. November 2017 10:22:22 CET Sebastian Gottschall wrote:

the assumption made in this patch is obviously wrong (at least for more
recent firmwares and 9984)
my log is flooded with messages like
[208802.803537] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[208805.108515] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[208821.747621] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[208822.516599] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[208841.257780] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats


i tested this with the 10.4.3.5-0038 firmware which isnt official
published but made from athwlan.bin i got from qca chipcode

Hm, yes there is most likely something wrong. But not sure whether this patch
is actually the culprit. It looks to me like this would also be reported the
same way without the patch. cec17c382140 ("ath10k: add per peer htt tx stats
support for 10.4") seems to be your problem, right?

This patch only splits WMI_RATE_PREAMBLE_HT & WMI_RATE_PREAMBLE_VHT. And for
WMI_RATE_PREAMBLE_HT (*not VHT*), it uses a slightly different approach. But
the WMI_RATE_PREAMBLE_VHT part (which you see in your logs) is basically
untouched.


then a question follows up. is this check really neccessary?


Sebastian




Kind regards,
Sven



--
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

Re: ath10k: Fix reported HT MCS rates with NSS > 1

[Sebastian Gottschall]

the assumption made in this patch is obviously wrong (at least for more 
recent firmwares and 9984)

my log is flooded with messages like
[208802.803537] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[208805.108515] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[208821.747621] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[208822.516599] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[208841.257780] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats


i tested this with the 10.4.3.5-0038 firmware which isnt official 
published but made from athwlan.bin i got from qca chipcode


Am 23.05.2017 um 17:28 schrieb Kalle Valo:

Sven Eckelmann <sven.eckelm...@openmesh.com> wrote:

The QCA4019 firmware 10.4-3.2.1-00050 reports only HT MCS rates between
0-9. But 802.11n MCS rates can be larger than that. For example a 2x2
device can send with up to MCS 15.

The firmware encodes the higher MCS rates using the NSS field. The actual
calculation is not documented by QCA but it seems like the NSS field can be
mapped for HT rates to following MCS offsets:

  * NSS 1: 0
  * NSS 2: 8
  * NSS 3: 16
  * NSS 4: 24

This offset therefore has to be added for HT rates before they are stored
in the rate_info struct.

Fixes: cec17c382140 ("ath10k: add per peer htt tx stats support for 10.4")
Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>

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

c1dd8016ae02 ath10k: fix reported HT MCS rates with NSS > 1



--
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

Re: [PATCH] ath10k: fix recent bandwidth conversion bug

[Sebastian Gottschall]

i know. saw that later too. code should be safe

Am 02.11.2017 um 20:34 schrieb Christian Lamparter:

On Wednesday, November 1, 2017 9:37:53 PM CET Sebastian Gottschall wrote:

a additional array bounds check would be good

Ah, about that:

the bw variable in ath10k_htt_rx_h_rates() is extracted from info2
in the following way [0]:
|   bw = info2 & 3;

the txrate.bw variable in ath10k_update_per_peer_tx_stats() is set by [1]:
|   txrate.bw = ATH10K_HW_BW(peer_stats->flags);

ATH10K_HW_BW is a macro defined as [2]:
|   #define ATH10K_HW_BW(flags) (((flags) >> 3) & 0x3)

In both cases the bandwidth values already are limited to 0-3 by
the "and 3" operation.

[0] 
<https://elixir.free-electrons.com/linux/v4.14-rc7/source/drivers/net/wireless/ath/ath10k/htt_rx.c#L646>

[1] 
<https://elixir.free-electrons.com/linux/v4.14-rc7/source/drivers/net/wireless/ath/ath10k/htt_rx.c#L2254>
[2] 
<https://elixir.free-electrons.com/linux/v4.14-rc7/source/drivers/net/wireless/ath/ath10k/wmi.h#L4810>



@@ -592,6 +592,9 @@ struct amsdu_subframe_hdr {
   
   #define GROUP_ID_IS_SU_MIMO(x) ((x) == 0 || (x) == 63)
   
+static const u8 ath10k_bw_to_mac80211[] = { RATE_INFO_BW_20, RATE_INFO_BW_40,

+   RATE_INFO_BW_80, RATE_INFO_BW_160 };
+
   static void ath10k_htt_rx_h_rates(struct ath10k *ar,
  struct ieee80211_rx_status *status,
  struct htt_rx_desc *rxd)
@@ -694,23 +697,7 @@ static void ath10k_htt_rx_h_rates(struct ath10k *ar,
if (sgi)
status->enc_flags |= RX_ENC_FLAG_SHORT_GI;
   
[...]

+   status->bw = ath10k_bw_to_mac80211[bw];
status->encoding = RX_ENC_VHT;
break;
default:
@@ -2297,7 +2284,7 @@ ath10k_update_per_peer_tx_stats(struct ath10k *ar,
arsta->txrate.flags |= RATE_INFO_FLAGS_SHORT_GI;
   
   	arsta->txrate.nss = txrate.nss;

-   arsta->txrate.bw = txrate.bw + RATE_INFO_BW_20;
+   arsta->txrate.bw = ath10k_bw_to_mac80211[txrate.bw];
   }
   
   static void ath10k_htt_fetch_peer_stats(struct ath10k *ar,






--
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

Re: [PATCH] ath10k: fix recent bandwidth conversion bug

[Sebastian Gottschall]

a additional array bounds check would be good

Am 01.11.2017 um 21:01 schrieb Christian Lamparter:

The commit "cfg80211: make RATE_INFO_BW_20 the default" changed
the index of RATE_INFO_BW_20, but the updates to ath10k missed
the special bandwidth calculation case in
ath10k_update_per_peer_tx_stats().

Fixes: 842be75c77cb ("cfg80211: make RATE_INFO_BW_20 the default")
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
  drivers/net/wireless/ath/ath10k/htt_rx.c | 23 +--
  1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index a3f5dc78353f..26b0d201a698 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -592,6 +592,9 @@ struct amsdu_subframe_hdr {
  
  #define GROUP_ID_IS_SU_MIMO(x) ((x) == 0 || (x) == 63)
  
+static const u8 ath10k_bw_to_mac80211[] = { RATE_INFO_BW_20, RATE_INFO_BW_40,

+   RATE_INFO_BW_80, RATE_INFO_BW_160 };
+
  static void ath10k_htt_rx_h_rates(struct ath10k *ar,
  struct ieee80211_rx_status *status,
  struct htt_rx_desc *rxd)
@@ -694,23 +697,7 @@ static void ath10k_htt_rx_h_rates(struct ath10k *ar,
if (sgi)
status->enc_flags |= RX_ENC_FLAG_SHORT_GI;
  
-		switch (bw) {

-   /* 20MHZ */
-   case 0:
-   break;
-   /* 40MHZ */
-   case 1:
-   status->bw = RATE_INFO_BW_40;
-   break;
-   /* 80MHZ */
-   case 2:
-   status->bw = RATE_INFO_BW_80;
-   break;
-   case 3:
-   status->bw = RATE_INFO_BW_160;
-   break;
-   }
-
+   status->bw = ath10k_bw_to_mac80211[bw];
status->encoding = RX_ENC_VHT;
break;
default:
@@ -2297,7 +2284,7 @@ ath10k_update_per_peer_tx_stats(struct ath10k *ar,
arsta->txrate.flags |= RATE_INFO_FLAGS_SHORT_GI;
  
  	arsta->txrate.nss = txrate.nss;

-   arsta->txrate.bw = txrate.bw + RATE_INFO_BW_20;
+   arsta->txrate.bw = ath10k_bw_to_mac80211[txrate.bw];
  }
  
  static void ath10k_htt_fetch_peer_stats(struct ath10k *ar,



--
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

Re: [PATCH] ath10k: fix recent bandwidth conversion bug

[Sebastian Gottschall]

true. good finding.

Am 01.11.2017 um 21:01 schrieb Christian Lamparter:

The commit "cfg80211: make RATE_INFO_BW_20 the default" changed
the index of RATE_INFO_BW_20, but the updates to ath10k missed
the special bandwidth calculation case in
ath10k_update_per_peer_tx_stats().

Fixes: 842be75c77cb ("cfg80211: make RATE_INFO_BW_20 the default")
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
  drivers/net/wireless/ath/ath10k/htt_rx.c | 23 +--
  1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index a3f5dc78353f..26b0d201a698 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -592,6 +592,9 @@ struct amsdu_subframe_hdr {
  
  #define GROUP_ID_IS_SU_MIMO(x) ((x) == 0 || (x) == 63)
  
+static const u8 ath10k_bw_to_mac80211[] = { RATE_INFO_BW_20, RATE_INFO_BW_40,

+   RATE_INFO_BW_80, RATE_INFO_BW_160 };
+
  static void ath10k_htt_rx_h_rates(struct ath10k *ar,
  struct ieee80211_rx_status *status,
  struct htt_rx_desc *rxd)
@@ -694,23 +697,7 @@ static void ath10k_htt_rx_h_rates(struct ath10k *ar,
if (sgi)
status->enc_flags |= RX_ENC_FLAG_SHORT_GI;
  
-		switch (bw) {

-   /* 20MHZ */
-   case 0:
-   break;
-   /* 40MHZ */
-   case 1:
-   status->bw = RATE_INFO_BW_40;
-   break;
-   /* 80MHZ */
-   case 2:
-   status->bw = RATE_INFO_BW_80;
-   break;
-   case 3:
-   status->bw = RATE_INFO_BW_160;
-   break;
-   }
-
+   status->bw = ath10k_bw_to_mac80211[bw];
status->encoding = RX_ENC_VHT;
break;
default:
@@ -2297,7 +2284,7 @@ ath10k_update_per_peer_tx_stats(struct ath10k *ar,
arsta->txrate.flags |= RATE_INFO_FLAGS_SHORT_GI;
  
  	arsta->txrate.nss = txrate.nss;

-   arsta->txrate.bw = txrate.bw + RATE_INFO_BW_20;
+   arsta->txrate.bw = ath10k_bw_to_mac80211[txrate.bw];
  }
  
  static void ath10k_htt_fetch_peer_stats(struct ath10k *ar,



--
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

Re: [v3] ath10k: rebuild crypto header in rx data frames

[Sebastian Gottschall]

Am 31.10.2017 um 16:00 schrieb Kalle Valo:

Sebastian Gottschall <s.gottsch...@dd-wrt.com> writes:


the following patchlines in the v3 patch look wrong

+   /* ICV */
+   if (status->flag & RX_FLAG_ICV_STRIPPED &&
+   enctype != HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
+   skb_trim(msdu, msdu->len -
+    ath10k_htt_rx_crypto_tail_len(ar,
enctype));


the enctype != wpa2 isnt enough since it also belongs to ccmp-256,
gcmp modes etc.

4.14 doesn't support CCMP-256 nor GCMP modes yet. Did you check the
separate patch for 4.15:


for me ccmp-256 and gcmp works but my current tree is based on a very 
recent mac80211 version


but did not check if this support is included in 4.14 since i'm 
developing embedded wireless firmwares on different kernel versions 
using wireless backports based on recent mac80211 /ath10k etc. versions




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

thanks for notifying me. havent seen it




--
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

Re: [v3] ath10k: rebuild crypto header in rx data frames

[Sebastian Gottschall]

the same is for the MIC

+   /* MIC */
+   if ((status->flag & RX_FLAG_MIC_STRIPPED) &&
+   enctype == HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
+   skb_trim(msdu, msdu->len - 8);


this code looks wrong too

Am 30.10.2017 um 10:32 schrieb Sebastian Gottschall:
will check it tomorrow including gcmp-256, ccmp-256. was out for 
weekend :-)


Am 30.10.2017 um 09:39 schrieb Kalle Valo:

Kalle Valo <kv...@qca.qualcomm.com> wrote:


Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and
HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done
on host (mac80211) rather than firmware. Rebuild cipher header
in every received data frames (that are notified through those
HTT interfaces) from the rx_hdr_status tlv available in the
rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED
flag for the packets which requires mac80211 PN/TSC check support
and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X,
QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the
rebuilding of cipher header to perform PN/TSC check for replay
attack.

Please note that removing crypto tail for CCMP-256, GCMP and 
GCMP-256 ciphers

in raw mode needs to be fixed. Since Rx with these ciphers in raw
mode does not work in the current form even without this patch and
removing crypto tail for these chipers needs clean up, raw mode related
issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up
patches.

Tested-by: Manikanta Pubbisetty <mpubb...@qti.qualcomm.com>
Signed-off-by: Vasanthakumar Thiagarajan <vthia...@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kv...@qca.qualcomm.com>

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

7eccb738fce5 ath10k: rebuild crypto header in rx data frames





--
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

Re: [v3] ath10k: rebuild crypto header in rx data frames

[Sebastian Gottschall]

the following patchlines in the v3 patch look wrong

+   /* ICV */
+   if (status->flag & RX_FLAG_ICV_STRIPPED &&
+   enctype != HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
+   skb_trim(msdu, msdu->len -
+    ath10k_htt_rx_crypto_tail_len(ar, 
enctype));



the enctype != wpa2 isnt enough since it also belongs to ccmp-256, gcmp 
modes etc.


my proposal

   if (status->flag & RX_FLAG_ICV_STRIPPED) {
   switch(enctype)
   {
   case HTT_RX_MPDU_ENCRYPT_WEP40:
   case HTT_RX_MPDU_ENCRYPT_WEP104:
- case HTT_RX_MPDU_ENCRYPT_TKIP_WITHOUT_MIC:
   case HTT_RX_MPDU_ENCRYPT_TKIP_WPA:
   skb_trim(msdu, msdu->len -
    ath10k_htt_rx_crypto_tail_len(ar, enctype));
   break;
   default:
   break;
  }
- }


Am 30.10.2017 um 10:32 schrieb Sebastian Gottschall:
will check it tomorrow including gcmp-256, ccmp-256. was out for 
weekend :-)


Am 30.10.2017 um 09:39 schrieb Kalle Valo:

Kalle Valo <kv...@qca.qualcomm.com> wrote:


Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and
HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done
on host (mac80211) rather than firmware. Rebuild cipher header
in every received data frames (that are notified through those
HTT interfaces) from the rx_hdr_status tlv available in the
rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED
flag for the packets which requires mac80211 PN/TSC check support
and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X,
QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the
rebuilding of cipher header to perform PN/TSC check for replay
attack.

Please note that removing crypto tail for CCMP-256, GCMP and 
GCMP-256 ciphers

in raw mode needs to be fixed. Since Rx with these ciphers in raw
mode does not work in the current form even without this patch and
removing crypto tail for these chipers needs clean up, raw mode related
issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up
patches.

Tested-by: Manikanta Pubbisetty <mpubb...@qti.qualcomm.com>
Signed-off-by: Vasanthakumar Thiagarajan <vthia...@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kv...@qca.qualcomm.com>

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

7eccb738fce5 ath10k: rebuild crypto header in rx data frames





--
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

Re: [v3] ath10k: rebuild crypto header in rx data frames

[Sebastian Gottschall]

will check it tomorrow including gcmp-256, ccmp-256. was out for weekend :-)

Am 30.10.2017 um 09:39 schrieb Kalle Valo:

Kalle Valo <kv...@qca.qualcomm.com> wrote:


Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and
HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done
on host (mac80211) rather than firmware. Rebuild cipher header
in every received data frames (that are notified through those
HTT interfaces) from the rx_hdr_status tlv available in the
rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED
flag for the packets which requires mac80211 PN/TSC check support
and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X,
QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the
rebuilding of cipher header to perform PN/TSC check for replay
attack.

Please note that removing crypto tail for CCMP-256, GCMP and GCMP-256 ciphers
in raw mode needs to be fixed. Since Rx with these ciphers in raw
mode does not work in the current form even without this patch and
removing crypto tail for these chipers needs clean up, raw mode related
issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up
patches.

Tested-by: Manikanta Pubbisetty <mpubb...@qti.qualcomm.com>
Signed-off-by: Vasanthakumar Thiagarajan <vthia...@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kv...@qca.qualcomm.com>

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

7eccb738fce5 ath10k: rebuild crypto header in rx data frames



--
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

Re: [PATCH v2] ath10k: rebuild crypto header in Rx data frames

[Sebastian Gottschall]

Am 25.10.2017 um 11:07 schrieb Kalle Valo:

(fixing top posting)

Jasmine Strong <j...@eero.com> writes:


On Tue, Oct 24, 2017 at 1:41 PM, Sebastian Gottschall
<s.gottsch...@dd-wrt.com> wrote:


patch works. tested in sta and ap mode so far on 9984

Seems to work okay on mixed networks of 9882, 4019 and 9888.

Thanks Sebastian and Jasmine for testing this, very much appreciated. We
have a v3 coming up soon which should fix GCMP, GCMP-256 and CCMP-256 as
well.


i have my own v3, but will wait for your version to check how much its 
different from mine


i'm also able to test gmp / aes 256 using 2 QCA 9984 devices


--
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

Re: [PATCH v2] ath10k: rebuild crypto header in Rx data frames

[Sebastian Gottschall]

hdr->frame_control &= ~__cpu_to_le16(IEEE80211_FCTL_PROTECTED);
}
@@ -1434,6 +1481,9 @@ static void ath10k_htt_rx_h_deliver(struct ath10k *ar,
struct ieee80211_rx_status *status)
  {
struct sk_buff *msdu;
+   struct sk_buff *first_subframe;
+
+   first_subframe = skb_peek(amsdu);
  
  	while ((msdu = __skb_dequeue(amsdu))) {

/* Setup per-MSDU flags */
@@ -1442,6 +1492,13 @@ static void ath10k_htt_rx_h_deliver(struct ath10k *ar,
else
status->flag |= RX_FLAG_AMSDU_MORE;
  
+		if (msdu == first_subframe) {

+   first_subframe = NULL;
+   status->flag &= ~RX_FLAG_ALLOW_SAME_PN;
+   } else {
+   status->flag |= RX_FLAG_ALLOW_SAME_PN;
+   }
+
ath10k_process_rx(ar, status, msdu);
}
  }
@@ -1584,7 +1641,7 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt 
*htt)
ath10k_htt_rx_h_unchain(ar, );
  
  	ath10k_htt_rx_h_filter(ar, , rx_status);

-   ath10k_htt_rx_h_mpdu(ar, , rx_status);
+   ath10k_htt_rx_h_mpdu(ar, , rx_status, true);
ath10k_htt_rx_h_deliver(ar, , rx_status);
  
  	return num_msdus;

@@ -1923,7 +1980,7 @@ static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, 
struct sk_buff *skb,
budget_left -= skb_queue_len();
ath10k_htt_rx_h_ppdu(ar, , status, vdev_id);
ath10k_htt_rx_h_filter(ar, , status);
-   ath10k_htt_rx_h_mpdu(ar, , status);
+   ath10k_htt_rx_h_mpdu(ar, , status, false);
    ath10k_htt_rx_h_deliver(ar, , status);
break;
case -EAGAIN:



--
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

Re: [PATCH] ath10k: rebuild crypto header in RX data frames

[Sebastian Gottschall]

Am 23.10.2017 um 16:24 schrieb Vasanthakumar Thiagarajan:

On Saturday 21 October 2017 01:41 AM, Sebastian Gottschall wrote:

i suggest the following patch on top of yours. please tell me if my thoughts 
are correct here. its mainly a guess

I agree we need to take care of this for newly added ciphers as well. How about 
making it as a separate patch
to make the patch bit smaller and to reduce the difficulties in back porting it 
for ciphers supported for long
time?
the patch for these both ciphers doesnt make it bigger. just a few 
lines. the main problem right now is that the original patch without my 
enhancements isnt working. it breaks encryption

Vasanth



--
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

Re: [PATCH] ath10k: rebuild crypto header in RX data frames

[Sebastian Gottschall]

+
+   if (fill_crypt_header)
+   status->flag |= RX_FLAG_MIC_STRIPPED |
+   RX_FLAG_ICV_STRIPPED;
+   else
+   status->flag |= RX_FLAG_IV_STRIPPED;
  }
  
  	skb_queue_walk(amsdu, msdu) {

ath10k_htt_rx_h_csum_offload(msdu);
-   ath10k_htt_rx_h_undecap(ar, msdu, status, first_hdr, enctype,
-   is_decrypted);
+   ath10k_htt_rx_h_undecap(ar, msdu, status, first_hdr,
+   (void *)first->data - sizeof(*rxd),
+   enctype, is_decrypted);
  
  		/* Undecapping involves copying the original 802.11 header back

 * to sk_buff. If frame is protected and hardware has decrypted
@@ -1424,6 +1499,9 @@ static void ath10k_htt_rx_h_mpdu(struct ath10k *ar,
if (is_mgmt)
continue;
  
+		if (fill_crypt_header)

+   continue;
+
hdr = (void *)msdu->data;
hdr->frame_control &= ~__cpu_to_le16(IEEE80211_FCTL_PROTECTED);
}
@@ -1434,6 +1512,9 @@ static void ath10k_htt_rx_h_deliver(struct ath10k *ar,
struct ieee80211_rx_status *status)
  {
struct sk_buff *msdu;
+   struct sk_buff *first_subframe;
+
+   first_subframe = skb_peek(amsdu);
  
  	while ((msdu = __skb_dequeue(amsdu))) {

/* Setup per-MSDU flags */
@@ -1442,6 +1523,13 @@ static void ath10k_htt_rx_h_deliver(struct ath10k *ar,
else
status->flag |= RX_FLAG_AMSDU_MORE;
  
+		if (msdu == first_subframe) {

+   first_subframe = NULL;
+   status->flag &= ~RX_FLAG_ALLOW_SAME_PN;
+   } else {
+   status->flag |= RX_FLAG_ALLOW_SAME_PN;
+   }
+
ath10k_process_rx(ar, status, msdu);
}
  }
@@ -1584,7 +1672,7 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt 
*htt)
ath10k_htt_rx_h_unchain(ar, );
  
  	ath10k_htt_rx_h_filter(ar, , rx_status);

-   ath10k_htt_rx_h_mpdu(ar, , rx_status);
+   ath10k_htt_rx_h_mpdu(ar, , rx_status, true);
ath10k_htt_rx_h_deliver(ar, , rx_status);
  
  	return num_msdus;

@@ -1923,7 +2011,7 @@ static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, 
struct sk_buff *skb,
budget_left -= skb_queue_len();
ath10k_htt_rx_h_ppdu(ar, , status, vdev_id);
ath10k_htt_rx_h_filter(ar, , status);
-   ath10k_htt_rx_h_mpdu(ar, , status);
+   ath10k_htt_rx_h_mpdu(ar, , status, false);
ath10k_htt_rx_h_deliver(ar, , status);
break;
case -EAGAIN:




--
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

Re: [PATCH] ath10k: rebuild crypto header in RX data frames

[Sebastian Gottschall]

   bool fill_crypt_header)
  {
struct sk_buff *first;
struct sk_buff *last;
@@ -1406,14 +1475,20 @@ static void ath10k_htt_rx_h_mpdu(struct ath10k *ar,
status->flag |= RX_FLAG_DECRYPTED;
  
  		if (likely(!is_mgmt))

-   status->flag |= RX_FLAG_IV_STRIPPED |
-   RX_FLAG_MMIC_STRIPPED;
+   status->flag |= RX_FLAG_MMIC_STRIPPED;
+
+   if (fill_crypt_header)
+   status->flag |= RX_FLAG_MIC_STRIPPED |
+   RX_FLAG_ICV_STRIPPED;
+   else
+   status->flag |= RX_FLAG_IV_STRIPPED;
  }
  
  	skb_queue_walk(amsdu, msdu) {

ath10k_htt_rx_h_csum_offload(msdu);
-   ath10k_htt_rx_h_undecap(ar, msdu, status, first_hdr, enctype,
-   is_decrypted);
+   ath10k_htt_rx_h_undecap(ar, msdu, status, first_hdr,
+   (void *)first->data - sizeof(*rxd),
+   enctype, is_decrypted);
  
  		/* Undecapping involves copying the original 802.11 header back

 * to sk_buff. If frame is protected and hardware has decrypted
@@ -1424,6 +1499,9 @@ static void ath10k_htt_rx_h_mpdu(struct ath10k *ar,
if (is_mgmt)
continue;
  
+		if (fill_crypt_header)

+   continue;
+
hdr = (void *)msdu->data;
hdr->frame_control &= ~__cpu_to_le16(IEEE80211_FCTL_PROTECTED);
}
@@ -1434,6 +1512,9 @@ static void ath10k_htt_rx_h_deliver(struct ath10k *ar,
struct ieee80211_rx_status *status)
  {
struct sk_buff *msdu;
+   struct sk_buff *first_subframe;
+
+   first_subframe = skb_peek(amsdu);
  
  	while ((msdu = __skb_dequeue(amsdu))) {

/* Setup per-MSDU flags */
@@ -1442,6 +1523,13 @@ static void ath10k_htt_rx_h_deliver(struct ath10k *ar,
else
status->flag |= RX_FLAG_AMSDU_MORE;
  
+		if (msdu == first_subframe) {

+   first_subframe = NULL;
+   status->flag &= ~RX_FLAG_ALLOW_SAME_PN;
+   } else {
+   status->flag |= RX_FLAG_ALLOW_SAME_PN;
+   }
+
ath10k_process_rx(ar, status, msdu);
}
  }
@@ -1584,7 +1672,7 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt 
*htt)
ath10k_htt_rx_h_unchain(ar, );
  
  	ath10k_htt_rx_h_filter(ar, , rx_status);

-   ath10k_htt_rx_h_mpdu(ar, , rx_status);
+   ath10k_htt_rx_h_mpdu(ar, , rx_status, true);
ath10k_htt_rx_h_deliver(ar, , rx_status);
  
  	return num_msdus;

@@ -1923,7 +2011,7 @@ static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, 
struct sk_buff *skb,
budget_left -= skb_queue_len();
ath10k_htt_rx_h_ppdu(ar, , status, vdev_id);
ath10k_htt_rx_h_filter(ar, , status);
-   ath10k_htt_rx_h_mpdu(ar, , status);
+   ath10k_htt_rx_h_mpdu(ar, , status, false);
    ath10k_htt_rx_h_deliver(ar, , status);
break;
case -EAGAIN:




--
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

Re: QCA988x and kernel 4.13

[Sebastian Gottschall]

Am 04.10.2017 um 17:13 schrieb Ben Greear:



On 10/04/2017 01:50 AM, Kalle Valo wrote:

Ben Greear <gree...@candelatech.com> writes:


On 10/01/2017 07:06 AM, Sebastian Gottschall wrote:

you have to update to the latest mac80211 code. there is a well
known bug in mac80211 which causes a deadlock with ath10k


Do you have a pointer to the patch that fixes this?  I'd like to 
check if it has

made it into 4.13 stable yet...


I think it's this one:

mac80211: fix deadlock in driver-managed RX BA session start

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bde59c475e0883e4c4294bcd9b9c7e08ae18c828 



Adding linux-wireless so that someone can correct me in case I'm wrong.


That did seem to fix my problems...

Thanks,
ben

consider that this bug does at least exist since may. so older kernels 
might be affected too



--
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

Re: QCA988x and kernel 4.13

[Sebastian Gottschall]

Am 04.10.2017 um 10:50 schrieb Kalle Valo:

Ben Greear <gree...@candelatech.com> writes:


On 10/01/2017 07:06 AM, Sebastian Gottschall wrote:

you have to update to the latest mac80211 code. there is a well
known bug in mac80211 which causes a deadlock with ath10k

Do you have a pointer to the patch that fixes this?  I'd like to check if it has
made it into 4.13 stable yet...

I think it's this one:

mac80211: fix deadlock in driver-managed RX BA session start

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bde59c475e0883e4c4294bcd9b9c7e08ae18c828

Adding linux-wireless so that someone can correct me in case I'm wrong.

i believe thats the correct one




--
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

Re: [PATCH] ath10k: add new cipher suite support

[Sebastian Gottschall]

Am 22.09.2017 um 23:17 schrieb Rajkumar Manoharan:

-   ar->hw->wiphy->n_cipher_suites = ARRAY_SIZE(cipher_suites);
+
+   /* QCA988x and QCA6174 family chips do not support CCMP-256, GCMP-128
+* and GCMP-256 ciphers in hardware.
+*/
+   if (!ar->hw_params.n_cipher_suites)
+   ar->hw->wiphy->n_cipher_suites = ARRAY_SIZE(cipher_suites);
this is a bug. you do not set ar->hw->wiphy->n_cipher_suites if its non 
zero. this breaks ath10k crypto support for all chipsets except for QCA998X



--
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