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

[Luis R. Rodriguez]

On Tue, Aug 02, 2016 at 11:10:22AM +, Valo, Kalle wrote:
> "Luis R. Rodriguez"  writes:
> 
> > I was considering this as a future extension to the firmware API
> > through the new extensible firmware API, the sysdata API.
> 
> I think Linus mentioned this already, but I want to reiterate anyway.
> The name "sysdata" is horrible, I didn't have any idea what it means
> until I read your description. Please continue to use the term
> "firmware", anyone already know what it means.

We've gone well past using the firmware API for firmware though, if
we use it for 802.11 to replace CRDA for instance its really odd to
be calling it firmware. But sure... I will rebrand again to firmware...

  Luis

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

Re: ath10k fail to load firmware

[Valo, Kalle]

Michal Kazior  writes:

> On 19 July 2016 at 10:24,   wrote:
>> Dell - Internal Use - Confidential
>>
>> HI  All:
>> I have replaced the new firmware files to old one. And I build new 
>> ath10k_pci.ko ,ath10k_core.ko to get some
>> debug info.
>>
>> The new firmware is still not loaded by ath10k driver .
>> And I compare the driver codes with 4.7 -rc7 , the codes are almost same.
>> So the issue should be in  firmware scope.
>>
>> [ 590.486970] ath10k_pci :02:00.0: Hardware name qca6174 hw3.2 version 
>> 0x503
>> [  590.487158] ath10k_pci :02:00.0: Direct firmware load failed with 
>> error -2
>> [  590.487159] ath10k_pci :02:00.0: Falling back to user helper
>
> You didn't attach a complete log so it's hard to tell. ath10k tends to
> print a few messages that may look like an error but aren't (there's a
> fallback mechanism for finding firmware files which is overly
> verbose).
>
> @Perry: You need to rename the
> firmware-4.bin_WLAN.RM.2.0-00180-QCARMSWPZ-1 to firmware-4.bin in case
> you merely mirrored the github repo.
>
> @Kalle: I think it'd be very useful to maintain ath10k-firmware in a
> way so that it is easier to the uninitiated to `git clone` it into
> /lib/firmware, e.g. maintain firmware-X.bin symlinks in each
> QCAxxx/hw.y/ to the latest one. Thoughts?

Yeah, something like that would be really nice. It would also make it
easier for me to update linux-firmware.git.

What about if we had a script which installs the latest ath10k firmware
files from ath10k-firmware.git? Something along lines of:

$ cd ~/git/ath10k-firmware
$ git pull
$ sudo ath10k-fw-install /lib/firmware/ath10k

I could also add a simple menu to select older firmware versions. But
this is just a wild idea.

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

[PATCH 0763/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 drivers/net/wireless/ath/ath10k/core.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 49af624..9e42274 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -36,11 +36,11 @@ static bool uart_print;
 static bool skip_otp;
 static bool rawmode;
 
-module_param_named(debug_mask, ath10k_debug_mask, uint, 0644);
-module_param_named(cryptmode, ath10k_cryptmode_param, uint, 0644);
-module_param(uart_print, bool, 0644);
-module_param(skip_otp, bool, 0644);
-module_param(rawmode, bool, 0644);
+module_param_named(debug_mask, ath10k_debug_mask, uint, S_IRUSR | S_IWUSR | 
S_IRGRP | S_IROTH);
+module_param_named(cryptmode, ath10k_cryptmode_param, uint, S_IRUSR | S_IWUSR 
| S_IRGRP | S_IROTH);
+module_param(uart_print, bool, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(skip_otp, bool, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rawmode, bool, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
 
 MODULE_PARM_DESC(debug_mask, "Debugging mask");
 MODULE_PARM_DESC(uart_print, "Uart target debugging");
-- 
2.9.2


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

[PATCH 2/2] ath10k: add platform regulatory domain support

[Bartosz Markowski]

This overrides whatever regulatory the device
EEPROM contains and uses what the platform says
instead - in this implementation the ACPI driver.

In case the hint is not programmed or corrupted (0x)
the device falls back to the eeprom programmed settings.

Signed-off-by: Bartosz Markowski 
---
 drivers/net/wireless/ath/ath10k/core.h |   1 +
 drivers/net/wireless/ath/ath10k/mac.c  | 117 +
 drivers/net/wireless/ath/ath10k/wmi.c  |   2 +-
 3 files changed, 119 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 30ae5bf81611..1df7c600a2bb 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -692,6 +692,7 @@ struct ath10k {
u32 phy_capability;
u32 hw_min_tx_power;
u32 hw_max_tx_power;
+   u32 hw_eeprom_rd;
u32 ht_cap_info;
u32 vht_cap_info;
u32 num_rf_chains;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index fb8e38df9446..b6b8a0b2046b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 
 #include "hif.h"
 #include "core.h"
@@ -7751,6 +7752,116 @@ struct ath10k_vif *ath10k_get_arvif(struct ath10k *ar, 
u32 vdev_id)
return arvif_iter.arvif;
 }
 
+#ifdef CONFIG_ACPI
+#define WRD_METHOD "WRDD"
+#define WRDD_WIFI  (0x07)
+
+static u32 ath10k_mac_wrdd_get_mcc(struct ath10k *ar, union acpi_object *wrdd)
+{
+   union acpi_object *mcc_pkg;
+   union acpi_object *domain_type;
+   union acpi_object *mcc_value;
+   u32 i;
+
+   if (wrdd->type != ACPI_TYPE_PACKAGE ||
+   wrdd->package.count < 2 ||
+   wrdd->package.elements[0].type != ACPI_TYPE_INTEGER ||
+   wrdd->package.elements[0].integer.value != 0) {
+   ath10k_warn(ar, "ignoring malformed/unsupported wrdd 
structure\n");
+   return 0;
+   }
+
+   for (i = 1; i < wrdd->package.count; ++i) {
+   mcc_pkg = >package.elements[i];
+
+   if (mcc_pkg->type != ACPI_TYPE_PACKAGE)
+   continue;
+   if (mcc_pkg->package.count < 2)
+   continue;
+   if (mcc_pkg->package.elements[0].type != ACPI_TYPE_INTEGER ||
+   mcc_pkg->package.elements[1].type != ACPI_TYPE_INTEGER)
+   continue;
+
+   domain_type = _pkg->package.elements[0];
+   if (domain_type->integer.value != WRDD_WIFI)
+   continue;
+
+   mcc_value = _pkg->package.elements[1];
+   return mcc_value->integer.value;
+   }
+   return 0;
+}
+
+static u16 ath10k_mac_get_wrdd_regulatory(struct ath10k *ar)
+{
+   u16 rd;
+   acpi_handle root_handle;
+   acpi_handle handle;
+   struct acpi_buffer wrdd = {ACPI_ALLOCATE_BUFFER, NULL};
+   acpi_status status;
+   u32 alpha2_code;
+   char alpha2[3];
+   struct pci_dev *pdev = to_pci_dev(ar->dev);
+
+   root_handle = ACPI_HANDLE(>dev);
+   if (!root_handle) {
+   ath10k_warn(ar, "failed to get root port acpi handle\n");
+   return -1;
+   }
+
+   status = acpi_get_handle(root_handle, (acpi_string)WRD_METHOD, );
+   if (ACPI_FAILURE(status)) {
+   ath10k_warn(ar, "failed to get wrd method %d\n", status);
+   return -1;
+   }
+
+   status = acpi_evaluate_object(handle, NULL, NULL, );
+   if (ACPI_FAILURE(status)) {
+   ath10k_warn(ar, "failed to call wrdc %d\n", status);
+   return -1;
+   }
+
+   alpha2_code = ath10k_mac_wrdd_get_mcc(ar, wrdd.pointer);
+   kfree(wrdd.pointer);
+   if (!alpha2_code)
+   return -1;
+
+   alpha2[0] = (alpha2_code >> 8) & 0xff;
+   alpha2[1] = (alpha2_code >> 0) & 0xff;
+   alpha2[2] = '\0';
+
+   ath10k_info(ar, "regulatory hint from WRDD (alpha2-code): %s\n", 
alpha2);
+
+   rd = ath_regd_find_country_by_name(alpha2);
+   if (rd == 0x)
+   return rd;
+
+   rd |= COUNTRY_ERD_FLAG;
+   return rd;
+}
+
+#else
+static u16 ath10k_mac_get_wrdd_regulatory(struct ath10k *ar)
+{
+   /* fallback to default eeprom settings */
+   return -1;
+}
+#endif
+
+static int ath10k_mac_init_rd(struct ath10k *ar)
+{
+   u16 rd;
+
+   rd = ath10k_mac_get_wrdd_regulatory(ar);
+   if (rd == 0x) {
+   ath10k_info(ar, "fallback to eeprom programmed regulatory 
settings\n");
+   rd = ar->hw_eeprom_rd;
+   }
+
+   ar->ath_common.regulatory.current_rd = rd;
+   return 0;
+}
+
 int ath10k_mac_register(struct ath10k *ar)
 {
static const u32 cipher_suites[] = {
@@ -7974,6 +8085,12 @@ int ath10k_mac_register(struct ath10k *ar)
  

[PATCH 0764/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 drivers/net/wireless/ath/ath10k/pci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
b/drivers/net/wireless/ath/ath10k/pci.c
index 8133d7b..0961a4e 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -41,10 +41,10 @@ enum ath10k_pci_reset_mode {
 static unsigned int ath10k_pci_irq_mode = ATH10K_PCI_IRQ_AUTO;
 static unsigned int ath10k_pci_reset_mode = ATH10K_PCI_RESET_AUTO;
 
-module_param_named(irq_mode, ath10k_pci_irq_mode, uint, 0644);
+module_param_named(irq_mode, ath10k_pci_irq_mode, uint, S_IRUSR | S_IWUSR | 
S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(irq_mode, "0: auto, 1: legacy, 2: msi (default: 0)");
 
-module_param_named(reset_mode, ath10k_pci_reset_mode, uint, 0644);
+module_param_named(reset_mode, ath10k_pci_reset_mode, uint, S_IRUSR | S_IWUSR 
| S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(reset_mode, "0: auto, 1: warm only (default: 0)");
 
 /* how long wait to wait for target to initialise, in ms */
-- 
2.9.2


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

[PATCH 1/2] ath: export alpha2 helper

[Bartosz Markowski]

From: Michal Kazior 

This will be helpful for drivers that can acquire
alpha2 regulatory codes.

Signed-off-by: Michal Kazior 
Signed-off-by: Bartosz Markowski 
---
 drivers/net/wireless/ath/regd.c | 3 ++-
 drivers/net/wireless/ath/regd.h | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index 7e15ed9ed31f..820bf880ada3 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -449,7 +449,7 @@ static void ath_reg_apply_world_flags(struct wiphy *wiphy,
}
 }
 
-static u16 ath_regd_find_country_by_name(char *alpha2)
+u16 ath_regd_find_country_by_name(char *alpha2)
 {
unsigned int i;
 
@@ -460,6 +460,7 @@ static u16 ath_regd_find_country_by_name(char *alpha2)
 
return -1;
 }
+EXPORT_SYMBOL(ath_regd_find_country_by_name);
 
 static int __ath_reg_dyn_country(struct wiphy *wiphy,
 struct ath_regulatory *reg,
diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index 565d3075f06e..5d80be213fac 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -251,6 +251,7 @@ enum CountryCode {
 
 bool ath_is_world_regd(struct ath_regulatory *reg);
 bool ath_is_49ghz_allowed(u16 redomain);
+u16 ath_regd_find_country_by_name(char *alpha2);
 int ath_regd_init(struct ath_regulatory *reg, struct wiphy *wiphy,
  void (*reg_notifier)(struct wiphy *wiphy,
   struct regulatory_request *request));
-- 
2.1.2


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

[PATCH 0/2] platform regulatory support

[Bartosz Markowski]

Hardware or platform manufacturers may want to use a persistent
memory storage to program ragulatory settings via e.g. bios, uefi, acpi.

This patch set implements methods to retrieve the platform regulatory
settings (via ACPI calls) and use them to override the wifi chip
eeprom default settings.

This has been developed and tested on Skylake (Chromebook) platform, where the
persistent area containing "region" value is called VPD.

Bartosz Markowski (1):
  ath10k: add platform regulatory domain support

Michal Kazior (1):
  ath: export alpha2 helper

 drivers/net/wireless/ath/ath10k/core.h |   1 +
 drivers/net/wireless/ath/ath10k/mac.c  | 117 +
 drivers/net/wireless/ath/ath10k/wmi.c  |   2 +-
 drivers/net/wireless/ath/regd.c|   3 +-
 drivers/net/wireless/ath/regd.h|   1 +
 5 files changed, 122 insertions(+), 2 deletions(-)

-- 
2.1.2


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

Re: ath10k fail to load firmware

[Valo, Kalle]

Michal Kazior  writes:

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

Sounds like a good idea. Or maybe we should always fail when using
board-2.bin (no matter what hw version is used)? Dunno.

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

I pushed a new board-2.bin:

https://github.com/kvalo/ath10k-firmware/commit/7c0411643b195b246d3871f409f9219f528b39c1

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

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

[Felix Fietkau]

On 2016-08-02 13:18, Valo, Kalle wrote:
> Michal Kazior  writes:
> 
>> Firmware files are versioned to prevent older
>> driver instances to load unsupported firmware
>> blobs. This is reflected with a fallback logic
>> which attempts to load several firmware files.
>>
>> This however produced a lot of unnecessary
>> warnings sometimes confusing users and leading
>> them to rename firmware files making things even
>> more confusing.
>>
>> Hence use request_firmware_direct() which does not
>> produce extra warnings. This shouldn't really
>> break anything because most modern systems don't
>> rely on udev/hotplug helpers to load firmware
>> files anymore.
>>
>> Signed-off-by: Michal Kazior 
> 
> Nice. These "firmware not found" messages have been confusing ath10k
> users for ages and should be properly fixed. I hope we find a solution.
> 
> But I talked with Felix about this and he made a good point about board
> and calibration files. Calibration files might be created runtime, for
> example retrieved from NAND etc, and this might break the use case when
> ath10k is statically linked to kernel. Is the combination used in real
> life and should we care, that I do not know, but I'm worried of possible
> regressions. I guess LEDE/openwrt always loads ath10k as a module and
> after the calibration file is created?
ath10k is always loaded as a module, and the calibration file is created
by a script that's triggered by the firmware uevent.

- Felix

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

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

[Valo, Kalle]

Michal Kazior  writes:

> Firmware files are versioned to prevent older
> driver instances to load unsupported firmware
> blobs. This is reflected with a fallback logic
> which attempts to load several firmware files.
>
> This however produced a lot of unnecessary
> warnings sometimes confusing users and leading
> them to rename firmware files making things even
> more confusing.
>
> Hence use request_firmware_direct() which does not
> produce extra warnings. This shouldn't really
> break anything because most modern systems don't
> rely on udev/hotplug helpers to load firmware
> files anymore.
>
> Signed-off-by: Michal Kazior 

Nice. These "firmware not found" messages have been confusing ath10k
users for ages and should be properly fixed. I hope we find a solution.

But I talked with Felix about this and he made a good point about board
and calibration files. Calibration files might be created runtime, for
example retrieved from NAND etc, and this might break the use case when
ath10k is statically linked to kernel. Is the combination used in real
life and should we care, that I do not know, but I'm worried of possible
regressions. I guess LEDE/openwrt always loads ath10k as a module and
after the calibration file is created?

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

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

[Valo, Kalle]

"Luis R. Rodriguez"  writes:

> I was considering this as a future extension to the firmware API
> through the new extensible firmware API, the sysdata API.

I think Linus mentioned this already, but I want to reiterate anyway.
The name "sysdata" is horrible, I didn't have any idea what it means
until I read your description. Please continue to use the term
"firmware", anyone already know what it means.

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

[PATCH] ath10k: Add WMI_SERVICE_PERIODIC_CHAN_STAT_SUPPORT wmi service

[c_traja]

From: Tamizh chelvam 

WMI_SERVICE_PERIODIC_CHAN_STAT_SUPPORT service has missed in
the commit 7e247a9e88dc ("ath10k: add dynamic tx mode switch
config support for qca4019"). This patch adds the service to
avoid mismatch between host and target.

Fixes:7e247a9e88dc ("ath10k: add dynamic tx mode switch config support for 
qca4019")
Signed-off-by: Tamizh chelvam 
---
 drivers/net/wireless/ath/ath10k/wmi.h |5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 3ef4688..f67cc19 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -180,6 +180,7 @@ enum wmi_service {
WMI_SERVICE_MESH_NON_11S,
WMI_SERVICE_PEER_STATS,
WMI_SERVICE_RESTRT_CHNL_SUPPORT,
+   WMI_SERVICE_PERIODIC_CHAN_STAT_SUPPORT,
WMI_SERVICE_TX_MODE_PUSH_ONLY,
WMI_SERVICE_TX_MODE_PUSH_PULL,
WMI_SERVICE_TX_MODE_DYNAMIC,
@@ -305,6 +306,7 @@ enum wmi_10_4_service {
WMI_10_4_SERVICE_RESTRT_CHNL_SUPPORT,
WMI_10_4_SERVICE_PEER_STATS,
WMI_10_4_SERVICE_MESH_11S,
+   WMI_10_4_SERVICE_PERIODIC_CHAN_STAT_SUPPORT,
WMI_10_4_SERVICE_TX_MODE_PUSH_ONLY,
WMI_10_4_SERVICE_TX_MODE_PUSH_PULL,
WMI_10_4_SERVICE_TX_MODE_DYNAMIC,
@@ -402,6 +404,7 @@ static inline char *wmi_service_name(int service_id)
SVCSTR(WMI_SERVICE_MESH_NON_11S);
SVCSTR(WMI_SERVICE_PEER_STATS);
SVCSTR(WMI_SERVICE_RESTRT_CHNL_SUPPORT);
+   SVCSTR(WMI_SERVICE_PERIODIC_CHAN_STAT_SUPPORT);
SVCSTR(WMI_SERVICE_TX_MODE_PUSH_ONLY);
SVCSTR(WMI_SERVICE_TX_MODE_PUSH_PULL);
SVCSTR(WMI_SERVICE_TX_MODE_DYNAMIC);
@@ -652,6 +655,8 @@ static inline void wmi_10_4_svc_map(const __le32 *in, 
unsigned long *out,
   WMI_SERVICE_PEER_STATS, len);
SVCMAP(WMI_10_4_SERVICE_MESH_11S,
   WMI_SERVICE_MESH_11S, len);
+   SVCMAP(WMI_10_4_SERVICE_PERIODIC_CHAN_STAT_SUPPORT,
+  WMI_SERVICE_PERIODIC_CHAN_STAT_SUPPORT, len);
SVCMAP(WMI_10_4_SERVICE_TX_MODE_PUSH_ONLY,
   WMI_SERVICE_TX_MODE_PUSH_ONLY, len);
SVCMAP(WMI_10_4_SERVICE_TX_MODE_PUSH_PULL,
-- 
1.7.9.5


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