From c_traja at qti.qualcomm.com  Fri Jul  1 00:05:09 2016
From: c_traja at qti.qualcomm.com (c_traja at qti.qualcomm.com)
Date: Fri, 1 Jul 2016 12:35:09 +0530
Subject: [PATCHv3 0/3]ath10k: Add testmode support for 10.4 
Message-ID: <1467356709-31555-1-git-send-email-c_traja@qti.qualcomm.com>

From: Tamizh chelvam <c_traja at qti.qualcomm.com>

* The below patches add testmode support for 10.4.

* Some of the codeswap related code in ath10k for example code which 
  initializes the code swap segment works only on normal fw, below patches 
  make such code generic so that it can be used for utf binary as well.

Tamizh chelvam (3):
  ath10k: move firmware_swap_code_seg_info to ath10k_fw_file
  ath10k: handle testmode events for 10.2 and 10.4 based firmware
  ath10k: add testmode support for 10.4 firmware

v3:
  * Fixed crash reported by Kalle.

v2:
  * changed author and signed off mail id.

 drivers/net/wireless/ath/ath10k/core.c     |    6 +++---
 drivers/net/wireless/ath/ath10k/core.h     |    6 ++----
 drivers/net/wireless/ath/ath10k/swap.c     |   26 ++++++++++++++------------
 drivers/net/wireless/ath/ath10k/swap.h     |   11 ++++++++---
 drivers/net/wireless/ath/ath10k/testmode.c |   23 +++++++++++++++++++++++
 drivers/net/wireless/ath/ath10k/wmi.c      |   26 ++++++++++++++++++++++++++
 6 files changed, 76 insertions(+), 22 deletions(-)

-- 
1.7.9.5



From c_traja at qti.qualcomm.com  Fri Jul  1 00:06:07 2016
From: c_traja at qti.qualcomm.com (c_traja at qti.qualcomm.com)
Date: Fri, 1 Jul 2016 12:36:07 +0530
Subject: [PATCHv3 1/3] ath10k: move firmware_swap_code_seg_info to
 ath10k_fw_file
Message-ID: <1467356767-31646-1-git-send-email-c_traja@qti.qualcomm.com>

From: Tamizh chelvam <c_traja at qti.qualcomm.com>

Preparation to make use of firmware_swap_code_seg_info for UTF binary.

Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c |    6 +++---
 drivers/net/wireless/ath/ath10k/core.h |    6 ++----
 drivers/net/wireless/ath/ath10k/swap.c |   26 ++++++++++++++------------
 drivers/net/wireless/ath/ath10k/swap.h |   11 ++++++++---
 4 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index dfb3db0..0a1946b 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -723,7 +723,7 @@ static int ath10k_download_fw(struct ath10k *ar)
 	data = ar->running_fw->fw_file.firmware_data;
 	data_len = ar->running_fw->fw_file.firmware_len;
 
-	ret = ath10k_swap_code_seg_configure(ar);
+	ret = ath10k_swap_code_seg_configure(ar, &ar->running_fw->fw_file);
 	if (ret) {
 		ath10k_err(ar, "failed to configure fw code swap: %d\n",
 			   ret);
@@ -765,7 +765,7 @@ static void ath10k_core_free_firmware_files(struct ath10k *ar)
 	if (!IS_ERR(ar->pre_cal_file))
 		release_firmware(ar->pre_cal_file);
 
-	ath10k_swap_code_seg_release(ar);
+	ath10k_swap_code_seg_release(ar, &ar->normal_mode_fw.fw_file);
 
 	ar->normal_mode_fw.fw_file.otp_data = NULL;
 	ar->normal_mode_fw.fw_file.otp_len = 0;
@@ -2009,7 +2009,7 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
 		goto err_free_firmware_files;
 	}
 
-	ret = ath10k_swap_code_seg_init(ar);
+	ret = ath10k_swap_code_seg_init(ar, &ar->normal_mode_fw.fw_file);
 	if (ret) {
 		ath10k_err(ar, "failed to initialize code swap segment: %d\n",
 			   ret);
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 3da18c9..e69e7e7 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -654,6 +654,8 @@ struct ath10k_fw_file {
 
 	const void *codeswap_data;
 	size_t codeswap_len;
+	/* FIXME: add a comment */
+	struct ath10k_swap_code_seg_info *firmware_swap_code_seg_info;
 };
 
 struct ath10k_fw_components {
@@ -765,10 +767,6 @@ struct ath10k {
 	const struct firmware *cal_file;
 
 	struct {
-		struct ath10k_swap_code_seg_info *firmware_swap_code_seg_info;
-	} swap;
-
-	struct {
 		u32 vendor;
 		u32 device;
 		u32 subsystem_vendor;
diff --git a/drivers/net/wireless/ath/ath10k/swap.c b/drivers/net/wireless/ath/ath10k/swap.c
index 0c5f586..adf4592 100644
--- a/drivers/net/wireless/ath/ath10k/swap.c
+++ b/drivers/net/wireless/ath/ath10k/swap.c
@@ -134,17 +134,18 @@ ath10k_swap_code_seg_alloc(struct ath10k *ar, size_t swap_bin_len)
 	return seg_info;
 }
 
-int ath10k_swap_code_seg_configure(struct ath10k *ar)
+int ath10k_swap_code_seg_configure(struct ath10k *ar,
+				   const struct ath10k_fw_file *fw_file)
 {
 	int ret;
 	struct ath10k_swap_code_seg_info *seg_info = NULL;
 
-	if (!ar->swap.firmware_swap_code_seg_info)
+	if (!fw_file->firmware_swap_code_seg_info)
 		return 0;
 
 	ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot found firmware code swap binary\n");
 
-	seg_info = ar->swap.firmware_swap_code_seg_info;
+	seg_info = fw_file->firmware_swap_code_seg_info;
 
 	ret = ath10k_bmi_write_memory(ar, seg_info->target_addr,
 				      &seg_info->seg_hw_info,
@@ -158,28 +159,29 @@ int ath10k_swap_code_seg_configure(struct ath10k *ar)
 	return 0;
 }
 
-void ath10k_swap_code_seg_release(struct ath10k *ar)
+void ath10k_swap_code_seg_release(struct ath10k *ar,
+				  struct ath10k_fw_file *fw_file)
 {
-	ath10k_swap_code_seg_free(ar, ar->swap.firmware_swap_code_seg_info);
+	ath10k_swap_code_seg_free(ar, fw_file->firmware_swap_code_seg_info);
 
 	/* FIXME: these two assignments look to bein wrong place! Shouldn't
 	 * they be in ath10k_core_free_firmware_files() like the rest?
 	 */
-	ar->normal_mode_fw.fw_file.codeswap_data = NULL;
-	ar->normal_mode_fw.fw_file.codeswap_len = 0;
+	fw_file->codeswap_data = NULL;
+	fw_file->codeswap_len = 0;
 
-	ar->swap.firmware_swap_code_seg_info = NULL;
+	fw_file->firmware_swap_code_seg_info = NULL;
 }
 
-int ath10k_swap_code_seg_init(struct ath10k *ar)
+int ath10k_swap_code_seg_init(struct ath10k *ar, struct ath10k_fw_file *fw_file)
 {
 	int ret;
 	struct ath10k_swap_code_seg_info *seg_info;
 	const void *codeswap_data;
 	size_t codeswap_len;
 
-	codeswap_data = ar->normal_mode_fw.fw_file.codeswap_data;
-	codeswap_len = ar->normal_mode_fw.fw_file.codeswap_len;
+	codeswap_data = fw_file->codeswap_data;
+	codeswap_len = fw_file->codeswap_len;
 
 	if (!codeswap_len || !codeswap_data)
 		return 0;
@@ -200,7 +202,7 @@ int ath10k_swap_code_seg_init(struct ath10k *ar)
 		return ret;
 	}
 
-	ar->swap.firmware_swap_code_seg_info = seg_info;
+	fw_file->firmware_swap_code_seg_info = seg_info;
 
 	return 0;
 }
diff --git a/drivers/net/wireless/ath/ath10k/swap.h b/drivers/net/wireless/ath/ath10k/swap.h
index 36991c7..f5dc047 100644
--- a/drivers/net/wireless/ath/ath10k/swap.h
+++ b/drivers/net/wireless/ath/ath10k/swap.h
@@ -23,6 +23,8 @@
 /* Currently only one swap segment is supported */
 #define ATH10K_SWAP_CODE_SEG_NUM_SUPPORTED	1
 
+struct ath10k_fw_file;
+
 struct ath10k_swap_code_seg_tlv {
 	__le32 address;
 	__le32 length;
@@ -58,8 +60,11 @@ struct ath10k_swap_code_seg_info {
 	dma_addr_t paddr[ATH10K_SWAP_CODE_SEG_NUM_SUPPORTED];
 };
 
-int ath10k_swap_code_seg_configure(struct ath10k *ar);
-void ath10k_swap_code_seg_release(struct ath10k *ar);
-int ath10k_swap_code_seg_init(struct ath10k *ar);
+int ath10k_swap_code_seg_configure(struct ath10k *ar,
+				   const struct ath10k_fw_file *fw_file);
+void ath10k_swap_code_seg_release(struct ath10k *ar,
+				  struct ath10k_fw_file *fw_file);
+int ath10k_swap_code_seg_init(struct ath10k *ar,
+			      struct ath10k_fw_file *fw_file);
 
 #endif
-- 
1.7.9.5



From c_traja at qti.qualcomm.com  Fri Jul  1 00:06:36 2016
From: c_traja at qti.qualcomm.com (c_traja at qti.qualcomm.com)
Date: Fri, 1 Jul 2016 12:36:36 +0530
Subject: [PATCHv3 2/3] ath10k: handle testmode events for 10.2 and 10.4 based
 firmware
Message-ID: <1467356796-31683-1-git-send-email-c_traja@qti.qualcomm.com>

From: Tamizh chelvam <c_traja at qti.qualcomm.com>

Currently testmode events for 10.x firmware are processed from
10.1 wmi event processing. This patch is used to handle testmode
events in 10.2 and 10.4 based firmware.

Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.c |   26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 12a4347..6c82a89 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5097,6 +5097,7 @@ static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, struct sk_buff *skb)
 {
 	struct wmi_cmd_hdr *cmd_hdr;
 	enum wmi_10_2_event_id id;
+	bool consumed;
 
 	cmd_hdr = (struct wmi_cmd_hdr *)skb->data;
 	id = MS(__le32_to_cpu(cmd_hdr->cmd_id), WMI_CMD_HDR_CMD_ID);
@@ -5106,6 +5107,18 @@ static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, struct sk_buff *skb)
 
 	trace_ath10k_wmi_event(ar, id, skb->data, skb->len);
 
+	consumed = ath10k_tm_event_wmi(ar, id, skb);
+
+	/* Ready event must be handled normally also in UTF mode so that we
+	 * know the UTF firmware has booted, others we are just bypass WMI
+	 * events to testmode.
+	 */
+	if (consumed && id != WMI_10_2_READY_EVENTID) {
+		ath10k_dbg(ar, ATH10K_DBG_WMI,
+			   "wmi testmode consumed 0x%x\n", id);
+		goto out;
+	}
+
 	switch (id) {
 	case WMI_10_2_MGMT_RX_EVENTID:
 		ath10k_wmi_event_mgmt_rx(ar, skb);
@@ -5221,6 +5234,7 @@ static void ath10k_wmi_10_4_op_rx(struct ath10k *ar, struct sk_buff *skb)
 {
 	struct wmi_cmd_hdr *cmd_hdr;
 	enum wmi_10_4_event_id id;
+	bool consumed;
 
 	cmd_hdr = (struct wmi_cmd_hdr *)skb->data;
 	id = MS(__le32_to_cpu(cmd_hdr->cmd_id), WMI_CMD_HDR_CMD_ID);
@@ -5230,6 +5244,18 @@ static void ath10k_wmi_10_4_op_rx(struct ath10k *ar, struct sk_buff *skb)
 
 	trace_ath10k_wmi_event(ar, id, skb->data, skb->len);
 
+	consumed = ath10k_tm_event_wmi(ar, id, skb);
+
+	/* Ready event must be handled normally also in UTF mode so that we
+	 * know the UTF firmware has booted, others we are just bypass WMI
+	 * events to testmode.
+	 */
+	if (consumed && id != WMI_10_4_READY_EVENTID) {
+		ath10k_dbg(ar, ATH10K_DBG_WMI,
+			   "wmi testmode consumed 0x%x\n", id);
+		goto out;
+	}
+
 	switch (id) {
 	case WMI_10_4_MGMT_RX_EVENTID:
 		ath10k_wmi_event_mgmt_rx(ar, skb);
-- 
1.7.9.5



From c_traja at qti.qualcomm.com  Fri Jul  1 00:07:15 2016
From: c_traja at qti.qualcomm.com (c_traja at qti.qualcomm.com)
Date: Fri, 1 Jul 2016 12:37:15 +0530
Subject: [PATCHv3 3/3] ath10k: add testmode support for 10.4 firmware
Message-ID: <1467356835-31836-1-git-send-email-c_traja@qti.qualcomm.com>

From: Tamizh chelvam <c_traja at qti.qualcomm.com>

This patch adds testmode support for 10.4 based chipsets
and added code swap support for UTF binary.

Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/testmode.c |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/testmode.c b/drivers/net/wireless/ath/ath10k/testmode.c
index 120f423..7b8e33b 100644
--- a/drivers/net/wireless/ath/ath10k/testmode.c
+++ b/drivers/net/wireless/ath/ath10k/testmode.c
@@ -23,6 +23,7 @@
 #include "wmi.h"
 #include "hif.h"
 #include "hw.h"
+#include "core.h"
 
 #include "testmode_i.h"
 
@@ -240,6 +241,18 @@ static int ath10k_tm_cmd_utf_start(struct ath10k *ar, struct nlattr *tb[])
 		goto err;
 	}
 
+	if (ar->testmode.utf_mode_fw.fw_file.codeswap_data &&
+	    ar->testmode.utf_mode_fw.fw_file.codeswap_len) {
+		ret = ath10k_swap_code_seg_init(ar,
+					&ar->testmode.utf_mode_fw.fw_file);
+		if (ret) {
+			ath10k_warn(ar,
+				"failed to init utf code swap segment: %d\n",
+				ret);
+			goto err_release_utf_mode_fw;
+		}
+	}
+
 	spin_lock_bh(&ar->data_lock);
 	ar->testmode.utf_monitor = true;
 	spin_unlock_bh(&ar->data_lock);
@@ -279,6 +292,11 @@ err_power_down:
 	ath10k_hif_power_down(ar);
 
 err_release_utf_mode_fw:
+	if (ar->testmode.utf_mode_fw.fw_file.codeswap_data &&
+	    ar->testmode.utf_mode_fw.fw_file.codeswap_len)
+		ath10k_swap_code_seg_release(ar,
+					     &ar->testmode.utf_mode_fw.fw_file);
+
 	release_firmware(ar->testmode.utf_mode_fw.fw_file.firmware);
 	ar->testmode.utf_mode_fw.fw_file.firmware = NULL;
 
@@ -301,6 +319,11 @@ static void __ath10k_tm_cmd_utf_stop(struct ath10k *ar)
 
 	spin_unlock_bh(&ar->data_lock);
 
+	if (ar->testmode.utf_mode_fw.fw_file.codeswap_data &&
+	    ar->testmode.utf_mode_fw.fw_file.codeswap_len)
+		ath10k_swap_code_seg_release(ar,
+					     &ar->testmode.utf_mode_fw.fw_file);
+
 	release_firmware(ar->testmode.utf_mode_fw.fw_file.firmware);
 	ar->testmode.utf_mode_fw.fw_file.firmware = NULL;
 
-- 
1.7.9.5



From c_traja at qti.qualcomm.com  Fri Jul  1 02:52:04 2016
From: c_traja at qti.qualcomm.com (c_traja at qti.qualcomm.com)
Date: Fri, 1 Jul 2016 15:22:04 +0530
Subject: [PATCHv3] dts: Add btcoex_support flag in device tree
Message-ID: <1467366724-32484-1-git-send-email-c_traja@qti.qualcomm.com>

From: Tamizh chelvam <tamizhchelvam at codeaurora.org>

BTCOEX feature is not available in all qca40xx chipsets.
To expose the btcoex support, this patch add btcoex_support
flag in device tree. If this value is 1 then the hardware
supports btcoex and 0 for not support.

Signed-off-by: Tamizh chelvam <tamizhchelvam at codeaurora.org>
---
v3:
  * separated from ath10k patch.

v2:
  * Used CAF address.

 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
index b9457dd..f2a2345 100644
--- a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
@@ -91,6 +91,14 @@
 			};
 		};
 
+		wifi0: wifi at a000000 {
+			btcoex_support = <0x1>;
+		}
+
+		wifi1: wifi at a800000 {
+			btcoex_support = <0x0>;
+		}
+
 		serial at 78af000 {
 			pinctrl-0 = <&serial_pins>;
 			pinctrl-names = "default";
-- 
1.7.9.5



From c_traja at qti.qualcomm.com  Fri Jul  1 02:48:04 2016
From: c_traja at qti.qualcomm.com (Raja, Tamizh Chelvam)
Date: Fri, 1 Jul 2016 09:48:04 +0000
Subject: [PATCHv3] dts: Add btcoex_support flag in device tree
In-Reply-To: <1467366724-32484-1-git-send-email-c_traja@qti.qualcomm.com>
References: <1467366724-32484-1-git-send-email-c_traja@qti.qualcomm.com>
Message-ID: <dc118e27958944b9be621f6e8d997ecc@aphydexm01f.ap.qualcomm.com>

Ignore this patch. Sorry for the noise.

-----Original Message-----
From: linux-wireless-owner at vger.kernel.org [mailto:linux-wireless-owner at vger.kernel.org] On Behalf Of c_traja at qti.qualcomm.com
Sent: Friday, July 01, 2016 3:22 PM
To: ath10k at lists.infradead.org
Cc: linux-wireless at vger.kernel.org; Tamizh chelvam <tamizhchelvam at codeaurora.org>
Subject: [PATCHv3] dts: Add btcoex_support flag in device tree

From: Tamizh chelvam <tamizhchelvam at codeaurora.org>

BTCOEX feature is not available in all qca40xx chipsets.
To expose the btcoex support, this patch add btcoex_support flag in device tree. If this value is 1 then the hardware supports btcoex and 0 for not support.

Signed-off-by: Tamizh chelvam <tamizhchelvam at codeaurora.org>
---
v3:
  * separated from ath10k patch.

v2:
  * Used CAF address.

 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
index b9457dd..f2a2345 100644
--- a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
@@ -91,6 +91,14 @@
 			};
 		};
 
+		wifi0: wifi at a000000 {
+			btcoex_support = <0x1>;
+		}
+
+		wifi1: wifi at a800000 {
+			btcoex_support = <0x0>;
+		}
+
 		serial at 78af000 {
 			pinctrl-0 = <&serial_pins>;
 			pinctrl-names = "default";
--
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo at vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html


From vthiagar at qti.qualcomm.com  Fri Jul  1 04:07:25 2016
From: vthiagar at qti.qualcomm.com (Vasanthakumar Thiagarajan)
Date: Fri, 1 Jul 2016 16:37:25 +0530
Subject: [PATCH] ath10k: Fix possible wrong rx_busy time reporting in QCA4019
Message-ID: <1467371245-5426-1-git-send-email-vthiagar@qti.qualcomm.com>

As hw cycle counters in QCA4019 wraparound independantly in QCA4019
it is possible cycle counter and rx clear counter would wraparound
at the same time. Current logic assumes only one of the counters
would wraparound at anytime. Fix this by moving 'else' part to
another 'if'.

Fixes: 8e100354a98 ("ath10k: fix cycle counter wraparound handling for QCA4019")
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/hw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/hw.c b/drivers/net/wireless/ath/ath10k/hw.c
index bd86e7a..7462627 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -198,7 +198,8 @@ void ath10k_hw_fill_survey_time(struct ath10k *ar, struct survey_info *survey,
 		case ATH10K_HW_CC_WRAP_SHIFTED_EACH:
 			if (cc < cc_prev)
 				cc_fix = 0x7fffffff;
-			else
+
+			if (rcc < rcc_prev)
 				rcc_fix = 0x7fffffff;
 			break;
 		case ATH10K_HW_CC_WRAP_DISABLED:
-- 
1.9.1



From lkp at intel.com  Sat Jul  2 00:37:33 2016
From: lkp at intel.com (kbuild test robot)
Date: Sat, 2 Jul 2016 15:37:33 +0800
Subject: [PATCHv3] dts: Add btcoex_support flag in device tree
In-Reply-To: <1467366724-32484-1-git-send-email-c_traja@qti.qualcomm.com>
Message-ID: <201607021530.U31GzXr6%fengguang.wu@intel.com>

Hi,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.7-rc5 next-20160701]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/c_traja-qti-qualcomm-com/dts-Add-btcoex_support-flag-in-device-tree/20160702-122641
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> Error: arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi:98.3-9 syntax error
   FATAL ERROR: Unable to parse input tree

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 37698 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160702/f6e942a9/attachment-0001.obj>

From lkp at intel.com  Sat Jul  2 21:59:20 2016
From: lkp at intel.com (kbuild test robot)
Date: Sun, 3 Jul 2016 12:59:20 +0800
Subject: [PATCHv3] dts: Add btcoex_support flag in device tree
In-Reply-To: <1467366724-32484-1-git-send-email-c_traja@qti.qualcomm.com>
Message-ID: <201607031203.1GldILIW%fengguang.wu@intel.com>

Hi,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.7-rc5 next-20160701]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Raja-Tamizh-Chelvam/dts-Add-btcoex_support-flag-in-device-tree/20160702-122300
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   Error: arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi:98.3-9 syntax error
>> FATAL ERROR: Unable to parse input tree

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 57589 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160703/3ffdff3c/attachment-0001.obj>

From julian.calaby at gmail.com  Sun Jul  3 17:33:07 2016
From: julian.calaby at gmail.com (Julian Calaby)
Date: Mon, 4 Jul 2016 10:33:07 +1000
Subject: [PATCH] ath10k: Fix possible wrong rx_busy time reporting in
 QCA4019
In-Reply-To: <1467371245-5426-1-git-send-email-vthiagar@qti.qualcomm.com>
References: <1467371245-5426-1-git-send-email-vthiagar@qti.qualcomm.com>
Message-ID: <CAGRGNgVHuWVf4i3MmPUKJuGQ+MmFVY-AVdVbgYbLX=uyBCu=mQ@mail.gmail.com>

Hi All,

On Fri, Jul 1, 2016 at 9:07 PM, Vasanthakumar Thiagarajan
<vthiagar at qti.qualcomm.com> wrote:
> As hw cycle counters in QCA4019 wraparound independantly in QCA4019
> it is possible cycle counter and rx clear counter would wraparound
> at the same time. Current logic assumes only one of the counters
> would wraparound at anytime. Fix this by moving 'else' part to
> another 'if'.
>
> Fixes: 8e100354a98 ("ath10k: fix cycle counter wraparound handling for QCA4019")
> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com>

Looks right to me.

Reviewed-by: Julian Calaby <julian.calaby at gmail.com>

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


From julian.calaby at gmail.com  Sun Jul  3 17:49:55 2016
From: julian.calaby at gmail.com (Julian Calaby)
Date: Mon, 4 Jul 2016 10:49:55 +1000
Subject: [PATCHv3 1/3] ath10k: move firmware_swap_code_seg_info to
 ath10k_fw_file
In-Reply-To: <1467356767-31646-1-git-send-email-c_traja@qti.qualcomm.com>
References: <1467356767-31646-1-git-send-email-c_traja@qti.qualcomm.com>
Message-ID: <CAGRGNgWd-5ef5bxOkthpfH1hjqO4HJuWuBA=jNRAr=geQDH1zA@mail.gmail.com>

Hi Tamizh,

On Fri, Jul 1, 2016 at 5:06 PM,  <c_traja at qti.qualcomm.com> wrote:
> From: Tamizh chelvam <c_traja at qti.qualcomm.com>
>
> Preparation to make use of firmware_swap_code_seg_info for UTF binary.
>
> Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>
> ---
>  drivers/net/wireless/ath/ath10k/core.c |    6 +++---
>  drivers/net/wireless/ath/ath10k/core.h |    6 ++----
>  drivers/net/wireless/ath/ath10k/swap.c |   26 ++++++++++++++------------
>  drivers/net/wireless/ath/ath10k/swap.h |   11 ++++++++---
>  4 files changed, 27 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> index 3da18c9..e69e7e7 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -654,6 +654,8 @@ struct ath10k_fw_file {
>
>         const void *codeswap_data;
>         size_t codeswap_len;
> +       /* FIXME: add a comment */
> +       struct ath10k_swap_code_seg_info *firmware_swap_code_seg_info;

Why not just add a comment? Adding FIXMEs makes the patch look incomplete to me.

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


From arnagara at codeaurora.org  Tue Jul  5 05:31:45 2016
From: arnagara at codeaurora.org (Ashok Raj Nagarajan)
Date: Tue, 05 Jul 2016 18:01:45 +0530
Subject: [PATCH 1/2] cfg80211: Add support to set tx power for a station
 associated
In-Reply-To: <1467110918.2493.9.camel@sipsolutions.net>
References: <1465926256-6463-1-git-send-email-arnagara@qti.qualcomm.com>
 <1467110918.2493.9.camel@sipsolutions.net>
Message-ID: <1cb3e2cc49b433fe5ed834a33adf64b6@codeaurora.org>

On 2016-06-28 16:18, Johannes Berg wrote:
> On Tue, 2016-06-14 at 23:14 +0530, Ashok Raj Nagarajan wrote:
>> This patch adds support to set transmit power setting type and
>> transmit power level attributes to NL80211_CMD_SET_STATION in order
>> to facilitate adjusting the transmit power level of a station
>> associated to the AP.
> 
> Why would you ever need to do that manually? Please give more
> explanation in the commit message.
> 
> We have minstrel-blues (which never made it into the code, but that's
> just because the submitter went away) doing power adjustments, so you
> need to explain why this should be necessary.
> 

Hi Johannes,

Sure.. First use case will be to help with the problem of legacy client 
devices that
roam across multiple APs. It is a classic enterprise Wi-Fi AP problem, 
often
managed by a "network controller" unit that is connected to all the APs. 
The
problem is how to handle seamless handoff of clients between multiple 
APs while
maximizing the client throughput and minimizing disruption of IP 
application
services like VoIP calls and video streaming. A legacy client will often 
hold
onto an AP association, even down to 1 Mbps as it roams away. Instead, 
if the
AP can recognise that the client RSSI (and therefore throughput) is 
poor, it
can "drop" the Tx power significantly (just to that client) such that it 
forces
the client to look for a better, closer, and therefore higher-throughput
association. It would "give it a kick" without blacklisting it. It just 
needs
to hold the power low for the small amount of time it takes to convince 
it to
go away.

Other use cases may be
         - Support a form of QoS per STA since a higher MCS rate might be
           achievable, and CW delays might be reduced
         - The optimal power can be negotiated (closed loop) or observed 
(open
           loop) for a given STA, reducing needless congestion on the 
overall channel
         - Reduce power to a STA that does not support certain radio 
features
           (e.g.  11b clients)

Thanks,
Ashok

> johannes


From greearb at candelatech.com  Tue Jul  5 08:21:01 2016
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 05 Jul 2016 08:21:01 -0700
Subject: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for
 QCA99X0 and later
In-Reply-To: <8760sr6kj8.fsf@kamboji.qca.qualcomm.com>
References: <1466700001-4883-1-git-send-email-mohammed@qca.qualcomm.com>	<1466700001-4883-2-git-send-email-mohammed@qca.qualcomm.com>	<576C1861.7020402@candelatech.com>	<20160625185350.GA25330@atheros-ThinkPad-T61>	<576F2165.3010109@candelatech.com>
 <8760sr6kj8.fsf@kamboji.qca.qualcomm.com>
Message-ID: <577BD05D.6000607@candelatech.com>

On 06/30/2016 03:25 AM, Valo, Kalle wrote:
> Ben Greear <greearb at candelatech.com> writes:
>
>> Is there a better way than posting to the ath10k mailing list?  There are quite
>> a few more of my patches that are stuck in pending or ignored state.  If you
>> could review some of them and add them to your testing trees then it might help
>> them go upstream.
>
> Yes, as you seem to test with your custom ath10k and custom firmware
> review and testing feedback from others is more than welcome. That way I
> can have more confidence that the patch really works with the mainline
> version.
>
> The problem with your patches is that you dump more responsibility on
> me. I have no idea if they work with the mainline kernel, or if they
> break something, so I need to personally test the patch and that takes
> time. Basically I have a rule if that I need to use more than two
> minutes on a patch it goes to the Deferred queue and I'll go through
> that less often than the normal patch queue.

I can do some testing with stock firmware, but stock firmware is often quite limited
so I cannot do the more interesting test cases that we use internally.
Some of my patches are for fixing edge cases that cannot be easily reproduced,
and that code really needs to be reviewed for correctness more by looking at
the code than by trying to run some exhaustive test case.

I think if there were a specific maintainer for ath10k that could take a more
active role, especially with regard to keeping a fairly wide variety of test rigs
around to run regression tests, then it would help all involved.  I think this person
needs access to firmware source so that they can more easily verify the driver
matches the firmware:  Many of the regressions and bug fixes, for instance with
stats, would be much easier to clean up if you look at firmware while developing
the driver bits.

Thanks,
Ben

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



From kvalo at qca.qualcomm.com  Thu Jul  7 09:30:48 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Thu, 7 Jul 2016 16:30:48 +0000
Subject: [PATCH] ath10k: disable wake_tx_queue for older devices
In-Reply-To: <1467201146-6844-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Wed, 29 Jun 2016 13:52:26 +0200")
References: <1463489221-24989-1-git-send-email-michal.kazior@tieto.com>
 <1467201146-6844-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87zipt1kco.fsf@kamboji.qca.qualcomm.com>

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

> Ideally wake_tx_queue should be used regardless as
> it is a requirement for reducing bufferbloat and
> implementing airtime fairness in the future.
>
> However some setups (typically low-end platforms
> hosting QCA988X) suffer performance regressions
> with the current wake_tx_queue implementation.
> Therefore disable it unless it is really
> beneficial with current codebase (which is when
> firmware supports smart pull-push tx scheduling).
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

I think it's too late to send this to 4.7 anymore (and this due to my
vacation). So I'm planning to queue this to 4.8, but if the feedback is
positive we can always send this to a 4.7 stable release.

-- 
Kalle Valo

From chaitanya.mgit at gmail.com  Thu Jul  7 11:35:46 2016
From: chaitanya.mgit at gmail.com (Krishna Chaitanya)
Date: Fri, 8 Jul 2016 00:05:46 +0530
Subject: ath10k + iw set bitrates is causing FW crash
In-Reply-To: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>
References: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>
Message-ID: <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>

On Thu, Jul 7, 2016 at 10:19 PM, Krishna Chaitanya
<chaitanya.mgit at gmail.com> wrote:
> Hi,
>
> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>
> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
> no crash is observed but it still uses MCS9.
>
> tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339
>
> 1) If i disable HW_RATE_CONTROL, will ath10k honor
> the mac80211 rates?
>
> 2) Please find below the dmesg after the crash.
>
> [ 3879.419737] ath10k_pci 0000:01:00.0: device successfully recovered
> [ 3941.919995] wlan0: deauthenticating from 74:d0:2b:41:e4:b4 by local
> choice (Reason: 3=DEAUTH_LEAVING)
> [ 3953.665725] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 3955.768675] wlan0: authenticate with 74:d0:2b:41:e4:b4
> [ 3955.768688] ieee80211_determine_chantype:306 enter..: cwid:3 vht_cwid:3
> [ 3955.776460] wlan0: send auth to 74:d0:2b:41:e4:b4 (try 1/3)
> [ 3955.777014] wlan0: authenticated
> [ 3955.781060] wlan0: associate with 74:d0:2b:41:e4:b4 (try 1/3)
> [ 3955.782124] wlan0: RX AssocResp from 74:d0:2b:41:e4:b4 (capab=0x11
> status=0 aid=2)
> [ 3955.783147] wlan0: associated
> [ 3955.783213] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [ 3959.053601] wlan0: deauthenticating from 74:d0:2b:41:e4:b4 by local
> choice (Reason: 3=DEAUTH_LEAVING)
> [ 3964.025669] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 3967.104520] wlan0: authenticate with 74:d0:2b:41:e4:b4
> [ 3967.104533] ieee80211_determine_chantype:306 enter..: cwid:3 vht_cwid:3
> [ 3967.112366] wlan0: send auth to 74:d0:2b:41:e4:b4 (try 1/3)
> [ 3967.112905] wlan0: authenticated
> [ 3967.113166] wlan0: associate with 74:d0:2b:41:e4:b4 (try 1/3)
> [ 3967.114248] wlan0: RX AssocResp from 74:d0:2b:41:e4:b4 (capab=0x11
> status=0 aid=2)
> [ 3967.115327] wlan0: associated
> [ 3967.115357] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [ 3976.110218] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> bfab5915-ae19-40b1-be67-544d909779ab)
> [ 3976.110226] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043222ff sub 0000:0000
> [ 3976.110228] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1
> tracing 1 dfs 0 testmode 0
> [ 3976.110467] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.9-2 api
> 5 features no-p2p,raw-mode crc32 b8d50af5
> [ 3976.110472] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [ 3976.110475] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
> cal otp max-sta 128 raw 0 hwcrypto 1
> [ 3976.112483] ath10k_pci 0000:01:00.0: firmware register dump:
> [ 3976.112485] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> 0x009BF931 0x00955B31
> [ 3976.112487] ath10k_pci 0000:01:00.0: [04]: 0x009BF931 0x00060530
> 0x00000010 0xFFFFFFFF
> [ 3976.112490] ath10k_pci 0000:01:00.0: [08]: 0x0044D9B8 0x0000C001
> 0x00000000 0x00000005
> [ 3976.112492] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
> 0x00957F04 0x00957F12
> [ 3976.112494] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> 0x00000000 0x00000000
> [ 3976.112496] ath10k_pci 0000:01:00.0: [20]: 0x409BF931 0x0040AA44
> 0x00420854 0x00440198
> [ 3976.112498] ath10k_pci 0000:01:00.0: [24]: 0x809BF9A1 0x0040AAA4
> 0x00789518 0xC09BF931
> [ 3976.112500] ath10k_pci 0000:01:00.0: [28]: 0x809B837F 0x0040AAC4
> 0x0044D9B8 0x000005DC
> [ 3976.112502] ath10k_pci 0000:01:00.0: [32]: 0x809B8555 0x0040AAE4
> 0x0044D9A0 0x00000100
> [ 3976.112504] ath10k_pci 0000:01:00.0: [36]: 0x809A0DF5 0x0040AB04
> 0x0043EAA8 0x0040AD14
> [ 3976.112506] ath10k_pci 0000:01:00.0: [40]: 0x809896F9 0x0040AB24
> 0x0043EAA8 0x0040AD14
> [ 3976.112508] ath10k_pci 0000:01:00.0: [44]: 0x809B5ACC 0x0040AB44
> 0x009C575C 0x0043EAA8
> [ 3976.112510] ath10k_pci 0000:01:00.0: [48]: 0x809B1C74 0x0040ADA4
> 0x00400000 0x00416DEC
> [ 3976.112512] ath10k_pci 0000:01:00.0: [52]: 0x809BFB39 0x0040ADE4
> 0x0040AE08 0x00411F80
> [ 3976.112514] ath10k_pci 0000:01:00.0: [56]: 0x809486FA 0x0040AE04
> 0x00000001 0x00000000
> [ 3976.195917] ieee80211 phy0: Hardware restart was requested
> [ 3977.561878] ath10k_pci 0000:01:00.0: device successfully recovered
> [ 8494.632109] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> 5b6f2fe0-1a2c-4485-a7d5-64705ca051a2)
> [ 8494.632116] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043222ff sub 0000:0000
> [ 8494.632119] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1
> tracing 1 dfs 0 testmode 0
> [ 8494.632357] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.9-2 api
> 5 features no-p2p,raw-mode crc32 b8d50af5
> [ 8494.632362] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [ 8494.632364] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
> cal otp max-sta 128 raw 0 hwcrypto 1
> [ 8494.634373] ath10k_pci 0000:01:00.0: firmware register dump:
> [ 8494.634376] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> 0x009BF931 0x00955B31
> [ 8494.634378] ath10k_pci 0000:01:00.0: [04]: 0x009BF931 0x00060530
> 0x00000010 0xFFFFFFFF
> [ 8494.634380] ath10k_pci 0000:01:00.0: [08]: 0x0044D9B8 0x0000C001
> 0x00000000 0x00000005
> [ 8494.634382] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
> 0x00957F04 0x00957F12
> [ 8494.634384] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> 0x00000000 0x00000000
> [ 8494.634386] ath10k_pci 0000:01:00.0: [20]: 0x409BF931 0x0040AA44
> 0x00420854 0x00440198
> [ 8494.634388] ath10k_pci 0000:01:00.0: [24]: 0x809BF9A1 0x0040AAA4
> 0x00789518 0xC09BF931
> [ 8494.634390] ath10k_pci 0000:01:00.0: [28]: 0x809B837F 0x0040AAC4
> 0x0044D9B8 0x000005DC
> [ 8494.634392] ath10k_pci 0000:01:00.0: [32]: 0x809B8555 0x0040AAE4
> 0x0044D9A0 0x00000100
> [ 8494.634394] ath10k_pci 0000:01:00.0: [36]: 0x809A0DF5 0x0040AB04
> 0x0043EAA8 0x0040AD14
> [ 8494.634396] ath10k_pci 0000:01:00.0: [40]: 0x809896F9 0x0040AB24
> 0x0043EAA8 0x0040AD14
> [ 8494.634398] ath10k_pci 0000:01:00.0: [44]: 0x809B5ACC 0x0040AB44
> 0x009C575C 0x0043EAA8
> [ 8494.634400] ath10k_pci 0000:01:00.0: [48]: 0x809B1C74 0x0040ADA4
> 0x00400000 0x00416E0C
> [ 8494.634402] ath10k_pci 0000:01:00.0: [52]: 0x809BFB39 0x0040ADE4
> 0x0040AE08 0x00411F80
> [ 8494.634404] ath10k_pci 0000:01:00.0: [56]: 0x809486FA 0x0040AE04
> 0x00000001 0x00000000
> [ 8494.724659] ieee80211 phy0: Hardware restart was requested
> [ 8496.090883] ath10k_pci 0000:01:00.0: device successfully recovered
>
>
+ath10k list.
I am using latest firmware-5.bin from linux-firmware.git.

Also i see below messages during fw loading:

ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
ath10k/pre-cal-pci-0000:01:00.0.bin failed with error -2
ath10k/cal-pci-0000:01:00.0.bin failed with error -2
ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c chip_id
0x043222ff sub 0000:0000
ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 0 testmode 0
ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.9-2 api 5 features
no-p2p,raw-mode crc32 b8d50af5
ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta
128 raw 0 hwcrypto 1


From jay0607 at gmail.com  Thu Jul  7 21:52:17 2016
From: jay0607 at gmail.com (Yu-Chieh)
Date: Fri, 8 Jul 2016 12:52:17 +0800
Subject: Does 99x0 support mesh mode?
Message-ID: <CAGJdtRASjA_+HPh1zFkoF4V=ttWcidxEwDAOU+ehbc7YhSxw7A@mail.gmail.com>

Hi,

Does anyone know if current firmware support mesh mode(802.11s) on 99x0?

Best regards,

Jay


From bskeggs at redhat.com  Thu Jul  7 22:29:05 2016
From: bskeggs at redhat.com (Ben Skeggs)
Date: Fri, 8 Jul 2016 15:29:05 +1000
Subject: AR9882 IOMMU faults
Message-ID: <4b0fdabc-ff87-c182-7db6-68bf32755407@redhat.com>

Hey,

I've just installed a COMPEX WLE600VX (AR9882) in my router machine,
operating in AP mode.

While it appears to be working well enough, I get massive floods of
IOMMU faults reported in my kernel log.  These appear to increase with
the load on the network.

I've attached both the info that ath10k reports when it detects the
device, and a sample of one of the DMAR messages (worth nothing that
it's the same fault address in all the messages).

Is this a known issue, and anything I can do to help get it resolved?

Thanks,
Ben.
-------------- next part --------------
Jul 08 14:53:08 ramiel kernel: ath10k_pci 0000:04:00.0: Direct firmware load for ath10k/cal-pci-0000:04:00.0.bin failed with error -2
Jul 08 14:53:08 ramiel kernel: ath10k_pci 0000:04:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043222ff sub 0000:0000
Jul 08 14:53:08 ramiel kernel: ath10k_pci 0000:04:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 0 testmode 0
Jul 08 14:53:08 ramiel kernel: ath10k_pci 0000:04:00.0: firmware ver 10.2.4.70.52 api 5 features no-p2p,raw-mode,mfp crc32 67c4d25c
Jul 08 14:53:08 ramiel kernel: ath10k_pci 0000:04:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
Jul 08 14:53:08 ramiel kernel: ath10k_pci 0000:04:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08

-------------- next part --------------
[ 1272.056416] DMAR: DRHD: handling fault status reg 3
[ 1272.057129] DMAR: DMAR:[DMA Write] Request device [04:00.0] fault addr ff9c0000 
               DMAR:[fault reason 05] PTE Write access is not set

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160708/a7ed9b42/attachment.sig>

From kvalo at qca.qualcomm.com  Thu Jul  7 23:37:25 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 8 Jul 2016 08:37:25 +0200
Subject: [v3] ath10k: Fix 10.4 extended peer stats update
In-Reply-To: <1464851602-12969-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <d69d17f6b281447d8a26994a0a1a2772@euamsexm01a.eu.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> 10.4 'extended peer stats' will be not be appended with normal peer stats
> data and they shall be coming in separate chunks. Fix this by maintaining
> a separate linked list 'extender peer stats' for 10.4 and update
> rx_duration for per station statistics. Also parse through beacon filter
> (if enabled), to make sure we parse the extended peer stats properly.
> This issue was exposed when more than one client is connected and
> extended peer stats for 10.4 is enabled
> 
> The order for the stats is as below
> S - standard peer stats, E- extended peer stats, B - beacon filter stats
> 
> {S1, S2, S3..} -> {B1, B2, B3..}(if available) -> {E1, E2, E3..}
> 
> Fixes: f9575793d44c ("ath10k: enable parsing per station rx duration for 10.4")
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Thanks, 1 patch applied to ath-next branch of ath.git:

4a49ae94a448 ath10k: fix 10.4 extended peer stats update

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9149357/



From kvalo at qca.qualcomm.com  Thu Jul  7 23:40:29 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 8 Jul 2016 08:40:29 +0200
Subject: [v4,1/2] ath10k: Add support for ath10k_sta_statistics support
In-Reply-To: <1465890866-2390-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <8a33ff29139b4261936f5d7a5c0d9865@euamsexm01a.eu.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> Enable support for 'drv_sta_statistics' callback.
> Export rx_duration support if available to cfg80211/nl80211
> 
> This can also act as a placeholder for any new per STA stats support
> 
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Thanks, 2 patches applied to ath-next branch of ath.git:

120a1f02a5c4 ath10k: add support for ath10k_sta_statistics support
2ba1f3709452 ath10k: remove debugfs support for Per STA total rx duration

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9175135/



From kvalo at qca.qualcomm.com  Thu Jul  7 23:43:03 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 8 Jul 2016 08:43:03 +0200
Subject: [v2,
 1/5] ath10k: Ensure txrx-compl-task is stopped when cleaning htt-tx.
In-Reply-To: <1459545132-11295-1-git-send-email-greearb@candelatech.com>
Message-ID: <6274be639a7342a7940d391ae0dac4a5@euamsexm01a.eu.qualcomm.com>

Ben Greear <greearb at candelatech.com> wrote:
> From: Ben Greear <greearb at candelatech.com>
> 
> Otherwise, the txrx-compl-task may access some bad memory?
> 
> Signed-off-by: Ben Greear <greearb at candelatech.com>

Thanks, 2 patches applied to ath-next branch of ath.git:

de0170beaa88 ath10k: ensure txrx-compl-task is stopped when cleaning htt-tx
6d68f7900d25 ath10k: ensure peer_map references are cleaned up

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/8727831/



From kvalo at qca.qualcomm.com  Thu Jul  7 23:44:28 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 8 Jul 2016 08:44:28 +0200
Subject: [1/2] ath10k: remove unused <linux/semaphore.h>
In-Reply-To: <20160621114539.15313-1-chaehyun.lim@gmail.com>
Message-ID: <71b9d76a0a914d21adf71ca7493fa637@euamsexm01a.eu.qualcomm.com>

Chaehyun Lim <chaehyun.lim at gmail.com> wrote:
> <linux/semaphore.h> is not used anymore, so just remove it.
> 
> Signed-off-by: Chaehyun Lim <chaehyun.lim at gmail.com>

Thanks, 1 patch applied to ath-next branch of ath.git:

a3dadad73324 ath10k: remove unused <linux/semaphore.h>

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9190357/



From kvalo at qca.qualcomm.com  Thu Jul  7 23:46:48 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 8 Jul 2016 08:46:48 +0200
Subject: ath10k: simplify pktlog htt event processing
In-Reply-To: <1466592761-6659-1-git-send-email-arnagara@qti.qualcomm.com>
Message-ID: <228b82f3cbc84bf7b217ef50632825cc@euamsexm01a.eu.qualcomm.com>

Ashok Raj Nagarajan <arnagara at qti.qualcomm.com> wrote:
> It is expected that all pktlog events for 10.4 firmware based solutions
> should come through CE8 where as in case of 10.2 firmware based solutions,
> it should come through one of the HTT events (HTT_T2H_MSG_TYPE_PKTLOG).
> 
> But from experiments with 10.4 based solutions, it is observed that pktlog
> event for ATH_PKTLOG_TYPE_TX_MSDU_ID is coming through HTT pktlog event.
> Currently, we always parse with 10.2 pktlog header which will lead to
> pktlog decoding issues (payload length mismatch exceptions)
> 
> For trace points, it is required to provide only the payload size. So
> fixing this by simplifying the payload size calculation without the use of
> ath10k pktlog headers.
> 
> While there, remove the unused ath10k pktlog headers.
> 
> Signed-off-by: Ashok Raj Nagarajan <arnagara at qti.qualcomm.com>

Thanks, 1 patch applied to ath-next branch of ath.git:

34293f75586b ath10k: simplify pktlog htt event processing

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9192399/



From kvalo at qca.qualcomm.com  Thu Jul  7 23:47:31 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 8 Jul 2016 08:47:31 +0200
Subject: ath10k: remove extra space on ath10k_update_channel_list
In-Reply-To: <576A93E2.9050901@riverbed.com>
Message-ID: <e6086d2660054aa997b7bdc856f3796c@euamsexm01a.eu.qualcomm.com>

Eduardo Abinader <eduardo.abinader at riverbed.com> wrote:
> just to comply to coding style.
> 
> Signed-off-by: Eduardo Abinader <eduardo.abinader at riverbed.com>
> Reviewed-by: Julian Calaby <julian.calaby at gmail.com>

Thanks, 1 patch applied to ath-next branch of ath.git:

9802977dcce5 ath10k: remove extra space on ath10k_update_channel_list

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9192945/



From kvalo at qca.qualcomm.com  Thu Jul  7 23:48:40 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 8 Jul 2016 08:48:40 +0200
Subject: [v2,3/5] ath10k: Add WARN_ON if we over-write peer-map pointer.
In-Reply-To: <1459545132-11295-3-git-send-email-greearb@candelatech.com>
Message-ID: <de2f7017a0ef446d994f1e8f6b2ed9fd@euamsexm01a.eu.qualcomm.com>

Ben Greear <greearb at candelatech.com> wrote:
> From: Ben Greear <greearb at candelatech.com>
> 
> Not sure this can happen, but seems like a reasonable sanity
> check.
> 
> Signed-off-by: Ben Greear <greearb at candelatech.com>

Thanks, 2 patches applied to ath-next branch of ath.git:

c5ace87a886d ath10k: Add WARN_ON if we over-write peer-map pointer.
d0eeafad1189 ath10k: Clean up peer when sta goes away.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/8727861/



From kvalo at qca.qualcomm.com  Thu Jul  7 23:51:10 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 8 Jul 2016 08:51:10 +0200
Subject: [1/2] ath10k: remove unused member in ath10k_hw_regs
In-Reply-To: <1466488088-20961-1-git-send-email-akolli@qti.qualcomm.com>
Message-ID: <d4ea57a3ffc1429f9e1a2df3220f54ec@euamsexm01a.eu.qualcomm.com>

akolli at qti.qualcomm.com wrote:
> From: Anilkumar Kolli <akolli at qti.qualcomm.com>
> 
> rtc_state_cold_reset_mask is unused in ath10k_hw_regs.
> instead fixed delays are used.
> 
> Signed-off-by: Anilkumar Kolli <akolli at qti.qualcomm.com>

Thanks, 2 patches applied to ath-next branch of ath.git:

2225378d840c ath10k: remove unused member in ath10k_hw_regs
e565c3125e03 ath10k: enable support for QCA9888

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9189535/



From kvalo at qca.qualcomm.com  Thu Jul  7 23:54:02 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 8 Jul 2016 08:54:02 +0200
Subject: [1/2] ath10k: Replace warning with an error message if HTT op
 version is unset
In-Reply-To: <1466700001-4883-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <f38889b09514441d82aef5559b645dc2@euamsexm01a.eu.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> Print an ath10k error message rather a call trace when HTT op version is
> not found from firmware META data (IE). This should be sufficient to figure
> out what went wrong.
> 
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

Thanks, 1 patch applied to ath-next branch of ath.git:

ce30c4fe1a22 ath10k: replace warning with an error message if HTT op version is unset

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9195581/



From kvalo at qca.qualcomm.com  Fri Jul  8 00:54:00 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Fri, 8 Jul 2016 07:54:00 +0000
Subject: [PATCHv3 3/3] ath10k: add testmode support for 10.4 firmware
In-Reply-To: <1467356835-31836-1-git-send-email-c_traja@qti.qualcomm.com> (c.
 traja's message of "Fri, 1 Jul 2016 12:37:15 +0530")
References: <1467356835-31836-1-git-send-email-c_traja@qti.qualcomm.com>
Message-ID: <87r3b41s6f.fsf@kamboji.qca.qualcomm.com>

<c_traja at qti.qualcomm.com> writes:

> From: Tamizh chelvam <c_traja at qti.qualcomm.com>
>
> This patch adds testmode support for 10.4 based chipsets
> and added code swap support for UTF binary.
>
> Signed-off-by: Tamizh chelvam <c_traja at qti.qualcomm.com>

This patch introduced new checkpatch warnings:

drivers/net/wireless/ath/ath10k/testmode.c:247: Alignment should match open parenthesis
drivers/net/wireless/ath/ath10k/testmode.c:250: Alignment should match open parenthesis

I fixed these in the pending branch.

-- 
Kalle Valo

From rmanohar at qti.qualcomm.com  Fri Jul  8 03:09:21 2016
From: rmanohar at qti.qualcomm.com (Manoharan, Rajkumar)
Date: Fri, 8 Jul 2016 10:09:21 +0000
Subject: ath10k + iw set bitrates is causing FW crash
In-Reply-To: <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>
References: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>,
 <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>
Message-ID: <1467972560885.99812@qti.qualcomm.com>

>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>>
>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
>> no crash is observed but it still uses MCS9.
>>
>> tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339
>>
>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
>> the mac80211 rates?
>>
>
Thanks for reporting the issue. Could you please try with below change?

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 5e1cc8f4c43c..cfa7e01a6103 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
                return ret;
        }

+       if (vif->type != NL80211_IFTYPE_ADHOC)
+               peer_arg.peer_reassoc = reassoc;
+
        ret = ath10k_wmi_peer_assoc(ar, &peer_arg);
        if (ret) {
                ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev %i: %d\n",


From mohammed at codeaurora.org  Fri Jul  8 04:00:53 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Fri, 8 Jul 2016 16:30:53 +0530
Subject: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for
 QCA99X0 and later
In-Reply-To: <577BD05D.6000607@candelatech.com>
References: <1466700001-4883-1-git-send-email-mohammed@qca.qualcomm.com>
 <1466700001-4883-2-git-send-email-mohammed@qca.qualcomm.com>
 <576C1861.7020402@candelatech.com>
 <20160625185350.GA25330@atheros-ThinkPad-T61>
 <576F2165.3010109@candelatech.com>
 <8760sr6kj8.fsf@kamboji.qca.qualcomm.com>
 <577BD05D.6000607@candelatech.com>
Message-ID: <20160708110053.GA19841@atheros-ThinkPad-T61>

Hi Michal / Kalle / Ben,

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


On Tue, Jul 05, 2016 at 08:21:01AM -0700, Ben Greear wrote:
> On 06/30/2016 03:25 AM, Valo, Kalle wrote:
> >Ben Greear <greearb at candelatech.com> writes:
> >
> >>Is there a better way than posting to the ath10k mailing list?  There are quite
> >>a few more of my patches that are stuck in pending or ignored state.  If you
> >>could review some of them and add them to your testing trees then it might help
> >>them go upstream.
> >
> >Yes, as you seem to test with your custom ath10k and custom firmware
> >review and testing feedback from others is more than welcome. That way I
> >can have more confidence that the patch really works with the mainline
> >version.
> >
> >The problem with your patches is that you dump more responsibility on
> >me. I have no idea if they work with the mainline kernel, or if they
> >break something, so I need to personally test the patch and that takes
> >time. Basically I have a rule if that I need to use more than two
> >minutes on a patch it goes to the Deferred queue and I'll go through
> >that less often than the normal patch queue.
> 
> I can do some testing with stock firmware, but stock firmware is often quite limited
> so I cannot do the more interesting test cases that we use internally.
> Some of my patches are for fixing edge cases that cannot be easily reproduced,
> and that code really needs to be reviewed for correctness more by looking at
> the code than by trying to run some exhaustive test case.
> 
> I think if there were a specific maintainer for ath10k that could take a more
> active role, especially with regard to keeping a fairly wide variety of test rigs
> around to run regression tests, then it would help all involved.  I think this person
> needs access to firmware source so that they can more easily verify the driver
> matches the firmware:  Many of the regressions and bug fixes, for instance with
> stats, would be much easier to clean up if you look at firmware while developing
> the driver bits.
>

regards,
shafi


From chaitanya.mgit at gmail.com  Fri Jul  8 04:56:15 2016
From: chaitanya.mgit at gmail.com (Krishna Chaitanya)
Date: Fri, 8 Jul 2016 17:26:15 +0530
Subject: ath10k + iw set bitrates is causing FW crash
In-Reply-To: <1467972560885.99812@qti.qualcomm.com>
References: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>
 <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>
 <1467972560885.99812@qti.qualcomm.com>
Message-ID: <CABPxzY+8Y-FHUFALGueN1hQwgjJHNpeyy_BRkrM4osguxJZS0Q@mail.gmail.com>

On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
<rmanohar at qti.qualcomm.com> wrote:
>>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
>>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>>>
>>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
>>> no crash is observed but it still uses MCS9.
>>>
>>> tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339
>>>
>>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
>>> the mac80211 rates?
>>>
>>
> Thanks for reporting the issue. Could you please try with below change?
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index 5e1cc8f4c43c..cfa7e01a6103 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
>                 return ret;
>         }
>
> +       if (vif->type != NL80211_IFTYPE_ADHOC)
> +               peer_arg.peer_reassoc = reassoc;
> +
>         ret = ath10k_wmi_peer_assoc(ar, &peer_arg);
>         if (ret) {
>                 ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev %i: %d\n",

Thanks Raj, with this fix the rates are 0-7, if i disable then i am
seeing 0-9, so its
working.

But i am seeing a weird issues, the moment i give bitrates command,
ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
interface up/down
it doesn't work.


From rmanohar at qti.qualcomm.com  Fri Jul  8 05:59:26 2016
From: rmanohar at qti.qualcomm.com (Manoharan, Rajkumar)
Date: Fri, 8 Jul 2016 12:59:26 +0000
Subject: ath10k + iw set bitrates is causing FW crash
In-Reply-To: <CABPxzY+8Y-FHUFALGueN1hQwgjJHNpeyy_BRkrM4osguxJZS0Q@mail.gmail.com>
References: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>
 <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>
 <1467972560885.99812@qti.qualcomm.com>,
 <CABPxzY+8Y-FHUFALGueN1hQwgjJHNpeyy_BRkrM4osguxJZS0Q@mail.gmail.com>
Message-ID: <1467982766213.21223@qti.qualcomm.com>

I think security failures are due to peer unmap & map upon reassoc. Can you please try below change?

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 5e1cc8f4c43c..f7f04bb46fc8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5745,8 +5745,9 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
                                    sta->addr, smps, err);
        }

-       if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
-           changed & IEEE80211_RC_NSS_CHANGED) {
+       if ((changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
+           changed & IEEE80211_RC_NSS_CHANGED) &&
+           (arvif->vif->type == NL80211_IFTYPE_ADHOC)) {
                ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp rates/nss\n",
                           sta->addr);

-Rajkumar
________________________________________
From: Krishna Chaitanya <chaitanya.mgit at gmail.com>
Sent: Friday, July 8, 2016 5:26 PM
To: Manoharan, Rajkumar
Cc: linux-wireless; ath10k
Subject: Re: ath10k + iw set bitrates is causing FW crash

On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
<rmanohar at qti.qualcomm.com> wrote:
>>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
>>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>>>
>>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
>>> no crash is observed but it still uses MCS9.
>>>
>>> tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339
>>>
>>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
>>> the mac80211 rates?
>>>
>>
> Thanks for reporting the issue. Could you please try with below change?
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index 5e1cc8f4c43c..cfa7e01a6103 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
>                 return ret;
>         }
>
> +       if (vif->type != NL80211_IFTYPE_ADHOC)
> +               peer_arg.peer_reassoc = reassoc;
> +
>         ret = ath10k_wmi_peer_assoc(ar, &peer_arg);
>         if (ret) {
>                 ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev %i: %d\n",

Thanks Raj, with this fix the rates are 0-7, if i disable then i am
seeing 0-9, so its
working.

But i am seeing a weird issues, the moment i give bitrates command,
ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
interface up/down
it doesn't work.


From rmanohar at qti.qualcomm.com  Fri Jul  8 06:09:48 2016
From: rmanohar at qti.qualcomm.com (Manoharan, Rajkumar)
Date: Fri, 8 Jul 2016 13:09:48 +0000
Subject: AR9882 IOMMU faults
In-Reply-To: <4b0fdabc-ff87-c182-7db6-68bf32755407@redhat.com>
References: <4b0fdabc-ff87-c182-7db6-68bf32755407@redhat.com>
Message-ID: <1467983388208.13042@qti.qualcomm.com>

Logs are so limited. If possible, revert below commit and give a try

"ath10k: do not use coherent memory for allocated device memory chunks"

If revert is not so clean, try with this patch.

https://patchwork.kernel.org/patch/9175029/

-Rajkumar
________________________________________
From: ath10k <ath10k-bounces at lists.infradead.org> on behalf of Ben Skeggs <bskeggs at redhat.com>
Sent: Friday, July 8, 2016 10:59 AM
To: ath10k at lists.infradead.org
Subject: AR9882 IOMMU faults

Hey,

I've just installed a COMPEX WLE600VX (AR9882) in my router machine,
operating in AP mode.

While it appears to be working well enough, I get massive floods of
IOMMU faults reported in my kernel log.  These appear to increase with
the load on the network.

I've attached both the info that ath10k reports when it detects the
device, and a sample of one of the DMAR messages (worth nothing that
it's the same fault address in all the messages).

Is this a known issue, and anything I can do to help get it resolved?

Thanks,
Ben.


From greearb at candelatech.com  Fri Jul  8 06:57:47 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 08 Jul 2016 06:57:47 -0700
Subject: AR9882 IOMMU faults
In-Reply-To: <1467983388208.13042@qti.qualcomm.com>
References: <4b0fdabc-ff87-c182-7db6-68bf32755407@redhat.com>
 <1467983388208.13042@qti.qualcomm.com>
Message-ID: <577FB15B.3050907@candelatech.com>



On 07/08/2016 06:09 AM, Manoharan, Rajkumar wrote:
> Logs are so limited. If possible, revert below commit and give a try
>
> "ath10k: do not use coherent memory for allocated device memory chunks"
>
> If revert is not so clean, try with this patch.
>
> https://patchwork.kernel.org/patch/9175029/

I use this patch, I don't think it is upstream, and per comment, I have not
tested this on other than x86 platform:

[greearb at ben-dt ath10k]$ git show 0e6e6f6b2
commit 0e6e6f6b2fac0ade990de56eef3841dbe7128f35
Author: Ben Greear <greearb at candelatech.com>
Date:   Thu Jan 21 18:57:11 2016 -0800

     ath10k:  wmi-alloc-chunk should use DMA_BIDIRECTIONAL.

     These memory chunks are often used as 'swap' by the NIC,
     so it will be both reading and writing to these areas.

     This seems to fix errors like this on my x86-64 machine:

     kernel: DMAR: DMAR:[DMA Write] Request device [05:00.0] fault addr ff5de000
             DMAR:[fault reason 05] PTE Write access is not set

     Should be tested and verified by someone who uses other platforms
     though...

     Signed-off-by: Ben Greear <greearb at candelatech.com>

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index af37a77..502f0e0 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -4404,7 +4404,7 @@ static int ath10k_wmi_alloc_chunk(struct ath10k *ar, u32 req_id,
         if (!num_units)
                 return -ENOMEM;

-       paddr = dma_map_single(ar->dev, vaddr, pool_size, DMA_TO_DEVICE);
+       paddr = dma_map_single(ar->dev, vaddr, pool_size, DMA_BIDIRECTIONAL);
         if (dma_mapping_error(ar->dev, paddr)) {
                 kfree(vaddr);
                 return -ENOMEM;
[greearb at ben-dt ath10k]$

>
> -Rajkumar
> ________________________________________
> From: ath10k <ath10k-bounces at lists.infradead.org> on behalf of Ben Skeggs <bskeggs at redhat.com>
> Sent: Friday, July 8, 2016 10:59 AM
> To: ath10k at lists.infradead.org
> Subject: AR9882 IOMMU faults
>
> Hey,
>
> I've just installed a COMPEX WLE600VX (AR9882) in my router machine,
> operating in AP mode.
>
> While it appears to be working well enough, I get massive floods of
> IOMMU faults reported in my kernel log.  These appear to increase with
> the load on the network.
>
> I've attached both the info that ath10k reports when it detects the
> device, and a sample of one of the DMAR messages (worth nothing that
> it's the same fault address in all the messages).
>
> Is this a known issue, and anything I can do to help get it resolved?
>
> Thanks,
> Ben.
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>

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


From kvalo at qca.qualcomm.com  Fri Jul  8 07:06:25 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 8 Jul 2016 16:06:25 +0200
Subject: ath10k: Fix possible wrong rx_busy time reporting in QCA4019
In-Reply-To: <1467371245-5426-1-git-send-email-vthiagar@qti.qualcomm.com>
Message-ID: <daa5435e9e124d1e8f2e0d05b1543c18@euamsexm01a.eu.qualcomm.com>

Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com> wrote:
> As hw cycle counters in QCA4019 wraparound independantly in QCA4019
> it is possible cycle counter and rx clear counter would wraparound
> at the same time. Current logic assumes only one of the counters
> would wraparound at anytime. Fix this by moving 'else' part to
> another 'if'.
> 
> Fixes: 8e100354a98 ("ath10k: fix cycle counter wraparound handling for QCA4019")
> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com>
> Reviewed-by: Julian Calaby <julian.calaby at gmail.com>

Thanks, 1 patch applied to ath-next branch of ath.git:

c11e99396d0f ath10k: fix possible wrong rx_busy time reporting in QCA4019

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9209723/



From kvalo at qca.qualcomm.com  Fri Jul  8 07:29:53 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 8 Jul 2016 16:29:53 +0200
Subject: ath10k: implement NAPI support
In-Reply-To: <20160627055128.7005-1-rmanohar@qti.qualcomm.com>
Message-ID: <6169ec35e7d9438180c60909a96390ae@euamsexm01a.eu.qualcomm.com>

Rajkumar Manoharan <rmanohar at qti.qualcomm.com> wrote:
> Add NAPI support for rx and tx completion. NAPI poll is scheduled
> from interrupt handler. The design is as below
> 
>  - on interrupt
>      - schedule napi and mask interrupts
>  - on poll
>    - process all pipes (no actual Tx/Rx)
>    - process Rx within budget
>    - if quota exceeds budget reschedule napi poll by returning budget
>    - process Tx completions and update budget if necessary
>    - process Tx fetch indications (pull-push)
>    - push any other pending Tx (if possible)
>    - before resched or napi completion replenish htt rx ring buffer
>    - if work done < budget, complete napi poll and unmask interrupts
> 
> This change also get rid of two tasklets (intr_tq and txrx_compl_task).
> 
> Measured peak throughput with NAPI on IPQ4019 platform in controlled
> environment. No noticeable reduction in throughput is seen and also
> observed improvements in CPU usage. Approx. 15% CPU usage got reduced
> in UDP uplink case.
> 
> DL: AP DUT Tx
> UL: AP DUT Rx
> 
> IPQ4019 (avg. cpu usage %)
> 
> ========
>                 TOT              +NAPI
>               ===========      =============
> TCP DL       644 Mbps (42%)    645 Mbps (36%)
> TCP UL       673 Mbps (30%)    675 Mbps (26%)
> UDP DL       682 Mbps (49%)    680 Mbps (49%)
> UDP UL       720 Mbps (28%)    717 Mbps (11%)
> 
> Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>

This is quite big change and I'm planning to queue this for 4.9. So I'm not
applying this quite yet.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9199911/



From mjkeeler7 at gmail.com  Fri Jul  8 07:40:04 2016
From: mjkeeler7 at gmail.com (Matthew Keeler)
Date: Fri, 8 Jul 2016 07:40:04 -0700
Subject: Wireless card no 5GHz IR
Message-ID: <CAC643aaa38i7o-RANc=h-_=4Q+EZYSvtv6fBynu1HYkn-xfY3A@mail.gmail.com>

I am having a bit of trouble with a QCA9880 based nic that was
previously working. At some point I did updates to my system and 5 GHz
no longer works (although it did for a week or so after the updates).

iw reg get output shows correct regulatory information:

global
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 17), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)

phy#0
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 17), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)


dmesg output while the device is coming up looks normal too (with
EEPROM getting the correct country code):

[ ? ?5.487506] ath10k_pci 0000:02:00.0: pci irq msi interrupts 1
irq_mode 0 reset_mode 0
[ ? ?5.856133] ath10k_pci 0000:02:00.0: Direct firmware load for
ath10k/cal-pci-0000:02:00.0.bin failed with error -2
[ ? ?5.867829] ath10k_pci 0000:02:00.0: qca988x hw2.0 target
0x4100016c chip_id 0x043202ff sub 0000:0000
[ ? ?5.867838] ath10k_pci 0000:02:00.0: kconfig debug 0 debugfs 1
tracing 0 dfs 0 testmode 0
[ ? ?5.868177] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.9-2 api
5 features no-p2p,raw-mode crc32 b8d50af5
[ ? ?5.908305] ath10k_pci 0000:02:00.0: Direct firmware load for
ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
[ ? ?5.908406] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A
crc32 bebc7c08
[ ? ?7.068008] ath10k_pci 0000:02:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
cal otp max-sta 128 raw 0 hwcrypto 1
[ ? ?7.129607] ath: EEPROM regdomain: 0x0
[ ? ?7.129614] ath: EEPROM indicates default country code should be used
[ ? ?7.129617] ath: doing EEPROM country->regdmn map search
[ ? ?7.129620] ath: country maps to regdmn code: 0x3a
[ ? ?7.129623] ath: Country alpha2 being used: US
[ ? ?7.129625] ath: Regpair used: 0x3a
[ ? ?7.141197] ath10k_pci 0000:02:00.0 wlan2: renamed from wlan0

However after this iw phy ph0 info show this for the 5 GHz frequencies:

Frequencies:
	* 5180 MHz [36] (17.0 dBm) (no IR)
	* 5200 MHz [40] (17.0 dBm) (no IR)
	* 5220 MHz [44] (17.0 dBm) (no IR)
	* 5240 MHz [48] (17.0 dBm) (no IR)
	* 5260 MHz [52] (23.0 dBm) (no IR, radar detection)
	 ?DFS state: usable (for 2898 sec)
	 ?DFS CAC time: 60000 ms
	* 5280 MHz [56] (23.0 dBm) (no IR, radar detection)
	 ?DFS state: usable (for 2898 sec)
	 ?DFS CAC time: 60000 ms
	* 5300 MHz [60] (23.0 dBm) (no IR, radar detection)
	 ?DFS state: usable (for 2898 sec)
	 ?DFS CAC time: 60000 ms
	* 5320 MHz [64] (23.0 dBm) (no IR, radar detection)
	 ?DFS state: usable (for 2898 sec)
	 ?DFS CAC time: 60000 ms
	* 5500 MHz [100] (disabled)
	* 5520 MHz [104] (disabled)
	* 5540 MHz [108] (disabled)
	* 5560 MHz [112] (disabled)
	* 5580 MHz [116] (disabled)
	* 5600 MHz [120] (disabled)
	* 5620 MHz [124] (disabled)
	* 5640 MHz [128] (disabled)
	* 5660 MHz [132] (disabled)
	* 5680 MHz [136] (disabled)
	* 5700 MHz [140] (disabled)
	* 5720 MHz [144] (23.0 dBm) (no IR, radar detection)
	 ?DFS state: usable (for 2898 sec)
	 ?DFS CAC time: 60000 ms
	* 5745 MHz [149] (30.0 dBm) (no IR)
	* 5765 MHz [153] (30.0 dBm) (no IR)
	* 5785 MHz [157] (30.0 dBm) (no IR)
	* 5805 MHz [161] (30.0 dBm) (no IR)
	* 5825 MHz [165] (30.0 dBm) (no IR)

And if I try to run hostapd using any 5GHz channel it fails.

This used to work. Has anyone else experienced something similar or
could there be a mismatch between firmware versions and kernel
versions? I did try using the lastest firmware 10.2.4.70.52 but this
one complained of pcie errors or AER driver support problems and shut
the card down during boot so I reverted back to the system default.

Relevant system information:
? ? Distro: ? ? ? ? ? ? ? ? ? Arch Linux
? ? kernel version: ? ? ? ? ? 4.6.3-1
? ? firmware package version:?20160516.80d463b-1
? ? ath10k firmware version: ?10.2.4.70.9-2
? ? iw version: ? ? ? ? ? ? ? 4.7.1
? ? crda version: ? ? ? ? ? ? 3.18-1
? ? hostapd version: ? ? ? ? ?2.5-2


?
Matt Keeler


From chaitanya.mgit at gmail.com  Fri Jul  8 08:27:23 2016
From: chaitanya.mgit at gmail.com (Krishna Chaitanya)
Date: Fri, 8 Jul 2016 20:57:23 +0530
Subject: ath10k + iw set bitrates is causing FW crash
In-Reply-To: <1467982766213.21223@qti.qualcomm.com>
References: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>
 <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>
 <1467972560885.99812@qti.qualcomm.com>
 <CABPxzY+8Y-FHUFALGueN1hQwgjJHNpeyy_BRkrM4osguxJZS0Q@mail.gmail.com>
 <1467982766213.21223@qti.qualcomm.com>
Message-ID: <CABPxzYLO8rzvOJ_1iqng89kYFS-xqC3qstbgETVRJHDpO4rikQ@mail.gmail.com>

On Fri, Jul 8, 2016 at 6:29 PM, Manoharan, Rajkumar
<rmanohar at qti.qualcomm.com> wrote:
> I think security failures are due to peer unmap & map upon reassoc. Can you please try below change?
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index 5e1cc8f4c43c..f7f04bb46fc8 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -5745,8 +5745,9 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
>                                     sta->addr, smps, err);
>         }
>
> -       if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
> -           changed & IEEE80211_RC_NSS_CHANGED) {
> +       if ((changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
> +           changed & IEEE80211_RC_NSS_CHANGED) &&
> +           (arvif->vif->type == NL80211_IFTYPE_ADHOC)) {
>                 ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp rates/nss\n",
>                            sta->addr);

Bottom posting please. I have tried your change i still see the same issue.
Right after connecting i see that packets are encrypted but once it
unset/set "bitrates" plain packets are seen in sniffer.

BTW, i am not rebooting for each driver update, just re-inserting the module,
do i need to do a reboot for each driver change?
 ________________________________________
> From: Krishna Chaitanya <chaitanya.mgit at gmail.com>
> Sent: Friday, July 8, 2016 5:26 PM
> To: Manoharan, Rajkumar
> Cc: linux-wireless; ath10k
> Subject: Re: ath10k + iw set bitrates is causing FW crash
>
> On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
> <rmanohar at qti.qualcomm.com> wrote:
>>>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
>>>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>>>>
>>>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
>>>> no crash is observed but it still uses MCS9.
>>>>
>>>> tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339
>>>>
>>>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
>>>> the mac80211 rates?
>>>>
>>>
>> Thanks for reporting the issue. Could you please try with below change?
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>> index 5e1cc8f4c43c..cfa7e01a6103 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
>>                 return ret;
>>         }
>>
>> +       if (vif->type != NL80211_IFTYPE_ADHOC)
>> +               peer_arg.peer_reassoc = reassoc;
>> +
>>         ret = ath10k_wmi_peer_assoc(ar, &peer_arg);
>>         if (ret) {
>>                 ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev %i: %d\n",
>
> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
> seeing 0-9, so its
> working.
>
> But i am seeing a weird issues, the moment i give bitrates command,
> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
> interface up/down
> it doesn't work.


From chaitanya.mgit at gmail.com  Fri Jul  8 08:37:40 2016
From: chaitanya.mgit at gmail.com (Krishna Chaitanya)
Date: Fri, 8 Jul 2016 21:07:40 +0530
Subject: ath10k + iw set bitrates is causing FW crash
In-Reply-To: <CABPxzYLO8rzvOJ_1iqng89kYFS-xqC3qstbgETVRJHDpO4rikQ@mail.gmail.com>
References: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>
 <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>
 <1467972560885.99812@qti.qualcomm.com>
 <CABPxzY+8Y-FHUFALGueN1hQwgjJHNpeyy_BRkrM4osguxJZS0Q@mail.gmail.com>
 <1467982766213.21223@qti.qualcomm.com>
 <CABPxzYLO8rzvOJ_1iqng89kYFS-xqC3qstbgETVRJHDpO4rikQ@mail.gmail.com>
Message-ID: <CABPxzYJPi4CqO+KUFA7=r=zpq_c2vFtrgBQ+nF_nThO-cYrteg@mail.gmail.com>

On Fri, Jul 8, 2016 at 8:57 PM, Krishna Chaitanya
<chaitanya.mgit at gmail.com> wrote:
> On Fri, Jul 8, 2016 at 6:29 PM, Manoharan, Rajkumar
> <rmanohar at qti.qualcomm.com> wrote:
>> I think security failures are due to peer unmap & map upon reassoc. Can you please try below change?
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>> index 5e1cc8f4c43c..f7f04bb46fc8 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -5745,8 +5745,9 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
>>                                     sta->addr, smps, err);
>>         }
>>
>> -       if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
>> -           changed & IEEE80211_RC_NSS_CHANGED) {
>> +       if ((changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
>> +           changed & IEEE80211_RC_NSS_CHANGED) &&
>> +           (arvif->vif->type == NL80211_IFTYPE_ADHOC)) {
>>                 ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp rates/nss\n",
>>                            sta->addr);
>
> Bottom posting please. I have tried your change i still see the same issue.
> Right after connecting i see that packets are encrypted but once it
> unset/set "bitrates" plain packets are seen in sniffer.
>
> BTW, i am not rebooting for each driver update, just re-inserting the module,
> do i need to do a reboot for each driver change?

After reboot i dont see the "unencrypted" packet issue, i will do
some more testing on limiting the rates, currently in my setup its
not reaching MCS9 so cannot verify now.

Thanks for the fixes and prompt reply.
  ________________________________________
>> From: Krishna Chaitanya <chaitanya.mgit at gmail.com>
>> Sent: Friday, July 8, 2016 5:26 PM
>> To: Manoharan, Rajkumar
>> Cc: linux-wireless; ath10k
>> Subject: Re: ath10k + iw set bitrates is causing FW crash
>>
>> On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
>> <rmanohar at qti.qualcomm.com> wrote:
>>>>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
>>>>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>>>>>
>>>>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
>>>>> no crash is observed but it still uses MCS9.
>>>>>
>>>>> tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339
>>>>>
>>>>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
>>>>> the mac80211 rates?
>>>>>
>>>>
>>> Thanks for reporting the issue. Could you please try with below change?
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>>> index 5e1cc8f4c43c..cfa7e01a6103 100644
>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
>>>                 return ret;
>>>         }
>>>
>>> +       if (vif->type != NL80211_IFTYPE_ADHOC)
>>> +               peer_arg.peer_reassoc = reassoc;
>>> +
>>>         ret = ath10k_wmi_peer_assoc(ar, &peer_arg);
>>>         if (ret) {
>>>                 ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev %i: %d\n",
>>
>> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
>> seeing 0-9, so its
>> working.
>>
>> But i am seeing a weird issues, the moment i give bitrates command,
>> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
>> interface up/down
>> it doesn't work.


From chaitanya.mgit at gmail.com  Fri Jul  8 08:39:40 2016
From: chaitanya.mgit at gmail.com (Krishna Chaitanya)
Date: Fri, 8 Jul 2016 21:09:40 +0530
Subject: ath10k + iw set bitrates is causing FW crash
In-Reply-To: <CABPxzYJPi4CqO+KUFA7=r=zpq_c2vFtrgBQ+nF_nThO-cYrteg@mail.gmail.com>
References: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>
 <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>
 <1467972560885.99812@qti.qualcomm.com>
 <CABPxzY+8Y-FHUFALGueN1hQwgjJHNpeyy_BRkrM4osguxJZS0Q@mail.gmail.com>
 <1467982766213.21223@qti.qualcomm.com>
 <CABPxzYLO8rzvOJ_1iqng89kYFS-xqC3qstbgETVRJHDpO4rikQ@mail.gmail.com>
 <CABPxzYJPi4CqO+KUFA7=r=zpq_c2vFtrgBQ+nF_nThO-cYrteg@mail.gmail.com>
Message-ID: <CABPxzYKOqBmrjRwAyZV9daV8adEhUV71XEAsfrLhtTnKwWzuaw@mail.gmail.com>

On Fri, Jul 8, 2016 at 9:07 PM, Krishna Chaitanya
<chaitanya.mgit at gmail.com> wrote:
> On Fri, Jul 8, 2016 at 8:57 PM, Krishna Chaitanya
> <chaitanya.mgit at gmail.com> wrote:
>> On Fri, Jul 8, 2016 at 6:29 PM, Manoharan, Rajkumar
>> <rmanohar at qti.qualcomm.com> wrote:
>>> I think security failures are due to peer unmap & map upon reassoc. Can you please try below change?
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>>> index 5e1cc8f4c43c..f7f04bb46fc8 100644
>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>> @@ -5745,8 +5745,9 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
>>>                                     sta->addr, smps, err);
>>>         }
>>>
>>> -       if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
>>> -           changed & IEEE80211_RC_NSS_CHANGED) {
>>> +       if ((changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
>>> +           changed & IEEE80211_RC_NSS_CHANGED) &&
>>> +           (arvif->vif->type == NL80211_IFTYPE_ADHOC)) {
>>>                 ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp rates/nss\n",
>>>                            sta->addr);
>>
>> Bottom posting please. I have tried your change i still see the same issue.
>> Right after connecting i see that packets are encrypted but once it
>> unset/set "bitrates" plain packets are seen in sniffer.
>>
>> BTW, i am not rebooting for each driver update, just re-inserting the module,
>> do i need to do a reboot for each driver change?
>
> After reboot i dont see the "unencrypted" packet issue, i will do
> some more testing on limiting the rates, currently in my setup its
> not reaching MCS9 so cannot verify now.
>
> Thanks for the fixes and prompt reply.
>   ________________________________________
>>> From: Krishna Chaitanya <chaitanya.mgit at gmail.com>
>>> Sent: Friday, July 8, 2016 5:26 PM
>>> To: Manoharan, Rajkumar
>>> Cc: linux-wireless; ath10k
>>> Subject: Re: ath10k + iw set bitrates is causing FW crash
>>>
>>> On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
>>> <rmanohar at qti.qualcomm.com> wrote:
>>>>>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
>>>>>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
>>>>>>
>>>>>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
>>>>>> no crash is observed but it still uses MCS9.
>>>>>>
>>>>>> tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339
>>>>>>
>>>>>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
>>>>>> the mac80211 rates?
>>>>>>
>>>>>
>>>> Thanks for reporting the issue. Could you please try with below change?
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>>>> index 5e1cc8f4c43c..cfa7e01a6103 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>>> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
>>>>                 return ret;
>>>>         }
>>>>
>>>> +       if (vif->type != NL80211_IFTYPE_ADHOC)
>>>> +               peer_arg.peer_reassoc = reassoc;
>>>> +
>>>>         ret = ath10k_wmi_peer_assoc(ar, &peer_arg);
>>>>         if (ret) {
>>>>                 ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev %i: %d\n",
>>>
>>> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
>>> seeing 0-9, so its
>>> working.
>>>
>>> But i am seeing a weird issues, the moment i give bitrates command,
>>> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
>>> interface up/down
>>> it doesn't work.

Also can you please tell me how to make ath10k use minstrel rc, its needed
for comparative purposes? Is disable HW_RATE_CONTROL enough or does
it need more changes?


From greearb at candelatech.com  Fri Jul  8 08:42:08 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 8 Jul 2016 08:42:08 -0700
Subject: ath10k + iw set bitrates is causing FW crash
In-Reply-To: <CABPxzYKOqBmrjRwAyZV9daV8adEhUV71XEAsfrLhtTnKwWzuaw@mail.gmail.com>
References: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>
 <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>
 <1467972560885.99812@qti.qualcomm.com>
 <CABPxzY+8Y-FHUFALGueN1hQwgjJHNpeyy_BRkrM4osguxJZS0Q@mail.gmail.com>
 <1467982766213.21223@qti.qualcomm.com>
 <CABPxzYLO8rzvOJ_1iqng89kYFS-xqC3qstbgETVRJHDpO4rikQ@mail.gmail.com>
 <CABPxzYJPi4CqO+KUFA7=r=zpq_c2vFtrgBQ+nF_nThO-cYrteg@mail.gmail.com>
 <CABPxzYKOqBmrjRwAyZV9daV8adEhUV71XEAsfrLhtTnKwWzuaw@mail.gmail.com>
Message-ID: <577FC9D0.2010809@candelatech.com>

On 07/08/2016 08:39 AM, Krishna Chaitanya wrote:

> Also can you please tell me how to make ath10k use minstrel rc, its needed
> for comparative purposes? Is disable HW_RATE_CONTROL enough or does
> it need more changes?

It cannot be done.  You have to use whatever rate-ctrl is baked into the
firmware.

Thanks,
Ben

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



From chaitanya.mgit at gmail.com  Fri Jul  8 08:44:48 2016
From: chaitanya.mgit at gmail.com (Krishna Chaitanya)
Date: Fri, 8 Jul 2016 21:14:48 +0530
Subject: ath10k + iw set bitrates is causing FW crash
In-Reply-To: <577FC9D0.2010809@candelatech.com>
References: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>
 <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>
 <1467972560885.99812@qti.qualcomm.com>
 <CABPxzY+8Y-FHUFALGueN1hQwgjJHNpeyy_BRkrM4osguxJZS0Q@mail.gmail.com>
 <1467982766213.21223@qti.qualcomm.com>
 <CABPxzYLO8rzvOJ_1iqng89kYFS-xqC3qstbgETVRJHDpO4rikQ@mail.gmail.com>
 <CABPxzYJPi4CqO+KUFA7=r=zpq_c2vFtrgBQ+nF_nThO-cYrteg@mail.gmail.com>
 <CABPxzYKOqBmrjRwAyZV9daV8adEhUV71XEAsfrLhtTnKwWzuaw@mail.gmail.com>
 <577FC9D0.2010809@candelatech.com>
Message-ID: <CABPxzYLdS-QicOj9AdcubT8uxgw0cqXpzerpuwGcwkSQ7PCiOA@mail.gmail.com>

On Fri, Jul 8, 2016 at 9:12 PM, Ben Greear <greearb at candelatech.com> wrote:
> On 07/08/2016 08:39 AM, Krishna Chaitanya wrote:
>
>> Also can you please tell me how to make ath10k use minstrel rc, its needed
>> for comparative purposes? Is disable HW_RATE_CONTROL enough or does
>> it need more changes?
>
>
> It cannot be done.  You have to use whatever rate-ctrl is baked into the
> firmware.
Ok, its a good feature to have.


From chaitanya.mgit at gmail.com  Fri Jul  8 08:49:37 2016
From: chaitanya.mgit at gmail.com (Krishna Chaitanya)
Date: Fri, 8 Jul 2016 21:19:37 +0530
Subject: ath10k + iw set bitrates is causing FW crash
In-Reply-To: <577FCB04.4030905@candelatech.com>
References: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>
 <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>
 <1467972560885.99812@qti.qualcomm.com>
 <CABPxzY+8Y-FHUFALGueN1hQwgjJHNpeyy_BRkrM4osguxJZS0Q@mail.gmail.com>
 <1467982766213.21223@qti.qualcomm.com>
 <CABPxzYLO8rzvOJ_1iqng89kYFS-xqC3qstbgETVRJHDpO4rikQ@mail.gmail.com>
 <CABPxzYJPi4CqO+KUFA7=r=zpq_c2vFtrgBQ+nF_nThO-cYrteg@mail.gmail.com>
 <CABPxzYKOqBmrjRwAyZV9daV8adEhUV71XEAsfrLhtTnKwWzuaw@mail.gmail.com>
 <577FC9D0.2010809@candelatech.com>
 <CABPxzYLdS-QicOj9AdcubT8uxgw0cqXpzerpuwGcwkSQ7PCiOA@mail.gmail.com>
 <577FCB04.4030905@candelatech.com>
Message-ID: <CABPxzYLTg5Y0-m6YNemXAd75s3_6uBCCecbsoJG09jM=vqKTFw@mail.gmail.com>

On Fri, Jul 8, 2016 at 9:17 PM, Ben Greear <greearb at candelatech.com> wrote:
> On 07/08/2016 08:44 AM, Krishna Chaitanya wrote:
>>
>> On Fri, Jul 8, 2016 at 9:12 PM, Ben Greear <greearb at candelatech.com>
>> wrote:
>>>
>>> On 07/08/2016 08:39 AM, Krishna Chaitanya wrote:
>>>
>>>> Also can you please tell me how to make ath10k use minstrel rc, its
>>>> needed
>>>> for comparative purposes? Is disable HW_RATE_CONTROL enough or does
>>>> it need more changes?
>>>
>>>
>>>
>>> It cannot be done.  You have to use whatever rate-ctrl is baked into the
>>> firmware.
>>
>> Ok, its a good feature to have.
>>
>
> It is unlikely to happen anytime soon.  It requires significant firmware
> modification (and driver too),
Ok, I understand.
>and probably you would have to add MU-MIMO
> support to minstrel if you wanted to support latest ath10k NICs.
It need not be a full pledged one, but 11ac MIMO works should be
good enough (for now).


From greearb at candelatech.com  Fri Jul  8 08:47:16 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 8 Jul 2016 08:47:16 -0700
Subject: ath10k + iw set bitrates is causing FW crash
In-Reply-To: <CABPxzYLdS-QicOj9AdcubT8uxgw0cqXpzerpuwGcwkSQ7PCiOA@mail.gmail.com>
References: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>
 <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>
 <1467972560885.99812@qti.qualcomm.com>
 <CABPxzY+8Y-FHUFALGueN1hQwgjJHNpeyy_BRkrM4osguxJZS0Q@mail.gmail.com>
 <1467982766213.21223@qti.qualcomm.com>
 <CABPxzYLO8rzvOJ_1iqng89kYFS-xqC3qstbgETVRJHDpO4rikQ@mail.gmail.com>
 <CABPxzYJPi4CqO+KUFA7=r=zpq_c2vFtrgBQ+nF_nThO-cYrteg@mail.gmail.com>
 <CABPxzYKOqBmrjRwAyZV9daV8adEhUV71XEAsfrLhtTnKwWzuaw@mail.gmail.com>
 <577FC9D0.2010809@candelatech.com>
 <CABPxzYLdS-QicOj9AdcubT8uxgw0cqXpzerpuwGcwkSQ7PCiOA@mail.gmail.com>
Message-ID: <577FCB04.4030905@candelatech.com>

On 07/08/2016 08:44 AM, Krishna Chaitanya wrote:
> On Fri, Jul 8, 2016 at 9:12 PM, Ben Greear <greearb at candelatech.com> wrote:
>> On 07/08/2016 08:39 AM, Krishna Chaitanya wrote:
>>
>>> Also can you please tell me how to make ath10k use minstrel rc, its needed
>>> for comparative purposes? Is disable HW_RATE_CONTROL enough or does
>>> it need more changes?
>>
>>
>> It cannot be done.  You have to use whatever rate-ctrl is baked into the
>> firmware.
> Ok, its a good feature to have.
>

It is unlikely to happen anytime soon.  It requires significant firmware
modification (and driver too), and probably you would have to add MU-MIMO
support to minstrel if you wanted to support latest ath10k NICs.

Thanks,
Ben

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



From yeohchunyeow at gmail.com  Fri Jul  8 10:15:11 2016
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Sat, 9 Jul 2016 01:15:11 +0800
Subject: Does 99x0 support mesh mode?
In-Reply-To: <CAGJdtRASjA_+HPh1zFkoF4V=ttWcidxEwDAOU+ehbc7YhSxw7A@mail.gmail.com>
References: <CAGJdtRASjA_+HPh1zFkoF4V=ttWcidxEwDAOU+ehbc7YhSxw7A@mail.gmail.com>
Message-ID: <CAEFj984kqhY5zM_S=CLfDdujbpmwsrKqzZx=xm1AyCPQcmWWKg@mail.gmail.com>

Make sure the firmware has the raw mode feature bit enabled to support mesh.

---
Chun-Yeow

On Fri, Jul 8, 2016 at 12:52 PM, Yu-Chieh <jay0607 at gmail.com> wrote:
> Hi,
>
> Does anyone know if current firmware support mesh mode(802.11s) on 99x0?
>
> Best regards,
>
> Jay
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From poh at codeaurora.org  Fri Jul  8 10:48:23 2016
From: poh at codeaurora.org (Peter Oh)
Date: Fri, 08 Jul 2016 10:48:23 -0700
Subject: Does 99x0 support mesh mode?
In-Reply-To: <CAEFj984kqhY5zM_S=CLfDdujbpmwsrKqzZx=xm1AyCPQcmWWKg@mail.gmail.com>
References: <CAGJdtRASjA_+HPh1zFkoF4V=ttWcidxEwDAOU+ehbc7YhSxw7A@mail.gmail.com>
 <CAEFj984kqhY5zM_S=CLfDdujbpmwsrKqzZx=xm1AyCPQcmWWKg@mail.gmail.com>
Message-ID: <577FE767.3020200@codeaurora.org>


On 07/08/2016 10:15 AM, Yeoh Chun-Yeow wrote:
> Make sure the firmware has the raw mode feature bit enabled to support
> mesh.
In addition to that, you may check out wmi_services (cat 
/sys/kernel/debug/ieee80211/phyX/ath10k/wmi_services) if 
WMI_SERVICE_MESH_11S is set to enabled which means 11s mesh supported in 
native Wi-Fi mode.
> ---
> Chun-Yeow
>
> On Fri, Jul 8, 2016 at 12:52 PM, Yu-Chieh <jay0607 at gmail.com> wrote:
>> Hi,
>>
>> Does anyone know if current firmware support mesh mode(802.11s) on 99x0?
>>
>> Best regards,
>>
>> Jay
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>
Peter


From bskeggs at redhat.com  Fri Jul  8 16:45:29 2016
From: bskeggs at redhat.com (Ben Skeggs)
Date: Sat, 9 Jul 2016 09:45:29 +1000
Subject: AR9882 IOMMU faults
In-Reply-To: <577FB15B.3050907@candelatech.com>
References: <4b0fdabc-ff87-c182-7db6-68bf32755407@redhat.com>
 <1467983388208.13042@qti.qualcomm.com> <577FB15B.3050907@candelatech.com>
Message-ID: <8e45724d-6edd-e366-5c53-8cbb9b0a09e2@redhat.com>

On 07/08/2016 11:57 PM, Ben Greear wrote:
> 
> 
> On 07/08/2016 06:09 AM, Manoharan, Rajkumar wrote:
>> Logs are so limited. If possible, revert below commit and give a try
>>
>> "ath10k: do not use coherent memory for allocated device memory chunks"
>>
>> If revert is not so clean, try with this patch.
>>
>> https://patchwork.kernel.org/patch/9175029/
> 
> I use this patch, I don't think it is upstream, and per comment, I have not
> tested this on other than x86 platform:
Both the revert, and the change too DMA_BIDIRECTIONAL seem to resolve
the issue here (also on x86).

Thank you!
Ben.

> 
> [greearb at ben-dt ath10k]$ git show 0e6e6f6b2
> commit 0e6e6f6b2fac0ade990de56eef3841dbe7128f35
> Author: Ben Greear <greearb at candelatech.com>
> Date:   Thu Jan 21 18:57:11 2016 -0800
> 
>     ath10k:  wmi-alloc-chunk should use DMA_BIDIRECTIONAL.
> 
>     These memory chunks are often used as 'swap' by the NIC,
>     so it will be both reading and writing to these areas.
> 
>     This seems to fix errors like this on my x86-64 machine:
> 
>     kernel: DMAR: DMAR:[DMA Write] Request device [05:00.0] fault addr
> ff5de000
>             DMAR:[fault reason 05] PTE Write access is not set
> 
>     Should be tested and verified by someone who uses other platforms
>     though...
> 
>     Signed-off-by: Ben Greear <greearb at candelatech.com>
> 
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
> b/drivers/net/wireless/ath/ath10k/wmi.c
> index af37a77..502f0e0 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -4404,7 +4404,7 @@ static int ath10k_wmi_alloc_chunk(struct ath10k
> *ar, u32 req_id,
>         if (!num_units)
>                 return -ENOMEM;
> 
> -       paddr = dma_map_single(ar->dev, vaddr, pool_size, DMA_TO_DEVICE);
> +       paddr = dma_map_single(ar->dev, vaddr, pool_size,
> DMA_BIDIRECTIONAL);
>         if (dma_mapping_error(ar->dev, paddr)) {
>                 kfree(vaddr);
>                 return -ENOMEM;
> [greearb at ben-dt ath10k]$
> 
>>
>> -Rajkumar
>> ________________________________________
>> From: ath10k <ath10k-bounces at lists.infradead.org> on behalf of Ben
>> Skeggs <bskeggs at redhat.com>
>> Sent: Friday, July 8, 2016 10:59 AM
>> To: ath10k at lists.infradead.org
>> Subject: AR9882 IOMMU faults
>>
>> Hey,
>>
>> I've just installed a COMPEX WLE600VX (AR9882) in my router machine,
>> operating in AP mode.
>>
>> While it appears to be working well enough, I get massive floods of
>> IOMMU faults reported in my kernel log.  These appear to increase with
>> the load on the network.
>>
>> I've attached both the info that ath10k reports when it detects the
>> device, and a sample of one of the DMAR messages (worth nothing that
>> it's the same fault address in all the messages).
>>
>> Is this a known issue, and anything I can do to help get it resolved?
>>
>> Thanks,
>> Ben.
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160709/be3ac533/attachment.sig>

From jay0607 at gmail.com  Fri Jul  8 19:57:16 2016
From: jay0607 at gmail.com (Yu-Chieh)
Date: Sat, 9 Jul 2016 10:57:16 +0800
Subject: Does 99x0 support mesh mode?
In-Reply-To: <577FE767.3020200@codeaurora.org>
References: <CAGJdtRASjA_+HPh1zFkoF4V=ttWcidxEwDAOU+ehbc7YhSxw7A@mail.gmail.com>
 <CAEFj984kqhY5zM_S=CLfDdujbpmwsrKqzZx=xm1AyCPQcmWWKg@mail.gmail.com>
 <577FE767.3020200@codeaurora.org>
Message-ID: <CAGJdtRDGOAo5DUp14HkJ2vr+gtkeLcOZarvYBxMnX2DeiV7_tg@mail.gmail.com>

i have checked firmware firmware-5.bin_10.4.3.00063-1 on codeaurora

regarding ram mode, i think it's not supported
<6>[232109.383248] ath10k_pci 0003:01:00.0: firmware ver 10.4.3.00063
api 5 features no-p2p,peer-flow-ctrl crc32 a0d385ce
<6>[232110.836979] ath10k_pci 0003:01:00.0: board_file api 1 bmi_id
1:1 crc32 77b2338a
<4>[232113.369117] ath10k_pci 0003:01:00.0: 10.4 wmi init: vdevs: 16
peers: 528  tid: 132
<4>[232113.376857] ath10k_pci 0003:01:00.0: msdu-desc: 1424  skid: 32
<6>[232113.452238] ath10k_pci 0003:01:00.0: htt-ver 2.2 wmi-op 6
htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1

regarding wmi_service, i have checked
/sys/kernel/debug/ieee80211/phy0/ath10k/wmi_services
WMI_SERVICE_MESH_11S                     -
WMI_SERVICE_MESH_NON_11S                 enabled

Any one knows MESH_NON_11S ?

Jay

2016-07-09 1:48 GMT+08:00 Peter Oh <poh at codeaurora.org>:
>
> On 07/08/2016 10:15 AM, Yeoh Chun-Yeow wrote:
>>
>> Make sure the firmware has the raw mode feature bit enabled to support
>> mesh.
>
> In addition to that, you may check out wmi_services (cat
> /sys/kernel/debug/ieee80211/phyX/ath10k/wmi_services) if
> WMI_SERVICE_MESH_11S is set to enabled which means 11s mesh supported in
> native Wi-Fi mode.
>
>> ---
>> Chun-Yeow
>>
>> On Fri, Jul 8, 2016 at 12:52 PM, Yu-Chieh <jay0607 at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> Does anyone know if current firmware support mesh mode(802.11s) on 99x0?
>>>
>>> Best regards,
>>>
>>> Jay
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>>
> Peter


From jay0607 at gmail.com  Fri Jul  8 20:25:56 2016
From: jay0607 at gmail.com (Yu-Chieh)
Date: Sat, 9 Jul 2016 11:25:56 +0800
Subject: Does 99x0 support mesh mode?
In-Reply-To: <CAGJdtRDGOAo5DUp14HkJ2vr+gtkeLcOZarvYBxMnX2DeiV7_tg@mail.gmail.com>
References: <CAGJdtRASjA_+HPh1zFkoF4V=ttWcidxEwDAOU+ehbc7YhSxw7A@mail.gmail.com>
 <CAEFj984kqhY5zM_S=CLfDdujbpmwsrKqzZx=xm1AyCPQcmWWKg@mail.gmail.com>
 <577FE767.3020200@codeaurora.org>
 <CAGJdtRDGOAo5DUp14HkJ2vr+gtkeLcOZarvYBxMnX2DeiV7_tg@mail.gmail.com>
Message-ID: <CAGJdtRCzx3cG0jWfJa3HeL82bAvSotm=EofeEEg2oj8OsMZu5g@mail.gmail.com>

OK, i think it's not supported now
# iw phy phy0 interface add mp0 type mp mesh_id MeshNetwork
# ifconfig mp0 up
[  289.502405] ath10k_pci 0003:01:00.0: 10.4 wmi init: vdevs: 16  peers: 528  ti
d: 132
[  289.510058] ath10k_pci 0003:01:00.0: msdu-desc: 1424  skid: 32
[  289.604802] ath10k_pci 0003:01:00.0: must load driver with rawmode=1 to add m
esh interfaces
ifconfig: SIOCSIFFLAGS: Invalid argument

then, i tried insmod ath10k_core.ko with rawmode=1, i got probe fw
fail log as following
[  350.779002] ath10k_pci 0003:01:00.0: rawmode = 1 requires support from firmwa
re
[  350.786294] ath10k_pci 0003:01:00.0: fatal problem with firmware features: -2
2
[  350.793575] ath10k_pci 0003:01:00.0: could not probe fw (-22)

Jay

2016-07-09 10:57 GMT+08:00 Yu-Chieh <jay0607 at gmail.com>:
> i have checked firmware firmware-5.bin_10.4.3.00063-1 on codeaurora
>
> regarding ram mode, i think it's not supported
> <6>[232109.383248] ath10k_pci 0003:01:00.0: firmware ver 10.4.3.00063
> api 5 features no-p2p,peer-flow-ctrl crc32 a0d385ce
> <6>[232110.836979] ath10k_pci 0003:01:00.0: board_file api 1 bmi_id
> 1:1 crc32 77b2338a
> <4>[232113.369117] ath10k_pci 0003:01:00.0: 10.4 wmi init: vdevs: 16
> peers: 528  tid: 132
> <4>[232113.376857] ath10k_pci 0003:01:00.0: msdu-desc: 1424  skid: 32
> <6>[232113.452238] ath10k_pci 0003:01:00.0: htt-ver 2.2 wmi-op 6
> htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1
>
> regarding wmi_service, i have checked
> /sys/kernel/debug/ieee80211/phy0/ath10k/wmi_services
> WMI_SERVICE_MESH_11S                     -
> WMI_SERVICE_MESH_NON_11S                 enabled
>
> Any one knows MESH_NON_11S ?
>
> Jay
>
> 2016-07-09 1:48 GMT+08:00 Peter Oh <poh at codeaurora.org>:
>>
>> On 07/08/2016 10:15 AM, Yeoh Chun-Yeow wrote:
>>>
>>> Make sure the firmware has the raw mode feature bit enabled to support
>>> mesh.
>>
>> In addition to that, you may check out wmi_services (cat
>> /sys/kernel/debug/ieee80211/phyX/ath10k/wmi_services) if
>> WMI_SERVICE_MESH_11S is set to enabled which means 11s mesh supported in
>> native Wi-Fi mode.
>>
>>> ---
>>> Chun-Yeow
>>>
>>> On Fri, Jul 8, 2016 at 12:52 PM, Yu-Chieh <jay0607 at gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Does anyone know if current firmware support mesh mode(802.11s) on 99x0?
>>>>
>>>> Best regards,
>>>>
>>>> Jay
>>>>
>>>> _______________________________________________
>>>> ath10k mailing list
>>>> ath10k at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>
>>>
>> Peter


From yeohchunyeow at gmail.com  Sat Jul  9 08:15:43 2016
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Sat, 9 Jul 2016 23:15:43 +0800
Subject: Does 99x0 support mesh mode?
In-Reply-To: <CAGJdtRCzx3cG0jWfJa3HeL82bAvSotm=EofeEEg2oj8OsMZu5g@mail.gmail.com>
References: <CAGJdtRASjA_+HPh1zFkoF4V=ttWcidxEwDAOU+ehbc7YhSxw7A@mail.gmail.com>
 <CAEFj984kqhY5zM_S=CLfDdujbpmwsrKqzZx=xm1AyCPQcmWWKg@mail.gmail.com>
 <577FE767.3020200@codeaurora.org>
 <CAGJdtRDGOAo5DUp14HkJ2vr+gtkeLcOZarvYBxMnX2DeiV7_tg@mail.gmail.com>
 <CAGJdtRCzx3cG0jWfJa3HeL82bAvSotm=EofeEEg2oj8OsMZu5g@mail.gmail.com>
Message-ID: <CAEFj9861s7hJOXj4H9WA4fD_JjWTUwim243AUB6dWXqO7pVNFQ@mail.gmail.com>

Take a look on the firmware here for your hardware and see how:
https://github.com/kvalo/ath10k-firmware

Regards,
Chun-Yeow

On Sat, Jul 9, 2016 at 11:25 AM, Yu-Chieh <jay0607 at gmail.com> wrote:
> OK, i think it's not supported now
> # iw phy phy0 interface add mp0 type mp mesh_id MeshNetwork
> # ifconfig mp0 up
> [  289.502405] ath10k_pci 0003:01:00.0: 10.4 wmi init: vdevs: 16  peers: 528  ti
> d: 132
> [  289.510058] ath10k_pci 0003:01:00.0: msdu-desc: 1424  skid: 32
> [  289.604802] ath10k_pci 0003:01:00.0: must load driver with rawmode=1 to add m
> esh interfaces
> ifconfig: SIOCSIFFLAGS: Invalid argument
>
> then, i tried insmod ath10k_core.ko with rawmode=1, i got probe fw
> fail log as following
> [  350.779002] ath10k_pci 0003:01:00.0: rawmode = 1 requires support from firmwa
> re
> [  350.786294] ath10k_pci 0003:01:00.0: fatal problem with firmware features: -2
> 2
> [  350.793575] ath10k_pci 0003:01:00.0: could not probe fw (-22)
>
> Jay
>
> 2016-07-09 10:57 GMT+08:00 Yu-Chieh <jay0607 at gmail.com>:
>> i have checked firmware firmware-5.bin_10.4.3.00063-1 on codeaurora
>>
>> regarding ram mode, i think it's not supported
>> <6>[232109.383248] ath10k_pci 0003:01:00.0: firmware ver 10.4.3.00063
>> api 5 features no-p2p,peer-flow-ctrl crc32 a0d385ce
>> <6>[232110.836979] ath10k_pci 0003:01:00.0: board_file api 1 bmi_id
>> 1:1 crc32 77b2338a
>> <4>[232113.369117] ath10k_pci 0003:01:00.0: 10.4 wmi init: vdevs: 16
>> peers: 528  tid: 132
>> <4>[232113.376857] ath10k_pci 0003:01:00.0: msdu-desc: 1424  skid: 32
>> <6>[232113.452238] ath10k_pci 0003:01:00.0: htt-ver 2.2 wmi-op 6
>> htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1
>>
>> regarding wmi_service, i have checked
>> /sys/kernel/debug/ieee80211/phy0/ath10k/wmi_services
>> WMI_SERVICE_MESH_11S                     -
>> WMI_SERVICE_MESH_NON_11S                 enabled
>>
>> Any one knows MESH_NON_11S ?
>>
>> Jay
>>
>> 2016-07-09 1:48 GMT+08:00 Peter Oh <poh at codeaurora.org>:
>>>
>>> On 07/08/2016 10:15 AM, Yeoh Chun-Yeow wrote:
>>>>
>>>> Make sure the firmware has the raw mode feature bit enabled to support
>>>> mesh.
>>>
>>> In addition to that, you may check out wmi_services (cat
>>> /sys/kernel/debug/ieee80211/phyX/ath10k/wmi_services) if
>>> WMI_SERVICE_MESH_11S is set to enabled which means 11s mesh supported in
>>> native Wi-Fi mode.
>>>
>>>> ---
>>>> Chun-Yeow
>>>>
>>>> On Fri, Jul 8, 2016 at 12:52 PM, Yu-Chieh <jay0607 at gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Does anyone know if current firmware support mesh mode(802.11s) on 99x0?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Jay
>>>>>
>>>>> _______________________________________________
>>>>> ath10k mailing list
>>>>> ath10k at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>
>>>>
>>> Peter


From jay0607 at gmail.com  Sat Jul  9 08:58:16 2016
From: jay0607 at gmail.com (Yu-Chieh)
Date: Sat, 9 Jul 2016 23:58:16 +0800
Subject: Does 99x0 support mesh mode?
In-Reply-To: <CAEFj9861s7hJOXj4H9WA4fD_JjWTUwim243AUB6dWXqO7pVNFQ@mail.gmail.com>
References: <CAGJdtRASjA_+HPh1zFkoF4V=ttWcidxEwDAOU+ehbc7YhSxw7A@mail.gmail.com>
 <CAEFj984kqhY5zM_S=CLfDdujbpmwsrKqzZx=xm1AyCPQcmWWKg@mail.gmail.com>
 <577FE767.3020200@codeaurora.org>
 <CAGJdtRDGOAo5DUp14HkJ2vr+gtkeLcOZarvYBxMnX2DeiV7_tg@mail.gmail.com>
 <CAGJdtRCzx3cG0jWfJa3HeL82bAvSotm=EofeEEg2oj8OsMZu5g@mail.gmail.com>
 <CAEFj9861s7hJOXj4H9WA4fD_JjWTUwim243AUB6dWXqO7pVNFQ@mail.gmail.com>
Message-ID: <CAGJdtRBDeAvMChyjRZ0wzDWYrL-eyEr-mvCU0oaa3NkaWhKGeQ@mail.gmail.com>

Thanks Chun-Yeow

Try the firmware on https://github.com/kvalo/ath10k-firmware
the firmware still not support RAW mode

Jay

2016-07-09 23:15 GMT+08:00 Yeoh Chun-Yeow <yeohchunyeow at gmail.com>:
> Take a look on the firmware here for your hardware and see how:
> https://github.com/kvalo/ath10k-firmware
>
> Regards,
> Chun-Yeow
>
> On Sat, Jul 9, 2016 at 11:25 AM, Yu-Chieh <jay0607 at gmail.com> wrote:
>> OK, i think it's not supported now
>> # iw phy phy0 interface add mp0 type mp mesh_id MeshNetwork
>> # ifconfig mp0 up
>> [  289.502405] ath10k_pci 0003:01:00.0: 10.4 wmi init: vdevs: 16  peers: 528  ti
>> d: 132
>> [  289.510058] ath10k_pci 0003:01:00.0: msdu-desc: 1424  skid: 32
>> [  289.604802] ath10k_pci 0003:01:00.0: must load driver with rawmode=1 to add m
>> esh interfaces
>> ifconfig: SIOCSIFFLAGS: Invalid argument
>>
>> then, i tried insmod ath10k_core.ko with rawmode=1, i got probe fw
>> fail log as following
>> [  350.779002] ath10k_pci 0003:01:00.0: rawmode = 1 requires support from firmwa
>> re
>> [  350.786294] ath10k_pci 0003:01:00.0: fatal problem with firmware features: -2
>> 2
>> [  350.793575] ath10k_pci 0003:01:00.0: could not probe fw (-22)
>>
>> Jay
>>
>> 2016-07-09 10:57 GMT+08:00 Yu-Chieh <jay0607 at gmail.com>:
>>> i have checked firmware firmware-5.bin_10.4.3.00063-1 on codeaurora
>>>
>>> regarding ram mode, i think it's not supported
>>> <6>[232109.383248] ath10k_pci 0003:01:00.0: firmware ver 10.4.3.00063
>>> api 5 features no-p2p,peer-flow-ctrl crc32 a0d385ce
>>> <6>[232110.836979] ath10k_pci 0003:01:00.0: board_file api 1 bmi_id
>>> 1:1 crc32 77b2338a
>>> <4>[232113.369117] ath10k_pci 0003:01:00.0: 10.4 wmi init: vdevs: 16
>>> peers: 528  tid: 132
>>> <4>[232113.376857] ath10k_pci 0003:01:00.0: msdu-desc: 1424  skid: 32
>>> <6>[232113.452238] ath10k_pci 0003:01:00.0: htt-ver 2.2 wmi-op 6
>>> htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1
>>>
>>> regarding wmi_service, i have checked
>>> /sys/kernel/debug/ieee80211/phy0/ath10k/wmi_services
>>> WMI_SERVICE_MESH_11S                     -
>>> WMI_SERVICE_MESH_NON_11S                 enabled
>>>
>>> Any one knows MESH_NON_11S ?
>>>
>>> Jay
>>>
>>> 2016-07-09 1:48 GMT+08:00 Peter Oh <poh at codeaurora.org>:
>>>>
>>>> On 07/08/2016 10:15 AM, Yeoh Chun-Yeow wrote:
>>>>>
>>>>> Make sure the firmware has the raw mode feature bit enabled to support
>>>>> mesh.
>>>>
>>>> In addition to that, you may check out wmi_services (cat
>>>> /sys/kernel/debug/ieee80211/phyX/ath10k/wmi_services) if
>>>> WMI_SERVICE_MESH_11S is set to enabled which means 11s mesh supported in
>>>> native Wi-Fi mode.
>>>>
>>>>> ---
>>>>> Chun-Yeow
>>>>>
>>>>> On Fri, Jul 8, 2016 at 12:52 PM, Yu-Chieh <jay0607 at gmail.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Does anyone know if current firmware support mesh mode(802.11s) on 99x0?
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Jay
>>>>>>
>>>>>> _______________________________________________
>>>>>> ath10k mailing list
>>>>>> ath10k at lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>
>>>>>
>>>> Peter


From yeohchunyeow at gmail.com  Sat Jul  9 09:26:06 2016
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Sun, 10 Jul 2016 00:26:06 +0800
Subject: Does 99x0 support mesh mode?
In-Reply-To: <CAGJdtRBDeAvMChyjRZ0wzDWYrL-eyEr-mvCU0oaa3NkaWhKGeQ@mail.gmail.com>
References: <CAGJdtRASjA_+HPh1zFkoF4V=ttWcidxEwDAOU+ehbc7YhSxw7A@mail.gmail.com>
 <CAEFj984kqhY5zM_S=CLfDdujbpmwsrKqzZx=xm1AyCPQcmWWKg@mail.gmail.com>
 <577FE767.3020200@codeaurora.org>
 <CAGJdtRDGOAo5DUp14HkJ2vr+gtkeLcOZarvYBxMnX2DeiV7_tg@mail.gmail.com>
 <CAGJdtRCzx3cG0jWfJa3HeL82bAvSotm=EofeEEg2oj8OsMZu5g@mail.gmail.com>
 <CAEFj9861s7hJOXj4H9WA4fD_JjWTUwim243AUB6dWXqO7pVNFQ@mail.gmail.com>
 <CAGJdtRBDeAvMChyjRZ0wzDWYrL-eyEr-mvCU0oaa3NkaWhKGeQ@mail.gmail.com>
Message-ID: <CAEFj9845+=7EmQqrTo17nsXdvUtUtwyxjxY6e9Xux1QKqjzMKw@mail.gmail.com>

You can try the hardware using QCA988X.

ath10k_pci 0000:03:00.0: firmware ver 10.2.4.70.52 api 5 features
no-p2p,raw-mode,mfp crc32 67c4d25c
ath10k_pci 0000:03:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta
128 raw 1 hwcrypto 1

----
Chun-Yeow

On Sat, Jul 9, 2016 at 11:58 PM, Yu-Chieh <jay0607 at gmail.com> wrote:
> Thanks Chun-Yeow
>
> Try the firmware on https://github.com/kvalo/ath10k-firmware
> the firmware still not support RAW mode
>
> Jay
>
> 2016-07-09 23:15 GMT+08:00 Yeoh Chun-Yeow <yeohchunyeow at gmail.com>:
>> Take a look on the firmware here for your hardware and see how:
>> https://github.com/kvalo/ath10k-firmware
>>
>> Regards,
>> Chun-Yeow
>>
>> On Sat, Jul 9, 2016 at 11:25 AM, Yu-Chieh <jay0607 at gmail.com> wrote:
>>> OK, i think it's not supported now
>>> # iw phy phy0 interface add mp0 type mp mesh_id MeshNetwork
>>> # ifconfig mp0 up
>>> [  289.502405] ath10k_pci 0003:01:00.0: 10.4 wmi init: vdevs: 16  peers: 528  ti
>>> d: 132
>>> [  289.510058] ath10k_pci 0003:01:00.0: msdu-desc: 1424  skid: 32
>>> [  289.604802] ath10k_pci 0003:01:00.0: must load driver with rawmode=1 to add m
>>> esh interfaces
>>> ifconfig: SIOCSIFFLAGS: Invalid argument
>>>
>>> then, i tried insmod ath10k_core.ko with rawmode=1, i got probe fw
>>> fail log as following
>>> [  350.779002] ath10k_pci 0003:01:00.0: rawmode = 1 requires support from firmwa
>>> re
>>> [  350.786294] ath10k_pci 0003:01:00.0: fatal problem with firmware features: -2
>>> 2
>>> [  350.793575] ath10k_pci 0003:01:00.0: could not probe fw (-22)
>>>
>>> Jay
>>>
>>> 2016-07-09 10:57 GMT+08:00 Yu-Chieh <jay0607 at gmail.com>:
>>>> i have checked firmware firmware-5.bin_10.4.3.00063-1 on codeaurora
>>>>
>>>> regarding ram mode, i think it's not supported
>>>> <6>[232109.383248] ath10k_pci 0003:01:00.0: firmware ver 10.4.3.00063
>>>> api 5 features no-p2p,peer-flow-ctrl crc32 a0d385ce
>>>> <6>[232110.836979] ath10k_pci 0003:01:00.0: board_file api 1 bmi_id
>>>> 1:1 crc32 77b2338a
>>>> <4>[232113.369117] ath10k_pci 0003:01:00.0: 10.4 wmi init: vdevs: 16
>>>> peers: 528  tid: 132
>>>> <4>[232113.376857] ath10k_pci 0003:01:00.0: msdu-desc: 1424  skid: 32
>>>> <6>[232113.452238] ath10k_pci 0003:01:00.0: htt-ver 2.2 wmi-op 6
>>>> htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1
>>>>
>>>> regarding wmi_service, i have checked
>>>> /sys/kernel/debug/ieee80211/phy0/ath10k/wmi_services
>>>> WMI_SERVICE_MESH_11S                     -
>>>> WMI_SERVICE_MESH_NON_11S                 enabled
>>>>
>>>> Any one knows MESH_NON_11S ?
>>>>
>>>> Jay
>>>>
>>>> 2016-07-09 1:48 GMT+08:00 Peter Oh <poh at codeaurora.org>:
>>>>>
>>>>> On 07/08/2016 10:15 AM, Yeoh Chun-Yeow wrote:
>>>>>>
>>>>>> Make sure the firmware has the raw mode feature bit enabled to support
>>>>>> mesh.
>>>>>
>>>>> In addition to that, you may check out wmi_services (cat
>>>>> /sys/kernel/debug/ieee80211/phyX/ath10k/wmi_services) if
>>>>> WMI_SERVICE_MESH_11S is set to enabled which means 11s mesh supported in
>>>>> native Wi-Fi mode.
>>>>>
>>>>>> ---
>>>>>> Chun-Yeow
>>>>>>
>>>>>> On Fri, Jul 8, 2016 at 12:52 PM, Yu-Chieh <jay0607 at gmail.com> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Does anyone know if current firmware support mesh mode(802.11s) on 99x0?
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Jay
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> ath10k mailing list
>>>>>>> ath10k at lists.infradead.org
>>>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>>
>>>>>>
>>>>> Peter


From jay0607 at gmail.com  Sun Jul 10 10:44:23 2016
From: jay0607 at gmail.com (Yu-Chieh)
Date: Mon, 11 Jul 2016 01:44:23 +0800
Subject: Does 99x0 support mesh mode?
In-Reply-To: <CAEFj9845+=7EmQqrTo17nsXdvUtUtwyxjxY6e9Xux1QKqjzMKw@mail.gmail.com>
References: <CAGJdtRASjA_+HPh1zFkoF4V=ttWcidxEwDAOU+ehbc7YhSxw7A@mail.gmail.com>
 <CAEFj984kqhY5zM_S=CLfDdujbpmwsrKqzZx=xm1AyCPQcmWWKg@mail.gmail.com>
 <577FE767.3020200@codeaurora.org>
 <CAGJdtRDGOAo5DUp14HkJ2vr+gtkeLcOZarvYBxMnX2DeiV7_tg@mail.gmail.com>
 <CAGJdtRCzx3cG0jWfJa3HeL82bAvSotm=EofeEEg2oj8OsMZu5g@mail.gmail.com>
 <CAEFj9861s7hJOXj4H9WA4fD_JjWTUwim243AUB6dWXqO7pVNFQ@mail.gmail.com>
 <CAGJdtRBDeAvMChyjRZ0wzDWYrL-eyEr-mvCU0oaa3NkaWhKGeQ@mail.gmail.com>
 <CAEFj9845+=7EmQqrTo17nsXdvUtUtwyxjxY6e9Xux1QKqjzMKw@mail.gmail.com>
Message-ID: <CAGJdtRCQcBy2LOz_jg_dpqHWtMDRHPPM7VUswzHuvtX0kZspnQ@mail.gmail.com>

Thanks Chun-Yeow,

I am focus on 99x0. so i don't consider 988x.
BTW, thanks for confirm the firmware of 988x supports RAM mode.

Jay

2016-07-10 0:26 GMT+08:00 Yeoh Chun-Yeow <yeohchunyeow at gmail.com>:
> You can try the hardware using QCA988X.
>
> ath10k_pci 0000:03:00.0: firmware ver 10.2.4.70.52 api 5 features
> no-p2p,raw-mode,mfp crc32 67c4d25c
> ath10k_pci 0000:03:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta
> 128 raw 1 hwcrypto 1
>
> ----
> Chun-Yeow
>
> On Sat, Jul 9, 2016 at 11:58 PM, Yu-Chieh <jay0607 at gmail.com> wrote:
>> Thanks Chun-Yeow
>>
>> Try the firmware on https://github.com/kvalo/ath10k-firmware
>> the firmware still not support RAW mode
>>
>> Jay
>>
>> 2016-07-09 23:15 GMT+08:00 Yeoh Chun-Yeow <yeohchunyeow at gmail.com>:
>>> Take a look on the firmware here for your hardware and see how:
>>> https://github.com/kvalo/ath10k-firmware
>>>
>>> Regards,
>>> Chun-Yeow
>>>
>>> On Sat, Jul 9, 2016 at 11:25 AM, Yu-Chieh <jay0607 at gmail.com> wrote:
>>>> OK, i think it's not supported now
>>>> # iw phy phy0 interface add mp0 type mp mesh_id MeshNetwork
>>>> # ifconfig mp0 up
>>>> [  289.502405] ath10k_pci 0003:01:00.0: 10.4 wmi init: vdevs: 16  peers: 528  ti
>>>> d: 132
>>>> [  289.510058] ath10k_pci 0003:01:00.0: msdu-desc: 1424  skid: 32
>>>> [  289.604802] ath10k_pci 0003:01:00.0: must load driver with rawmode=1 to add m
>>>> esh interfaces
>>>> ifconfig: SIOCSIFFLAGS: Invalid argument
>>>>
>>>> then, i tried insmod ath10k_core.ko with rawmode=1, i got probe fw
>>>> fail log as following
>>>> [  350.779002] ath10k_pci 0003:01:00.0: rawmode = 1 requires support from firmwa
>>>> re
>>>> [  350.786294] ath10k_pci 0003:01:00.0: fatal problem with firmware features: -2
>>>> 2
>>>> [  350.793575] ath10k_pci 0003:01:00.0: could not probe fw (-22)
>>>>
>>>> Jay
>>>>
>>>> 2016-07-09 10:57 GMT+08:00 Yu-Chieh <jay0607 at gmail.com>:
>>>>> i have checked firmware firmware-5.bin_10.4.3.00063-1 on codeaurora
>>>>>
>>>>> regarding ram mode, i think it's not supported
>>>>> <6>[232109.383248] ath10k_pci 0003:01:00.0: firmware ver 10.4.3.00063
>>>>> api 5 features no-p2p,peer-flow-ctrl crc32 a0d385ce
>>>>> <6>[232110.836979] ath10k_pci 0003:01:00.0: board_file api 1 bmi_id
>>>>> 1:1 crc32 77b2338a
>>>>> <4>[232113.369117] ath10k_pci 0003:01:00.0: 10.4 wmi init: vdevs: 16
>>>>> peers: 528  tid: 132
>>>>> <4>[232113.376857] ath10k_pci 0003:01:00.0: msdu-desc: 1424  skid: 32
>>>>> <6>[232113.452238] ath10k_pci 0003:01:00.0: htt-ver 2.2 wmi-op 6
>>>>> htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1
>>>>>
>>>>> regarding wmi_service, i have checked
>>>>> /sys/kernel/debug/ieee80211/phy0/ath10k/wmi_services
>>>>> WMI_SERVICE_MESH_11S                     -
>>>>> WMI_SERVICE_MESH_NON_11S                 enabled
>>>>>
>>>>> Any one knows MESH_NON_11S ?
>>>>>
>>>>> Jay
>>>>>
>>>>> 2016-07-09 1:48 GMT+08:00 Peter Oh <poh at codeaurora.org>:
>>>>>>
>>>>>> On 07/08/2016 10:15 AM, Yeoh Chun-Yeow wrote:
>>>>>>>
>>>>>>> Make sure the firmware has the raw mode feature bit enabled to support
>>>>>>> mesh.
>>>>>>
>>>>>> In addition to that, you may check out wmi_services (cat
>>>>>> /sys/kernel/debug/ieee80211/phyX/ath10k/wmi_services) if
>>>>>> WMI_SERVICE_MESH_11S is set to enabled which means 11s mesh supported in
>>>>>> native Wi-Fi mode.
>>>>>>
>>>>>>> ---
>>>>>>> Chun-Yeow
>>>>>>>
>>>>>>> On Fri, Jul 8, 2016 at 12:52 PM, Yu-Chieh <jay0607 at gmail.com> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Does anyone know if current firmware support mesh mode(802.11s) on 99x0?
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Jay
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> ath10k mailing list
>>>>>>>> ath10k at lists.infradead.org
>>>>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>>>
>>>>>>>
>>>>>> Peter


From ipascual at cttc.cat  Wed Jul 13 07:10:50 2016
From: ipascual at cttc.cat (=?UTF-8?Q?I=c3=b1aki_Pascual?=)
Date: Wed, 13 Jul 2016 16:10:50 +0200
Subject: How to obtain Link Quality information
Message-ID: <57864BEA.4090202@cttc.cat>

Hi everyone,

I am trying to get link quality information from an 802.11ac interface 
and it looks like the only way is to use "iw wlan2 scan". I don't like 
this solution as it scans all channels and takes a while.

If I try "cat /proc/net/wireless" (this would be my preferred option) 
the output is empty and I am not able to get this information with any 
other tool. Below is the output for some commands I tried.

I am using kernel 4.2 with ath10k and Candela firmware 10.1 on a 
Qualcomm Atheros QCA988x

Any ideas on how can I get the link quality information?

Thanks,

Inaki

===============================
monet at sc229:~$ ethtool -i wlan2
driver: ath10k_pci
version: 4.2.0+
firmware-version: 10.1.467-ct-_fH-016-b797ef5
bus-info: 0000:0b:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
monet at sc229:~$
===============================
monet at sc229:~$ cat /proc/net/wireless
Inter-| sta-|   Quality        |   Discarded packets               | 
Missed | WE
  face | tus | link level noise |  nwid  crypt   frag  retry   misc | 
beacon | 22
monet at sc229:~$

===============================
monet at sc229:~$ iwconfig wlan2
wlan2     IEEE 802.11abgn  ESSID:"SC228SC229"
           Mode:Ad-Hoc  Frequency:5.24 GHz  Cell: 8E:CE:DE:4F:86:95
           Tx-Power=17 dBm
           Retry short limit:7   RTS thr:off   Fragment thr:off
           Power Management:on

monet at sc229:~$
===============================
monet at sc229:~$ iw wlan2 link
Joined IBSS 8e:ce:de:4f:86:95 (on wlan2)
     SSID: SC228SC229
     freq: 5240
monet at sc229:~$
===============================


From greearb at candelatech.com  Wed Jul 13 07:40:54 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 13 Jul 2016 07:40:54 -0700
Subject: How to obtain Link Quality information
In-Reply-To: <57864BEA.4090202@cttc.cat>
References: <57864BEA.4090202@cttc.cat>
Message-ID: <578652F6.5030909@candelatech.com>

On 07/13/2016 07:10 AM, I?aki Pascual wrote:
> Hi everyone,
>
> I am trying to get link quality information from an 802.11ac interface and it looks like the only way is to use "iw wlan2 scan". I don't like this solution as
> it scans all channels and takes a while.
>
> If I try "cat /proc/net/wireless" (this would be my preferred option) the output is empty and I am not able to get this information with any other tool. Below
> is the output for some commands I tried.
>
> I am using kernel 4.2 with ath10k and Candela firmware 10.1 on a Qualcomm Atheros QCA988x
>
> Any ideas on how can I get the link quality information?

Did you try:

iw dev wlan0 station dump

If you want tx rate reporting, you need to run my driver patches as well
as my firmware, but rx-rate should be reported with stock driver
(and stock firmware, for that matter)...

Thanks,
Ben

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



From ipascual at cttc.cat  Wed Jul 13 08:37:10 2016
From: ipascual at cttc.cat (=?UTF-8?Q?I=c3=b1aki_Pascual?=)
Date: Wed, 13 Jul 2016 17:37:10 +0200
Subject: How to obtain Link Quality information
In-Reply-To: <578652F6.5030909@candelatech.com>
References: <57864BEA.4090202@cttc.cat> <578652F6.5030909@candelatech.com>
Message-ID: <57866026.20504@cttc.cat>

Hi Ben,

yes, I tried, it shows signal value but not link quality :(

onet at sc229:~$ iw dev wlan2 station dump
Station 04:f0:21:18:26:af (on wlan2)
     inactive time:    65 ms
     rx bytes:    3102896
     rx packets:    87403
     tx bytes:    0
     tx packets:    0
     tx retries:    0
     tx failed:    0
     signal:      -63 dBm
     signal avg:    -62 dBm
     tx bitrate:    6.0 MBit/s
     rx bitrate:    6.0 MBit/s
     authorized:    yes
     authenticated:    yes
     preamble:    long
     WMM/WME:    yes
     MFP:        no
     TDLS peer:    no
     connected time:    4476 seconds
monet at sc229:~$

Thanks,

I?aki

On 13/07/16 16:40, Ben Greear wrote:
> On 07/13/2016 07:10 AM, I?aki Pascual wrote:
>> Hi everyone,
>>
>> I am trying to get link quality information from an 802.11ac 
>> interface and it looks like the only way is to use "iw wlan2 scan". I 
>> don't like this solution as
>> it scans all channels and takes a while.
>>
>> If I try "cat /proc/net/wireless" (this would be my preferred option) 
>> the output is empty and I am not able to get this information with 
>> any other tool. Below
>> is the output for some commands I tried.
>>
>> I am using kernel 4.2 with ath10k and Candela firmware 10.1 on a 
>> Qualcomm Atheros QCA988x
>>
>> Any ideas on how can I get the link quality information?
>
> Did you try:
>
> iw dev wlan0 station dump
>
> If you want tx rate reporting, you need to run my driver patches as well
> as my firmware, but rx-rate should be reported with stock driver
> (and stock firmware, for that matter)...
>
> Thanks,
> Ben
>



From greearb at candelatech.com  Wed Jul 13 08:44:23 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 13 Jul 2016 08:44:23 -0700
Subject: How to obtain Link Quality information
In-Reply-To: <57866026.20504@cttc.cat>
References: <57864BEA.4090202@cttc.cat> <578652F6.5030909@candelatech.com>
 <57866026.20504@cttc.cat>
Message-ID: <578661D7.9050804@candelatech.com>

On 07/13/2016 08:37 AM, I?aki Pascual wrote:
> Hi Ben,
>
> yes, I tried, it shows signal value but not link quality :(

Link 'quality' is mostly just a made-up number anyway. Signal quality
is probably the most similar value, but tx and rx bitrates give you the
best idea of how RF is performing in my opinion.  Those rates are only
accurate when sending at least modest amounts of packets though.

Thanks,
Ben


>
> onet at sc229:~$ iw dev wlan2 station dump
> Station 04:f0:21:18:26:af (on wlan2)
>      inactive time:    65 ms
>      rx bytes:    3102896
>      rx packets:    87403
>      tx bytes:    0
>      tx packets:    0
>      tx retries:    0
>      tx failed:    0
>      signal:      -63 dBm
>      signal avg:    -62 dBm
>      tx bitrate:    6.0 MBit/s
>      rx bitrate:    6.0 MBit/s
>      authorized:    yes
>      authenticated:    yes
>      preamble:    long
>      WMM/WME:    yes
>      MFP:        no
>      TDLS peer:    no
>      connected time:    4476 seconds
> monet at sc229:~$
>
> Thanks,
>
> I?aki
>
> On 13/07/16 16:40, Ben Greear wrote:
>> On 07/13/2016 07:10 AM, I?aki Pascual wrote:
>>> Hi everyone,
>>>
>>> I am trying to get link quality information from an 802.11ac interface and it looks like the only way is to use "iw wlan2 scan". I don't like this solution as
>>> it scans all channels and takes a while.
>>>
>>> If I try "cat /proc/net/wireless" (this would be my preferred option) the output is empty and I am not able to get this information with any other tool. Below
>>> is the output for some commands I tried.
>>>
>>> I am using kernel 4.2 with ath10k and Candela firmware 10.1 on a Qualcomm Atheros QCA988x
>>>
>>> Any ideas on how can I get the link quality information?
>>
>> Did you try:
>>
>> iw dev wlan0 station dump
>>
>> If you want tx rate reporting, you need to run my driver patches as well
>> as my firmware, but rx-rate should be reported with stock driver
>> (and stock firmware, for that matter)...
>>
>> Thanks,
>> Ben
>>
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>


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



From greearb at candelatech.com  Wed Jul 13 10:01:14 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 13 Jul 2016 10:01:14 -0700
Subject: Anyone brought up 9984 NIC on x86-64?
Message-ID: <578673DA.1010907@candelatech.com>

I added a few patches to my 4.7 kernel to enable ath10k to load for 9984,
but it immediately crashes due to IOMMU error when trying to allocate
memory.

I'm building the latest linux-ath tree now and will test that when it
is done, but I am curious to know if anyone has successfully booted
9984 on x86-64?

Thanks,
Ben

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



From rmanohar at qti.qualcomm.com  Wed Jul 13 10:26:09 2016
From: rmanohar at qti.qualcomm.com (Manoharan, Rajkumar)
Date: Wed, 13 Jul 2016 17:26:09 +0000
Subject: Anyone brought up 9984 NIC on x86-64?
In-Reply-To: <578673DA.1010907@candelatech.com>
References: <578673DA.1010907@candelatech.com>
Message-ID: <1468430769350.75672@qti.qualcomm.com>

> I added a few patches to my 4.7 kernel to enable ath10k to load for 9984,
> but it immediately crashes due to IOMMU error when trying to allocate
> memory.
> 
> I'm building the latest linux-ath tree now and will test that when it
> is done, but I am curious to know if anyone has successfully booted
> 9984 on x86-64?
> 
Ben,

Are you seeing IOMMU error even after wtih your DMA_BIDIRECTIONAL change? Could you please try with

https://patchwork.kernel.org/patch/9175029/

But increase WMI_MAX_MEM_CHUNK_SIZE to 512.

-Rajkumar


From greearb at candelatech.com  Wed Jul 13 10:22:59 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 13 Jul 2016 10:22:59 -0700
Subject: Anyone brought up 9984 NIC on x86-64?
In-Reply-To: <578673DA.1010907@candelatech.com>
References: <578673DA.1010907@candelatech.com>
Message-ID: <578678F3.9020800@candelatech.com>

On 07/13/2016 10:01 AM, Ben Greear wrote:
> I added a few patches to my 4.7 kernel to enable ath10k to load for 9984,
> but it immediately crashes due to IOMMU error when trying to allocate
> memory.
>
> I'm building the latest linux-ath tree now and will test that when it
> is done, but I am curious to know if anyone has successfully booted
> 9984 on x86-64?
>
> Thanks,
> Ben
>

Today's stock linux-ath and stock 9984 firmware with 9984 NIC crashes on bootup as well :(

How completely frustrating!

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



From greearb at candelatech.com  Wed Jul 13 10:54:00 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 13 Jul 2016 10:54:00 -0700
Subject: Anyone brought up 9984 NIC on x86-64?
In-Reply-To: <1468430769350.75672@qti.qualcomm.com>
References: <578673DA.1010907@candelatech.com>
 <1468430769350.75672@qti.qualcomm.com>
Message-ID: <57868038.3040907@candelatech.com>

On 07/13/2016 10:26 AM, Manoharan, Rajkumar wrote:
>> I added a few patches to my 4.7 kernel to enable ath10k to load for 9984,
>> but it immediately crashes due to IOMMU error when trying to allocate
>> memory.
>>
>> I'm building the latest linux-ath tree now and will test that when it
>> is done, but I am curious to know if anyone has successfully booted
>> 9984 on x86-64?
>>
> Ben,
>
> Are you seeing IOMMU error even after wtih your DMA_BIDIRECTIONAL change? Could you please try with

My BIDIRECTIONAL patch is in my 4.7, and that did not fix the issue.

It is more for the IOMMU access failures that I saw and the redhat user reported.

I would appreciate it if you could roll that patch into your testing set and
make sure you don't see regressions on your systems.  That way maybe it can go
upstream.



For reference, this is today's un-patched linux-ath:

DMA: Out of SW-IOMMU space for 770224 bytes at device 0000:05:00.0
Kernel panic - not syncing: DMA: Random memory could be DMA read

CPU: 5 PID: 288 Comm: kworker/u16:3 Not tainted 4.7.0-rc7-wt-ath+ #34
Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.5 06/07/2013
Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work [ath10k_core]
  0000000000000000 ffff8800d3edfbf0 ffffffff8140abd1 ffffffff81c88b78
  ffff8800d3edfc80 ffff8800d3edfc70 ffffffff811ea260 ffff880000000008
  ffff8800d3edfc80 ffff8800d3edfc18 ffffffff811ea591 ffff88021e34db68
Call Trace:
  [<ffffffff8140abd1>] dump_stack+0x63/0x82
  [<ffffffff811ea260>] panic+0xca/0x216
  [<ffffffff811ea591>] ? printk+0x43/0x4b
  [<ffffffff814382a2>] swiotlb_map_page+0x1a2/0x1d0
  [<ffffffffa07ea1a9>] ath10k_wmi_event_service_ready_work+0x3f9/0x750 [ath10k_core]
  [<ffffffff8113667a>] ? dequeue_entity+0x26a/0xba0
  [<ffffffff8111aebd>] process_one_work+0x15d/0x4b0
  [<ffffffff8111b253>] worker_thread+0x43/0x4e0
  [<ffffffff8111b210>] ? process_one_work+0x4b0/0x4b0
  [<ffffffff81120a34>] kthread+0xc4/0xe0
  [<ffffffff81853e9f>] ret_from_fork+0x1f/0x40
  [<ffffffff81120970>] ? kthread_worker_fn+0x180/0x180
Kernel Offset: disabled
---[ end Kernel panic - not syncing: DMA: Random memory could be DMA read

I tried with your patch set to 512 block size, but that fails with
similar DMA error and reboots.

Your original patch with 256 block size boots up the firmware OK on my
system.

I guess I'll do more testing with your original 256k chunk patch and see
how that works.


Thanks,
Ben

>
> https://patchwork.kernel.org/patch/9175029/
>
> But increase WMI_MAX_MEM_CHUNK_SIZE to 512.
>
> -Rajkumar
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>


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



From adrian at freebsd.org  Wed Jul 13 12:17:47 2016
From: adrian at freebsd.org (Adrian Chadd)
Date: Wed, 13 Jul 2016 12:17:47 -0700
Subject: Anyone brought up 9984 NIC on x86-64?
In-Reply-To: <57868038.3040907@candelatech.com>
References: <578673DA.1010907@candelatech.com>
 <1468430769350.75672@qti.qualcomm.com>
 <57868038.3040907@candelatech.com>
Message-ID: <CAJ-Vmo=v2BSXP1UzzX3B_PJqQxtRVsQL2hJ0MFJgPujOR9yCPQ@mail.gmail.com>

On 13 July 2016 at 10:54, Ben Greear <greearb at candelatech.com> wrote:

>
>
> For reference, this is today's un-patched linux-ath:
>
> DMA: Out of SW-IOMMU space for 770224 bytes at device 0000:05:00.0
> Kernel panic - not syncing: DMA: Random memory could be DMA read
>

Hi,

So I looked at this code in a bit more detail. Ideally for large
requests you shouldn't be asking for separate bounce buffers, you'd
just allocate memory that was within the 32 bit physmem boundary so
you don't /need/ a bounce buffer.

That's likely what's tripping things up.

Now, on freebsd I'd just request memory that was under 32 bit and the
memory allocator would fail the allocation if it wasn't available.
Bounce buffers get used for general system things like mbufs (our
skbs), disk buffers, etc that can come from any memory and need a
temporary mapping. This kind of stuff isn't temporary.

So to save me having to dig into what the linux kernel allocator
provides (since I'm really a freebsd developer at heart!), what's the
"right" way to maintain large, non-ephermal memory allocation that may
have to do DMA? eg, like descriptor rings, etc.



-adrian


From greearb at candelatech.com  Wed Jul 13 14:14:54 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 13 Jul 2016 14:14:54 -0700
Subject: Anyone brought up 9984 NIC on x86-64?
In-Reply-To: <57868038.3040907@candelatech.com>
References: <578673DA.1010907@candelatech.com>
 <1468430769350.75672@qti.qualcomm.com> <57868038.3040907@candelatech.com>
Message-ID: <5786AF4E.50200@candelatech.com>

On 07/13/2016 10:54 AM, Ben Greear wrote:
> On 07/13/2016 10:26 AM, Manoharan, Rajkumar wrote:
>>> I added a few patches to my 4.7 kernel to enable ath10k to load for 9984,
>>> but it immediately crashes due to IOMMU error when trying to allocate
>>> memory.
>>>
>>> I'm building the latest linux-ath tree now and will test that when it
>>> is done, but I am curious to know if anyone has successfully booted
>>> 9984 on x86-64?
>>>
>> Ben,
>>
>> Are you seeing IOMMU error even after wtih your DMA_BIDIRECTIONAL change? Could you please try with
>
> My BIDIRECTIONAL patch is in my 4.7, and that did not fix the issue.
>
> It is more for the IOMMU access failures that I saw and the redhat user reported.
>
> I would appreciate it if you could roll that patch into your testing set and
> make sure you don't see regressions on your systems.  That way maybe it can go
> upstream.
>
>
>
> For reference, this is today's un-patched linux-ath:
>
> DMA: Out of SW-IOMMU space for 770224 bytes at device 0000:05:00.0
> Kernel panic - not syncing: DMA: Random memory could be DMA read
>
> CPU: 5 PID: 288 Comm: kworker/u16:3 Not tainted 4.7.0-rc7-wt-ath+ #34
> Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.5 06/07/2013
> Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work [ath10k_core]
>   0000000000000000 ffff8800d3edfbf0 ffffffff8140abd1 ffffffff81c88b78
>   ffff8800d3edfc80 ffff8800d3edfc70 ffffffff811ea260 ffff880000000008
>   ffff8800d3edfc80 ffff8800d3edfc18 ffffffff811ea591 ffff88021e34db68
> Call Trace:
>   [<ffffffff8140abd1>] dump_stack+0x63/0x82
>   [<ffffffff811ea260>] panic+0xca/0x216
>   [<ffffffff811ea591>] ? printk+0x43/0x4b
>   [<ffffffff814382a2>] swiotlb_map_page+0x1a2/0x1d0
>   [<ffffffffa07ea1a9>] ath10k_wmi_event_service_ready_work+0x3f9/0x750 [ath10k_core]
>   [<ffffffff8113667a>] ? dequeue_entity+0x26a/0xba0
>   [<ffffffff8111aebd>] process_one_work+0x15d/0x4b0
>   [<ffffffff8111b253>] worker_thread+0x43/0x4e0
>   [<ffffffff8111b210>] ? process_one_work+0x4b0/0x4b0
>   [<ffffffff81120a34>] kthread+0xc4/0xe0
>   [<ffffffff81853e9f>] ret_from_fork+0x1f/0x40
>   [<ffffffff81120970>] ? kthread_worker_fn+0x180/0x180
> Kernel Offset: disabled
> ---[ end Kernel panic - not syncing: DMA: Random memory could be DMA read
>
> I tried with your patch set to 512 block size, but that fails with
> similar DMA error and reboots.
>
> Your original patch with 256 block size boots up the firmware OK on my
> system.
>
> I guess I'll do more testing with your original 256k chunk patch and see
> how that works.

I just realized that I was booting with "intel_iommu=off", that is probably why
I had to enable the 256k chunk patch.

And FYI, at least my 9984 firmware appears to blow up when passed multiple
chunks...I'm still trying to figure out exactly why.

That said, would be nice if ath10k worked on systems w/out intel-iommu too...

Thanks,
Ben

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



From s.gottschall at dd-wrt.com  Wed Jul 13 16:12:24 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Thu, 14 Jul 2016 01:12:24 +0200
Subject: Anyone brought up 9984 NIC on x86-64?
In-Reply-To: <1468430769350.75672@qti.qualcomm.com>
References: <578673DA.1010907@candelatech.com>
 <1468430769350.75672@qti.qualcomm.com>
Message-ID: <6b019cbc-e909-540e-95d1-b14f2be0128d@dd-wrt.com>

Am 13.07.2016 um 19:26 schrieb Manoharan, Rajkumar:
>> I added a few patches to my 4.7 kernel to enable ath10k to load for 9984,
>> but it immediately crashes due to IOMMU error when trying to allocate
>> memory.
>>
>> I'm building the latest linux-ath tree now and will test that when it
>> is done, but I am curious to know if anyone has successfully booted
>> 9984 on x86-64?
>>
> Ben,
>
> Are you seeing IOMMU error even after wtih your DMA_BIDIRECTIONAL change? Could you please try with
>
> https://patchwork.kernel.org/patch/9175029/
>
> But increase WMI_MAX_MEM_CHUNK_SIZE to 512.
while debugging i found out that it will allocate up to 800 kb here on 
99xx chipsets. truncating  this value in any way will definitly cause 
out of bound access conditions.
so i assume the code is wrong. the firmware requests the size, so it 
should get it. otherwise unexpected behaviour is guaranteed

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


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From yeohchunyeow at gmail.com  Thu Jul 14 08:41:42 2016
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Thu, 14 Jul 2016 23:41:42 +0800
Subject: How to obtain Link Quality information
In-Reply-To: <578661D7.9050804@candelatech.com>
References: <57864BEA.4090202@cttc.cat> <578652F6.5030909@candelatech.com>
 <57866026.20504@cttc.cat> <578661D7.9050804@candelatech.com>
Message-ID: <CAEFj98473uC94zuU-Y4pMjeEy7ZDDMysN2H7SBUctseEhP9G=w@mail.gmail.com>

tx rate reporting for Candela firmware is working? Any changes go into
the QCA released firmware?

---
Chun-Yeow

On Wed, Jul 13, 2016 at 11:44 PM, Ben Greear <greearb at candelatech.com> wrote:
> On 07/13/2016 08:37 AM, I?aki Pascual wrote:
>>
>> Hi Ben,
>>
>> yes, I tried, it shows signal value but not link quality :(
>
>
> Link 'quality' is mostly just a made-up number anyway. Signal quality
> is probably the most similar value, but tx and rx bitrates give you the
> best idea of how RF is performing in my opinion.  Those rates are only
> accurate when sending at least modest amounts of packets though.
>
> Thanks,
> Ben
>
>
>
>>
>> onet at sc229:~$ iw dev wlan2 station dump
>> Station 04:f0:21:18:26:af (on wlan2)
>>      inactive time:    65 ms
>>      rx bytes:    3102896
>>      rx packets:    87403
>>      tx bytes:    0
>>      tx packets:    0
>>      tx retries:    0
>>      tx failed:    0
>>      signal:      -63 dBm
>>      signal avg:    -62 dBm
>>      tx bitrate:    6.0 MBit/s
>>      rx bitrate:    6.0 MBit/s
>>      authorized:    yes
>>      authenticated:    yes
>>      preamble:    long
>>      WMM/WME:    yes
>>      MFP:        no
>>      TDLS peer:    no
>>      connected time:    4476 seconds
>> monet at sc229:~$
>>
>> Thanks,
>>
>> I?aki
>>
>> On 13/07/16 16:40, Ben Greear wrote:
>>>
>>> On 07/13/2016 07:10 AM, I?aki Pascual wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> I am trying to get link quality information from an 802.11ac interface
>>>> and it looks like the only way is to use "iw wlan2 scan". I don't like this
>>>> solution as
>>>> it scans all channels and takes a while.
>>>>
>>>> If I try "cat /proc/net/wireless" (this would be my preferred option)
>>>> the output is empty and I am not able to get this information with any other
>>>> tool. Below
>>>> is the output for some commands I tried.
>>>>
>>>> I am using kernel 4.2 with ath10k and Candela firmware 10.1 on a
>>>> Qualcomm Atheros QCA988x
>>>>
>>>> Any ideas on how can I get the link quality information?
>>>
>>>
>>> Did you try:
>>>
>>> iw dev wlan0 station dump
>>>
>>> If you want tx rate reporting, you need to run my driver patches as well
>>> as my firmware, but rx-rate should be reported with stock driver
>>> (and stock firmware, for that matter)...
>>>
>>> Thanks,
>>> Ben
>>>
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From greearb at candelatech.com  Thu Jul 14 08:44:08 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 14 Jul 2016 08:44:08 -0700
Subject: How to obtain Link Quality information
In-Reply-To: <CAEFj98473uC94zuU-Y4pMjeEy7ZDDMysN2H7SBUctseEhP9G=w@mail.gmail.com>
References: <57864BEA.4090202@cttc.cat> <578652F6.5030909@candelatech.com>
 <57866026.20504@cttc.cat> <578661D7.9050804@candelatech.com>
 <CAEFj98473uC94zuU-Y4pMjeEy7ZDDMysN2H7SBUctseEhP9G=w@mail.gmail.com>
Message-ID: <5787B348.6040205@candelatech.com>

On 07/14/2016 08:41 AM, Yeoh Chun-Yeow wrote:
> tx rate reporting for Candela firmware is working? Any changes go into
> the QCA released firmware?

It is working in CT firmware (when using my patched ath10k driver to
support the feature), and I have no way to get changes into
upstream QCA firmware.

Thanks,
Ben

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



From arnagara at qti.qualcomm.com  Fri Jul 15 04:49:09 2016
From: arnagara at qti.qualcomm.com (Nagarajan, Ashok Raj)
Date: Fri, 15 Jul 2016 11:49:09 +0000
Subject: ath10k/QCA9980 - Issues introduced in wireless testing 2016-05
In-Reply-To: <575ABDA2.9020609@candelatech.com>
References: <ff65514a-47a3-2f32-658c-a2177401aa9a@bk.ru>
 <CA+BoTQmJ+JruxZ9WsG8Dnz=cwNY+e3Dy=g74-brS+0OE_5iu0Q@mail.gmail.com>
 <d836933e-ddbb-d10c-0715-6bce4396fd41@nbd.name>
 <877fdxfd2l.fsf@kamboji.qca.qualcomm.com> <575AB829.10101@candelatech.com>
 <f80db123-9b8a-289d-aed8-12531db13424@nbd.name>,
 <575ABDA2.9020609@candelatech.com>
Message-ID: <1468583339047.52453@qti.qualcomm.com>

> On 06/10/2016 05:57 AM, Felix Fietkau wrote:
>>> On 2016-06-10 14:52, Ben Greear wrote:
>>> This looks a lot like the problems I was having.
>>>
>>> Two of these 5 patches recently made it upstream (but may not be in LEDE yet),
>>> but the other patches also were related to memory corruption.
>>>
>>> See my patches posted on 4/1/16:
>>>
>>> https://patchwork.kernel.org/project/ath10k/list/
>>>
>>> I don't know where the 5/5 patch ended up.
>> I had already asked affected users to test with those patches (I have a
>> commit that adds them in my staging tree), but it did not resolve the issue.
>
>Ok, must be something else then.
>
>If you can run on x86 under KASAN it may provide some clues..that is how I eventually
>made progress on the issues I was seeing.  My rebase onto 3.7 has been slow and painful,
>but I should be ready to start testing that sometime soon, maybe I can reproduce something
>there.

Hi Benz,

Could you please check with the following diff if it is solving your issue?

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 6f19fca..c192a41 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1528,7 +1528,7 @@ static void ath10k_htt_rx_h_filter(struct ath10k *ar,
static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
{
        struct ath10k *ar = htt->ar;
-       static struct ieee80211_rx_status rx_status;
+       struct ieee80211_rx_status *rx_status = &htt->rx_status;
        struct sk_buff_head amsdu;
        int ret;
 
@@ -1553,11 +1553,11 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
        }
 
        ath10k_pktlog_rx(ar, &amsdu);
-       ath10k_htt_rx_h_ppdu(ar, &amsdu, &rx_status, 0xffff);
+       ath10k_htt_rx_h_ppdu(ar, &amsdu, rx_status, 0xffff);
        ath10k_htt_rx_h_unchain(ar, &amsdu, ret > 0);
-       ath10k_htt_rx_h_filter(ar, &amsdu, &rx_status);
-       ath10k_htt_rx_h_mpdu(ar, &amsdu, &rx_status);
-       ath10k_htt_rx_h_deliver(ar, &amsdu, &rx_status);
+       ath10k_htt_rx_h_filter(ar, &amsdu, rx_status);
+       ath10k_htt_rx_h_mpdu(ar, &amsdu, rx_status);
+       ath10k_htt_rx_h_deliver(ar, &amsdu, rx_status);

Thanks,
Ashok

>Thanks,
>Ben


From joshbendavid at gmail.com  Sat Jul 16 09:24:11 2016
From: joshbendavid at gmail.com (Josh Bendavid)
Date: Sat, 16 Jul 2016 18:24:11 +0200
Subject: ath10k/QCA9980 - Issues introduced in wireless testing 2016-05
Message-ID: <CAD1MEweVh5ubi6sa609ip294WmSsPXkhOtzdJrH2TbLoQg=WBg@mail.gmail.com>

This patch solves the stack traces for me in lede trunk with the same
TP-Link Archer C2600 (QCA9980).

I still have occasionally clients "disconnected due to excessive
missing ACKs", but this is probably a separate issue.

Thanks,
Josh


From kvalo at qca.qualcomm.com  Mon Jul 18 13:08:05 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Mon, 18 Jul 2016 22:08:05 +0200
Subject: ath10k: add support for controlling tx power to a station
In-Reply-To: <1465925914-6404-1-git-send-email-arnagara@qti.qualcomm.com>
Message-ID: <75a921ad7f1940f6ba046564f67c508d@euamsexm01a.eu.qualcomm.com>

Ashok Raj Nagarajan <arnagara at qti.qualcomm.com> wrote:
> This patch will add the support to control the transmit power for traffic
> to a station associated with the AP. Userspace provide the transmit power
> value in mBm units and the allowed range is from 0 to 70. Underlying FW
> will enforce that the maximum tx power will be based on the regulatory
> requirements. If the user given transmit power is greater than the allowed
> tx power in the given channel, then the FW will use the maximum tx power
> in the same channel.
> 
> When 0 is sent to the FW as tx power, it will revert to the automatic tx
> power for the station.
> 
> Signed-off-by: Ashok Raj Nagarajan <arnagara at qti.qualcomm.com>

(A note to patchwork)

Depends on these patches:

cfg80211: Add support to set tx power for a station associated
https://patchwork.kernel.org/patch/9176355/

mac80211: store tx power value from user to station
https://patchwork.kernel.org/patch/9176359/

Both are currently in state Changes Requested.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9176353/



From fengguang.wu at intel.com  Mon Jul 18 18:14:19 2016
From: fengguang.wu at intel.com (kbuild test robot)
Date: Tue, 19 Jul 2016 09:14:19 +0800
Subject: [ath6kl:pending 14/24] drivers/mtd/devices/bcm47xxsflash.c:299:2:
 error: implicit declaration of function 'ioremap_cache'
Message-ID: <201607190916.c8xDOxpA%fengguang.wu@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending
head:   7a1b79bd39dda1f12b9f6708583250f40354c981
commit: 57d8f7dd2132df3ac21044e93a8ecdc9744b4459 [14/24] bcma: allow enabling serial flash support on non-MIPS SoCs
config: cris-allmodconfig (attached as .config)
compiler: cris-linux-gcc (GCC) 4.6.3
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout 57d8f7dd2132df3ac21044e93a8ecdc9744b4459
        # save the attached .config to linux build tree
        make.cross ARCH=cris 

All error/warnings (new ones prefixed by >>):

   drivers/mtd/devices/bcm47xxsflash.c: In function 'bcm47xxsflash_bcma_probe':
>> drivers/mtd/devices/bcm47xxsflash.c:299:2: error: implicit declaration of function 'ioremap_cache' [-Werror=implicit-function-declaration]
>> drivers/mtd/devices/bcm47xxsflash.c:299:15: warning: assignment makes pointer from integer without a cast [enabled by default]
   cc1: some warnings being treated as errors

vim +/ioremap_cache +299 drivers/mtd/devices/bcm47xxsflash.c

5fe42d5bf Rafa? Mi?ecki 2012-09-17  283  
5651d6aaf Brian Norris  2016-02-26  284  	b47s = devm_kzalloc(dev, sizeof(*b47s), GFP_KERNEL);
d2b1bd142 Libo Chen     2013-05-30  285  	if (!b47s)
d2b1bd142 Libo Chen     2013-05-30  286  		return -ENOMEM;
a2f74a7da Rafa? Mi?ecki 2013-01-06  287  	sflash->priv = b47s;
a2f74a7da Rafa? Mi?ecki 2013-01-06  288  
5651d6aaf Brian Norris  2016-02-26  289  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
5651d6aaf Brian Norris  2016-02-26  290  	if (!res) {
5651d6aaf Brian Norris  2016-02-26  291  		dev_err(dev, "invalid resource\n");
5651d6aaf Brian Norris  2016-02-26  292  		return -EINVAL;
5651d6aaf Brian Norris  2016-02-26  293  	}
5651d6aaf Brian Norris  2016-02-26  294  	if (!devm_request_mem_region(dev, res->start, resource_size(res),
5651d6aaf Brian Norris  2016-02-26  295  				     res->name)) {
5651d6aaf Brian Norris  2016-02-26  296  		dev_err(dev, "can't request region for resource %pR\n", res);
5651d6aaf Brian Norris  2016-02-26  297  		return -EBUSY;
5651d6aaf Brian Norris  2016-02-26  298  	}
5651d6aaf Brian Norris  2016-02-26 @299  	b47s->window = ioremap_cache(res->start, resource_size(res));
5651d6aaf Brian Norris  2016-02-26  300  	if (!b47s->window) {
5651d6aaf Brian Norris  2016-02-26  301  		dev_err(dev, "ioremap failed for resource %pR\n", res);
5651d6aaf Brian Norris  2016-02-26  302  		return -ENOMEM;
5651d6aaf Brian Norris  2016-02-26  303  	}
5651d6aaf Brian Norris  2016-02-26  304  
41c81536e Rafa? Mi?ecki 2013-03-06  305  	b47s->bcma_cc = container_of(sflash, struct bcma_drv_cc, sflash);
265dfbd9a Rafa? Mi?ecki 2013-03-24  306  	b47s->cc_read = bcm47xxsflash_bcma_cc_read;
265dfbd9a Rafa? Mi?ecki 2013-03-24  307  	b47s->cc_write = bcm47xxsflash_bcma_cc_write;

:::::: The code at line 299 was first introduced by commit
:::::: 5651d6aaf489d1db48c253cf884b40214e91c2c5 mtd: bcm47xxsflash: use ioremap_cache() instead of KSEG0ADDR()

:::::: TO: Brian Norris <computersforpeace at gmail.com>
:::::: CC: Brian Norris <computersforpeace at gmail.com>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 38644 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160719/4cd81d1e/attachment-0001.obj>

From zajec5 at gmail.com  Mon Jul 18 22:52:18 2016
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Tue, 19 Jul 2016 07:52:18 +0200
Subject: [ath6kl:pending 14/24] drivers/mtd/devices/bcm47xxsflash.c:299:2:
 error: implicit declaration of function 'ioremap_cache'
In-Reply-To: <201607190916.c8xDOxpA%fengguang.wu@intel.com>
References: <201607190916.c8xDOxpA%fengguang.wu@intel.com>
Message-ID: <e3e378f0-8ff9-09a3-7295-ada51dc6e16d@gmail.com>

On 07/19/2016 03:14 AM, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending
> head:   7a1b79bd39dda1f12b9f6708583250f40354c981
> commit: 57d8f7dd2132df3ac21044e93a8ecdc9744b4459 [14/24] bcma: allow enabling serial flash support on non-MIPS SoCs
> config: cris-allmodconfig (attached as .config)
> compiler: cris-linux-gcc (GCC) 4.6.3
> reproduce:
>         wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         git checkout 57d8f7dd2132df3ac21044e93a8ecdc9744b4459
>         # save the attached .config to linux build tree
>         make.cross ARCH=cris
>
> All error/warnings (new ones prefixed by >>):
>
>    drivers/mtd/devices/bcm47xxsflash.c: In function 'bcm47xxsflash_bcma_probe':
>>> drivers/mtd/devices/bcm47xxsflash.c:299:2: error: implicit declaration of function 'ioremap_cache' [-Werror=implicit-function-declaration]
>>> drivers/mtd/devices/bcm47xxsflash.c:299:15: warning: assignment makes pointer from integer without a cast [enabled by default]
>    cc1: some warnings being treated as errors

Oh, great :( With commit:
5651d6aaf489 ("mtd: bcm47xxsflash: use ioremap_cache() instead of KSEG0ADDR()")
we believed to make this driver compilable on all architectures. It seems that
ioremap_cache is available only on arm, arm64, ia64, mips, sh, x86 and xtensa.

I noticed that kernel/memremap.c implements ioremap_cache on its own for archs
that don't provide it. There is a comment in this file:
/* temporary while we convert existing ioremap_cache users to memremap */

Should we use memremap? I don't understand this function well, it seems I could
call it with with MEMREMAP_WB flag (and trigger ioremap_cache call), but is it a
correct thing to do?

Or should we simply make some symbol (CONFIG_MTD_BCM47XXSFLASH?) depend on
ARM || MIPS?


> vim +/ioremap_cache +299 drivers/mtd/devices/bcm47xxsflash.c
>
> 5fe42d5bf Rafa? Mi?ecki 2012-09-17  283
> 5651d6aaf Brian Norris  2016-02-26  284  	b47s = devm_kzalloc(dev, sizeof(*b47s), GFP_KERNEL);
> d2b1bd142 Libo Chen     2013-05-30  285  	if (!b47s)
> d2b1bd142 Libo Chen     2013-05-30  286  		return -ENOMEM;
> a2f74a7da Rafa? Mi?ecki 2013-01-06  287  	sflash->priv = b47s;
> a2f74a7da Rafa? Mi?ecki 2013-01-06  288
> 5651d6aaf Brian Norris  2016-02-26  289  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> 5651d6aaf Brian Norris  2016-02-26  290  	if (!res) {
> 5651d6aaf Brian Norris  2016-02-26  291  		dev_err(dev, "invalid resource\n");
> 5651d6aaf Brian Norris  2016-02-26  292  		return -EINVAL;
> 5651d6aaf Brian Norris  2016-02-26  293  	}
> 5651d6aaf Brian Norris  2016-02-26  294  	if (!devm_request_mem_region(dev, res->start, resource_size(res),
> 5651d6aaf Brian Norris  2016-02-26  295  				     res->name)) {
> 5651d6aaf Brian Norris  2016-02-26  296  		dev_err(dev, "can't request region for resource %pR\n", res);
> 5651d6aaf Brian Norris  2016-02-26  297  		return -EBUSY;
> 5651d6aaf Brian Norris  2016-02-26  298  	}
> 5651d6aaf Brian Norris  2016-02-26 @299  	b47s->window = ioremap_cache(res->start, resource_size(res));
> 5651d6aaf Brian Norris  2016-02-26  300  	if (!b47s->window) {
> 5651d6aaf Brian Norris  2016-02-26  301  		dev_err(dev, "ioremap failed for resource %pR\n", res);
> 5651d6aaf Brian Norris  2016-02-26  302  		return -ENOMEM;
> 5651d6aaf Brian Norris  2016-02-26  303  	}
> 5651d6aaf Brian Norris  2016-02-26  304
> 41c81536e Rafa? Mi?ecki 2013-03-06  305  	b47s->bcma_cc = container_of(sflash, struct bcma_drv_cc, sflash);
> 265dfbd9a Rafa? Mi?ecki 2013-03-24  306  	b47s->cc_read = bcm47xxsflash_bcma_cc_read;
> 265dfbd9a Rafa? Mi?ecki 2013-03-24  307  	b47s->cc_write = bcm47xxsflash_bcma_cc_write;
>
> :::::: The code at line 299 was first introduced by commit
> :::::: 5651d6aaf489d1db48c253cf884b40214e91c2c5 mtd: bcm47xxsflash: use ioremap_cache() instead of KSEG0ADDR()
>
> :::::: TO: Brian Norris <computersforpeace at gmail.com>
> :::::: CC: Brian Norris <computersforpeace at gmail.com>
>
> ---
> 0-DAY kernel test infrastructure                Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
>


From zajec5 at gmail.com  Mon Jul 18 22:56:06 2016
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Tue, 19 Jul 2016 07:56:06 +0200
Subject: [ath6kl:pending 14/24] drivers/mtd/devices/bcm47xxsflash.c:299:2:
 error: implicit declaration of function 'ioremap_cache'
In-Reply-To: <201607190916.c8xDOxpA%fengguang.wu@intel.com>
References: <201607190916.c8xDOxpA%fengguang.wu@intel.com>
Message-ID: <b1bcfe6c-6875-b01b-7d10-ea8d1e00adfc@gmail.com>

Resending reply with proper To/Cc.

On 07/19/2016 03:14 AM, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending
> head:   7a1b79bd39dda1f12b9f6708583250f40354c981
> commit: 57d8f7dd2132df3ac21044e93a8ecdc9744b4459 [14/24] bcma: allow enabling serial flash support on non-MIPS SoCs
> config: cris-allmodconfig (attached as .config)
> compiler: cris-linux-gcc (GCC) 4.6.3
> reproduce:
>         wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         git checkout 57d8f7dd2132df3ac21044e93a8ecdc9744b4459
>         # save the attached .config to linux build tree
>         make.cross ARCH=cris
>
> All error/warnings (new ones prefixed by >>):
>
>    drivers/mtd/devices/bcm47xxsflash.c: In function 'bcm47xxsflash_bcma_probe':
>>> drivers/mtd/devices/bcm47xxsflash.c:299:2: error: implicit declaration of function 'ioremap_cache' [-Werror=implicit-function-declaration]
>>> drivers/mtd/devices/bcm47xxsflash.c:299:15: warning: assignment makes pointer from integer without a cast [enabled by default]
>    cc1: some warnings being treated as errors

Oh, great :( With commit:
5651d6aaf489 ("mtd: bcm47xxsflash: use ioremap_cache() instead of KSEG0ADDR()")
we believed to make this driver compilable on all architectures. It seems that
ioremap_cache is available only on arm, arm64, ia64, mips, sh, x86 and xtensa.

I noticed that kernel/memremap.c implements ioremap_cache on its own for archs
that don't provide it. There is a comment in this file:
/* temporary while we convert existing ioremap_cache users to memremap */

Should we use memremap? I don't understand this function well, it seems I could
call it with with MEMREMAP_WB flag (and trigger ioremap_cache call), but is it a
correct thing to do?

Or should we simply make some symbol (CONFIG_MTD_BCM47XXSFLASH?) depend on
ARM || MIPS?


> vim +/ioremap_cache +299 drivers/mtd/devices/bcm47xxsflash.c
>
> 5fe42d5bf Rafa? Mi?ecki 2012-09-17  283
> 5651d6aaf Brian Norris  2016-02-26  284  	b47s = devm_kzalloc(dev, sizeof(*b47s), GFP_KERNEL);
> d2b1bd142 Libo Chen     2013-05-30  285  	if (!b47s)
> d2b1bd142 Libo Chen     2013-05-30  286  		return -ENOMEM;
> a2f74a7da Rafa? Mi?ecki 2013-01-06  287  	sflash->priv = b47s;
> a2f74a7da Rafa? Mi?ecki 2013-01-06  288
> 5651d6aaf Brian Norris  2016-02-26  289  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> 5651d6aaf Brian Norris  2016-02-26  290  	if (!res) {
> 5651d6aaf Brian Norris  2016-02-26  291  		dev_err(dev, "invalid resource\n");
> 5651d6aaf Brian Norris  2016-02-26  292  		return -EINVAL;
> 5651d6aaf Brian Norris  2016-02-26  293  	}
> 5651d6aaf Brian Norris  2016-02-26  294  	if (!devm_request_mem_region(dev, res->start, resource_size(res),
> 5651d6aaf Brian Norris  2016-02-26  295  				     res->name)) {
> 5651d6aaf Brian Norris  2016-02-26  296  		dev_err(dev, "can't request region for resource %pR\n", res);
> 5651d6aaf Brian Norris  2016-02-26  297  		return -EBUSY;
> 5651d6aaf Brian Norris  2016-02-26  298  	}
> 5651d6aaf Brian Norris  2016-02-26 @299  	b47s->window = ioremap_cache(res->start, resource_size(res));
> 5651d6aaf Brian Norris  2016-02-26  300  	if (!b47s->window) {
> 5651d6aaf Brian Norris  2016-02-26  301  		dev_err(dev, "ioremap failed for resource %pR\n", res);
> 5651d6aaf Brian Norris  2016-02-26  302  		return -ENOMEM;
> 5651d6aaf Brian Norris  2016-02-26  303  	}
> 5651d6aaf Brian Norris  2016-02-26  304
> 41c81536e Rafa? Mi?ecki 2013-03-06  305  	b47s->bcma_cc = container_of(sflash, struct bcma_drv_cc, sflash);
> 265dfbd9a Rafa? Mi?ecki 2013-03-24  306  	b47s->cc_read = bcm47xxsflash_bcma_cc_read;
> 265dfbd9a Rafa? Mi?ecki 2013-03-24  307  	b47s->cc_write = bcm47xxsflash_bcma_cc_write;
>
> :::::: The code at line 299 was first introduced by commit
> :::::: 5651d6aaf489d1db48c253cf884b40214e91c2c5 mtd: bcm47xxsflash: use ioremap_cache() instead of KSEG0ADDR()
>
> :::::: TO: Brian Norris <computersforpeace at gmail.com>
> :::::: CC: Brian Norris <computersforpeace at gmail.com>
>
> ---
> 0-DAY kernel test infrastructure                Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
>


From sgruszka at redhat.com  Tue Jul 19 00:09:33 2016
From: sgruszka at redhat.com (Stanislaw Gruszka)
Date: Tue, 19 Jul 2016 09:09:33 +0200
Subject: ath10k fail to load firmware
Message-ID: <20160719070932.GA2751@redhat.com>

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.

Thanks
Stanislaw
-------------- next part --------------
[ 3657.824833] ath10k_pci 0000:01:00.0: irq 127 for MSI/MSI-X
[ 3657.824850] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[ 3658.026412] ath10k_pci 0000:01:00.0: Direct firmware load failed with error -2
[ 3658.026415] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 3718.215979] ath10k_pci 0000:01:00.0: Direct firmware load failed with error -2
[ 3718.215983] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 3778.377278] ath10k_pci 0000:01:00.0: Direct firmware load failed with error -2
[ 3778.377281] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 3838.538737] ath10k_pci 0000:01:00.0: could not fetch firmware file 'ath10k/QCA6174/hw3.0/firmware-5.bin': -2
[ 3838.539093] ath10k_pci 0000:01:00.0: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1028:0310
[ 3838.539096] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 0 testmode 0
[ 3838.539676] ath10k_pci 0000:01:00.0: firmware ver WLAN.RM.2.0-00180-QCARMSWPZ-1 api 4 features wowlan,ignore-otp,no-4addr-pad crc32 75dee6c5
[ 3838.601884] ath10k_pci 0000: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 0000:01:00.0: board_file api 1 bmi_id N/A crc32 ed5f849a
[ 3840.719768] ath10k_pci 0000:01:00.0: htt-ver 3.26 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
[ 3840.774653] ath: EEPROM regdomain: 0x6c
[ 3840.774657] ath: EEPROM indicates we should expect a direct regpair map
[ 3840.774659] ath: Country alpha2 being used: 00
[ 3840.774660] ath: Regpair used: 0x6c
[ 3840.806880] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
[ 3846.032903] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 3849.032954] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 3855.033103] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 3860.316236] ath10k_pci 0000:01:00.0: failed to enable dynamic BW: -11
[ 3866.316381] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 3871.595515] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 3874.595587] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 3880.595733] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 3885.878861] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 3888.878966] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 3894.879083] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 3900.159214] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 3903.159290] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 3909.159436] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 3914.441566] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 3917.441639] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 3923.441811] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 3928.721921] ath10k_pci 0000:01:00.0: failed to set rx-chainmask: -11, req 0x3
[ 3931.721989] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 3937.722141] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 3943.006271] ath10k_pci 0000:01:00.0: failed to enable dynamic BW: -11
[ 3949.006419] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 3954.289546] ath10k_pci 0000:01:00.0: failed to set rx-chainmask: -11, req 0x3
[ 3957.289619] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 3963.291067] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 3968.595899] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 3971.595972] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 3977.596123] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 3982.888250] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 3985.888324] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 3991.888474] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 3997.170623] ath10k_pci 0000:01:00.0: failed to set rx-chainmask: -11, req 0x3
[ 4000.170679] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4005.673217] usb 1-3: USB disconnect, device number 9
[ 4006.170824] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4011.453957] ath10k_pci 0000:01:00.0: failed to enable dynamic BW: -11
[ 4017.454133] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4022.733233] ath10k_pci 0000:01:00.0: failed to enable adaptive qcs: -11
[ 4028.733380] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4034.014508] ath10k_pci 0000:01:00.0: failed to set rx-chainmask: -11, req 0x3
[ 4037.014584] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4043.014732] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4048.297860] ath10k_pci 0000:01:00.0: failed to set rx-chainmask: -11, req 0x3
[ 4051.297952] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4057.298086] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4062.582212] ath10k_pci 0000:01:00.0: failed to enable dynamic BW: -11
[ 4068.582368] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4073.866492] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 4076.866569] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4082.866730] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4088.145842] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 4091.145914] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4097.146076] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4102.427194] ath10k_pci 0000:01:00.0: failed to enable dynamic BW: -11
[ 4108.427367] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4113.708515] ath10k_pci 0000:01:00.0: failed to set rx-chainmask: -11, req 0x3
[ 4116.708558] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4122.708698] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4127.986823] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 4130.986897] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4136.987045] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4142.269176] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 4145.269248] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4151.269508] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4156.549528] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 4159.549604] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4165.549748] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4170.829877] ath10k_pci 0000:01:00.0: failed to set rx-chainmask: -11, req 0x3
[ 4173.829952] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4179.830102] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4185.110229] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 4188.110302] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4194.110449] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4199.390615] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 4202.390653] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4208.390800] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4213.671964] ath10k_pci 0000:01:00.0: failed to enable dynamic BW: -11
[ 4219.672080] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4224.951209] ath10k_pci 0000:01:00.0: failed to set rx-chainmask: -11, req 0x3
[ 4227.951283] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4233.951430] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4239.231565] ath10k_pci 0000:01:00.0: failed to set rx-chainmask: -11, req 0x3
[ 4242.231863] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4248.231786] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4253.512913] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 4256.512987] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4262.513152] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4267.794282] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 4270.794346] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4276.794486] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4282.077630] ath10k_pci 0000:01:00.0: failed to set rx-chainmask: -11, req 0x3
[ 4285.077694] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4291.077838] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4296.356967] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 4299.357040] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4305.357187] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4310.637320] ath10k_pci 0000:01:00.0: failed to enable dynamic BW: -11
[ 4316.637467] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4321.917596] ath10k_pci 0000:01:00.0: failed to enable dynamic BW: -11
[ 4327.917742] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4333.198873] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 4335.383925] usb 1-3: new high-speed USB device number 10 using xhci_hcd
[ 4335.549396] usb 1-3: New USB device found, idVendor=0930, idProduct=6545
[ 4335.549400] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4335.549403] usb 1-3: Product: TransMemory
[ 4335.549405] usb 1-3: Manufacturer: TOSHIBA
[ 4335.549407] usb 1-3: SerialNumber: C03FD5FBC7ECE020B0006F57
[ 4335.550532] usb-storage 1-3:1.0: USB Mass Storage device detected
[ 4335.552690] scsi host5: usb-storage 1-3:1.0
[ 4336.198950] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4336.555509] scsi 5:0:0:0: Direct-Access     TOSHIBA  TransMemory      PMAP PQ: 0 ANSI: 6
[ 4336.555860] sd 5:0:0:0: Attached scsi generic sg1 type 0
[ 4336.556179] sd 5:0:0:0: [sdd] 30253056 512-byte logical blocks: (15.4 GB/14.4 GiB)
[ 4336.556391] sd 5:0:0:0: [sdd] Write Protect is off
[ 4336.556395] sd 5:0:0:0: [sdd] Mode Sense: 45 00 00 00
[ 4336.556591] sd 5:0:0:0: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 4336.610953]  sdd: sdd1
[ 4336.612040] sd 5:0:0:0: [sdd] Attached SCSI removable disk
[ 4338.782315] FAT-fs (sdd1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 4342.199098] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4344.921485] FAT-fs (sdc1): FAT read failed (blocknr 988)
[ 4347.491288] ath10k_pci 0000:01:00.0: failed to set rx-chainmask: -11, req 0x3
[ 4350.491331] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4353.447107] FAT-fs (sdd1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 4356.035732] FAT-fs (sdc1): Directory bread(block 8192) failed
[ 4356.035737] FAT-fs (sdc1): Directory bread(block 8193) failed
[ 4356.035739] FAT-fs (sdc1): Directory bread(block 8194) failed
[ 4356.035741] FAT-fs (sdc1): Directory bread(block 8195) failed
[ 4356.035742] FAT-fs (sdc1): Directory bread(block 8196) failed
[ 4356.035744] FAT-fs (sdc1): Directory bread(block 8197) failed
[ 4356.035745] FAT-fs (sdc1): Directory bread(block 8198) failed
[ 4356.035746] FAT-fs (sdc1): Directory bread(block 8199) failed
[ 4356.035748] FAT-fs (sdc1): Directory bread(block 8200) failed
[ 4356.035749] FAT-fs (sdc1): Directory bread(block 8201) failed
[ 4356.491450] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4360.795098] usb 1-3: USB disconnect, device number 10
[ 4361.772579] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 4361.978580] usb 1-3: new high-speed USB device number 11 using xhci_hcd
[ 4362.143504] usb 1-3: New USB device found, idVendor=0930, idProduct=6545
[ 4362.143509] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4362.143511] usb 1-3: Product: TransMemory
[ 4362.143513] usb 1-3: Manufacturer: TOSHIBA
[ 4362.143515] usb 1-3: SerialNumber: C03FD5FBC7ECE020B0006F57
[ 4362.144382] usb-storage 1-3:1.0: USB Mass Storage device detected
[ 4362.144498] scsi host6: usb-storage 1-3:1.0
[ 4363.146215] scsi 6:0:0:0: Direct-Access     TOSHIBA  TransMemory      PMAP PQ: 0 ANSI: 6
[ 4363.146501] sd 6:0:0:0: Attached scsi generic sg1 type 0
[ 4363.147387] sd 6:0:0:0: [sdd] 30253056 512-byte logical blocks: (15.4 GB/14.4 GiB)
[ 4363.147606] sd 6:0:0:0: [sdd] Write Protect is off
[ 4363.147610] sd 6:0:0:0: [sdd] Mode Sense: 45 00 00 00
[ 4363.147824] sd 6:0:0:0: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 4363.203504]  sdd: sdd1
[ 4363.204555] sd 6:0:0:0: [sdd] Attached SCSI removable disk
[ 4363.386793] FAT-fs (sdd1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 4364.772651] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4365.018219] FAT-fs (sdc1): FAT read failed (blocknr 988)
[ 4370.772800] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4375.491274] fat__get_entry: 374 callbacks suppressed
[ 4375.491278] FAT-fs (sdc1): Directory bread(block 8192) failed
[ 4375.491283] FAT-fs (sdc1): Directory bread(block 8193) failed
[ 4375.491285] FAT-fs (sdc1): Directory bread(block 8194) failed
[ 4375.491287] FAT-fs (sdc1): Directory bread(block 8195) failed
[ 4375.491289] FAT-fs (sdc1): Directory bread(block 8196) failed
[ 4375.491291] FAT-fs (sdc1): Directory bread(block 8197) failed
[ 4375.491293] FAT-fs (sdc1): Directory bread(block 8198) failed
[ 4375.491295] FAT-fs (sdc1): Directory bread(block 8199) failed
[ 4375.491297] FAT-fs (sdc1): Directory bread(block 8200) failed
[ 4375.491299] FAT-fs (sdc1): Directory bread(block 8201) failed
[ 4376.076929] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3
[ 4379.077003] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4380.825017] fat__get_entry: 758 callbacks suppressed
[ 4380.825022] FAT-fs (sdc1): Directory bread(block 8192) failed
[ 4380.825025] FAT-fs (sdc1): Directory bread(block 8193) failed
[ 4380.825028] FAT-fs (sdc1): Directory bread(block 8194) failed
[ 4380.825030] FAT-fs (sdc1): Directory bread(block 8195) failed
[ 4380.825042] FAT-fs (sdc1): Directory bread(block 8196) failed
[ 4380.825045] FAT-fs (sdc1): Directory bread(block 8197) failed
[ 4380.825048] FAT-fs (sdc1): Directory bread(block 8198) failed
[ 4380.825051] FAT-fs (sdc1): Directory bread(block 8199) failed
[ 4380.825053] FAT-fs (sdc1): Directory bread(block 8200) failed
[ 4380.825055] FAT-fs (sdc1): Directory bread(block 8201) failed
[ 4381.253552] FAT-fs (sdd1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 4385.077150] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4387.400123] fat__get_entry: 630 callbacks suppressed
[ 4387.400127] FAT-fs (sdc1): Directory bread(block 8192) failed
[ 4387.400131] FAT-fs (sdc1): Directory bread(block 8193) failed
[ 4387.400133] FAT-fs (sdc1): Directory bread(block 8194) failed
[ 4387.400135] FAT-fs (sdc1): Directory bread(block 8195) failed
[ 4387.400138] FAT-fs (sdc1): Directory bread(block 8196) failed
[ 4387.400140] FAT-fs (sdc1): Directory bread(block 8197) failed
[ 4387.400142] FAT-fs (sdc1): Directory bread(block 8198) failed
[ 4387.400144] FAT-fs (sdc1): Directory bread(block 8199) failed
[ 4387.400147] FAT-fs (sdc1): Directory bread(block 8200) failed
[ 4387.400149] FAT-fs (sdc1): Directory bread(block 8201) failed
[ 4390.359284] ath10k_pci 0000:01:00.0: failed to set rx-chainmask: -11, req 0x3
[ 4393.359353] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4399.359502] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4404.642633] ath10k_pci 0000:01:00.0: failed to set rx-chainmask: -11, req 0x3
[ 4407.642724] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4413.642887] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4414.220306] usb 1-3: USB disconnect, device number 11
[ 4418.959019] ath10k_pci 0000:01:00.0: failed to set rx-chainmask: -11, req 0x3
[ 4421.959090] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4427.959209] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4433.257338] ath10k_pci 0000:01:00.0: failed to set rx-chainmask: -11, req 0x3
[ 4436.257470] ath10k_pci 0000:01:00.0: failed to set arp ac override parameter: -11
[ 4438.436778] usb 1-3: new high-speed USB device number 12 using xhci_hcd
[ 4438.601141] usb 1-3: New USB device found, idVendor=0930, idProduct=6545
[ 4438.601145] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4438.601146] usb 1-3: Product: TransMemory
[ 4438.601148] usb 1-3: Manufacturer: TOSHIBA
[ 4438.601149] usb 1-3: SerialNumber: C03FD5FBC7ECE020B0006F57
[ 4438.601617] usb-storage 1-3:1.0: USB Mass Storage device detected
[ 4438.602075] scsi host7: usb-storage 1-3:1.0
[ 4439.604125] scsi 7:0:0:0: Direct-Access     TOSHIBA  TransMemory      PMAP PQ: 0 ANSI: 6
[ 4439.604931] sd 7:0:0:0: Attached scsi generic sg1 type 0
[ 4439.605131] sd 7:0:0:0: [sde] 30253056 512-byte logical blocks: (15.4 GB/14.4 GiB)
[ 4439.605325] sd 7:0:0:0: [sde] Write Protect is off
[ 4439.605329] sd 7:0:0:0: [sde] Mode Sense: 45 00 00 00
[ 4439.605574] sd 7:0:0:0: [sde] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 4439.666342]  sde: sde1
[ 4439.667442] sd 7:0:0:0: [sde] Attached SCSI removable disk
[ 4439.860368] FAT-fs (sde1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 4441.095233] FAT-fs (sdd1): Directory bread(block 28256) failed
[ 4441.095237] FAT-fs (sdd1): Directory bread(block 28257) failed
[ 4441.095238] FAT-fs (sdd1): Directory bread(block 28258) failed
[ 4441.095240] FAT-fs (sdd1): Directory bread(block 28259) failed
[ 4441.095241] FAT-fs (sdd1): Directory bread(block 28260) failed
[ 4441.095242] FAT-fs (sdd1): Directory bread(block 28261) failed
[ 4441.095244] FAT-fs (sdd1): Directory bread(block 28262) failed
[ 4441.095245] FAT-fs (sdd1): Directory bread(block 28263) failed
[ 4441.095246] FAT-fs (sdd1): Directory bread(block 28264) failed
[ 4441.095247] FAT-fs (sdd1): Directory bread(block 28265) failed
[ 4442.257558] ath10k_pci 0000:01:00.0: could not suspend target (-11)
[ 4447.592688] ath10k_pci 0000:01:00.0: failed to set tx-chainmask: -11, req 0x3

From michal.kazior at tieto.com  Tue Jul 19 00:18:01 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 19 Jul 2016 09:18:01 +0200
Subject: ath10k fail to load firmware
In-Reply-To: <20160719070932.GA2751@redhat.com>
References: <20160719070932.GA2751@redhat.com>
Message-ID: <CA+BoTQn98UFuGT0NntdE1HgG9UmmwzS=JsGkLmeGoMHSFGyDRg@mail.gmail.com>

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

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

  [ 3838.601884] ath10k_pci 0000: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 0000:01:00.0: board_file api 1 bmi_id N/A
crc32 ed5f849a

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

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

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


Micha?


From sgruszka at redhat.com  Tue Jul 19 00:27:55 2016
From: sgruszka at redhat.com (Stanislaw Gruszka)
Date: Tue, 19 Jul 2016 09:27:55 +0200
Subject: ath10k fail to load firmware
In-Reply-To: <CA+BoTQn98UFuGT0NntdE1HgG9UmmwzS=JsGkLmeGoMHSFGyDRg@mail.gmail.com>
References: <20160719070932.GA2751@redhat.com>
 <CA+BoTQn98UFuGT0NntdE1HgG9UmmwzS=JsGkLmeGoMHSFGyDRg@mail.gmail.com>
Message-ID: <20160719072754.GB2751@redhat.com>

On Tue, Jul 19, 2016 at 09:18:01AM +0200, Michal Kazior wrote:
> On 19 July 2016 at 09:09, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
> > Perry from Dell has ath10k device, which do not work with current
> > linux-firmware. It's on RHEL kernel, however wirelss stack and drivers
> > are from 4.7-rc1 (I did not update to 4.7 final yet, since I do not see
> > ath10k fix, which could possibly help here). Partial dmesg is in
> > the attachment.
> 
> hw.3 qca6174 chips tend to require very specific board data for proper
> calibration.
> 
>   [ 3838.601884] ath10k_pci 0000: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 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 ed5f849a
> 
> Your board-2.bin doesn't contain the matching board data and the
> driver then falls back to the older board API1 which is pretty much
> doomed to fail on qca6174 hw.3.
> 
> @Kalle: Perhaps ath10k needs to fail early with an adequate message
> for qca6174 hw.3 if board API2 lookup fails (e.g. hw_params flag
> because this seems to be quite closely coupled with hardware itself).
> 
> @Stanislaw: You either need to grab a more recent board-2.bin
> (https://github.com/kvalo/ath10k-firmware/tree/master/QCA6174/hw3.0),

@Perry, could you replace board-2.bin from above link on
/lib/firmware/ath10k/QCA6174/hw3.0/ and check if that work ?

> 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 think we can wait till firmware will be updated upstream, however
Dell would like to know if what we provide in new RHEL7 release
will work on their hardware.

Thanks
Stanislaw


From Perry_Yuan at Dell.com  Tue Jul 19 01:07:20 2016
From: Perry_Yuan at Dell.com (Perry_Yuan at Dell.com)
Date: Tue, 19 Jul 2016 16:07:20 +0800
Subject: ath10k fail to load firmware
In-Reply-To: <20160719072754.GB2751@redhat.com>
References: <20160719070932.GA2751@redhat.com>
 <CA+BoTQn98UFuGT0NntdE1HgG9UmmwzS=JsGkLmeGoMHSFGyDRg@mail.gmail.com>
 <20160719072754.GB2751@redhat.com>
Message-ID: <A3D794F1192BBF449DF2EC3D7EE263F44A5402F0B3@SHAX7MCDC101.APAC.DELL.COM>

Dell - Internal Use - Confidential 

Hi all:
I  will try this firmware  now . Give you feedback later.
(https://github.com/kvalo/ath10k-firmware/tree/master/QCA6174/hw3.0)



keep up the good work
Perry? Yuan
Dell | Client Software Group | Platform Sftwr Senior Engineer
office +86 21 22030689, mobile +86 18521512823
perry_yuan at dell.com
Please consider the environment before printing this email.

-----Original Message-----
From: Stanislaw Gruszka [mailto:sgruszka at redhat.com] 
Sent: Tuesday, July 19, 2016 3:28 PM
To: Michal Kazior <michal.kazior at tieto.com>
Cc: Kalle Valo <kvalo at qca.qualcomm.com>; ath10k at lists.infradead.org; Yuan, Perry <Perry_Yuan at Dell.com>
Subject: Re: ath10k fail to load firmware

On Tue, Jul 19, 2016 at 09:18:01AM +0200, Michal Kazior wrote:
> On 19 July 2016 at 09:09, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
> > Perry from Dell has ath10k device, which do not work with current 
> > linux-firmware. It's on RHEL kernel, however wirelss stack and 
> > drivers are from 4.7-rc1 (I did not update to 4.7 final yet, since I 
> > do not see ath10k fix, which could possibly help here). Partial 
> > dmesg is in the attachment.
> 
> hw.3 qca6174 chips tend to require very specific board data for proper 
> calibration.
> 
>   [ 3838.601884] ath10k_pci 0000: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 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 ed5f849a
> 
> Your board-2.bin doesn't contain the matching board data and the 
> driver then falls back to the older board API1 which is pretty much 
> doomed to fail on qca6174 hw.3.
> 
> @Kalle: Perhaps ath10k needs to fail early with an adequate message 
> for qca6174 hw.3 if board API2 lookup fails (e.g. hw_params flag 
> because this seems to be quite closely coupled with hardware itself).
> 
> @Stanislaw: You either need to grab a more recent board-2.bin 
> (https://github.com/kvalo/ath10k-firmware/tree/master/QCA6174/hw3.0),

@Perry, could you replace board-2.bin from above link on /lib/firmware/ath10k/QCA6174/hw3.0/ and check if that work ?

> 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 think we can wait till firmware will be updated upstream, however Dell would like to know if what we provide in new RHEL7 release will work on their hardware.

Thanks
Stanislaw


From Perry_Yuan at Dell.com  Tue Jul 19 01:24:41 2016
From: Perry_Yuan at Dell.com (Perry_Yuan at Dell.com)
Date: Tue, 19 Jul 2016 16:24:41 +0800
Subject: ath10k fail to load firmware
In-Reply-To: <20160719072754.GB2751@redhat.com>
References: <20160719070932.GA2751@redhat.com>
 <CA+BoTQn98UFuGT0NntdE1HgG9UmmwzS=JsGkLmeGoMHSFGyDRg@mail.gmail.com>
 <20160719072754.GB2751@redhat.com>
Message-ID: <A3D794F1192BBF449DF2EC3D7EE263F44A5402F0C8@SHAX7MCDC101.APAC.DELL.COM>

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 0000:02:00.0: Hardware name qca6174 hw3.2 version 0x5030000
[  590.487158] ath10k_pci 0000:02:00.0: Direct firmware load failed with error -2
[  590.487159] ath10k_pci 0000:02:00.0: Falling back to user helper



keep up the good work
Perry? Yuan
Dell | Client Software Group | Platform Sftwr Senior Engineer
office +86 21 22030689, mobile +86 18521512823
perry_yuan at dell.com
Please consider the environment before printing this email.


-----Original Message-----
From: Stanislaw Gruszka [mailto:sgruszka at redhat.com] 
Sent: Tuesday, July 19, 2016 3:28 PM
To: Michal Kazior <michal.kazior at tieto.com>
Cc: Kalle Valo <kvalo at qca.qualcomm.com>; ath10k at lists.infradead.org; Yuan, Perry <Perry_Yuan at Dell.com>
Subject: Re: ath10k fail to load firmware

On Tue, Jul 19, 2016 at 09:18:01AM +0200, Michal Kazior wrote:
> On 19 July 2016 at 09:09, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
> > Perry from Dell has ath10k device, which do not work with current 
> > linux-firmware. It's on RHEL kernel, however wirelss stack and 
> > drivers are from 4.7-rc1 (I did not update to 4.7 final yet, since I 
> > do not see ath10k fix, which could possibly help here). Partial 
> > dmesg is in the attachment.
> 
> hw.3 qca6174 chips tend to require very specific board data for proper 
> calibration.
> 
>   [ 3838.601884] ath10k_pci 0000: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 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 ed5f849a
> 
> Your board-2.bin doesn't contain the matching board data and the 
> driver then falls back to the older board API1 which is pretty much 
> doomed to fail on qca6174 hw.3.
> 
> @Kalle: Perhaps ath10k needs to fail early with an adequate message 
> for qca6174 hw.3 if board API2 lookup fails (e.g. hw_params flag 
> because this seems to be quite closely coupled with hardware itself).
> 
> @Stanislaw: You either need to grab a more recent board-2.bin 
> (https://github.com/kvalo/ath10k-firmware/tree/master/QCA6174/hw3.0),

@Perry, could you replace board-2.bin from above link on /lib/firmware/ath10k/QCA6174/hw3.0/ and check if that work ?

> 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 think we can wait till firmware will be updated upstream, however Dell would like to know if what we provide in new RHEL7 release will work on their hardware.

Thanks
Stanislaw
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ath10k_log_new_fw_1.txt
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160719/399dd99a/attachment-0001.txt>

From michal.kazior at tieto.com  Tue Jul 19 01:32:59 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 19 Jul 2016 10:32:59 +0200
Subject: ath10k fail to load firmware
In-Reply-To: <A3D794F1192BBF449DF2EC3D7EE263F44A5402F0C8@SHAX7MCDC101.APAC.DELL.COM>
References: <20160719070932.GA2751@redhat.com>
 <CA+BoTQn98UFuGT0NntdE1HgG9UmmwzS=JsGkLmeGoMHSFGyDRg@mail.gmail.com>
 <20160719072754.GB2751@redhat.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F0C8@SHAX7MCDC101.APAC.DELL.COM>
Message-ID: <CA+BoTQn4T+4zMrJEbLBfu92w=mVqWBZZkZaYaW__V2_-VLkCyQ@mail.gmail.com>

On 19 July 2016 at 10:24,  <Perry_Yuan at dell.com> 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 0000:02:00.0: Hardware name qca6174 hw3.2 version 0x5030000
> [  590.487158] ath10k_pci 0000:02:00.0: Direct firmware load failed with error -2
> [  590.487159] ath10k_pci 0000:02:00.0: Falling back to user helper

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

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

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


Micha?


From Perry_Yuan at Dell.com  Tue Jul 19 02:02:23 2016
From: Perry_Yuan at Dell.com (Perry_Yuan at Dell.com)
Date: Tue, 19 Jul 2016 17:02:23 +0800
Subject: ath10k fail to load firmware
In-Reply-To: <CA+BoTQn4T+4zMrJEbLBfu92w=mVqWBZZkZaYaW__V2_-VLkCyQ@mail.gmail.com>
References: <20160719070932.GA2751@redhat.com>
 <CA+BoTQn98UFuGT0NntdE1HgG9UmmwzS=JsGkLmeGoMHSFGyDRg@mail.gmail.com>
 <20160719072754.GB2751@redhat.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F0C8@SHAX7MCDC101.APAC.DELL.COM>
 <CA+BoTQn4T+4zMrJEbLBfu92w=mVqWBZZkZaYaW__V2_-VLkCyQ@mail.gmail.com>
Message-ID: <A3D794F1192BBF449DF2EC3D7EE263F44A5402F107@SHAX7MCDC101.APAC.DELL.COM>

Dell - Internal Use - Confidential 

I rename the bin file  . and capture new full logs from booting to firmware error . 
The error still happened. Please help to check it .
I want to know whether the new firmware bin are updated  the right one  in this git ?
If the firmware is good , the errors should be gone .


keep up the good work
Perry? Yuan
Dell | Client Software Group | Platform Sftwr Senior Engineer
office +86 21 22030689, mobile +86 18521512823
perry_yuan at dell.com
Please consider the environment before printing this email.


-----Original Message-----
From: Michal Kazior [mailto:michal.kazior at tieto.com] 
Sent: Tuesday, July 19, 2016 4:33 PM
To: Yuan, Perry <Perry_Yuan at Dell.com>
Cc: Stanislaw Gruszka <sgruszka at redhat.com>; Kalle Valo <kvalo at qca.qualcomm.com>; ath10k at lists.infradead.org
Subject: Re: ath10k fail to load firmware

On 19 July 2016 at 10:24,  <Perry_Yuan at dell.com> 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 0000:02:00.0: Hardware name qca6174 hw3.2 
> version 0x5030000 [  590.487158] ath10k_pci 0000:02:00.0: Direct 
> firmware load failed with error -2 [  590.487159] ath10k_pci 
> 0000:02:00.0: Falling back to user helper

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

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

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


Micha?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logs-ath10k.zip
Type: application/x-zip-compressed
Size: 38749 bytes
Desc: logs-ath10k.zip
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160719/772cc925/attachment-0001.bin>

From michal.kazior at tieto.com  Tue Jul 19 02:17:03 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 19 Jul 2016 11:17:03 +0200
Subject: ath10k fail to load firmware
In-Reply-To: <A3D794F1192BBF449DF2EC3D7EE263F44A5402F107@SHAX7MCDC101.APAC.DELL.COM>
References: <20160719070932.GA2751@redhat.com>
 <CA+BoTQn98UFuGT0NntdE1HgG9UmmwzS=JsGkLmeGoMHSFGyDRg@mail.gmail.com>
 <20160719072754.GB2751@redhat.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F0C8@SHAX7MCDC101.APAC.DELL.COM>
 <CA+BoTQn4T+4zMrJEbLBfu92w=mVqWBZZkZaYaW__V2_-VLkCyQ@mail.gmail.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F107@SHAX7MCDC101.APAC.DELL.COM>
Message-ID: <CA+BoTQk7QKaO2yxMq5JEhrBhn4WtpmWTcOxfiXcvYxrFvaxdgw@mail.gmail.com>

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

Thanks for checking!

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

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


Micha?


From sgruszka at redhat.com  Tue Jul 19 02:27:27 2016
From: sgruszka at redhat.com (Stanislaw Gruszka)
Date: Tue, 19 Jul 2016 11:27:27 +0200
Subject: ath10k fail to load firmware
In-Reply-To: <CA+BoTQk7QKaO2yxMq5JEhrBhn4WtpmWTcOxfiXcvYxrFvaxdgw@mail.gmail.com>
References: <20160719070932.GA2751@redhat.com>
 <CA+BoTQn98UFuGT0NntdE1HgG9UmmwzS=JsGkLmeGoMHSFGyDRg@mail.gmail.com>
 <20160719072754.GB2751@redhat.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F0C8@SHAX7MCDC101.APAC.DELL.COM>
 <CA+BoTQn4T+4zMrJEbLBfu92w=mVqWBZZkZaYaW__V2_-VLkCyQ@mail.gmail.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F107@SHAX7MCDC101.APAC.DELL.COM>
 <CA+BoTQk7QKaO2yxMq5JEhrBhn4WtpmWTcOxfiXcvYxrFvaxdgw@mail.gmail.com>
Message-ID: <20160719092727.GD2751@redhat.com>

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

Please use reply-to-all, so I could see messages. You can drop ML
eventually if you thing your data is confidential.

> Thanks for checking!
> 
> Apparently the available board-2.bin doesn't contain any subsystem
> vendor=1028 board data (just checked).
> 
> Also, you guys (i.e. Perry & Stanislaw) seem to be using 2 slightly
> different devices. One reports its subsystem ids as 1028:0310 (in the
> original log Stanislaw provided) and 1028:0410 (found in logs attached
> by Perry).

I provided dmesg, which I get from Perry, hence seems that Perry tests
on 2 different devices :-)

Stanislaw 


From Perry_Yuan at Dell.com  Tue Jul 19 02:41:41 2016
From: Perry_Yuan at Dell.com (Perry_Yuan at Dell.com)
Date: Tue, 19 Jul 2016 17:41:41 +0800
Subject: ath10k fail to load firmware
In-Reply-To: <20160719092727.GD2751@redhat.com>
References: <20160719070932.GA2751@redhat.com>
 <CA+BoTQn98UFuGT0NntdE1HgG9UmmwzS=JsGkLmeGoMHSFGyDRg@mail.gmail.com>
 <20160719072754.GB2751@redhat.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F0C8@SHAX7MCDC101.APAC.DELL.COM>
 <CA+BoTQn4T+4zMrJEbLBfu92w=mVqWBZZkZaYaW__V2_-VLkCyQ@mail.gmail.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F107@SHAX7MCDC101.APAC.DELL.COM>
 <CA+BoTQk7QKaO2yxMq5JEhrBhn4WtpmWTcOxfiXcvYxrFvaxdgw@mail.gmail.com>
 <20160719092727.GD2751@redhat.com>
Message-ID: <A3D794F1192BBF449DF2EC3D7EE263F44A5402F143@SHAX7MCDC101.APAC.DELL.COM>

Dell - Internal Use - Confidential 

Yeah , I  provide the logs from two system .  but I don't   notice the  wireless card system ID is different .
In my opinion . even the subsystem ID is not same . at least one wireless car should work well . 
The two cards all not working with current firmware .

So  could you tell me how to make it available  ?


keep up the good work
Perry? Yuan
Dell | Client Software Group | Platform Sftwr Senior Engineer
office +86 21 22030689, mobile +86 18521512823
perry_yuan at dell.com
Please consider the environment before printing this email.


-----Original Message-----
From: Stanislaw Gruszka [mailto:sgruszka at redhat.com] 
Sent: Tuesday, July 19, 2016 5:27 PM
To: Michal Kazior <michal.kazior at tieto.com>
Cc: Yuan, Perry <Perry_Yuan at Dell.com>; Kalle Valo <kvalo at qca.qualcomm.com>; ath10k at lists.infradead.org; Shen, Yijun <Yijun_Shen at Dell.com>
Subject: Re: ath10k fail to load firmware

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

Please use reply-to-all, so I could see messages. You can drop ML eventually if you thing your data is confidential.

> Thanks for checking!
> 
> Apparently the available board-2.bin doesn't contain any subsystem
> vendor=1028 board data (just checked).
> 
> Also, you guys (i.e. Perry & Stanislaw) seem to be using 2 slightly 
> different devices. One reports its subsystem ids as 1028:0310 (in the 
> original log Stanislaw provided) and 1028:0410 (found in logs attached 
> by Perry).

I provided dmesg, which I get from Perry, hence seems that Perry tests on 2 different devices :-)

Stanislaw 


From michal.kazior at tieto.com  Tue Jul 19 03:34:08 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 19 Jul 2016 12:34:08 +0200
Subject: [PATCH 0/4] ath10k: fix spurious tx/rx during boot
Message-ID: <1468924452-23877-1-git-send-email-michal.kazior@tieto.com>

Hi,

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

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

See last patch for more details.

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



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

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

-- 
2.1.4



From michal.kazior at tieto.com  Tue Jul 19 03:34:12 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 19 Jul 2016 12:34:12 +0200
Subject: [PATCH 4/4] ath10k: fix spurious tx/rx during boot
In-Reply-To: <1468924452-23877-1-git-send-email-michal.kazior@tieto.com>
References: <1468924452-23877-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1468924452-23877-5-git-send-email-michal.kazior@tieto.com>

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

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

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

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

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

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

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

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

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

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

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



From michal.kazior at tieto.com  Tue Jul 19 03:34:09 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 19 Jul 2016 12:34:09 +0200
Subject: [PATCH 1/4] ath10k: implement wmi echo command
In-Reply-To: <1468924452-23877-1-git-send-email-michal.kazior@tieto.com>
References: <1468924452-23877-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1468924452-23877-2-git-send-email-michal.kazior@tieto.com>

Will be useful for implementing command barriers.

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

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



From michal.kazior at tieto.com  Tue Jul 19 03:34:11 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 19 Jul 2016 12:34:11 +0200
Subject: [PATCH 3/4] ath10k: add wmi command barrier utility
In-Reply-To: <1468924452-23877-1-git-send-email-michal.kazior@tieto.com>
References: <1468924452-23877-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1468924452-23877-4-git-send-email-michal.kazior@tieto.com>

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

Useful for future driver development.

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

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



From michal.kazior at tieto.com  Tue Jul 19 03:34:10 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 19 Jul 2016 12:34:10 +0200
Subject: [PATCH 2/4] ath10k: implement wmi echo event
In-Reply-To: <1468924452-23877-1-git-send-email-michal.kazior@tieto.com>
References: <1468924452-23877-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1468924452-23877-3-git-send-email-michal.kazior@tieto.com>

Will be useful for implementing command barriers.

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

diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index b1d88fa60d11..c67eda78b69e 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -51,6 +51,8 @@ struct wmi_ops {
 			    struct wmi_roam_ev_arg *arg);
 	int (*pull_wow_event)(struct ath10k *ar, struct sk_buff *skb,
 			      struct wmi_wow_ev_arg *arg);
+	int (*pull_echo_ev)(struct ath10k *ar, struct sk_buff *skb,
+			    struct wmi_echo_ev_arg *arg);
 	enum wmi_txbf_conf (*get_txbf_conf_scheme)(struct ath10k *ar);
 
 	struct sk_buff *(*gen_pdev_suspend)(struct ath10k *ar, u32 suspend_opt);
@@ -350,6 +352,16 @@ ath10k_wmi_pull_wow_event(struct ath10k *ar, struct sk_buff *skb,
 	return ar->wmi.ops->pull_wow_event(ar, skb, arg);
 }
 
+static inline int
+ath10k_wmi_pull_echo_ev(struct ath10k *ar, struct sk_buff *skb,
+			struct wmi_echo_ev_arg *arg)
+{
+	if (!ar->wmi.ops->pull_echo_ev)
+		return -EOPNOTSUPP;
+
+	return ar->wmi.ops->pull_echo_ev(ar, skb, arg);
+}
+
 static inline enum wmi_txbf_conf
 ath10k_wmi_get_txbf_conf_scheme(struct ath10k *ar)
 {
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index cd595855af36..a42f52dd9a36 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -1223,6 +1223,33 @@ ath10k_wmi_tlv_op_pull_wow_ev(struct ath10k *ar, struct sk_buff *skb,
 	return 0;
 }
 
+static int ath10k_wmi_tlv_op_pull_echo_ev(struct ath10k *ar,
+					  struct sk_buff *skb,
+					  struct wmi_echo_ev_arg *arg)
+{
+	const void **tb;
+	const struct wmi_echo_event *ev;
+	int ret;
+
+	tb = ath10k_wmi_tlv_parse_alloc(ar, skb->data, skb->len, GFP_ATOMIC);
+	if (IS_ERR(tb)) {
+		ret = PTR_ERR(tb);
+		ath10k_warn(ar, "failed to parse tlv: %d\n", ret);
+		return ret;
+	}
+
+	ev = tb[WMI_TLV_TAG_STRUCT_ECHO_EVENT];
+	if (!ev) {
+		kfree(tb);
+		return -EPROTO;
+	}
+
+	arg->value = ev->value;
+
+	kfree(tb);
+	return 0;
+}
+
 static struct sk_buff *
 ath10k_wmi_tlv_op_gen_pdev_suspend(struct ath10k *ar, u32 opt)
 {
@@ -3457,6 +3484,7 @@ static const struct wmi_ops wmi_tlv_ops = {
 	.pull_fw_stats = ath10k_wmi_tlv_op_pull_fw_stats,
 	.pull_roam_ev = ath10k_wmi_tlv_op_pull_roam_ev,
 	.pull_wow_event = ath10k_wmi_tlv_op_pull_wow_ev,
+	.pull_echo_ev = ath10k_wmi_tlv_op_pull_echo_ev,
 	.get_txbf_conf_scheme = ath10k_wmi_tlv_txbf_conf_scheme,
 
 	.gen_pdev_suspend = ath10k_wmi_tlv_op_gen_pdev_suspend,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 9ae4aacadb38..8ca76ecd7e9b 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2495,7 +2495,18 @@ exit:
 
 void ath10k_wmi_event_echo(struct ath10k *ar, struct sk_buff *skb)
 {
-	ath10k_dbg(ar, ATH10K_DBG_WMI, "WMI_ECHO_EVENTID\n");
+	struct wmi_echo_ev_arg arg = {};
+	int ret;
+
+	ret = ath10k_wmi_pull_echo_ev(ar, skb, &arg);
+	if (ret) {
+		ath10k_warn(ar, "failed to parse echo: %d\n", ret);
+		return;
+	}
+
+	ath10k_dbg(ar, ATH10K_DBG_WMI,
+		   "wmi event echo value 0x%08x\n",
+		   le32_to_cpu(arg.value));
 }
 
 int ath10k_wmi_event_debug_mesg(struct ath10k *ar, struct sk_buff *skb)
@@ -4792,6 +4803,17 @@ static int ath10k_wmi_op_pull_roam_ev(struct ath10k *ar, struct sk_buff *skb,
 	return 0;
 }
 
+static int ath10k_wmi_op_pull_echo_ev(struct ath10k *ar,
+				      struct sk_buff *skb,
+				      struct wmi_echo_ev_arg *arg)
+{
+	struct wmi_echo_event *ev = (void *)skb->data;
+
+	arg->value = ev->value;
+
+	return 0;
+}
+
 int ath10k_wmi_event_ready(struct ath10k *ar, struct sk_buff *skb)
 {
 	struct wmi_rdy_ev_arg arg = {};
@@ -7683,6 +7705,7 @@ static const struct wmi_ops wmi_ops = {
 	.pull_rdy = ath10k_wmi_op_pull_rdy_ev,
 	.pull_fw_stats = ath10k_wmi_main_op_pull_fw_stats,
 	.pull_roam_ev = ath10k_wmi_op_pull_roam_ev,
+	.pull_echo_ev = ath10k_wmi_op_pull_echo_ev,
 
 	.gen_pdev_suspend = ath10k_wmi_op_gen_pdev_suspend,
 	.gen_pdev_resume = ath10k_wmi_op_gen_pdev_resume,
@@ -7757,6 +7780,7 @@ static const struct wmi_ops wmi_10_1_ops = {
 	.pull_phyerr = ath10k_wmi_op_pull_phyerr_ev,
 	.pull_rdy = ath10k_wmi_op_pull_rdy_ev,
 	.pull_roam_ev = ath10k_wmi_op_pull_roam_ev,
+	.pull_echo_ev = ath10k_wmi_op_pull_echo_ev,
 
 	.gen_pdev_suspend = ath10k_wmi_op_gen_pdev_suspend,
 	.gen_pdev_resume = ath10k_wmi_op_gen_pdev_resume,
@@ -7828,6 +7852,7 @@ static const struct wmi_ops wmi_10_2_ops = {
 	.pull_phyerr = ath10k_wmi_op_pull_phyerr_ev,
 	.pull_rdy = ath10k_wmi_op_pull_rdy_ev,
 	.pull_roam_ev = ath10k_wmi_op_pull_roam_ev,
+	.pull_echo_ev = ath10k_wmi_op_pull_echo_ev,
 
 	.gen_pdev_suspend = ath10k_wmi_op_gen_pdev_suspend,
 	.gen_pdev_resume = ath10k_wmi_op_gen_pdev_resume,
@@ -7895,6 +7920,7 @@ static const struct wmi_ops wmi_10_2_4_ops = {
 	.pull_phyerr = ath10k_wmi_op_pull_phyerr_ev,
 	.pull_rdy = ath10k_wmi_op_pull_rdy_ev,
 	.pull_roam_ev = ath10k_wmi_op_pull_roam_ev,
+	.pull_echo_ev = ath10k_wmi_op_pull_echo_ev,
 
 	.gen_pdev_suspend = ath10k_wmi_op_gen_pdev_suspend,
 	.gen_pdev_resume = ath10k_wmi_op_gen_pdev_resume,
@@ -8002,6 +8028,7 @@ static const struct wmi_ops wmi_10_4_ops = {
 	.ext_resource_config = ath10k_wmi_10_4_ext_resource_config,
 
 	/* shared with 10.2 */
+	.pull_echo_ev = ath10k_wmi_op_pull_echo_ev,
 	.gen_request_stats = ath10k_wmi_op_gen_request_stats,
 	.gen_pdev_get_temperature = ath10k_wmi_10_2_op_gen_pdev_get_temperature,
 	.get_vdev_subtype = ath10k_wmi_10_4_op_get_vdev_subtype,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 3ef468893b3f..086d78807d2f 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6296,6 +6296,10 @@ struct wmi_roam_ev_arg {
 	__le32 rssi;
 };
 
+struct wmi_echo_ev_arg {
+	__le32 value;
+};
+
 struct wmi_pdev_temperature_event {
 	/* temperature value in Celcius degree */
 	__le32 temperature;
-- 
2.1.4



From michal.kazior at tieto.com  Tue Jul 19 06:00:37 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 19 Jul 2016 15:00:37 +0200
Subject: [RFC] ath10k: silence firmware file probing warnings
Message-ID: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>

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

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

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

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

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



From kvalo at qca.qualcomm.com  Tue Jul 19 06:19:39 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 19 Jul 2016 15:19:39 +0200
Subject: ath10k: disable wake_tx_queue for older devices
In-Reply-To: <1467201146-6844-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <fddd6abaa3394cf5ae8133f627ffd47d@euamsexm01a.eu.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> wrote:
> Ideally wake_tx_queue should be used regardless as
> it is a requirement for reducing bufferbloat and
> implementing airtime fairness in the future.
> 
> However some setups (typically low-end platforms
> hosting QCA988X) suffer performance regressions
> with the current wake_tx_queue implementation.
> Therefore disable it unless it is really
> beneficial with current codebase (which is when
> firmware supports smart pull-push tx scheduling).
> 
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Thanks, 1 patch applied to ath-next branch of ath.git:

4ca1807815aa ath10k: disable wake_tx_queue for older devices

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9204997/



From rmanohar at qti.qualcomm.com  Tue Jul 19 08:25:49 2016
From: rmanohar at qti.qualcomm.com (Manoharan, Rajkumar)
Date: Tue, 19 Jul 2016 15:25:49 +0000
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>,
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
Message-ID: <1468941948774.87860@qti.qualcomm.com>

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

Could you please shed some light on this issue? It seems this issue is popping up
more frequently and there are multiple threads for this issue.

"Anyone brought up 9984 NIC on x86-64?"
"AR9882 IOMMU faults"

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

-Rajkumar

From adrian at freebsd.org  Tue Jul 19 09:13:08 2016
From: adrian at freebsd.org (Adrian Chadd)
Date: Tue, 19 Jul 2016 09:13:08 -0700
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <1468941948774.87860@qti.qualcomm.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
Message-ID: <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>

On 19 July 2016 at 08:25, Manoharan, Rajkumar <rmanohar at qti.qualcomm.com> wrote:
> On June 30, 2016 12:39 PM, Michal Kazior <michal.kazior at tieto.com> wrote:
>> On 29 June 2016 at 18:35, Manoharan, Rajkumar <rmanohar at qti.qualcomm.com> wrote:
>>>>> Am 29.06.2016 um 16:04 schrieb Sebastian Gottschall:
>>>>> this fix will crash QCA9980 on QCA IPQ8064 cpu based systems.
>>>>> so please rework it, or leave it out.
>>>>> note:
>>>>> maybe the limit of 256kb is too low for that card
>>>>>
>>>> by the way. 512 works
>>
>> I think this suggests the problem isn't about memory chunk size limit
>> per se but some kind of bug in address/offset logic in fw or hw.
>>
>> DMA coherent and single-map addresses use completely different ranges
>> in many cases. Perhaps some MSBs are not properly handled in fw or hw.
>> I recall there is a magic macro through which target device accesses
>> host memory so maybe that's a good place to look to better understand
>> the problem?
>>
> Micha?,
>
> Could you please shed some light on this issue? It seems this issue is popping up
> more frequently and there are multiple threads for this issue.
>
> "Anyone brought up 9984 NIC on x86-64?"
> "AR9882 IOMMU faults"
>
>> I recall Ben mentioned he worked around the problem by enabling
>> IOMMU/VT-d on his system. This could either prevent the device from
>> doing bad things or maybe changed DMA address ranges that are handed
>> out to the driver effectively or changed PCI controller behavior in
>> some way.
>>
>>> Thanks a lot Sebastian. Let me confirm the same on x86 and will update the change.
>>
>> Just changing the memory chunk size limit blindly is bad and
>> Sebastian's crash has proven it. 512 may seem to work now but it may
>> fail with a other 10.4 firmware revisions or make x86 hang in other
>> cases.
>>
> Even with current logic, If the memory chunk allocation fails for bigger size, then it tries
> to allocate smaller chunks. So If smaller chunks causes unexpected behaviour, it is even
> applicable to existing logic. no?

Try allocating WMI memory with GFP_DMA32. The way it currently is
working in linux is that caling dma map ends up allocating iommu slots
to map that 64 bit memory back into 32 bit space, /or/ it will end up
allocating bounce buffers.

The WMI memory alloc routine is being used for the swap space too,
which ends up with 700kbyte or more allocated twice - once for the
initial alloc, and another for the dma map call.

You should try GFP_DMA32 and see if that fixes it. You need contig, <
32 bit physical memory allocated, and bounce buffers are really
supposed to be ephemeral.



-adrian


From greearb at candelatech.com  Tue Jul 19 09:53:14 2016
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 19 Jul 2016 09:53:14 -0700
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
Message-ID: <578E5AFA.4000908@candelatech.com>

On 07/19/2016 09:13 AM, Adrian Chadd wrote:
> On 19 July 2016 at 08:25, Manoharan, Rajkumar <rmanohar at qti.qualcomm.com> wrote:
>> On June 30, 2016 12:39 PM, Michal Kazior <michal.kazior at tieto.com> wrote:
>>> On 29 June 2016 at 18:35, Manoharan, Rajkumar <rmanohar at qti.qualcomm.com> wrote:
>>>>>> Am 29.06.2016 um 16:04 schrieb Sebastian Gottschall:
>>>>>> this fix will crash QCA9980 on QCA IPQ8064 cpu based systems.
>>>>>> so please rework it, or leave it out.
>>>>>> note:
>>>>>> maybe the limit of 256kb is too low for that card
>>>>>>
>>>>> by the way. 512 works
>>>
>>> I think this suggests the problem isn't about memory chunk size limit
>>> per se but some kind of bug in address/offset logic in fw or hw.
>>>
>>> DMA coherent and single-map addresses use completely different ranges
>>> in many cases. Perhaps some MSBs are not properly handled in fw or hw.
>>> I recall there is a magic macro through which target device accesses
>>> host memory so maybe that's a good place to look to better understand
>>> the problem?
>>>
>> Micha?,
>>
>> Could you please shed some light on this issue? It seems this issue is popping up
>> more frequently and there are multiple threads for this issue.
>>
>> "Anyone brought up 9984 NIC on x86-64?"
>> "AR9882 IOMMU faults"
>>
>>> I recall Ben mentioned he worked around the problem by enabling
>>> IOMMU/VT-d on his system. This could either prevent the device from
>>> doing bad things or maybe changed DMA address ranges that are handed
>>> out to the driver effectively or changed PCI controller behavior in
>>> some way.
>>>
>>>> Thanks a lot Sebastian. Let me confirm the same on x86 and will update the change.
>>>
>>> Just changing the memory chunk size limit blindly is bad and
>>> Sebastian's crash has proven it. 512 may seem to work now but it may
>>> fail with a other 10.4 firmware revisions or make x86 hang in other
>>> cases.
>>>
>> Even with current logic, If the memory chunk allocation fails for bigger size, then it tries
>> to allocate smaller chunks. So If smaller chunks causes unexpected behaviour, it is even
>> applicable to existing logic. no?
>
> Try allocating WMI memory with GFP_DMA32. The way it currently is
> working in linux is that caling dma map ends up allocating iommu slots
> to map that 64 bit memory back into 32 bit space, /or/ it will end up
> allocating bounce buffers.
>
> The WMI memory alloc routine is being used for the swap space too,
> which ends up with 700kbyte or more allocated twice - once for the
> initial alloc, and another for the dma map call.
>
> You should try GFP_DMA32 and see if that fixes it. You need contig, <
> 32 bit physical memory allocated, and bounce buffers are really
> supposed to be ephemeral.

I briefly tested with the GFP_DMA32 and it worked on my 9984 test rig.

I also found firmware bugs in my 10.4.3 (3.3-25) based firmware when smaller
chunk sizes are used.  Possibly this is fixed in QCA firmware images, but likely
if you select more active peers than will fit in one 256k chunk your firmware
will crash.  I tested with 72 active peers.  I have fixed this bug in my 9984 firmware
as far as I can tell, but I have not run stress tests on it yet.

Thanks,
Ben

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


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



From adrian at freebsd.org  Tue Jul 19 10:00:11 2016
From: adrian at freebsd.org (Adrian Chadd)
Date: Tue, 19 Jul 2016 10:00:11 -0700
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <578E5AFA.4000908@candelatech.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
Message-ID: <CAJ-VmokHgMVn530PfJS_KEwnUiYBvebOAkP72k319b4BUkYRUg@mail.gmail.com>

Some more test hardware arrived on Friday, so I'll whack a peregrine
v2 NIC in this afternoon and test out my changes.

I'll send a pull request with the DMA32 changes today or tomorrow.

(If someone would like to send me some beeliner/cascade hardware or
arrange something to be picked up in San Jose then I can test on that,
otherwise it'll have to wait; I don't have easy access to anything
else besides dakota and that is being used for other bring-up
activities atm.)



-adrian


From Perry_Yuan at Dell.com  Tue Jul 19 20:14:22 2016
From: Perry_Yuan at Dell.com (Perry_Yuan at Dell.com)
Date: Wed, 20 Jul 2016 11:14:22 +0800
Subject: ath10k fail to load firmware
In-Reply-To: <20160719092727.GD2751@redhat.com>
References: <20160719070932.GA2751@redhat.com>
 <CA+BoTQn98UFuGT0NntdE1HgG9UmmwzS=JsGkLmeGoMHSFGyDRg@mail.gmail.com>
 <20160719072754.GB2751@redhat.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F0C8@SHAX7MCDC101.APAC.DELL.COM>
 <CA+BoTQn4T+4zMrJEbLBfu92w=mVqWBZZkZaYaW__V2_-VLkCyQ@mail.gmail.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F107@SHAX7MCDC101.APAC.DELL.COM>
 <CA+BoTQk7QKaO2yxMq5JEhrBhn4WtpmWTcOxfiXcvYxrFvaxdgw@mail.gmail.com>
 <20160719092727.GD2751@redhat.com>
Message-ID: <A3D794F1192BBF449DF2EC3D7EE263F44A5402F23C@SHAX7MCDC101.APAC.DELL.COM>

Dell - Internal Use - Confidential 

Add Jared 

keep up the good work
Perry? Yuan
Dell | Client Software Group | Platform Sftwr Senior Engineer
office +86 21 22030689, mobile +86 18521512823
perry_yuan at dell.com
Please consider the environment before printing this email.

-----Original Message-----
From: Stanislaw Gruszka [mailto:sgruszka at redhat.com] 
Sent: Tuesday, July 19, 2016 5:27 PM
To: Michal Kazior <michal.kazior at tieto.com>
Cc: Yuan, Perry <Perry_Yuan at Dell.com>; Kalle Valo <kvalo at qca.qualcomm.com>; ath10k at lists.infradead.org; Shen, Yijun <Yijun_Shen at Dell.com>
Subject: Re: ath10k fail to load firmware

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

Please use reply-to-all, so I could see messages. You can drop ML eventually if you thing your data is confidential.

> Thanks for checking!
> 
> Apparently the available board-2.bin doesn't contain any subsystem
> vendor=1028 board data (just checked).
> 
> Also, you guys (i.e. Perry & Stanislaw) seem to be using 2 slightly 
> different devices. One reports its subsystem ids as 1028:0310 (in the 
> original log Stanislaw provided) and 1028:0410 (found in logs attached 
> by Perry).

I provided dmesg, which I get from Perry, hence seems that Perry tests on 2 different devices :-)

Stanislaw 


From michal.kazior at tieto.com  Tue Jul 19 22:36:02 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 20 Jul 2016 07:36:02 +0200
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <1468941948774.87860@qti.qualcomm.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
Message-ID: <CA+BoTQmRL=LO_U0DDkNbrwLv0-1JB50cD8QyY7WnpqzMF+VMFQ@mail.gmail.com>

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

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

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


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

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


Micha?


From michal.kazior at tieto.com  Tue Jul 19 22:38:54 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 20 Jul 2016 07:38:54 +0200
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <578E5AFA.4000908@candelatech.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
Message-ID: <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>

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

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


Micha?


From adrian at freebsd.org  Tue Jul 19 22:44:40 2016
From: adrian at freebsd.org (Adrian Chadd)
Date: Tue, 19 Jul 2016 22:44:40 -0700
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
Message-ID: <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>

Hi,

dma coherent doesn't /have/ to mean "low 32 bits". It's just supposed
to mean "try really hard to use uncached memory on platforms that
support it."

The ath10k hardware (at least what I've played with thus far) is all
32 bit DMA hardware, not 64 bit, so it can't be handed 64 bit memory -
contiguous or otherwise.

So, if dma coherent on linux means 32 bit only physmem, great.

Now, it also turns out that various platforms that say they do
coherent memory these days do "mostly coherent", and you still need
some flush/sync ops..


-adrian


From adrian at freebsd.org  Tue Jul 19 23:11:37 2016
From: adrian at freebsd.org (Adrian Chadd)
Date: Tue, 19 Jul 2016 23:11:37 -0700
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
Message-ID: <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>

Hi,

The ath10k on-chip DMA engine only knows how to address the low 32
bits of physical address space. It can't do DMA elsewhere without a
hardware IOMMU in the system. Even then, as far as the device is
concerned, it's being given < 32 bit physical memory addresses to DMA
around.

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


-adrian


From michal.kazior at tieto.com  Tue Jul 19 23:05:49 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 20 Jul 2016 08:05:49 +0200
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
Message-ID: <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>

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

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

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


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

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


Micha?


From michal.kazior at tieto.com  Tue Jul 19 23:27:22 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 20 Jul 2016 08:27:22 +0200
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
Message-ID: <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>

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

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


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

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

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

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

        val |= 0x100000 | (addr & 0xfffff);
        return val;
}

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

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


Micha?


From michal.kazior at tieto.com  Tue Jul 19 23:58:12 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 20 Jul 2016 08:58:12 +0200
Subject: ath10k fail to load firmware
In-Reply-To: <A3D794F1192BBF449DF2EC3D7EE263F44A5402F23C@SHAX7MCDC101.APAC.DELL.COM>
References: <20160719070932.GA2751@redhat.com>
 <CA+BoTQn98UFuGT0NntdE1HgG9UmmwzS=JsGkLmeGoMHSFGyDRg@mail.gmail.com>
 <20160719072754.GB2751@redhat.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F0C8@SHAX7MCDC101.APAC.DELL.COM>
 <CA+BoTQn4T+4zMrJEbLBfu92w=mVqWBZZkZaYaW__V2_-VLkCyQ@mail.gmail.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F107@SHAX7MCDC101.APAC.DELL.COM>
 <CA+BoTQk7QKaO2yxMq5JEhrBhn4WtpmWTcOxfiXcvYxrFvaxdgw@mail.gmail.com>
 <20160719092727.GD2751@redhat.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F23C@SHAX7MCDC101.APAC.DELL.COM>
Message-ID: <CA+BoTQk_R9sv4-wXGLOt-JzP+3PqSHeyMEweGEXAv84HjJPp3Q@mail.gmail.com>

Hi Perry,

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


Micha?


From Perry_Yuan at Dell.com  Wed Jul 20 00:23:16 2016
From: Perry_Yuan at Dell.com (Perry_Yuan at Dell.com)
Date: Wed, 20 Jul 2016 15:23:16 +0800
Subject: ath10k fail to load firmware
In-Reply-To: <CA+BoTQk_R9sv4-wXGLOt-JzP+3PqSHeyMEweGEXAv84HjJPp3Q@mail.gmail.com>
References: <20160719070932.GA2751@redhat.com>
 <CA+BoTQn98UFuGT0NntdE1HgG9UmmwzS=JsGkLmeGoMHSFGyDRg@mail.gmail.com>
 <20160719072754.GB2751@redhat.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F0C8@SHAX7MCDC101.APAC.DELL.COM>
 <CA+BoTQn4T+4zMrJEbLBfu92w=mVqWBZZkZaYaW__V2_-VLkCyQ@mail.gmail.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F107@SHAX7MCDC101.APAC.DELL.COM>
 <CA+BoTQk7QKaO2yxMq5JEhrBhn4WtpmWTcOxfiXcvYxrFvaxdgw@mail.gmail.com>
 <20160719092727.GD2751@redhat.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F23C@SHAX7MCDC101.APAC.DELL.COM>
 <CA+BoTQk_R9sv4-wXGLOt-JzP+3PqSHeyMEweGEXAv84HjJPp3Q@mail.gmail.com>
Message-ID: <A3D794F1192BBF449DF2EC3D7EE263F44A5402F315@SHAX7MCDC101.APAC.DELL.COM>

Dell - Internal Use - Confidential 

Hi Michal:
I will  contact with Windows driver team to get the right board-2.bin file .
Thanks a lot .

keep up the good work
Perry? Yuan
Dell | Client Software Group | Platform Sftwr Senior Engineer
office +86 21 22030689, mobile +86 18521512823
perry_yuan at dell.com
Please consider the environment before printing this email.


-----Original Message-----
From: Michal Kazior [mailto:michal.kazior at tieto.com] 
Sent: Wednesday, July 20, 2016 2:58 PM
To: Yuan, Perry <Perry_Yuan at Dell.com>
Cc: Stanislaw Gruszka <sgruszka at redhat.com>; Kalle Valo <kvalo at qca.qualcomm.com>; ath10k at lists.infradead.org; Shen, Yijun <Yijun_Shen at Dell.com>; Dominguez, Jared <Jared_Dominguez at DELL.com>
Subject: Re: ath10k fail to load firmware

Hi Perry,

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


Micha?

From s.gottschall at dd-wrt.com  Wed Jul 20 01:49:10 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Wed, 20 Jul 2016 10:49:10 +0200
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
Message-ID: <00174431-61c3-0f5d-4adc-2fdcfe8e3171@dd-wrt.com>

Hello

while hunting a link stability (packet transmission stop) issue i 
discovered a maybe cosmetic, but maybe als serious issue.
AP is a QCA9880 3x3 card configured as WDS AP
Station is a QCA9880 2x2 card configured as WDS STA

the TX rate of the station matches to the rx rate of the AP.
but the RX rate of the station is wrong as it seems which may be a cause 
of the issue.
could this be a firmware bug on QCA9880?

output of fw_stats

WDS AP:
              Peer MAC address 40:a5:ef:85:4d:6f
                      Peer RSSI 12
                   Peer TX rate 175500
                   Peer RX rate 175500
               Peer RX duration 0


WDS STA:
             Peer MAC address 40:a5:ef:51:49:db
                      Peer RSSI 13
                   Peer TX rate 175500
                   Peer RX rate 351000
               Peer RX duration 0


Sebastian


From s.gottschall at dd-wrt.com  Wed Jul 20 01:51:04 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Wed, 20 Jul 2016 10:51:04 +0200
Subject: rx rate issue
In-Reply-To: <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
Message-ID: <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>

Hello

while hunting a link stability (packet transmission stop) issue i 
discovered a maybe cosmetic, but maybe als serious issue.
AP is a QCA9880 3x3 card configured as WDS AP
Station is a QCA9880 2x2 card configured as WDS STA

the TX rate of the station matches to the rx rate of the AP.
but the RX rate of the station is wrong as it seems which may be a cause 
of the issue.
could this be a firmware bug on QCA9880?

output of fw_stats

WDS AP:
              Peer MAC address 40:a5:ef:85:4d:6f
                      Peer RSSI 12
                   Peer TX rate 175500
                   Peer RX rate 175500
               Peer RX duration 0


WDS STA:
             Peer MAC address 40:a5:ef:51:49:db
                      Peer RSSI 13
                   Peer TX rate 175500
                   Peer RX rate 351000
               Peer RX duration 0


Sebastian


From michal.kazior at tieto.com  Wed Jul 20 03:23:13 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 20 Jul 2016 12:23:13 +0200
Subject: rx rate issue
In-Reply-To: <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
Message-ID: <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>

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

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

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

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

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


Micha?


From s.gottschall at dd-wrt.com  Wed Jul 20 03:50:50 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Wed, 20 Jul 2016 12:50:50 +0200
Subject: rx rate issue
In-Reply-To: <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
Message-ID: <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>

Am 20.07.2016 um 12:23 schrieb Michal Kazior:
> On 20 July 2016 at 10:51, Sebastian Gottschall 
> <s.gottschall at dd-wrt.com> wrote:
>> Hello
>>
>> while hunting a link stability (packet transmission stop) issue i 
>> discovered
>> a maybe cosmetic, but maybe als serious issue.
>> AP is a QCA9880 3x3 card configured as WDS AP
>> Station is a QCA9880 2x2 card configured as WDS STA
>>
>> the TX rate of the station matches to the rx rate of the AP.
>> but the RX rate of the station is wrong as it seems which may be a 
>> cause of
>> the issue.
>> could this be a firmware bug on QCA9880?
>>
>> output of fw_stats
>>
>> WDS AP:
>>               Peer MAC address 40:a5:ef:85:4d:6f
>>                       Peer RSSI 12
>>                    Peer TX rate 175500
>>                    Peer RX rate 175500
>>                Peer RX duration 0
>>
>>
>> WDS STA:
>>              Peer MAC address 40:a5:ef:51:49:db
>>                       Peer RSSI 13
>>                    Peer TX rate 175500
>>                    Peer RX rate 351000
>>                Peer RX duration 0
> Hmm.. Interesting. FWIW these are "last tx/rx rate". This isn't
> average nor anything fancy like that.
this is in sync yes. its also not that i just observed it for a second. 
this test installation is running here for a while
and while looking for the cause i observed this behavior.

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

peer rx rate and iw dump is identical
STA:
Peer RX rate 526500
rx bitrate:     526.6 MBit/s VHT-MCS 6 80MHz VHT-NSS 2
AP:

AP
Peer TX rate 234000

interesting here is that the TX rate on STA side matches to the RX rate 
on AP side, but not vice versa

>
> I do wonder at what rate frames are actually transmitted OTA.
>
> Is this reproducible? Can you try setting a fixed tx bitrate (`iw
> wlanX set bitrates legacy-5 ht-mcs vht-mcs 1:4` to force vht mcs=4,
> nss=1) to see if it makes any difference? Perhaps rate-control and tx
> try-list/status are not parsed properly (for statistical purposes) in
> firmware which ends up with invalid peer-tx-rate on WDS AP.
lets try. can you correct the syntax? the following is not correct
iw dev ath1 set bitrates legacy-5 ht-mcs vht-mcs 1:4

Usage:  iw [options] dev <devname> set bitrates [legacy-<2.4|5> <legacy 
rate in Mbps>*] [ht-mcs-<2.4|5> <MCS index>*] [v
ht-mcs-<2.4|5> <NSS:MCSx,MCSy... | NSS:MCSx-MCSy>*] [sgi-2.4|lgi-2.4] 
[sgi-5|lgi-5]

Sets up the specified rate masks.
Not passing any arguments would clear the existing mask (if any).


>
>
> Micha?
>


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From chaitanya.mgit at gmail.com  Wed Jul 20 03:52:30 2016
From: chaitanya.mgit at gmail.com (Krishna Chaitanya)
Date: Wed, 20 Jul 2016 16:22:30 +0530
Subject: ath10k + iw set bitrates is causing FW crash
In-Reply-To: <CABPxzYJPi4CqO+KUFA7=r=zpq_c2vFtrgBQ+nF_nThO-cYrteg@mail.gmail.com>
References: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>
 <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>
 <1467972560885.99812@qti.qualcomm.com>
 <CABPxzY+8Y-FHUFALGueN1hQwgjJHNpeyy_BRkrM4osguxJZS0Q@mail.gmail.com>
 <1467982766213.21223@qti.qualcomm.com>
 <CABPxzYLO8rzvOJ_1iqng89kYFS-xqC3qstbgETVRJHDpO4rikQ@mail.gmail.com>
 <CABPxzYJPi4CqO+KUFA7=r=zpq_c2vFtrgBQ+nF_nThO-cYrteg@mail.gmail.com>
Message-ID: <CABPxzYKomhw5rF4Crj6sMbmr3VuuDYi=zqN2ky83v-=RJe7Zhg@mail.gmail.com>

On Fri, Jul 8, 2016 at 9:07 PM, Krishna Chaitanya
<chaitanya.mgit at gmail.com> wrote:
>
> On Fri, Jul 8, 2016 at 8:57 PM, Krishna Chaitanya
> <chaitanya.mgit at gmail.com> wrote:
> > On Fri, Jul 8, 2016 at 6:29 PM, Manoharan, Rajkumar
> > <rmanohar at qti.qualcomm.com> wrote:
> >> I think security failures are due to peer unmap & map upon reassoc. Can you please try below change?
> >>
> >> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> >> index 5e1cc8f4c43c..f7f04bb46fc8 100644
> >> --- a/drivers/net/wireless/ath/ath10k/mac.c
> >> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> >> @@ -5745,8 +5745,9 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
> >>                                     sta->addr, smps, err);
> >>         }
> >>
> >> -       if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
> >> -           changed & IEEE80211_RC_NSS_CHANGED) {
> >> +       if ((changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
> >> +           changed & IEEE80211_RC_NSS_CHANGED) &&
> >> +           (arvif->vif->type == NL80211_IFTYPE_ADHOC)) {
> >>                 ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp rates/nss\n",
> >>                            sta->addr);
> >
> > Bottom posting please. I have tried your change i still see the same issue.
> > Right after connecting i see that packets are encrypted but once it
> > unset/set "bitrates" plain packets are seen in sniffer.
> >
> > BTW, i am not rebooting for each driver update, just re-inserting the module,
> > do i need to do a reboot for each driver change?
>
> After reboot i dont see the "unencrypted" packet issue, i will do
> some more testing on limiting the rates, currently in my setup its
> not reaching MCS9 so cannot verify now.
>
> Thanks for the fixes and prompt reply.



>
>   ________________________________________
> >> From: Krishna Chaitanya <chaitanya.mgit at gmail.com>
> >> Sent: Friday, July 8, 2016 5:26 PM
> >> To: Manoharan, Rajkumar
> >> Cc: linux-wireless; ath10k
> >> Subject: Re: ath10k + iw set bitrates is causing FW crash
> >>
> >> On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
> >> <rmanohar at qti.qualcomm.com> wrote:
> >>>>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
> >>>>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
> >>>>>
> >>>>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
> >>>>> no crash is observed but it still uses MCS9.
> >>>>>
> >>>>> tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339
> >>>>>
> >>>>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
> >>>>> the mac80211 rates?
> >>>>>
> >>>>
> >>> Thanks for reporting the issue. Could you please try with below change?
> >>>
> >>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> >>> index 5e1cc8f4c43c..cfa7e01a6103 100644
> >>> --- a/drivers/net/wireless/ath/ath10k/mac.c
> >>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> >>> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
> >>>                 return ret;
> >>>         }
> >>>
> >>> +       if (vif->type != NL80211_IFTYPE_ADHOC)
> >>> +               peer_arg.peer_reassoc = reassoc;
> >>> +
> >>>         ret = ath10k_wmi_peer_assoc(ar, &peer_arg);
> >>>         if (ret) {
> >>>                 ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev %i: %d\n",
> >>
> >> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
> >> seeing 0-9, so its
> >> working.
> >>
> >> But i am seeing a weird issues, the moment i give bitrates command,
> >> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
> >> interface up/down
> >> it doesn't work.
Rajkumar,

I am still not able to make mcs9 work, so i have tried to change the Nss to 1
using iw, but that is not taking affect. This command is not taking effect.


From michal.kazior at tieto.com  Wed Jul 20 04:03:00 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 20 Jul 2016 13:03:00 +0200
Subject: rx rate issue
In-Reply-To: <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
Message-ID: <CA+BoTQ=yC7kN7ayWqZ9Y3SBL0jQZRkKMU2=T9Z21Vwxjp2m7uw@mail.gmail.com>

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

Ah, sorry, my bad.

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

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

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


Micha?


From s.gottschall at dd-wrt.com  Wed Jul 20 04:10:01 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Wed, 20 Jul 2016 13:10:01 +0200
Subject: rx rate issue
In-Reply-To: <CA+BoTQ=yC7kN7ayWqZ9Y3SBL0jQZRkKMU2=T9Z21Vwxjp2m7uw@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
 <CA+BoTQ=yC7kN7ayWqZ9Y3SBL0jQZRkKMU2=T9Z21Vwxjp2m7uw@mail.gmail.com>
Message-ID: <f1129e1d-a30c-69a0-c973-2953c3786f61@dd-wrt.com>

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

sta:
rx bitrate:     175.5 MBit/s VHT-MCS 4 80MHz VHT-NSS 1
                  Peer TX rate 234000
                   Peer RX rate 175500


AP:
         rx bitrate:     175.5 MBit/s VHT-MCS 4 80MHz VHT-NSS 1
                   Peer TX rate 263300
                   Peer RX rate 175500

this looks even more curious
>
> Micha?
>


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From s.gottschall at dd-wrt.com  Wed Jul 20 04:12:50 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Wed, 20 Jul 2016 13:12:50 +0200
Subject: rx rate issue
In-Reply-To: <CA+BoTQ=yC7kN7ayWqZ9Y3SBL0jQZRkKMU2=T9Z21Vwxjp2m7uw@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
 <CA+BoTQ=yC7kN7ayWqZ9Y3SBL0jQZRkKMU2=T9Z21Vwxjp2m7uw@mail.gmail.com>
Message-ID: <b08002e3-8f45-d6c2-607e-344fbddbd957@dd-wrt.com>

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

sta:
rx bitrate:     175.5 MBit/s VHT-MCS 4 80MHz VHT-NSS 1
                  Peer TX rate 234000
                   Peer RX rate 175500


AP:
         rx bitrate:     175.5 MBit/s VHT-MCS 4 80MHz VHT-NSS 1
                   Peer TX rate 263300
                   Peer RX rate 175500

this looks even more curious
>
> Micha?
>


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From michal.kazior at tieto.com  Wed Jul 20 04:32:07 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 20 Jul 2016 13:32:07 +0200
Subject: rx rate issue
In-Reply-To: <f1129e1d-a30c-69a0-c973-2953c3786f61@dd-wrt.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
 <CA+BoTQ=yC7kN7ayWqZ9Y3SBL0jQZRkKMU2=T9Z21Vwxjp2m7uw@mail.gmail.com>
 <f1129e1d-a30c-69a0-c973-2953c3786f61@dd-wrt.com>
Message-ID: <CA+BoTQk6Uzb02h0oDDOm7stct9=3YVw--yQJWyCYwN5G7f6sPQ@mail.gmail.com>

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

Thanks for checking.

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

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

On the plus side it's probably harmless.


Micha?


From mohammed at qti.qualcomm.com  Wed Jul 20 05:10:59 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Wed, 20 Jul 2016 17:40:59 +0530
Subject: [RESEND PATCH v4] ath10k: Fix sending NULL/ Qos NULL data frames for
 QCA99X0 and later
Message-ID: <1469016659-1887-1-git-send-email-mohammed@qca.qualcomm.com>

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

For chipsets like QCA99X0, IPQ4019 and later we are not getting proper
NULL func status (always acked/successs !!) when hostapd does a
PROBE_CLIENT via nullfunc frames when the station is powered off
abruptly (inactive timer probes client via null func after the inactive
time reaches beyond the threshold). Fix this by disabling the workaround
introduced by the change ("ath10k: fix beacon loss handling ") for
QCA99X0 and later chipsets. The normal tx path provides the proper
status for NULL data frames. As of now disable this workaround for
chipsets QCA99X0 and later, once the 10.1 firmware is obselete we can
completely get rid of this workaround for all the chipsets

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

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index dcc76b6..8687aaa 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -181,6 +181,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
 			.board_size = QCA99X0_BOARD_DATA_SZ,
 			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+			.disable_null_func_workaround = true,
 		},
 	},
 	{
@@ -204,6 +205,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board = QCA9984_HW_1_0_BOARD_DATA_FILE,
 			.board_size = QCA99X0_BOARD_DATA_SZ,
 			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+			.disable_null_func_workaround = true,
 		},
 	},
 	{
@@ -262,6 +264,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
 			.board_size = QCA4019_BOARD_DATA_SZ,
 			.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
+			.disable_null_func_workaround = true,
 		},
 	},
 };
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 3da18c9..d3dfda0 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -750,6 +750,7 @@ struct ath10k {
 			const char *board;
 			size_t board_size;
 			size_t board_ext_size;
+			bool disable_null_func_workaround;
 		} fw;
 	} hw_params;
 
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d4b7a16..f1e9672 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3236,6 +3236,7 @@ ath10k_mac_tx_h_get_txmode(struct ath10k *ar,
 	 * mode though because AP don't sleep.
 	 */
 	if (ar->htt.target_version_major < 3 &&
+	    !ar->hw_params.fw.disable_null_func_workaround &&
 	    (ieee80211_is_nullfunc(fc) || ieee80211_is_qos_nullfunc(fc)) &&
 	    !test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX,
 		      ar->running_fw->fw_file.fw_features))
-- 
1.9.1



From michal.kazior at tieto.com  Wed Jul 20 05:22:29 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 20 Jul 2016 14:22:29 +0200
Subject: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for
 QCA99X0 and later
In-Reply-To: <900ae7541c5a4194a2f73479e1dd8bb2@aphydexm01b.ap.qualcomm.com>
References: <1466700001-4883-1-git-send-email-mohammed@qca.qualcomm.com>
 <1466700001-4883-2-git-send-email-mohammed@qca.qualcomm.com>
 <CA+BoTQnUvF2Zy7_WuEi0V+KjByRghVmoeR6yrs6hu6ag=KmBqQ@mail.gmail.com>
 <20160627143600.GA5292@atheros-ThinkPad-T61>
 <CA+BoTQn+HeishCMf4hjpWjLBmvFG2r0gosBv77RTyk7+uOAvPA@mail.gmail.com>
 <20160629094754.GA8867@atheros-ThinkPad-T61>
 <CAD2nsn3TOSaOCmm5YT6_D+aaoH9=pagQamDDz2VT+nKrFH0K8g@mail.gmail.com>
 <900ae7541c5a4194a2f73479e1dd8bb2@aphydexm01b.ap.qualcomm.com>
Message-ID: <CA+BoTQmHW=uYompSLXUv2d+-Nr=11KYuA=VrmUz6X2T+D=-=Ag@mail.gmail.com>

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

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

Quoting your other email:

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

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

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

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

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


Micha?


From mohammed at codeaurora.org  Wed Jul 20 09:27:51 2016
From: mohammed at codeaurora.org (Mohammed Shafi Shajakhan)
Date: Wed, 20 Jul 2016 21:57:51 +0530
Subject: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for
 QCA99X0 and later
In-Reply-To: <CA+BoTQmHW=uYompSLXUv2d+-Nr=11KYuA=VrmUz6X2T+D=-=Ag@mail.gmail.com>
References: <1466700001-4883-1-git-send-email-mohammed@qca.qualcomm.com>
 <1466700001-4883-2-git-send-email-mohammed@qca.qualcomm.com>
 <CA+BoTQnUvF2Zy7_WuEi0V+KjByRghVmoeR6yrs6hu6ag=KmBqQ@mail.gmail.com>
 <20160627143600.GA5292@atheros-ThinkPad-T61>
 <CA+BoTQn+HeishCMf4hjpWjLBmvFG2r0gosBv77RTyk7+uOAvPA@mail.gmail.com>
 <20160629094754.GA8867@atheros-ThinkPad-T61>
 <CAD2nsn3TOSaOCmm5YT6_D+aaoH9=pagQamDDz2VT+nKrFH0K8g@mail.gmail.com>
 <900ae7541c5a4194a2f73479e1dd8bb2@aphydexm01b.ap.qualcomm.com>
 <CA+BoTQmHW=uYompSLXUv2d+-Nr=11KYuA=VrmUz6X2T+D=-=Ag@mail.gmail.com>
Message-ID: <20160720162751.GA17599@atheros-ThinkPad-T61>

On Wed, Jul 20, 2016 at 02:22:29PM +0200, Michal Kazior wrote:
> On 20 July 2016 at 13:43, Shajakhan, Mohammed Shafi (Mohammed Shafi)
> <mohammed at qti.qualcomm.com> wrote:
> > Michal,
> >
> > Can you please let me know if this change is fine or not ?
> > I am waiting infinitely for  your reply long time
> 
> Sorry. I was absent for a while and this email slipped by.

[shafi] ah ok, i thought you had blacklisted this change :)

> 
> Quoting your other email:
> 
> > is this patch is good to go (or) should i re-work  ?
> > I had replied to Michal's comment of introducing a new firmware
> > feature flag will not address the issue in older firmware / code.
> > Let me know if i had missed something very obvious.
> 
> I couldn't really find any conclusion to this thread in my inbox.
> 
> The hw_params approach is definitely wrong. The ACK problem is
> firmware-specific, not hardware-specific.

[shafi] sure let me see if i can figure out an alternative way that shall be
accepted by you and Kalle

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

[shafi] sorry i am not sure how to validate that, so i will keep this workaround

> 
> Nullfunc tx-status ack/noack reports could be probably fixed up using
> sta kickout events (with short timeouts) as a fallback. This would
> make it easier for users because otherwise they'd need to enable
> disassoc_low_ack in hostapd (which is probably impossible with
> wpa_supplicant for p2p, no?).
> 
>
[shafi] let me check this, i think we usually don't enable disassoc_low_ack to
avoid kicking out stations frequently.

shafi


From greearb at candelatech.com  Wed Jul 20 09:42:58 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 20 Jul 2016 09:42:58 -0700
Subject: rx rate issue
In-Reply-To: <b08002e3-8f45-d6c2-607e-344fbddbd957@dd-wrt.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
 <CA+BoTQ=yC7kN7ayWqZ9Y3SBL0jQZRkKMU2=T9Z21Vwxjp2m7uw@mail.gmail.com>
 <b08002e3-8f45-d6c2-607e-344fbddbd957@dd-wrt. com>
Message-ID: <578FAA12.4020509@candelatech.com>



On 07/20/2016 04:12 AM, Sebastian Gottschall wrote:
> Am 20.07.2016 um 13:03 schrieb Michal Kazior:

>>>>> WDS AP:
>>>>>                Peer MAC address 40:a5:ef:85:4d:6f
>>>>>                        Peer RSSI 12
>>>>>                     Peer TX rate 175500
>>>>>                     Peer RX rate 175500
>>>>>                 Peer RX duration 0
>>>>>
>>>>>
>>>>> WDS STA:
>>>>>               Peer MAC address 40:a5:ef:51:49:db
>>>>>                        Peer RSSI 13
>>>>>                     Peer TX rate 175500
>>>>>                     Peer RX rate 351000
>>>>>                 Peer RX duration 0
>> [...]

One thing, if your signal is really this hot (-12, -13), then you are likely over-saturating
the RF logic.  You normally get best results at around -40 signal level...

Thanks,
Ben

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


From greearb at candelatech.com  Wed Jul 20 09:52:30 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 20 Jul 2016 09:52:30 -0700
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <CA+BoTQmRL=LO_U0DDkNbrwLv0-1JB50cD8QyY7WnpqzMF+VMFQ@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CA+BoTQmRL=LO_U0DDkNbrwLv0-1JB50cD8QyY7WnpqzMF+VMFQ@mail.gmail.com>
Message-ID: <578FAC4E.2010706@candelatech.com>



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

Yes, that resolves the faults, or at least the vast majority of them.

Remaining spurious faults are likely firmware bugs accessing bad memory, I guess.
You probably don't notice this at all on ARM and other systems w/out hardware IOMMU?

>> Even with current logic, If the memory chunk allocation fails for bigger size, then it tries
>> to allocate smaller chunks. So If smaller chunks causes unexpected behaviour, it is even
>> applicable to existing logic. no?
>
> We still don't know *why* using non-coherent memory causes problems.
> Changing chunk size limit seems to alter the behavior in some
> unpredictable ways, yes, but it's really hard to tell if the "try
> smaller chunk sizes" *itself* introduces any problems.

If it is crashing firmware somehow, and you can get a backtrace, then likely
it can be debugged.  In my case, changing the size caused firmware to crash due to
lame logic bug in the firmware, for instance.  Possibly other crashes are as
mundane as that.

Thanks,
Ben


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


From greearb at candelatech.com  Wed Jul 20 09:48:22 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 20 Jul 2016 09:48:22 -0700
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
Message-ID: <578FAB56.1030606@candelatech.com>



On 07/19/2016 11:05 PM, Michal Kazior wrote:
> On 20 July 2016 at 07:44, Adrian Chadd <adrian at freebsd.org> wrote:
>> Hi,
>>
>> dma coherent doesn't /have/ to mean "low 32 bits". It's just supposed
>> to mean "try really hard to use uncached memory on platforms that
>> support it."
>
> Good point. Maybe it does on x86, or at least some machines.
>
> @Ben: Can you verify if that's the case for you? Can you see what
> address ranges hostmem chunks get with and without the GFP_DMA32 (and
> maybe compare it against a revert to compare to dma-coherent as well)?

You just want a printk("%p", foo); for the chunks returned with and without
this flag?

>
>
>> The ath10k hardware (at least what I've played with thus far) is all
>> 32 bit DMA hardware, not 64 bit, so it can't be handed 64 bit memory -
>> contiguous or otherwise.
>>
>> So, if dma coherent on linux means 32 bit only physmem, great.
>>
>> Now, it also turns out that various platforms that say they do
>> coherent memory these days do "mostly coherent", and you still need
>> some flush/sync ops..
>
> Yeah, but since the device has it's own CPU and RAM it has to have a
> way to distinguish local and host memory in some way using these 32
> bits, no? (think about firmware generating local 802.11 frames vs
> pushing frames coming from host driver)

Host memory cannot be accessed directly I think, at least not by normal
code.  Firmware uses some low level 'ce' type logic to handle that I think?

In 10.4 firmware, check out the code-swap code, for instance, or the
rate-ctrl swap logic in 10.1 or higher?

Thanks,
Ben

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


From s.gottschall at dd-wrt.com  Wed Jul 20 09:50:45 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Wed, 20 Jul 2016 18:50:45 +0200
Subject: rx rate issue
In-Reply-To: <578FAA12.4020509@candelatech.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
 <CA+BoTQ=yC7kN7ayWqZ9Y3SBL0jQZRkKMU2=T9Z21Vwxjp2m7uw@mail.gmail.com>
 <b08002e3-8f45-d6c2-607e-344fbddbd957@dd-wrt. com>
 <578FAA12.4020509@candelatech.com>
Message-ID: <5511d94c-3f25-a7e2-6724-2540d8cfa7f6@dd-wrt.com>

Am 20.07.2016 um 18:42 schrieb Ben Greear:
>
>
> On 07/20/2016 04:12 AM, Sebastian Gottschall wrote:
>> Am 20.07.2016 um 13:03 schrieb Michal Kazior:
>
>>>>>> WDS AP:
>>>>>>                Peer MAC address 40:a5:ef:85:4d:6f
>>>>>>                        Peer RSSI 12
>>>>>>                     Peer TX rate 175500
>>>>>>                     Peer RX rate 175500
>>>>>>                 Peer RX duration 0
>>>>>>
>>>>>>
>>>>>> WDS STA:
>>>>>>               Peer MAC address 40:a5:ef:51:49:db
>>>>>>                        Peer RSSI 13
>>>>>>                     Peer TX rate 175500
>>>>>>                     Peer RX rate 351000
>>>>>>                 Peer RX duration 0
>>> [...]
>
> One thing, if your signal is really this hot (-12, -13), then you are 
> likely over-saturating
> the RF logic.  You normally get best results at around -40 signal 
> level...
the peer ssid is not db. its more likelly the snr. both devices have 20 
meter distance with a brick wall in between
so its not over saturating. mac80211 shows about -81 rssi and -95 noise 
right now with heavy fluctuations up to -70
>
> Thanks,
> Ben
>


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From adrian at freebsd.org  Wed Jul 20 10:02:19 2016
From: adrian at freebsd.org (Adrian Chadd)
Date: Wed, 20 Jul 2016 10:02:19 -0700
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
Message-ID: <CAJ-VmomcD8FgA34z3OFKZvc5yq8EsHOTqP=Lg-6gFOAcWys8og@mail.gmail.com>

Hi,

The "right" way for the target CPU to interact with host CPU memory
(and vice versa, for mostly what it's worth) is to have the copy
engine copy (ie, "DMA") the pieces between them. This may be for
diagnostic purposes, but it's not supposed to be used like this for
doing wifi data exchange, right? :-P

Now, there /may/ be some alignment hilarity in various bits of code
and/or hardware. Eg, Merlin (AR9280) requires its descriptors to be
within a 4k block - the code to iterate through the descriptor
physical address space didn't do a "val = val + offset", it did
something in verilog like "val = (val & 0xffffc000) | (offset &
0x3fff)". This meant if you allocated a descriptor that started just
before the end of a 4k physmem aligned block, you'd end up with
exciting results. I don't know if there are any situations like this
in the ath10k hardware, but I'm sure there will be some gotchas
somewhere.

In any case, if ath10k is consuming too much bounce buffers, the calls
to allocate memory aren't working right and should be restricted to 32
bit addresses. Whether that's by using the DMA memory API (before it's
mapped) or passing in GFP_DMA32 is a fun debate.

(My test hardware arrived, so I'll test this all out today on
Peregrine-v2 and see if the driver works.)



-adrian




-adrian


From rmanohar at qti.qualcomm.com  Wed Jul 20 23:20:00 2016
From: rmanohar at qti.qualcomm.com (Rajkumar Manoharan)
Date: Thu, 21 Jul 2016 11:50:00 +0530
Subject: [PATCH v2] ath10k: implement NAPI support
Message-ID: <20160721062000.12533-1-rmanohar@qti.qualcomm.com>

Add NAPI support for rx and tx completion. NAPI poll is scheduled
from interrupt handler. The design is as below

 - on interrupt
     - schedule napi and mask interrupts
 - on poll
   - process all pipes (no actual Tx/Rx)
   - process Rx within budget
   - if quota exceeds budget reschedule napi poll by returning budget
   - process Tx completions and update budget if necessary
   - process Tx fetch indications (pull-push)
   - push any other pending Tx (if possible)
   - before resched or napi completion replenish htt rx ring buffer
   - if work done < budget, complete napi poll and unmask interrupts

This change also get rid of two tasklets (intr_tq and txrx_compl_task).

Measured peak throughput with NAPI on IPQ4019 platform in controlled
environment. No noticeable reduction in throughput is seen and also
observed improvements in CPU usage. Approx. 15% CPU usage got reduced
in UDP uplink case.

DL: AP DUT Tx
UL: AP DUT Rx

IPQ4019 (avg. cpu usage %)
========
                TOT              +NAPI
              ===========      =============
TCP DL       644 Mbps (42%)    645 Mbps (36%)
TCP UL       673 Mbps (30%)    675 Mbps (26%)
UDP DL       682 Mbps (49%)    680 Mbps (49%)
UDP UL       720 Mbps (28%)    717 Mbps (11%)

Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
---
v2: rebased change

 drivers/net/wireless/ath/ath10k/ahb.c    |   6 +-
 drivers/net/wireless/ath/ath10k/core.c   |   2 +
 drivers/net/wireless/ath/ath10k/core.h   |   8 ++
 drivers/net/wireless/ath/ath10k/htt.h    |   2 +-
 drivers/net/wireless/ath/ath10k/htt_rx.c | 154 +++++++++++++++++++------------
 drivers/net/wireless/ath/ath10k/htt_tx.c |   2 -
 drivers/net/wireless/ath/ath10k/pci.c    |  69 ++++++++------
 drivers/net/wireless/ath/ath10k/pci.h    |   6 +-
 8 files changed, 153 insertions(+), 96 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/ahb.c b/drivers/net/wireless/ath/ath10k/ahb.c
index acec16b9cf49..cdedfb2cfa41 100644
--- a/drivers/net/wireless/ath/ath10k/ahb.c
+++ b/drivers/net/wireless/ath/ath10k/ahb.c
@@ -462,13 +462,13 @@ static void ath10k_ahb_halt_chip(struct ath10k *ar)
 static irqreturn_t ath10k_ahb_interrupt_handler(int irq, void *arg)
 {
 	struct ath10k *ar = arg;
-	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
 
 	if (!ath10k_pci_irq_pending(ar))
 		return IRQ_NONE;
 
 	ath10k_pci_disable_and_clear_legacy_irq(ar);
-	tasklet_schedule(&ar_pci->intr_tq);
+	ath10k_pci_irq_msi_fw_mask(ar);
+	napi_schedule(&ar->napi);
 
 	return IRQ_HANDLED;
 }
@@ -831,7 +831,7 @@ static int ath10k_ahb_probe(struct platform_device *pdev)
 		goto err_resource_deinit;
 	}
 
-	ath10k_pci_init_irq_tasklets(ar);
+	ath10k_pci_init_napi(ar);
 
 	ret = ath10k_ahb_request_irq_legacy(ar);
 	if (ret)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index e88982921aa3..0ca58cf0ffea 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2249,6 +2249,8 @@ struct ath10k *ath10k_core_create(size_t priv_size, struct device *dev,
 	INIT_WORK(&ar->register_work, ath10k_core_register_work);
 	INIT_WORK(&ar->restart_work, ath10k_core_restart);
 
+	init_dummy_netdev(&ar->napi_dev);
+
 	ret = ath10k_debug_create(ar);
 	if (ret)
 		goto err_free_aux_wq;
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 30ae5bf81611..f36c2b274ee5 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -65,6 +65,10 @@
 #define ATH10K_KEEPALIVE_MAX_IDLE 3895
 #define ATH10K_KEEPALIVE_MAX_UNRESPONSIVE 3900
 
+/* NAPI poll budget */
+#define ATH10K_NAPI_BUDGET      64
+#define ATH10K_NAPI_QUOTA_LIMIT 60
+
 struct ath10k;
 
 enum ath10k_bus {
@@ -936,6 +940,10 @@ struct ath10k {
 	struct ath10k_thermal thermal;
 	struct ath10k_wow wow;
 
+	/* NAPI */
+	struct net_device napi_dev;
+	struct napi_struct napi;
+
 	/* must be last */
 	u8 drv_priv[0] __aligned(sizeof(void *));
 };
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 430a83e142aa..98c14247021b 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1665,7 +1665,6 @@ struct ath10k_htt {
 
 	/* This is used to group tx/rx completions separately and process them
 	 * in batches to reduce cache stalls */
-	struct tasklet_struct txrx_compl_task;
 	struct sk_buff_head rx_compl_q;
 	struct sk_buff_head rx_in_ord_compl_q;
 	struct sk_buff_head tx_fetch_ind_q;
@@ -1798,5 +1797,6 @@ int ath10k_htt_tx(struct ath10k_htt *htt,
 		  struct sk_buff *msdu);
 void ath10k_htt_rx_pktlog_completion_handler(struct ath10k *ar,
 					     struct sk_buff *skb);
+int ath10k_htt_txrx_compl_task(struct ath10k *ar, int budget);
 
 #endif
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 78db5d679f19..d3f8baf532d4 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -34,7 +34,6 @@
 #define HTT_RX_RING_REFILL_RESCHED_MS 5
 
 static int ath10k_htt_rx_get_csum_state(struct sk_buff *skb);
-static void ath10k_htt_txrx_compl_task(unsigned long ptr);
 
 static struct sk_buff *
 ath10k_htt_rx_find_skb_paddr(struct ath10k *ar, u32 paddr)
@@ -226,7 +225,6 @@ int ath10k_htt_rx_ring_refill(struct ath10k *ar)
 void ath10k_htt_rx_free(struct ath10k_htt *htt)
 {
 	del_timer_sync(&htt->rx_ring.refill_retry_timer);
-	tasklet_kill(&htt->txrx_compl_task);
 
 	skb_queue_purge(&htt->rx_compl_q);
 	skb_queue_purge(&htt->rx_in_ord_compl_q);
@@ -520,9 +518,6 @@ int ath10k_htt_rx_alloc(struct ath10k_htt *htt)
 	skb_queue_head_init(&htt->tx_fetch_ind_q);
 	atomic_set(&htt->num_mpdus_ready, 0);
 
-	tasklet_init(&htt->txrx_compl_task, ath10k_htt_txrx_compl_task,
-		     (unsigned long)htt);
-
 	ath10k_dbg(ar, ATH10K_DBG_BOOT, "htt rx ring size %d fill_level %d\n",
 		   htt->rx_ring.size, htt->rx_ring.fill_level);
 	return 0;
@@ -958,7 +953,7 @@ static void ath10k_process_rx(struct ath10k *ar,
 	trace_ath10k_rx_hdr(ar, skb->data, skb->len);
 	trace_ath10k_rx_payload(ar, skb->data, skb->len);
 
-	ieee80211_rx(ar->hw, skb);
+	ieee80211_rx_napi(ar->hw, NULL, skb, &ar->napi);
 }
 
 static int ath10k_htt_rx_nwifi_hdrlen(struct ath10k *ar,
@@ -1527,7 +1522,7 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
 	struct ath10k *ar = htt->ar;
 	static struct ieee80211_rx_status rx_status;
 	struct sk_buff_head amsdu;
-	int ret;
+	int ret, num_msdus;
 
 	__skb_queue_head_init(&amsdu);
 
@@ -1549,13 +1544,14 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
 		return ret;
 	}
 
+	num_msdus = skb_queue_len(&amsdu);
 	ath10k_htt_rx_h_ppdu(ar, &amsdu, &rx_status, 0xffff);
 	ath10k_htt_rx_h_unchain(ar, &amsdu, ret > 0);
 	ath10k_htt_rx_h_filter(ar, &amsdu, &rx_status);
 	ath10k_htt_rx_h_mpdu(ar, &amsdu, &rx_status);
 	ath10k_htt_rx_h_deliver(ar, &amsdu, &rx_status);
 
-	return 0;
+	return num_msdus;
 }
 
 static void ath10k_htt_rx_proc_rx_ind(struct ath10k_htt *htt,
@@ -1579,15 +1575,6 @@ static void ath10k_htt_rx_proc_rx_ind(struct ath10k_htt *htt,
 		mpdu_count += mpdu_ranges[i].mpdu_count;
 
 	atomic_add(mpdu_count, &htt->num_mpdus_ready);
-
-	tasklet_schedule(&htt->txrx_compl_task);
-}
-
-static void ath10k_htt_rx_frag_handler(struct ath10k_htt *htt)
-{
-	atomic_inc(&htt->num_mpdus_ready);
-
-	tasklet_schedule(&htt->txrx_compl_task);
 }
 
 static void ath10k_htt_rx_tx_compl_ind(struct ath10k *ar,
@@ -1772,14 +1759,15 @@ static void ath10k_htt_rx_h_rx_offload_prot(struct ieee80211_rx_status *status,
 			RX_FLAG_MMIC_STRIPPED;
 }
 
-static void ath10k_htt_rx_h_rx_offload(struct ath10k *ar,
-				       struct sk_buff_head *list)
+static int ath10k_htt_rx_h_rx_offload(struct ath10k *ar,
+				      struct sk_buff_head *list)
 {
 	struct ath10k_htt *htt = &ar->htt;
 	struct ieee80211_rx_status *status = &htt->rx_status;
 	struct htt_rx_offload_msdu *rx;
 	struct sk_buff *msdu;
 	size_t offset;
+	int num_msdu = 0;
 
 	while ((msdu = __skb_dequeue(list))) {
 		/* Offloaded frames don't have Rx descriptor. Instead they have
@@ -1819,10 +1807,12 @@ static void ath10k_htt_rx_h_rx_offload(struct ath10k *ar,
 		ath10k_htt_rx_h_rx_offload_prot(status, msdu);
 		ath10k_htt_rx_h_channel(ar, status, NULL, rx->vdev_id);
 		ath10k_process_rx(ar, status, msdu);
+		num_msdu++;
 	}
+	return num_msdu;
 }
 
-static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
+static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 {
 	struct ath10k_htt *htt = &ar->htt;
 	struct htt_resp *resp = (void *)skb->data;
@@ -1835,12 +1825,12 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 	u8 tid;
 	bool offload;
 	bool frag;
-	int ret;
+	int ret, num_msdus = 0;
 
 	lockdep_assert_held(&htt->rx_ring.lock);
 
 	if (htt->rx_confused)
-		return;
+		return -EIO;
 
 	skb_pull(skb, sizeof(resp->hdr));
 	skb_pull(skb, sizeof(resp->rx_in_ord_ind));
@@ -1859,7 +1849,7 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 
 	if (skb->len < msdu_count * sizeof(*resp->rx_in_ord_ind.msdu_descs)) {
 		ath10k_warn(ar, "dropping invalid in order rx indication\n");
-		return;
+		return -EINVAL;
 	}
 
 	/* The event can deliver more than 1 A-MSDU. Each A-MSDU is later
@@ -1870,14 +1860,14 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 	if (ret < 0) {
 		ath10k_warn(ar, "failed to pop paddr list: %d\n", ret);
 		htt->rx_confused = true;
-		return;
+		return -EIO;
 	}
 
 	/* Offloaded frames are very different and need to be handled
 	 * separately.
 	 */
 	if (offload)
-		ath10k_htt_rx_h_rx_offload(ar, &list);
+		num_msdus = ath10k_htt_rx_h_rx_offload(ar, &list);
 
 	while (!skb_queue_empty(&list)) {
 		__skb_queue_head_init(&amsdu);
@@ -1890,6 +1880,7 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 			 * better to report something than nothing though. This
 			 * should still give an idea about rx rate to the user.
 			 */
+			num_msdus += skb_queue_len(&amsdu);
 			ath10k_htt_rx_h_ppdu(ar, &amsdu, status, vdev_id);
 			ath10k_htt_rx_h_filter(ar, &amsdu, status);
 			ath10k_htt_rx_h_mpdu(ar, &amsdu, status);
@@ -1902,9 +1893,10 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 			ath10k_warn(ar, "failed to extract amsdu: %d\n", ret);
 			htt->rx_confused = true;
 			__skb_queue_purge(&list);
-			return;
+			return -EIO;
 		}
 	}
+	return num_msdus;
 }
 
 static void ath10k_htt_rx_tx_fetch_resp_id_confirm(struct ath10k *ar,
@@ -2267,7 +2259,6 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
 	}
 	case HTT_T2H_MSG_TYPE_TX_COMPL_IND:
 		ath10k_htt_rx_tx_compl_ind(htt->ar, skb);
-		tasklet_schedule(&htt->txrx_compl_task);
 		break;
 	case HTT_T2H_MSG_TYPE_SEC_IND: {
 		struct ath10k *ar = htt->ar;
@@ -2284,7 +2275,7 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
 	case HTT_T2H_MSG_TYPE_RX_FRAG_IND: {
 		ath10k_dbg_dump(ar, ATH10K_DBG_HTT_DUMP, NULL, "htt event: ",
 				skb->data, skb->len);
-		ath10k_htt_rx_frag_handler(htt);
+		atomic_inc(&htt->num_mpdus_ready);
 		break;
 	}
 	case HTT_T2H_MSG_TYPE_TEST:
@@ -2320,8 +2311,7 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
 		break;
 	}
 	case HTT_T2H_MSG_TYPE_RX_IN_ORD_PADDR_IND: {
-		skb_queue_tail(&htt->rx_in_ord_compl_q, skb);
-		tasklet_schedule(&htt->txrx_compl_task);
+		__skb_queue_tail(&htt->rx_in_ord_compl_q, skb);
 		return false;
 	}
 	case HTT_T2H_MSG_TYPE_TX_CREDIT_UPDATE_IND:
@@ -2347,7 +2337,6 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
 			break;
 		}
 		skb_queue_tail(&htt->tx_fetch_ind_q, tx_fetch_ind);
-		tasklet_schedule(&htt->txrx_compl_task);
 		break;
 	}
 	case HTT_T2H_MSG_TYPE_TX_FETCH_CONFIRM:
@@ -2376,27 +2365,77 @@ void ath10k_htt_rx_pktlog_completion_handler(struct ath10k *ar,
 }
 EXPORT_SYMBOL(ath10k_htt_rx_pktlog_completion_handler);
 
-static void ath10k_htt_txrx_compl_task(unsigned long ptr)
+int ath10k_htt_txrx_compl_task(struct ath10k *ar, int budget)
 {
-	struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
-	struct ath10k *ar = htt->ar;
+	struct ath10k_htt *htt = &ar->htt;
 	struct htt_tx_done tx_done = {};
-	struct sk_buff_head rx_ind_q;
 	struct sk_buff_head tx_ind_q;
 	struct sk_buff *skb;
 	unsigned long flags;
-	int num_mpdus;
+	int quota = 0, done, num_rx_msdus;
+	bool resched_napi = false;
 
-	__skb_queue_head_init(&rx_ind_q);
 	__skb_queue_head_init(&tx_ind_q);
 
-	spin_lock_irqsave(&htt->rx_in_ord_compl_q.lock, flags);
-	skb_queue_splice_init(&htt->rx_in_ord_compl_q, &rx_ind_q);
-	spin_unlock_irqrestore(&htt->rx_in_ord_compl_q.lock, flags);
+	/* Since in-ord-ind can deliver more than 1 A-MSDU in single event,
+	 * process it first to utilize full available quota.
+	 */
+	while (quota < budget) {
+		if (skb_queue_empty(&htt->rx_in_ord_compl_q))
+			break;
 
-	spin_lock_irqsave(&htt->tx_fetch_ind_q.lock, flags);
-	skb_queue_splice_init(&htt->tx_fetch_ind_q, &tx_ind_q);
-	spin_unlock_irqrestore(&htt->tx_fetch_ind_q.lock, flags);
+		skb = __skb_dequeue(&htt->rx_in_ord_compl_q);
+		if (!skb) {
+			resched_napi = true;
+			goto exit;
+		}
+
+		spin_lock_bh(&htt->rx_ring.lock);
+		num_rx_msdus = ath10k_htt_rx_in_ord_ind(ar, skb);
+		spin_unlock_bh(&htt->rx_ring.lock);
+		if (num_rx_msdus < 0) {
+			resched_napi = true;
+			goto exit;
+		}
+
+		dev_kfree_skb_any(skb);
+		if (num_rx_msdus > 0)
+			quota += num_rx_msdus;
+
+		if ((quota > ATH10K_NAPI_QUOTA_LIMIT) &&
+		    !skb_queue_empty(&htt->rx_in_ord_compl_q)) {
+			resched_napi = true;
+			goto exit;
+		}
+	}
+
+	while (quota < budget) {
+		/* no more data to receive */
+		if (!atomic_read(&htt->num_mpdus_ready))
+			break;
+
+		num_rx_msdus = ath10k_htt_rx_handle_amsdu(htt);
+		if (num_rx_msdus < 0) {
+			resched_napi = true;
+			goto exit;
+		}
+
+		quota += num_rx_msdus;
+		atomic_dec(&htt->num_mpdus_ready);
+		if ((quota > ATH10K_NAPI_QUOTA_LIMIT) &&
+		    atomic_read(&htt->num_mpdus_ready)) {
+			resched_napi = true;
+			goto exit;
+		}
+	}
+
+	/* From NAPI documentation:
+	 *  The napi poll() function may also process TX completions, in which
+	 *  case if it processes the entire TX ring then it should count that
+	 *  work as the rest of the budget.
+	 */
+	if ((quota < budget) && !kfifo_is_empty(&htt->txdone_fifo))
+		quota = budget;
 
 	/* kfifo_get: called only within txrx_tasklet so it's neatly serialized.
 	 * From kfifo_get() documentation:
@@ -2406,27 +2445,22 @@ static void ath10k_htt_txrx_compl_task(unsigned long ptr)
 	while (kfifo_get(&htt->txdone_fifo, &tx_done))
 		ath10k_txrx_tx_unref(htt, &tx_done);
 
+	spin_lock_irqsave(&htt->tx_fetch_ind_q.lock, flags);
+	skb_queue_splice_init(&htt->tx_fetch_ind_q, &tx_ind_q);
+	spin_unlock_irqrestore(&htt->tx_fetch_ind_q.lock, flags);
+
 	while ((skb = __skb_dequeue(&tx_ind_q))) {
 		ath10k_htt_rx_tx_fetch_ind(ar, skb);
 		dev_kfree_skb_any(skb);
 	}
 
-	num_mpdus = atomic_read(&htt->num_mpdus_ready);
-
-	while (num_mpdus) {
-		if (ath10k_htt_rx_handle_amsdu(htt))
-			break;
-
-		num_mpdus--;
-		atomic_dec(&htt->num_mpdus_ready);
-	}
-
-	while ((skb = __skb_dequeue(&rx_ind_q))) {
-		spin_lock_bh(&htt->rx_ring.lock);
-		ath10k_htt_rx_in_ord_ind(ar, skb);
-		spin_unlock_bh(&htt->rx_ring.lock);
-		dev_kfree_skb_any(skb);
-	}
-
+exit:
 	ath10k_htt_rx_msdu_buff_replenish(htt);
+	/* In case of rx failure or more data to read, report budget
+	 * to reschedule NAPI poll
+	 */
+	done = resched_napi ? budget : quota;
+
+	return done;
 }
+EXPORT_SYMBOL(ath10k_htt_txrx_compl_task);
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 7c072b605bc7..ae5b33fe5ba8 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -390,8 +390,6 @@ void ath10k_htt_tx_free(struct ath10k_htt *htt)
 {
 	int size;
 
-	tasklet_kill(&htt->txrx_compl_task);
-
 	idr_for_each(&htt->pending_tx, ath10k_htt_tx_clean_up_pending, htt->ar);
 	idr_destroy(&htt->pending_tx);
 
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 9a22c478dd1b..6e21fa1478ea 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1506,12 +1506,10 @@ void ath10k_pci_hif_send_complete_check(struct ath10k *ar, u8 pipe,
 	ath10k_ce_per_engine_service(ar, pipe);
 }
 
-void ath10k_pci_kill_tasklet(struct ath10k *ar)
+static void ath10k_pci_rx_retry_sync(struct ath10k *ar)
 {
 	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
 
-	tasklet_kill(&ar_pci->intr_tq);
-
 	del_timer_sync(&ar_pci->rx_post_retry);
 }
 
@@ -1570,7 +1568,7 @@ void ath10k_pci_hif_get_default_pipe(struct ath10k *ar,
 						 ul_pipe, dl_pipe);
 }
 
-static void ath10k_pci_irq_msi_fw_mask(struct ath10k *ar)
+void ath10k_pci_irq_msi_fw_mask(struct ath10k *ar)
 {
 	u32 val;
 
@@ -1753,7 +1751,7 @@ void ath10k_pci_ce_deinit(struct ath10k *ar)
 
 void ath10k_pci_flush(struct ath10k *ar)
 {
-	ath10k_pci_kill_tasklet(ar);
+	ath10k_pci_rx_retry_sync(ar);
 	ath10k_pci_buffer_cleanup(ar);
 }
 
@@ -2772,35 +2770,53 @@ static irqreturn_t ath10k_pci_interrupt_handler(int irq, void *arg)
 		return IRQ_NONE;
 	}
 
-	if (ar_pci->oper_irq_mode == ATH10K_PCI_IRQ_LEGACY) {
-		if (!ath10k_pci_irq_pending(ar))
-			return IRQ_NONE;
-
-		ath10k_pci_disable_and_clear_legacy_irq(ar);
-	}
+	if ((ar_pci->oper_irq_mode == ATH10K_PCI_IRQ_LEGACY) &&
+	    !ath10k_pci_irq_pending(ar))
+		return IRQ_NONE;
 
-	tasklet_schedule(&ar_pci->intr_tq);
+	ath10k_pci_disable_and_clear_legacy_irq(ar);
+	ath10k_pci_irq_msi_fw_mask(ar);
+	napi_schedule(&ar->napi);
 
 	return IRQ_HANDLED;
 }
 
-static void ath10k_pci_tasklet(unsigned long data)
+static int ath10k_pci_napi_poll(struct napi_struct *ctx, int budget)
 {
-	struct ath10k *ar = (struct ath10k *)data;
-	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
+	struct ath10k *ar = container_of(ctx, struct ath10k, napi);
+	int done = 0;
 
 	if (ath10k_pci_has_fw_crashed(ar)) {
-		ath10k_pci_irq_disable(ar);
 		ath10k_pci_fw_crashed_clear(ar);
 		ath10k_pci_fw_crashed_dump(ar);
-		return;
+		napi_complete(ctx);
+		return done;
 	}
 
 	ath10k_ce_per_engine_service_any(ar);
 
-	/* Re-enable legacy irq that was disabled in the irq handler */
-	if (ar_pci->oper_irq_mode == ATH10K_PCI_IRQ_LEGACY)
+	done = ath10k_htt_txrx_compl_task(ar, budget);
+
+	if (done < budget) {
+		napi_complete(ctx);
+		/* In case of MSI, it is possible that interrupts are received
+		 * while NAPI poll is inprogress. So pending interrupts that are
+		 * received after processing all copy engine pipes by NAPI poll
+		 * will not be handled again. This is causing failure to
+		 * complete boot sequence in x86 platform. So before enabling
+		 * interrupts safer to check for pending interrupts for
+		 * immediate servicing.
+		 */
+		if (CE_INTERRUPT_SUMMARY(ar)) {
+			napi_reschedule(&ar->napi);
+			goto out;
+		}
 		ath10k_pci_enable_legacy_irq(ar);
+		ath10k_pci_irq_msi_fw_unmask(ar);
+	}
+
+out:
+	return done;
 }
 
 static int ath10k_pci_request_irq_msi(struct ath10k *ar)
@@ -2858,11 +2874,11 @@ static void ath10k_pci_free_irq(struct ath10k *ar)
 	free_irq(ar_pci->pdev->irq, ar);
 }
 
-void ath10k_pci_init_irq_tasklets(struct ath10k *ar)
+void ath10k_pci_init_napi(struct ath10k *ar)
 {
-	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
-
-	tasklet_init(&ar_pci->intr_tq, ath10k_pci_tasklet, (unsigned long)ar);
+	netif_napi_add(&ar->napi_dev, &ar->napi, ath10k_pci_napi_poll,
+		       ATH10K_NAPI_BUDGET);
+	napi_enable(&ar->napi);
 }
 
 static int ath10k_pci_init_irq(struct ath10k *ar)
@@ -2870,7 +2886,7 @@ static int ath10k_pci_init_irq(struct ath10k *ar)
 	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
 	int ret;
 
-	ath10k_pci_init_irq_tasklets(ar);
+	ath10k_pci_init_napi(ar);
 
 	if (ath10k_pci_irq_mode != ATH10K_PCI_IRQ_AUTO)
 		ath10k_info(ar, "limiting irq mode to: %d\n",
@@ -3131,7 +3147,8 @@ int ath10k_pci_setup_resource(struct ath10k *ar)
 
 void ath10k_pci_release_resource(struct ath10k *ar)
 {
-	ath10k_pci_kill_tasklet(ar);
+	ath10k_pci_rx_retry_sync(ar);
+	netif_napi_del(&ar->napi);
 	ath10k_pci_ce_deinit(ar);
 	ath10k_pci_free_pipes(ar);
 }
@@ -3298,7 +3315,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
 
 err_free_irq:
 	ath10k_pci_free_irq(ar);
-	ath10k_pci_kill_tasklet(ar);
+	ath10k_pci_rx_retry_sync(ar);
 
 err_deinit_irq:
 	ath10k_pci_deinit_irq(ar);
diff --git a/drivers/net/wireless/ath/ath10k/pci.h b/drivers/net/wireless/ath/ath10k/pci.h
index 6eca1df2ce60..9854ad56b2de 100644
--- a/drivers/net/wireless/ath/ath10k/pci.h
+++ b/drivers/net/wireless/ath/ath10k/pci.h
@@ -177,8 +177,6 @@ struct ath10k_pci {
 	/* Operating interrupt mode */
 	enum ath10k_pci_irq_mode oper_irq_mode;
 
-	struct tasklet_struct intr_tq;
-
 	struct ath10k_pci_pipe pipe_info[CE_COUNT_MAX];
 
 	/* Copy Engine used for Diagnostic Accesses */
@@ -294,8 +292,7 @@ void ath10k_pci_free_pipes(struct ath10k *ar);
 void ath10k_pci_free_pipes(struct ath10k *ar);
 void ath10k_pci_rx_replenish_retry(unsigned long ptr);
 void ath10k_pci_ce_deinit(struct ath10k *ar);
-void ath10k_pci_init_irq_tasklets(struct ath10k *ar);
-void ath10k_pci_kill_tasklet(struct ath10k *ar);
+void ath10k_pci_init_napi(struct ath10k *ar);
 int ath10k_pci_init_pipes(struct ath10k *ar);
 int ath10k_pci_init_config(struct ath10k *ar);
 void ath10k_pci_rx_post(struct ath10k *ar);
@@ -303,6 +300,7 @@ void ath10k_pci_flush(struct ath10k *ar);
 void ath10k_pci_enable_legacy_irq(struct ath10k *ar);
 bool ath10k_pci_irq_pending(struct ath10k *ar);
 void ath10k_pci_disable_and_clear_legacy_irq(struct ath10k *ar);
+void ath10k_pci_irq_msi_fw_mask(struct ath10k *ar);
 int ath10k_pci_wait_for_target_init(struct ath10k *ar);
 int ath10k_pci_setup_resource(struct ath10k *ar);
 void ath10k_pci_release_resource(struct ath10k *ar);
-- 
2.9.0



From sgruszka at redhat.com  Thu Jul 21 00:09:39 2016
From: sgruszka at redhat.com (Stanislaw Gruszka)
Date: Thu, 21 Jul 2016 09:09:39 +0200
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <20160721070938.GA2658@redhat.com>

On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
> Firmware files are versioned to prevent older
> driver instances to load unsupported firmware
> blobs. This is reflected with a fallback logic
> which attempts to load several firmware files.
> 
> This however produced a lot of unnecessary
> warnings sometimes confusing users and leading
> them to rename firmware files making things even
> more confusing.

This happens on kernels configured with
CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
but also 60 seconds delay before loading next firmware version.
For some reason RHEL kernel needs above config option, so this
patch is very welcome from my perspective.

Stanislaw


From egrumbach at gmail.com  Thu Jul 21 00:36:42 2016
From: egrumbach at gmail.com (Emmanuel Grumbach)
Date: Thu, 21 Jul 2016 10:36:42 +0300
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <20160721070938.GA2658@redhat.com>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
 <20160721070938.GA2658@redhat.com>
Message-ID: <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>

On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
>> Firmware files are versioned to prevent older
>> driver instances to load unsupported firmware
>> blobs. This is reflected with a fallback logic
>> which attempts to load several firmware files.
>>
>> This however produced a lot of unnecessary
>> warnings sometimes confusing users and leading
>> them to rename firmware files making things even
>> more confusing.
>
> This happens on kernels configured with
> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
> but also 60 seconds delay before loading next firmware version.
> For some reason RHEL kernel needs above config option, so this
> patch is very welcome from my perspective.
>

Sorry for my ignorance but how does the firmware loading work if not
with udev's help? As you can imagine, iwlwifi is suffering from the
same problem and I would be interested in applying the same change,
but I'd love to understand a bit more :)


From sgruszka at redhat.com  Thu Jul 21 01:05:42 2016
From: sgruszka at redhat.com (Stanislaw Gruszka)
Date: Thu, 21 Jul 2016 10:05:42 +0200
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
 <20160721070938.GA2658@redhat.com>
 <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>
Message-ID: <20160721080541.GB2658@redhat.com>

On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
> > On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
> >> Firmware files are versioned to prevent older
> >> driver instances to load unsupported firmware
> >> blobs. This is reflected with a fallback logic
> >> which attempts to load several firmware files.
> >>
> >> This however produced a lot of unnecessary
> >> warnings sometimes confusing users and leading
> >> them to rename firmware files making things even
> >> more confusing.
> >
> > This happens on kernels configured with
> > CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
> > but also 60 seconds delay before loading next firmware version.
> > For some reason RHEL kernel needs above config option, so this
> > patch is very welcome from my perspective.
> >
> 
> Sorry for my ignorance but how does the firmware loading work if not
> with udev's help?

I'm not sure exactly, but I think kernel VFS layer is capable to copy
file data directly from mounted filesystem without user space helper.

> As you can imagine, iwlwifi is suffering from the
> same problem and I would be interested in applying the same change,
> but I'd love to understand a bit more :)

Yes, iwlwifi (and some other drivers) suffer from this. However this
happen when the newest firmware version is not installed on the system
and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
it's not common.

I started to see this currently, because that option was enabled on 
RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
happened because of that, i.e. thermal device was not functional
because f/w wasn't loaded due to big delay.

I'm not sure if replacing to request_firmware_direct() is a good
fix though. For example I can see this problem also on brcmfmac, which
use request_firmware_nowait(). I think I would rather prefer special
helper for firmware drivers that needs user helper and have
request_firmware() be direct as default.

Stanislaw


From prarit at redhat.com  Thu Jul 21 03:23:11 2016
From: prarit at redhat.com (Prarit Bhargava)
Date: Thu, 21 Jul 2016 06:23:11 -0400
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <20160721080541.GB2658@redhat.com>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
 <20160721070938.GA2658@redhat.com>
 <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>
 <20160721080541.GB2658@redhat.com>
Message-ID: <5790A28F.8030102@redhat.com>



On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
> On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
>> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
>>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
>>>> Firmware files are versioned to prevent older
>>>> driver instances to load unsupported firmware
>>>> blobs. This is reflected with a fallback logic
>>>> which attempts to load several firmware files.
>>>>
>>>> This however produced a lot of unnecessary
>>>> warnings sometimes confusing users and leading
>>>> them to rename firmware files making things even
>>>> more confusing.
>>>
>>> This happens on kernels configured with
>>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
>>> but also 60 seconds delay before loading next firmware version.
>>> For some reason RHEL kernel needs above config option, so this
>>> patch is very welcome from my perspective.
>>>
>>
>> Sorry for my ignorance but how does the firmware loading work if not
>> with udev's help?
> 
> I'm not sure exactly, but I think kernel VFS layer is capable to copy
> file data directly from mounted filesystem without user space helper.

Here's the situation: request_firmware() waits 60 seconds for udev to do its
loading magic via a "usermode helper".  This delay is there to allow, for
example, userspace to unpack or download a new firmware image or verify the
firmware image *in userspace* before providing it to the driver to apply to the HW.

Why 60 seconds?  It is arbitrary and there is no way for udev & the kernel to
handshake on completion.

> 
>> As you can imagine, iwlwifi is suffering from the
>> same problem and I would be interested in applying the same change,
>> but I'd love to understand a bit more :)
> 
> Yes, iwlwifi (and some other drivers) suffer from this. However this
> happen when the newest firmware version is not installed on the system
> and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
> it's not common.

request_firmware_direct() was introduced at my request because (as you've
noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
periods of time when starting.  The bug that this introduced was a 60 second
delay per logical cpu when starting a system.  On a 64 cpu system that meant the
boot would complete in a little over one hour.

> 
> I started to see this currently, because that option was enabled on 
> RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
> happened because of that, i.e. thermal device was not functional
> because f/w wasn't loaded due to big delay.
> 
> I'm not sure if replacing to request_firmware_direct() is a good
> fix though. For example I can see this problem also on brcmfmac, which
> use request_firmware_nowait(). I think I would rather prefer special
> helper for firmware drivers that needs user helper and have
> request_firmware() be direct as default.
> 

The difference between request_firmware_direct() and request_firmware() is that
the _direct() version does not wait the 60 seconds for udev interaction.  The
only userspace check performed is to see if the file is there, and if the file
does exist it is provided to the driver to be applied to the hardware.

So the real question to ask here is whether or not the ath10k, brcmfmac, and
iwlwifi require udev to do anything beyond checking for the existence and
loading the firmware image.  If they don't, then it is better to use
request_firmware_direct().

P.

> Stanislaw
> 


From sgruszka at redhat.com  Thu Jul 21 04:51:24 2016
From: sgruszka at redhat.com (Stanislaw Gruszka)
Date: Thu, 21 Jul 2016 13:51:24 +0200
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <5790A28F.8030102@redhat.com>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
 <20160721070938.GA2658@redhat.com>
 <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>
 <20160721080541.GB2658@redhat.com> <5790A28F.8030102@redhat.com>
Message-ID: <20160721115122.GA31869@redhat.com>

(cc: firmware and brcmfmac maintainers)

On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
> 
> 
> On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
> > On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
> >> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
> >>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
> >>>> Firmware files are versioned to prevent older
> >>>> driver instances to load unsupported firmware
> >>>> blobs. This is reflected with a fallback logic
> >>>> which attempts to load several firmware files.
> >>>>
> >>>> This however produced a lot of unnecessary
> >>>> warnings sometimes confusing users and leading
> >>>> them to rename firmware files making things even
> >>>> more confusing.
> >>>
> >>> This happens on kernels configured with
> >>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
> >>> but also 60 seconds delay before loading next firmware version.
> >>> For some reason RHEL kernel needs above config option, so this
> >>> patch is very welcome from my perspective.
> >>>
> >>
> >> Sorry for my ignorance but how does the firmware loading work if not
> >> with udev's help?
> > 
> > I'm not sure exactly, but I think kernel VFS layer is capable to copy
> > file data directly from mounted filesystem without user space helper.
> 
> Here's the situation: request_firmware() waits 60 seconds for udev to do its
> loading magic via a "usermode helper".  This delay is there to allow, for
> example, userspace to unpack or download a new firmware image or verify the
> firmware image *in userspace* before providing it to the driver to apply to the HW.
> 
> Why 60 seconds?  It is arbitrary and there is no way for udev & the kernel to
> handshake on completion.
> 
> > 
> >> As you can imagine, iwlwifi is suffering from the
> >> same problem and I would be interested in applying the same change,
> >> but I'd love to understand a bit more :)
> > 
> > Yes, iwlwifi (and some other drivers) suffer from this. However this
> > happen when the newest firmware version is not installed on the system
> > and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
> > it's not common.
> 
> request_firmware_direct() was introduced at my request because (as you've
> noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
> periods of time when starting.  The bug that this introduced was a 60 second
> delay per logical cpu when starting a system.  On a 64 cpu system that meant the
> boot would complete in a little over one hour.
> 
> > 
> > I started to see this currently, because that option was enabled on 
> > RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
> > happened because of that, i.e. thermal device was not functional
> > because f/w wasn't loaded due to big delay.
> > 
> > I'm not sure if replacing to request_firmware_direct() is a good
> > fix though. For example I can see this problem also on brcmfmac, which
> > use request_firmware_nowait(). I think I would rather prefer special
> > helper for firmware drivers that needs user helper and have
> > request_firmware() be direct as default.
> > 
> 
> The difference between request_firmware_direct() and request_firmware() is that
> the _direct() version does not wait the 60 seconds for udev interaction.  The
> only userspace check performed is to see if the file is there, and if the file
> does exist it is provided to the driver to be applied to the hardware.
> 
> So the real question to ask here is whether or not the ath10k, brcmfmac, and
> iwlwifi require udev to do anything beyond checking for the existence and
> loading the firmware image.  If they don't, then it is better to use
> request_firmware_direct().

They don't need that, like 99% of the drivers I think, hence changing the
default seems to be more reasonable. However changing 3 drivers would work
for me as well, and that change do not introduce risk of broking drivers
that require udev fw download.

iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
use request_firmware_nowait(), so it first need to be converted to
ordinary request_firmware(), but this should be doable and I can do
that.

However I wonder if changing that will not broke the case when
driver is build-in in the kernel and f/w is not yet available when
driver start to initialize. Or maybe nowadays this is not the case
any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w 
images are build-in in the kernel or copied to initramfs?

Thanks
Stanislaw


From prarit at redhat.com  Thu Jul 21 05:01:12 2016
From: prarit at redhat.com (Prarit Bhargava)
Date: Thu, 21 Jul 2016 08:01:12 -0400
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <20160721115122.GA31869@redhat.com>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
 <20160721070938.GA2658@redhat.com>
 <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>
 <20160721080541.GB2658@redhat.com> <5790A28F.8030102@redhat.com>
 <20160721115122.GA31869@redhat.com>
Message-ID: <5790B988.3080600@redhat.com>



On 07/21/2016 07:51 AM, Stanislaw Gruszka wrote:
> (cc: firmware and brcmfmac maintainers)

<snip>

>>>
>>> I'm not sure if replacing to request_firmware_direct() is a good
>>> fix though. For example I can see this problem also on brcmfmac, which
>>> use request_firmware_nowait(). I think I would rather prefer special
>>> helper for firmware drivers that needs user helper and have
>>> request_firmware() be direct as default.
>>>
>>
>> The difference between request_firmware_direct() and request_firmware() is that
>> the _direct() version does not wait the 60 seconds for udev interaction.  The
>> only userspace check performed is to see if the file is there, and if the file
>> does exist it is provided to the driver to be applied to the hardware.
>>
>> So the real question to ask here is whether or not the ath10k, brcmfmac, and
>> iwlwifi require udev to do anything beyond checking for the existence and
>> loading the firmware image.  If they don't, then it is better to use
>> request_firmware_direct().
> 
> They don't need that, like 99% of the drivers I think, hence changing the
> default seems to be more reasonable. However changing 3 drivers would work

I think I argued for that a while back and changing the default was rejected.
I can't remember why it was rejected :(.  It may have had something to do with
the complexity of getting a large number of driver maintainers to ack the change.

> for me as well, and that change do not introduce risk of broking drivers
> that require udev fw download.

In my experience, there are very few drivers that actually require userspace
interaction beyond verifying the image location.  (The one that comes to mind is
the dell_rbu driver which attempts to download FW images)

> 
> iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
> use request_firmware_nowait(), so it first need to be converted to
> ordinary request_firmware(), but this should be doable and I can do
> that.
> 
> However I wonder if changing that will not broke the case when
> driver is build-in in the kernel and f/w is not yet available when
> driver start to initialize. 

As you say below ...

Or maybe nowadays this is not the case
> any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w 
> images are build-in in the kernel or copied to initramfs?

This is correct AFAIU.  If MODULE_FIRMWARE=y then the firmware should be loaded
into the kernel image temp fs and/or initramfs.  This of course assumes that the
person building the image is smart enough to have installed the FW on their system.

P.


From rajjoshi at comp.nus.edu.sg  Thu Jul 21 07:15:06 2016
From: rajjoshi at comp.nus.edu.sg (Raj Joshi)
Date: Thu, 21 Jul 2016 21:15:06 +0700
Subject: Completely disabling RTS/CTS
Message-ID: <CA+uUJGu6qSmxupEkaqPmLBQf53wQtjyXidFCf+4X9vMxL4WmoA@mail.gmail.com>

Hi all,

I am trying to "completely" disable RTS/CTS.

* Case 1: Using iw/iwconfig when I set the sender's RTS threshold to a
very high value (RTS thr=10000 B), I expect that no RTS should be
sent. However, it seems that this threshold is not being honored and I
can sniff large number of RTS/CTS frames. I verified that no A-MSDU is
exceeding 10000 B.
* Case 2: Interestingly, when I set the sender's RTS threshold to off
(RTS thr:off), compared to case #1 much less number of RTS/CTS frames
are seen and throughput is seen to improve. But I can still see
RTS/CTS frames being sent.
* Since the channel is clear and much isolated, and there is just one
AP and one STA, there is negligible chance of other factors playing
any role.
* There is one change though that I have disabled dynamic bandwidth
i.e. ar->wmi.pdev_param->dynamic_bw set zero in mac.c. I believe this
is likely not an issue as similar RTS/CTS behavior is seen even with
dynamic_bw set to 1 (there are no heterogeneous channel widths in the
network in any case).
* Another thing I noticed is that the RTS/CTS protection mode if set,
it is set to CTS-to-self, rather than "RTS/CTS" i.e.
ar->wmi.vdev_param->protection_mode in mac.c is either set to 1 or 0
(depending upon use_cts_prot), but not 2. This probably seems not
helpful in hidden node scenarios as the CTS frame is unicasted instead
broadcasting.

I would appreciate any pointers on completely disabling RTS/CTS as
well as the ability to choose between complete RTS/CTS versus
CTS-to-self whenever RTS/CTS is enabled.

Thanks,
Raj Joshi

--------------------------
More info on setup
--------------------------
- QCA9880 (Compex wle900vx)
- Ubuntu 16.04 x64 running kernel 4.7.0-rc4-wt-ath-201606202115 from ath.git
- firmware-version: 10.2.4.70.9-2


From chaitanya.mgit at gmail.com  Thu Jul 21 07:29:14 2016
From: chaitanya.mgit at gmail.com (Krishna Chaitanya)
Date: Thu, 21 Jul 2016 19:59:14 +0530
Subject: Completely disabling RTS/CTS
In-Reply-To: <CA+uUJGu6qSmxupEkaqPmLBQf53wQtjyXidFCf+4X9vMxL4WmoA@mail.gmail.com>
References: <CA+uUJGu6qSmxupEkaqPmLBQf53wQtjyXidFCf+4X9vMxL4WmoA@mail.gmail.com>
Message-ID: <CABPxzY+KHVGAUKjU2kWdKiEPZFV3=sOnWe-qBMDOPffw_vJ0+g@mail.gmail.com>

On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <rajjoshi at comp.nus.edu.sg> wrote:
> Hi all,
>
> I am trying to "completely" disable RTS/CTS.
>
> * Case 1: Using iw/iwconfig when I set the sender's RTS threshold to a
> very high value (RTS thr=10000 B), I expect that no RTS should be
> sent. However, it seems that this threshold is not being honored and I
> can sniff large number of RTS/CTS frames. I verified that no A-MSDU is
> exceeding 10000 B.
> * Case 2: Interestingly, when I set the sender's RTS threshold to off
> (RTS thr:off), compared to case #1 much less number of RTS/CTS frames
> are seen and throughput is seen to improve. But I can still see
> RTS/CTS frames being sent.
> * Since the channel is clear and much isolated, and there is just one
> AP and one STA, there is negligible chance of other factors playing
> any role.
> * There is one change though that I have disabled dynamic bandwidth
> i.e. ar->wmi.pdev_param->dynamic_bw set zero in mac.c. I believe this
> is likely not an issue as similar RTS/CTS behavior is seen even with
> dynamic_bw set to 1 (there are no heterogeneous channel widths in the
> network in any case).
> * Another thing I noticed is that the RTS/CTS protection mode if set,
> it is set to CTS-to-self, rather than "RTS/CTS" i.e.
> ar->wmi.vdev_param->protection_mode in mac.c is either set to 1 or 0
> (depending upon use_cts_prot), but not 2. This probably seems not
> helpful in hidden node scenarios as the CTS frame is unicasted instead
> broadcasting.
>
> I would appreciate any pointers on completely disabling RTS/CTS as
> well as the ability to choose between complete RTS/CTS versus
> CTS-to-self whenever RTS/CTS is enabled.
Which mode is this? For aggregated frames (AMPDU) RTS Threshold is
not checked, so it can still be enabled


From greearb at candelatech.com  Thu Jul 21 09:44:32 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 21 Jul 2016 09:44:32 -0700
Subject: Completely disabling RTS/CTS
In-Reply-To: <CABPxzY+KHVGAUKjU2kWdKiEPZFV3=sOnWe-qBMDOPffw_vJ0+g@mail.gmail.com>
References: <CA+uUJGu6qSmxupEkaqPmLBQf53wQtjyXidFCf+4X9vMxL4WmoA@mail.gmail.com>
 <CABPxzY+KHVGAUKjU2kWdKiEPZFV3=sOnWe-qBMDOPffw_vJ0+g@mail.gmail.com>
Message-ID: <5790FBF0.2060800@candelatech.com>

On 07/21/2016 07:29 AM, Krishna Chaitanya wrote:
> On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <rajjoshi at comp.nus.edu.sg> wrote:
>> Hi all,
>>
>> I am trying to "completely" disable RTS/CTS.
>>
>> * Case 1: Using iw/iwconfig when I set the sender's RTS threshold to a
>> very high value (RTS thr=10000 B), I expect that no RTS should be
>> sent. However, it seems that this threshold is not being honored and I
>> can sniff large number of RTS/CTS frames. I verified that no A-MSDU is
>> exceeding 10000 B.
>> * Case 2: Interestingly, when I set the sender's RTS threshold to off
>> (RTS thr:off), compared to case #1 much less number of RTS/CTS frames
>> are seen and throughput is seen to improve. But I can still see
>> RTS/CTS frames being sent.
>> * Since the channel is clear and much isolated, and there is just one
>> AP and one STA, there is negligible chance of other factors playing
>> any role.
>> * There is one change though that I have disabled dynamic bandwidth
>> i.e. ar->wmi.pdev_param->dynamic_bw set zero in mac.c. I believe this
>> is likely not an issue as similar RTS/CTS behavior is seen even with
>> dynamic_bw set to 1 (there are no heterogeneous channel widths in the
>> network in any case).
>> * Another thing I noticed is that the RTS/CTS protection mode if set,
>> it is set to CTS-to-self, rather than "RTS/CTS" i.e.
>> ar->wmi.vdev_param->protection_mode in mac.c is either set to 1 or 0
>> (depending upon use_cts_prot), but not 2. This probably seems not
>> helpful in hidden node scenarios as the CTS frame is unicasted instead
>> broadcasting.
>>
>> I would appreciate any pointers on completely disabling RTS/CTS as
>> well as the ability to choose between complete RTS/CTS versus
>> CTS-to-self whenever RTS/CTS is enabled.
> Which mode is this? For aggregated frames (AMPDU) RTS Threshold is
> not checked, so it can still be enabled

Probably would require firmware changes to fully disable RTS/CTS
from what I recall when I was reading the rate-ctrl code...

Thanks,
Ben

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


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



From rajjoshi at comp.nus.edu.sg  Thu Jul 21 19:54:39 2016
From: rajjoshi at comp.nus.edu.sg (Raj Joshi)
Date: Fri, 22 Jul 2016 10:54:39 +0800
Subject: Completely disabling RTS/CTS
In-Reply-To: <5790FBF0.2060800@candelatech.com>
References: <CA+uUJGu6qSmxupEkaqPmLBQf53wQtjyXidFCf+4X9vMxL4WmoA@mail.gmail.com>
 <CABPxzY+KHVGAUKjU2kWdKiEPZFV3=sOnWe-qBMDOPffw_vJ0+g@mail.gmail.com>
 <5790FBF0.2060800@candelatech.com>
Message-ID: <CA+uUJGv4qD=-su8792tWEHCJQg5soXfQ6trzb5mwxteXDD_ZRA@mail.gmail.com>

I am operating VHT (802.11ac) in AP-client configuration and thus
aggregation is inevitable (as per the standard) as well as desirable
(I suppose). I am receiving all A-MSDUs and not A-MPDUs. Now since
losses are expensive to recover in case of A-MSDUs than A-MPDUs, is
that the reason that there are intermittent RTS/CTS frames by rate
control?

If the culprit is firmware rate-control, I can try setting the bitrate
mask and check again. Also how can I force the use of A-MPDUs rather
than A-MSDUs? If this is outside the purview of firmware rate control,
then I can try this one as well.

Thanks,
Raj Joshi


On Fri, Jul 22, 2016 at 12:44 AM, Ben Greear <greearb at candelatech.com> wrote:
> On 07/21/2016 07:29 AM, Krishna Chaitanya wrote:
>>
>> On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <rajjoshi at comp.nus.edu.sg>
>> wrote:
>>>
>>> Hi all,
>>>
>>> I am trying to "completely" disable RTS/CTS.
>>>
>>> * Case 1: Using iw/iwconfig when I set the sender's RTS threshold to a
>>> very high value (RTS thr=10000 B), I expect that no RTS should be
>>> sent. However, it seems that this threshold is not being honored and I
>>> can sniff large number of RTS/CTS frames. I verified that no A-MSDU is
>>> exceeding 10000 B.
>>> * Case 2: Interestingly, when I set the sender's RTS threshold to off
>>> (RTS thr:off), compared to case #1 much less number of RTS/CTS frames
>>> are seen and throughput is seen to improve. But I can still see
>>> RTS/CTS frames being sent.
>>> * Since the channel is clear and much isolated, and there is just one
>>> AP and one STA, there is negligible chance of other factors playing
>>> any role.
>>> * There is one change though that I have disabled dynamic bandwidth
>>> i.e. ar->wmi.pdev_param->dynamic_bw set zero in mac.c. I believe this
>>> is likely not an issue as similar RTS/CTS behavior is seen even with
>>> dynamic_bw set to 1 (there are no heterogeneous channel widths in the
>>> network in any case).
>>> * Another thing I noticed is that the RTS/CTS protection mode if set,
>>> it is set to CTS-to-self, rather than "RTS/CTS" i.e.
>>> ar->wmi.vdev_param->protection_mode in mac.c is either set to 1 or 0
>>> (depending upon use_cts_prot), but not 2. This probably seems not
>>> helpful in hidden node scenarios as the CTS frame is unicasted instead
>>> broadcasting.
>>>
>>> I would appreciate any pointers on completely disabling RTS/CTS as
>>> well as the ability to choose between complete RTS/CTS versus
>>> CTS-to-self whenever RTS/CTS is enabled.
>>
>> Which mode is this? For aggregated frames (AMPDU) RTS Threshold is
>> not checked, so it can still be enabled
>
>
> Probably would require firmware changes to fully disable RTS/CTS
> from what I recall when I was reading the rate-ctrl code...
>
> Thanks,
> Ben
>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>


From greearb at candelatech.com  Thu Jul 21 20:21:10 2016
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 21 Jul 2016 20:21:10 -0700
Subject: Completely disabling RTS/CTS
In-Reply-To: <CA+uUJGv4qD=-su8792tWEHCJQg5soXfQ6trzb5mwxteXDD_ZRA@mail.gmail.com>
References: <CA+uUJGu6qSmxupEkaqPmLBQf53wQtjyXidFCf+4X9vMxL4WmoA@mail.gmail.com>
 <CABPxzY+KHVGAUKjU2kWdKiEPZFV3=sOnWe-qBMDOPffw_vJ0+g@mail.gmail.com>
 <5790FBF0.2060800@candelatech.com>
 <CA+uUJGv4qD=-su8792tWEHCJQg5soXfQ6trzb5mwxteXDD_ZRA@mail.gmail.com>
Message-ID: <57919126.7000601@candelatech.com>



On 07/21/2016 07:54 PM, Raj Joshi wrote:
> I am operating VHT (802.11ac) in AP-client configuration and thus
> aggregation is inevitable (as per the standard) as well as desirable
> (I suppose). I am receiving all A-MSDUs and not A-MPDUs. Now since
> losses are expensive to recover in case of A-MSDUs than A-MPDUs, is
> that the reason that there are intermittent RTS/CTS frames by rate
> control?
>
> If the culprit is firmware rate-control, I can try setting the bitrate
> mask and check again. Also how can I force the use of A-MPDUs rather
> than A-MSDUs? If this is outside the purview of firmware rate control,
> then I can try this one as well.

AMPDU and AMSDU should work fine in STA and AP mode.  If you are using IBSS,
then firmware must disable AMSDU since there seems to be some hardware bug with
IBSS and AMSDU.

I don't think you can affect RTS/CTS from the host.  I think it would require
a firmware code change to disable RTS/CTS rate-code entries.

I think there is a way to set the AMSDU size, and you could make it small
enough to effectively disable AMSDU.

Thanks,
Ben

>
> Thanks,
> Raj Joshi
>
>
> On Fri, Jul 22, 2016 at 12:44 AM, Ben Greear <greearb at candelatech.com> wrote:
>> On 07/21/2016 07:29 AM, Krishna Chaitanya wrote:
>>>
>>> On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <rajjoshi at comp.nus.edu.sg>
>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I am trying to "completely" disable RTS/CTS.
>>>>
>>>> * Case 1: Using iw/iwconfig when I set the sender's RTS threshold to a
>>>> very high value (RTS thr=10000 B), I expect that no RTS should be
>>>> sent. However, it seems that this threshold is not being honored and I
>>>> can sniff large number of RTS/CTS frames. I verified that no A-MSDU is
>>>> exceeding 10000 B.
>>>> * Case 2: Interestingly, when I set the sender's RTS threshold to off
>>>> (RTS thr:off), compared to case #1 much less number of RTS/CTS frames
>>>> are seen and throughput is seen to improve. But I can still see
>>>> RTS/CTS frames being sent.
>>>> * Since the channel is clear and much isolated, and there is just one
>>>> AP and one STA, there is negligible chance of other factors playing
>>>> any role.
>>>> * There is one change though that I have disabled dynamic bandwidth
>>>> i.e. ar->wmi.pdev_param->dynamic_bw set zero in mac.c. I believe this
>>>> is likely not an issue as similar RTS/CTS behavior is seen even with
>>>> dynamic_bw set to 1 (there are no heterogeneous channel widths in the
>>>> network in any case).
>>>> * Another thing I noticed is that the RTS/CTS protection mode if set,
>>>> it is set to CTS-to-self, rather than "RTS/CTS" i.e.
>>>> ar->wmi.vdev_param->protection_mode in mac.c is either set to 1 or 0
>>>> (depending upon use_cts_prot), but not 2. This probably seems not
>>>> helpful in hidden node scenarios as the CTS frame is unicasted instead
>>>> broadcasting.
>>>>
>>>> I would appreciate any pointers on completely disabling RTS/CTS as
>>>> well as the ability to choose between complete RTS/CTS versus
>>>> CTS-to-self whenever RTS/CTS is enabled.
>>>
>>> Which mode is this? For aggregated frames (AMPDU) RTS Threshold is
>>> not checked, so it can still be enabled
>>
>>
>> Probably would require firmware changes to fully disable RTS/CTS
>> from what I recall when I was reading the rate-ctrl code...
>>
>> Thanks,
>> Ben
>>
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>
>>
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>

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


From arend.vanspriel at broadcom.com  Fri Jul 22 01:38:24 2016
From: arend.vanspriel at broadcom.com (Arend Van Spriel)
Date: Fri, 22 Jul 2016 10:38:24 +0200
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <20160721115122.GA31869@redhat.com>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
 <20160721070938.GA2658@redhat.com>
 <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>
 <20160721080541.GB2658@redhat.com> <5790A28F.8030102@redhat.com>
 <20160721115122.GA31869@redhat.com>
Message-ID: <a264e995-fc46-7fcd-69f9-80992385b6b1@broadcom.com>

+ Luis

On 21-7-2016 13:51, Stanislaw Gruszka wrote:
> (cc: firmware and brcmfmac maintainers)
> 
> On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
>>
>>
>> On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
>>> On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
>>>> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
>>>>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
>>>>>> Firmware files are versioned to prevent older
>>>>>> driver instances to load unsupported firmware
>>>>>> blobs. This is reflected with a fallback logic
>>>>>> which attempts to load several firmware files.
>>>>>>
>>>>>> This however produced a lot of unnecessary
>>>>>> warnings sometimes confusing users and leading
>>>>>> them to rename firmware files making things even
>>>>>> more confusing.
>>>>>
>>>>> This happens on kernels configured with
>>>>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
>>>>> but also 60 seconds delay before loading next firmware version.
>>>>> For some reason RHEL kernel needs above config option, so this
>>>>> patch is very welcome from my perspective.
>>>>>
>>>>
>>>> Sorry for my ignorance but how does the firmware loading work if not
>>>> with udev's help?
>>>
>>> I'm not sure exactly, but I think kernel VFS layer is capable to copy
>>> file data directly from mounted filesystem without user space helper.
>>
>> Here's the situation: request_firmware() waits 60 seconds for udev to do its
>> loading magic via a "usermode helper".  This delay is there to allow, for
>> example, userspace to unpack or download a new firmware image or verify the
>> firmware image *in userspace* before providing it to the driver to apply to the HW.
>>
>> Why 60 seconds?  It is arbitrary and there is no way for udev & the kernel to
>> handshake on completion.
>>
>>>
>>>> As you can imagine, iwlwifi is suffering from the
>>>> same problem and I would be interested in applying the same change,
>>>> but I'd love to understand a bit more :)
>>>
>>> Yes, iwlwifi (and some other drivers) suffer from this. However this
>>> happen when the newest firmware version is not installed on the system
>>> and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
>>> it's not common.
>>
>> request_firmware_direct() was introduced at my request because (as you've
>> noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
>> periods of time when starting.  The bug that this introduced was a 60 second
>> delay per logical cpu when starting a system.  On a 64 cpu system that meant the
>> boot would complete in a little over one hour.
>>
>>>
>>> I started to see this currently, because that option was enabled on 
>>> RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
>>> happened because of that, i.e. thermal device was not functional
>>> because f/w wasn't loaded due to big delay.
>>>
>>> I'm not sure if replacing to request_firmware_direct() is a good
>>> fix though. For example I can see this problem also on brcmfmac, which
>>> use request_firmware_nowait(). I think I would rather prefer special
>>> helper for firmware drivers that needs user helper and have
>>> request_firmware() be direct as default.
>>>
>>
>> The difference between request_firmware_direct() and request_firmware() is that
>> the _direct() version does not wait the 60 seconds for udev interaction.  The
>> only userspace check performed is to see if the file is there, and if the file
>> does exist it is provided to the driver to be applied to the hardware.
>>
>> So the real question to ask here is whether or not the ath10k, brcmfmac, and
>> iwlwifi require udev to do anything beyond checking for the existence and
>> loading the firmware image.  If they don't, then it is better to use
>> request_firmware_direct().
> 
> They don't need that, like 99% of the drivers I think, hence changing the
> default seems to be more reasonable. However changing 3 drivers would work
> for me as well, and that change do not introduce risk of broking drivers
> that require udev fw download.
> 
> iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
> use request_firmware_nowait(), so it first need to be converted to
> ordinary request_firmware(), but this should be doable and I can do
> that.

I am going bonkers here. This is the Nth time a discussion pops up on
firmware API usage. I stopped counting N :-( So the first issue was that
the INIT was taking to long as we were requesting firmware during probe
which was executed in the INIT context. So we added a worker and
register the driver from there. There was probably a reason for
switching to _no_wait() as well, but I do not recall the details. The
things is I don't know if I need user-space or not. I just need firmware
to get the device up and running. We have changed our driver a couple of
times now to accommodate something that in my opinion should have been
abstracted behind the firmware API in the first place and now here is
another proposal to change the drivers. Come on!

> However I wonder if changing that will not broke the case when
> driver is build-in in the kernel and f/w is not yet available when
> driver start to initialize. Or maybe nowadays this is not the case
> any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w 
> images are build-in in the kernel or copied to initramfs?

That is a nice idea, but I have not seen any change in that area. Could
have missed it.

Regards,
Arend

> Thanks
> Stanislaw
> 


From sgruszka at redhat.com  Fri Jul 22 03:26:00 2016
From: sgruszka at redhat.com (Stanislaw Gruszka)
Date: Fri, 22 Jul 2016 12:26:00 +0200
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <a264e995-fc46-7fcd-69f9-80992385b6b1@broadcom.com>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
 <20160721070938.GA2658@redhat.com>
 <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>
 <20160721080541.GB2658@redhat.com> <5790A28F.8030102@redhat.com>
 <20160721115122.GA31869@redhat.com>
 <a264e995-fc46-7fcd-69f9-80992385b6b1@broadcom.com>
Message-ID: <20160722102559.GA2662@redhat.com>

On Fri, Jul 22, 2016 at 10:38:24AM +0200, Arend Van Spriel wrote:
> + Luis
> 
> On 21-7-2016 13:51, Stanislaw Gruszka wrote:
> > (cc: firmware and brcmfmac maintainers)
> > 
> > On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
> >>
> >>
> >> On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
> >>> On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
> >>>> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
> >>>>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
> >>>>>> Firmware files are versioned to prevent older
> >>>>>> driver instances to load unsupported firmware
> >>>>>> blobs. This is reflected with a fallback logic
> >>>>>> which attempts to load several firmware files.
> >>>>>>
> >>>>>> This however produced a lot of unnecessary
> >>>>>> warnings sometimes confusing users and leading
> >>>>>> them to rename firmware files making things even
> >>>>>> more confusing.
> >>>>>
> >>>>> This happens on kernels configured with
> >>>>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
> >>>>> but also 60 seconds delay before loading next firmware version.
> >>>>> For some reason RHEL kernel needs above config option, so this
> >>>>> patch is very welcome from my perspective.
> >>>>>
> >>>>
> >>>> Sorry for my ignorance but how does the firmware loading work if not
> >>>> with udev's help?
> >>>
> >>> I'm not sure exactly, but I think kernel VFS layer is capable to copy
> >>> file data directly from mounted filesystem without user space helper.
> >>
> >> Here's the situation: request_firmware() waits 60 seconds for udev to do its
> >> loading magic via a "usermode helper".  This delay is there to allow, for
> >> example, userspace to unpack or download a new firmware image or verify the
> >> firmware image *in userspace* before providing it to the driver to apply to the HW.
> >>
> >> Why 60 seconds?  It is arbitrary and there is no way for udev & the kernel to
> >> handshake on completion.
> >>
> >>>
> >>>> As you can imagine, iwlwifi is suffering from the
> >>>> same problem and I would be interested in applying the same change,
> >>>> but I'd love to understand a bit more :)
> >>>
> >>> Yes, iwlwifi (and some other drivers) suffer from this. However this
> >>> happen when the newest firmware version is not installed on the system
> >>> and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
> >>> it's not common.
> >>
> >> request_firmware_direct() was introduced at my request because (as you've
> >> noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
> >> periods of time when starting.  The bug that this introduced was a 60 second
> >> delay per logical cpu when starting a system.  On a 64 cpu system that meant the
> >> boot would complete in a little over one hour.
> >>
> >>>
> >>> I started to see this currently, because that option was enabled on 
> >>> RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
> >>> happened because of that, i.e. thermal device was not functional
> >>> because f/w wasn't loaded due to big delay.
> >>>
> >>> I'm not sure if replacing to request_firmware_direct() is a good
> >>> fix though. For example I can see this problem also on brcmfmac, which
> >>> use request_firmware_nowait(). I think I would rather prefer special
> >>> helper for firmware drivers that needs user helper and have
> >>> request_firmware() be direct as default.
> >>>
> >>
> >> The difference between request_firmware_direct() and request_firmware() is that
> >> the _direct() version does not wait the 60 seconds for udev interaction.  The
> >> only userspace check performed is to see if the file is there, and if the file
> >> does exist it is provided to the driver to be applied to the hardware.
> >>
> >> So the real question to ask here is whether or not the ath10k, brcmfmac, and
> >> iwlwifi require udev to do anything beyond checking for the existence and
> >> loading the firmware image.  If they don't, then it is better to use
> >> request_firmware_direct().
> > 
> > They don't need that, like 99% of the drivers I think, hence changing the
> > default seems to be more reasonable. However changing 3 drivers would work
> > for me as well, and that change do not introduce risk of broking drivers
> > that require udev fw download.
> > 
> > iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
> > use request_firmware_nowait(), so it first need to be converted to
> > ordinary request_firmware(), but this should be doable and I can do
> > that.
> 
> I am going bonkers here. This is the Nth time a discussion pops up on
> firmware API usage. I stopped counting N :-( So the first issue was that
> the INIT was taking to long as we were requesting firmware during probe
> which was executed in the INIT context. So we added a worker and
> register the driver from there. There was probably a reason for
> switching to _no_wait() as well, but I do not recall the details. The
> things is I don't know if I need user-space or not. I just need firmware
> to get the device up and running. We have changed our driver a couple of
> times now to accommodate something that in my opinion should have been
> abstracted behind the firmware API in the first place and now here is
> another proposal to change the drivers. Come on!

I understand you dislike that :-) Just to clarify the issue here:

Some drivers (including brcmfmac) request new firmware images, which are
not yet available (i.e. development F/W versions) and then fall-back
to older firmware version and works perfectly fine.

However with CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y configured, in case
of missing F/W image, request firmware involve user space helper and
waits 60s (loading_timeout value from drivers/base/firmware_class.c),
what delays creating network interface and confuse users.

For brcmfmac this looks like this:

[   15.160923] brcmfmac 0000:03:00.0: Direct firmware load for brcm/brcmfmac4356-pcie.txt failed with error -2
[   15.170759] brcmfmac 0000:03:00.0: Falling back to user helper
<snip>
[   75.709397] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 22 2015 06:16:41 version 7.35.180.119 (r594535) FWID 01-1a5c4016
[   75.736941] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code (0x30 0x30)

Without CONFIG_FW_LOADER_USER_HELPER_FALLBACK first firmware request
silently fail and then instantly next F/W image is loaded.

Another option to solve to problem would be stop requesting not
available publicly firmware. However, I assume some drivers would
like to preserve that option.

> > However I wonder if changing that will not broke the case when
> > driver is build-in in the kernel and f/w is not yet available when
> > driver start to initialize. Or maybe nowadays this is not the case
> > any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w 
> > images are build-in in the kernel or copied to initramfs?
> 
> That is a nice idea, but I have not seen any change in that area. Could
> have missed it.

I believe this is how the things are already done, IOW switching to
request_firmware_direct() in the driver should be no harm.

Stanislaw


From rmanohar at qti.qualcomm.com  Fri Jul 22 04:59:41 2016
From: rmanohar at qti.qualcomm.com (Manoharan, Rajkumar)
Date: Fri, 22 Jul 2016 11:59:41 +0000
Subject: ath10k + iw set bitrates is causing FW crash
In-Reply-To: <CABPxzYKomhw5rF4Crj6sMbmr3VuuDYi=zqN2ky83v-=RJe7Zhg@mail.gmail.com>
References: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>
 <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>
 <1467972560885.99812@qti.qualcomm.com>
 <CABPxzY+8Y-FHUFALGueN1hQwgjJHNpeyy_BRkrM4osguxJZS0Q@mail.gmail.com>
 <1467982766213.21223@qti.qualcomm.com>
 <CABPxzYLO8rzvOJ_1iqng89kYFS-xqC3qstbgETVRJHDpO4rikQ@mail.gmail.com>
 <CABPxzYJPi4CqO+KUFA7=r=zpq_c2vFtrgBQ+nF_nThO-cYrteg@mail.gmail.com>,
 <CABPxzYKomhw5rF4Crj6sMbmr3VuuDYi=zqN2ky83v-=RJe7Zhg@mail.gmail.com>
Message-ID: <1469188781289.75799@qti.qualcomm.com>

[...]
> >> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
> >> seeing 0-9, so its
> >> working.
> >>
> >> But i am seeing a weird issues, the moment i give bitrates command,
> >> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
> >> interface up/down
> >> it doesn't work.
>> After reboot i dont see the "unencrypted" packet issue, i will do
>> some more testing on limiting the rates, currently in my setup its
>> not reaching MCS9 so cannot verify now.
> Rajkumar,
>
> I am still not able to make mcs9 work, so i have tried to change the Nss to 1
> using iw, but that is not taking affect. This command is not taking effect.
>
you mean not able to fix VHT rates alone. am i right? By auto rate mode, is firmware selecting
mcs9? What is the command used for fixing vht rate?

-Rajkumar

From arend.vanspriel at broadcom.com  Fri Jul 22 05:21:47 2016
From: arend.vanspriel at broadcom.com (Arend Van Spriel)
Date: Fri, 22 Jul 2016 14:21:47 +0200
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <20160722102559.GA2662@redhat.com>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
 <20160721070938.GA2658@redhat.com>
 <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>
 <20160721080541.GB2658@redhat.com> <5790A28F.8030102@redhat.com>
 <20160721115122.GA31869@redhat.com>
 <a264e995-fc46-7fcd-69f9-80992385b6b1@broadcom.com>
 <20160722102559.GA2662@redhat.com>
Message-ID: <84a2cfbe-3d58-a5ec-e028-166dce4c9304@broadcom.com>

On 22-7-2016 12:26, Stanislaw Gruszka wrote:
> On Fri, Jul 22, 2016 at 10:38:24AM +0200, Arend Van Spriel wrote:
>> + Luis
>>
>> On 21-7-2016 13:51, Stanislaw Gruszka wrote:
>>> (cc: firmware and brcmfmac maintainers)
>>>
>>> On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
>>>>
>>>>
>>>> On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
>>>>> On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
>>>>>> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
>>>>>>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
>>>>>>>> Firmware files are versioned to prevent older
>>>>>>>> driver instances to load unsupported firmware
>>>>>>>> blobs. This is reflected with a fallback logic
>>>>>>>> which attempts to load several firmware files.
>>>>>>>>
>>>>>>>> This however produced a lot of unnecessary
>>>>>>>> warnings sometimes confusing users and leading
>>>>>>>> them to rename firmware files making things even
>>>>>>>> more confusing.
>>>>>>>
>>>>>>> This happens on kernels configured with
>>>>>>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
>>>>>>> but also 60 seconds delay before loading next firmware version.
>>>>>>> For some reason RHEL kernel needs above config option, so this
>>>>>>> patch is very welcome from my perspective.
>>>>>>>
>>>>>>
>>>>>> Sorry for my ignorance but how does the firmware loading work if not
>>>>>> with udev's help?
>>>>>
>>>>> I'm not sure exactly, but I think kernel VFS layer is capable to copy
>>>>> file data directly from mounted filesystem without user space helper.
>>>>
>>>> Here's the situation: request_firmware() waits 60 seconds for udev to do its
>>>> loading magic via a "usermode helper".  This delay is there to allow, for
>>>> example, userspace to unpack or download a new firmware image or verify the
>>>> firmware image *in userspace* before providing it to the driver to apply to the HW.
>>>>
>>>> Why 60 seconds?  It is arbitrary and there is no way for udev & the kernel to
>>>> handshake on completion.
>>>>
>>>>>
>>>>>> As you can imagine, iwlwifi is suffering from the
>>>>>> same problem and I would be interested in applying the same change,
>>>>>> but I'd love to understand a bit more :)
>>>>>
>>>>> Yes, iwlwifi (and some other drivers) suffer from this. However this
>>>>> happen when the newest firmware version is not installed on the system
>>>>> and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
>>>>> it's not common.
>>>>
>>>> request_firmware_direct() was introduced at my request because (as you've
>>>> noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
>>>> periods of time when starting.  The bug that this introduced was a 60 second
>>>> delay per logical cpu when starting a system.  On a 64 cpu system that meant the
>>>> boot would complete in a little over one hour.
>>>>
>>>>>
>>>>> I started to see this currently, because that option was enabled on 
>>>>> RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
>>>>> happened because of that, i.e. thermal device was not functional
>>>>> because f/w wasn't loaded due to big delay.
>>>>>
>>>>> I'm not sure if replacing to request_firmware_direct() is a good
>>>>> fix though. For example I can see this problem also on brcmfmac, which
>>>>> use request_firmware_nowait(). I think I would rather prefer special
>>>>> helper for firmware drivers that needs user helper and have
>>>>> request_firmware() be direct as default.
>>>>>
>>>>
>>>> The difference between request_firmware_direct() and request_firmware() is that
>>>> the _direct() version does not wait the 60 seconds for udev interaction.  The
>>>> only userspace check performed is to see if the file is there, and if the file
>>>> does exist it is provided to the driver to be applied to the hardware.
>>>>
>>>> So the real question to ask here is whether or not the ath10k, brcmfmac, and
>>>> iwlwifi require udev to do anything beyond checking for the existence and
>>>> loading the firmware image.  If they don't, then it is better to use
>>>> request_firmware_direct().
>>>
>>> They don't need that, like 99% of the drivers I think, hence changing the
>>> default seems to be more reasonable. However changing 3 drivers would work
>>> for me as well, and that change do not introduce risk of broking drivers
>>> that require udev fw download.
>>>
>>> iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
>>> use request_firmware_nowait(), so it first need to be converted to
>>> ordinary request_firmware(), but this should be doable and I can do
>>> that.
>>
>> I am going bonkers here. This is the Nth time a discussion pops up on
>> firmware API usage. I stopped counting N :-( So the first issue was that
>> the INIT was taking to long as we were requesting firmware during probe
>> which was executed in the INIT context. So we added a worker and
>> register the driver from there. There was probably a reason for
>> switching to _no_wait() as well, but I do not recall the details. The
>> things is I don't know if I need user-space or not. I just need firmware
>> to get the device up and running. We have changed our driver a couple of
>> times now to accommodate something that in my opinion should have been
>> abstracted behind the firmware API in the first place and now here is
>> another proposal to change the drivers. Come on!
> 
> I understand you dislike that :-) Just to clarify the issue here:
> 
> Some drivers (including brcmfmac) request new firmware images, which are
> not yet available (i.e. development F/W versions) and then fall-back
> to older firmware version and works perfectly fine.
> 
> However with CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y configured, in case
> of missing F/W image, request firmware involve user space helper and
> waits 60s (loading_timeout value from drivers/base/firmware_class.c),
> what delays creating network interface and confuse users.
> 
> For brcmfmac this looks like this:
> 
> [   15.160923] brcmfmac 0000:03:00.0: Direct firmware load for brcm/brcmfmac4356-pcie.txt failed with error -2
> [   15.170759] brcmfmac 0000:03:00.0: Falling back to user helper
> <snip>
> [   75.709397] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 22 2015 06:16:41 version 7.35.180.119 (r594535) FWID 01-1a5c4016
> [   75.736941] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code (0x30 0x30)
> 
> Without CONFIG_FW_LOADER_USER_HELPER_FALLBACK first firmware request
> silently fail and then instantly next F/W image is loaded.
> 
> Another option to solve to problem would be stop requesting not
> available publicly firmware. However, I assume some drivers would
> like to preserve that option.

Actually, this is not the case with brcmfmac. We do need a firmware
file, ie. brcm/brcmfmac4356-pcie.bin, and also request for a nvram file,
ie. brcm/brcmfmac4356-pcie.txt. The latter is optional and the device
works fine without it.

What is still unclear to me is when request_firmware_direct() would fail
and in what circumstances the udev helper is a valid callback. Can you
explain such a scenario. Another question I have is what the reasons are
behind the 60 seconds timeout.

>>> However I wonder if changing that will not broke the case when
>>> driver is build-in in the kernel and f/w is not yet available when
>>> driver start to initialize. Or maybe nowadays this is not the case
>>> any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w 
>>> images are build-in in the kernel or copied to initramfs?
>>
>> That is a nice idea, but I have not seen any change in that area. Could
>> have missed it.
> 
> I believe this is how the things are already done, IOW switching to
> request_firmware_direct() in the driver should be no harm.

Ok. What are the consequences when:
- driver is built-in.
- driver+firmware present on initramfs.
- driver on initramfs, firmware only present on rootfs.
- driver+firmware only on rootfs.

I assume the third one would be considered a configuration issue.

Regards,
Arend


From chaitanya.mgit at gmail.com  Fri Jul 22 05:21:40 2016
From: chaitanya.mgit at gmail.com (Krishna Chaitanya)
Date: Fri, 22 Jul 2016 17:51:40 +0530
Subject: ath10k + iw set bitrates is causing FW crash
In-Reply-To: <1469188781289.75799@qti.qualcomm.com>
References: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>
 <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>
 <1467972560885.99812@qti.qualcomm.com>
 <CABPxzY+8Y-FHUFALGueN1hQwgjJHNpeyy_BRkrM4osguxJZS0Q@mail.gmail.com>
 <1467982766213.21223@qti.qualcomm.com>
 <CABPxzYLO8rzvOJ_1iqng89kYFS-xqC3qstbgETVRJHDpO4rikQ@mail.gmail.com>
 <CABPxzYJPi4CqO+KUFA7=r=zpq_c2vFtrgBQ+nF_nThO-cYrteg@mail.gmail.com>
 <CABPxzYKomhw5rF4Crj6sMbmr3VuuDYi=zqN2ky83v-=RJe7Zhg@mail.gmail.com>
 <1469188781289.75799@qti.qualcomm.com>
Message-ID: <CABPxzYL2D1b08vOJc9b9WCjjEDtgHW2UQFNVSyxD5wSjidmiQA@mail.gmail.com>

On Fri, Jul 22, 2016 at 5:29 PM, Manoharan, Rajkumar
<rmanohar at qti.qualcomm.com> wrote:
> [...]
>> >> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
>> >> seeing 0-9, so its
>> >> working.
>> >>
>> >> But i am seeing a weird issues, the moment i give bitrates command,
>> >> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
>> >> interface up/down
>> >> it doesn't work.
>>> After reboot i dont see the "unencrypted" packet issue, i will do
>>> some more testing on limiting the rates, currently in my setup its
>>> not reaching MCS9 so cannot verify now.
>> Rajkumar,
>>
>> I am still not able to make mcs9 work, so i have tried to change the Nss to 1
>> using iw, but that is not taking affect. This command is not taking effect.
>>
> you mean not able to fix VHT rates alone. am i right? By auto rate mode, is firmware selecting
> mcs9? What is the command used for fixing vht rate?
Basically my requirement is to disable MCS8 and 9 for comparison.
to check whether ath10k honors the iw command, i used below
command. changing to 1SS, but i could see that it still transmits
using 2SS. Does your patch ignore these settings except for
adhoc mode?

iw set bitrates vht-mcs-5 1:0-7


From prarit at redhat.com  Fri Jul 22 05:51:36 2016
From: prarit at redhat.com (Prarit Bhargava)
Date: Fri, 22 Jul 2016 08:51:36 -0400
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <84a2cfbe-3d58-a5ec-e028-166dce4c9304@broadcom.com>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
 <20160721070938.GA2658@redhat.com>
 <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>
 <20160721080541.GB2658@redhat.com> <5790A28F.8030102@redhat.com>
 <20160721115122.GA31869@redhat.com>
 <a264e995-fc46-7fcd-69f9-80992385b6b1@broadcom.com>
 <20160722102559.GA2662@redhat.com>
 <84a2cfbe-3d58-a5ec-e028-166dce4c9304@broadcom.com>
Message-ID: <579216D8.2010401@redhat.com>



On 07/22/2016 08:21 AM, Arend Van Spriel wrote:
> On 22-7-2016 12:26, Stanislaw Gruszka wrote:
>> On Fri, Jul 22, 2016 at 10:38:24AM +0200, Arend Van Spriel wrote:
>>> + Luis
>>>
>>> On 21-7-2016 13:51, Stanislaw Gruszka wrote:
>>>> (cc: firmware and brcmfmac maintainers)
>>>>
>>>> On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
>>>>>
>>>>>
>>>>> On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
>>>>>> On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
>>>>>>> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
>>>>>>>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
>>>>>>>>> Firmware files are versioned to prevent older
>>>>>>>>> driver instances to load unsupported firmware
>>>>>>>>> blobs. This is reflected with a fallback logic
>>>>>>>>> which attempts to load several firmware files.
>>>>>>>>>
>>>>>>>>> This however produced a lot of unnecessary
>>>>>>>>> warnings sometimes confusing users and leading
>>>>>>>>> them to rename firmware files making things even
>>>>>>>>> more confusing.
>>>>>>>>
>>>>>>>> This happens on kernels configured with
>>>>>>>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
>>>>>>>> but also 60 seconds delay before loading next firmware version.
>>>>>>>> For some reason RHEL kernel needs above config option, so this
>>>>>>>> patch is very welcome from my perspective.
>>>>>>>>
>>>>>>>
>>>>>>> Sorry for my ignorance but how does the firmware loading work if not
>>>>>>> with udev's help?
>>>>>>
>>>>>> I'm not sure exactly, but I think kernel VFS layer is capable to copy
>>>>>> file data directly from mounted filesystem without user space helper.
>>>>>
>>>>> Here's the situation: request_firmware() waits 60 seconds for udev to do its
>>>>> loading magic via a "usermode helper".  This delay is there to allow, for
>>>>> example, userspace to unpack or download a new firmware image or verify the
>>>>> firmware image *in userspace* before providing it to the driver to apply to the HW.
>>>>>
>>>>> Why 60 seconds?  It is arbitrary and there is no way for udev & the kernel to
>>>>> handshake on completion.
>>>>>
>>>>>>
>>>>>>> As you can imagine, iwlwifi is suffering from the
>>>>>>> same problem and I would be interested in applying the same change,
>>>>>>> but I'd love to understand a bit more :)
>>>>>>
>>>>>> Yes, iwlwifi (and some other drivers) suffer from this. However this
>>>>>> happen when the newest firmware version is not installed on the system
>>>>>> and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
>>>>>> it's not common.
>>>>>
>>>>> request_firmware_direct() was introduced at my request because (as you've
>>>>> noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
>>>>> periods of time when starting.  The bug that this introduced was a 60 second
>>>>> delay per logical cpu when starting a system.  On a 64 cpu system that meant the
>>>>> boot would complete in a little over one hour.
>>>>>
>>>>>>
>>>>>> I started to see this currently, because that option was enabled on 
>>>>>> RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
>>>>>> happened because of that, i.e. thermal device was not functional
>>>>>> because f/w wasn't loaded due to big delay.
>>>>>>
>>>>>> I'm not sure if replacing to request_firmware_direct() is a good
>>>>>> fix though. For example I can see this problem also on brcmfmac, which
>>>>>> use request_firmware_nowait(). I think I would rather prefer special
>>>>>> helper for firmware drivers that needs user helper and have
>>>>>> request_firmware() be direct as default.
>>>>>>
>>>>>
>>>>> The difference between request_firmware_direct() and request_firmware() is that
>>>>> the _direct() version does not wait the 60 seconds for udev interaction.  The
>>>>> only userspace check performed is to see if the file is there, and if the file
>>>>> does exist it is provided to the driver to be applied to the hardware.
>>>>>
>>>>> So the real question to ask here is whether or not the ath10k, brcmfmac, and
>>>>> iwlwifi require udev to do anything beyond checking for the existence and
>>>>> loading the firmware image.  If they don't, then it is better to use
>>>>> request_firmware_direct().
>>>>
>>>> They don't need that, like 99% of the drivers I think, hence changing the
>>>> default seems to be more reasonable. However changing 3 drivers would work
>>>> for me as well, and that change do not introduce risk of broking drivers
>>>> that require udev fw download.
>>>>
>>>> iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
>>>> use request_firmware_nowait(), so it first need to be converted to
>>>> ordinary request_firmware(), but this should be doable and I can do
>>>> that.
>>>
>>> I am going bonkers here. This is the Nth time a discussion pops up on
>>> firmware API usage. I stopped counting N :-( So the first issue was that
>>> the INIT was taking to long as we were requesting firmware during probe
>>> which was executed in the INIT context. So we added a worker and
>>> register the driver from there. There was probably a reason for
>>> switching to _no_wait() as well, but I do not recall the details. The
>>> things is I don't know if I need user-space or not. I just need firmware
>>> to get the device up and running. We have changed our driver a couple of
>>> times now to accommodate something that in my opinion should have been
>>> abstracted behind the firmware API in the first place and now here is
>>> another proposal to change the drivers. Come on!
>>
>> I understand you dislike that :-) Just to clarify the issue here:
>>
>> Some drivers (including brcmfmac) request new firmware images, which are
>> not yet available (i.e. development F/W versions) and then fall-back
>> to older firmware version and works perfectly fine.
>>
>> However with CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y configured, in case
>> of missing F/W image, request firmware involve user space helper and
>> waits 60s (loading_timeout value from drivers/base/firmware_class.c),
>> what delays creating network interface and confuse users.
>>
>> For brcmfmac this looks like this:
>>
>> [   15.160923] brcmfmac 0000:03:00.0: Direct firmware load for brcm/brcmfmac4356-pcie.txt failed with error -2
>> [   15.170759] brcmfmac 0000:03:00.0: Falling back to user helper
>> <snip>
>> [   75.709397] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 22 2015 06:16:41 version 7.35.180.119 (r594535) FWID 01-1a5c4016
>> [   75.736941] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code (0x30 0x30)
>>
>> Without CONFIG_FW_LOADER_USER_HELPER_FALLBACK first firmware request
>> silently fail and then instantly next F/W image is loaded.
>>
>> Another option to solve to problem would be stop requesting not
>> available publicly firmware. However, I assume some drivers would
>> like to preserve that option.
> 
> Actually, this is not the case with brcmfmac. We do need a firmware
> file, ie. brcm/brcmfmac4356-pcie.bin, and also request for a nvram file,
> ie. brcm/brcmfmac4356-pcie.txt. The latter is optional and the device
> works fine without it.
> 
> What is still unclear to me is when request_firmware_direct() would fail
> and in what circumstances the udev helper is a valid callback. Can you
> explain such a scenario. Another question I have is what the reasons are
> behind the 60 seconds timeout.

request_firmware_direct() will fail when the specified FW file is not present.
This is different from request_firmware() which implements a usermode helper to
potentially download firmware, or unpack a firmware image.

Re: 60 second timeout ... The 60 second timeout with request_firmware() is
completely arbitrary.  There is no way for udev to signal back to the kernel
that userspace helper has not completed its actions, so the kernel has a 60 dead
man timer-ish delay.

> 
>>>> However I wonder if changing that will not broke the case when
>>>> driver is build-in in the kernel and f/w is not yet available when
>>>> driver start to initialize. Or maybe nowadays this is not the case
>>>> any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w 
>>>> images are build-in in the kernel or copied to initramfs?
>>>
>>> That is a nice idea, but I have not seen any change in that area. Could
>>> have missed it.
>>
>> I believe this is how the things are already done, IOW switching to
>> request_firmware_direct() in the driver should be no harm.
> 
> Ok. What are the consequences when:
> - driver is built-in.
> - driver+firmware present on initramfs.
> - driver on initramfs, firmware only present on rootfs.
> - driver+firmware only on rootfs.
> 
> I assume the third one would be considered a configuration issue.

I think your question here can be answered by reading drivers/base/Kconfig:88,
and reading about those 4 config options.  I could paraphrase it butI think the
Kconfig notes are better than I could explain it.  Note that this is how things
currently work with request_firmware_nowait().  IIRC request_firmware_nowait()
is just an asynchronous version of request_firmware().

HTH,

P.


From greearb at candelatech.com  Fri Jul 22 06:32:36 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 22 Jul 2016 06:32:36 -0700
Subject: ath10k + iw set bitrates is causing FW crash
In-Reply-To: <CABPxzYL2D1b08vOJc9b9WCjjEDtgHW2UQFNVSyxD5wSjidmiQA@mail.gmail.com>
References: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>
 <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>
 <1467972560885.99812@qti.qualcomm.com>
 <CABPxzY+8Y-FHUFALGueN1hQwgjJHNpeyy_BRkrM4osguxJZS0Q@mail.gmail.com>
 <1467982766213.21223@qti.qualcomm.com>
 <CABPxzYLO8rzvOJ_1iqng89kYFS-xqC3qstbgETVRJHDpO4rikQ@mail.gmail.com>
 <CABPxzYJPi4CqO+KUFA7=r=zpq_c2vFtrgBQ+nF_nThO-cYrteg@mail.gmail.com>
 <CABPxzYKomhw5rF4Crj6sMbmr3VuuDYi=zqN2ky83v-=RJe7Zhg@mail.gmail.com>
 <1469188781289.75799@qti.qualcomm.com>
 <CABPxzYL2D1b08vOJc9b9WCjjEDtgHW2UQFNVSyxD5wSjidmiQA@mail.gmail.com>
Message-ID: <57922074.5060009@candelatech.com>



On 07/22/2016 05:21 AM, Krishna Chaitanya wrote:
> On Fri, Jul 22, 2016 at 5:29 PM, Manoharan, Rajkumar
> <rmanohar at qti.qualcomm.com> wrote:
>> [...]
>>>>> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
>>>>> seeing 0-9, so its
>>>>> working.
>>>>>
>>>>> But i am seeing a weird issues, the moment i give bitrates command,
>>>>> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
>>>>> interface up/down
>>>>> it doesn't work.
>>>> After reboot i dont see the "unencrypted" packet issue, i will do
>>>> some more testing on limiting the rates, currently in my setup its
>>>> not reaching MCS9 so cannot verify now.
>>> Rajkumar,
>>>
>>> I am still not able to make mcs9 work, so i have tried to change the Nss to 1
>>> using iw, but that is not taking affect. This command is not taking effect.
>>>
>> you mean not able to fix VHT rates alone. am i right? By auto rate mode, is firmware selecting
>> mcs9? What is the command used for fixing vht rate?
> Basically my requirement is to disable MCS8 and 9 for comparison.
> to check whether ath10k honors the iw command, i used below
> command. changing to 1SS, but i could see that it still transmits
> using 2SS. Does your patch ignore these settings except for
> adhoc mode?
>
> iw set bitrates vht-mcs-5 1:0-7

You can set the number of spatial streams on the phy device.  Search around
for a 'chainmask' configurable.

In general, stock ath10k firmware does not have full support for setting
arbitrary bitrates options.

Thanks,
Ben

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


From chaitanya.mgit at gmail.com  Fri Jul 22 07:48:14 2016
From: chaitanya.mgit at gmail.com (Krishna Chaitanya)
Date: Fri, 22 Jul 2016 20:18:14 +0530
Subject: ath10k + iw set bitrates is causing FW crash
In-Reply-To: <57922074.5060009@candelatech.com>
References: <CABPxzYLwye1t1Ycjr3nO5C18vc7OqS9dbbQ1yJ7B-YN+Bkx_PA@mail.gmail.com>
 <CABPxzYL5DHU7ZE1X1AibygBUz0TJEnNLLTp5_hDivmBBkjnVtg@mail.gmail.com>
 <1467972560885.99812@qti.qualcomm.com>
 <CABPxzY+8Y-FHUFALGueN1hQwgjJHNpeyy_BRkrM4osguxJZS0Q@mail.gmail.com>
 <1467982766213.21223@qti.qualcomm.com>
 <CABPxzYLO8rzvOJ_1iqng89kYFS-xqC3qstbgETVRJHDpO4rikQ@mail.gmail.com>
 <CABPxzYJPi4CqO+KUFA7=r=zpq_c2vFtrgBQ+nF_nThO-cYrteg@mail.gmail.com>
 <CABPxzYKomhw5rF4Crj6sMbmr3VuuDYi=zqN2ky83v-=RJe7Zhg@mail.gmail.com>
 <1469188781289.75799@qti.qualcomm.com>
 <CABPxzYL2D1b08vOJc9b9WCjjEDtgHW2UQFNVSyxD5wSjidmiQA@mail.gmail.com>
 <57922074.5060009@candelatech.com>
Message-ID: <CABPxzYJZ=+ECmM3KUNSAQSKCthxxGYnpDn=p-cmC1qoaoJsc4g@mail.gmail.com>

On Fri, Jul 22, 2016 at 7:02 PM, Ben Greear <greearb at candelatech.com> wrote:
>
>
> On 07/22/2016 05:21 AM, Krishna Chaitanya wrote:
>>
>> On Fri, Jul 22, 2016 at 5:29 PM, Manoharan, Rajkumar
>> <rmanohar at qti.qualcomm.com> wrote:
>>>
>>> [...]
>>>>>>
>>>>>> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
>>>>>> seeing 0-9, so its
>>>>>> working.
>>>>>>
>>>>>> But i am seeing a weird issues, the moment i give bitrates command,
>>>>>> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
>>>>>> interface up/down
>>>>>> it doesn't work.
>>>>>
>>>>> After reboot i dont see the "unencrypted" packet issue, i will do
>>>>> some more testing on limiting the rates, currently in my setup its
>>>>> not reaching MCS9 so cannot verify now.
>>>>
>>>> Rajkumar,
>>>>
>>>> I am still not able to make mcs9 work, so i have tried to change the Nss
>>>> to 1
>>>> using iw, but that is not taking affect. This command is not taking
>>>> effect.
>>>>
>>> you mean not able to fix VHT rates alone. am i right? By auto rate mode,
>>> is firmware selecting
>>> mcs9? What is the command used for fixing vht rate?
>>
>> Basically my requirement is to disable MCS8 and 9 for comparison.
>> to check whether ath10k honors the iw command, i used below
>> command. changing to 1SS, but i could see that it still transmits
>> using 2SS. Does your patch ignore these settings except for
>> adhoc mode?
>>
>> iw set bitrates vht-mcs-5 1:0-7
>
>
> You can set the number of spatial streams on the phy device.  Search around
> for a 'chainmask' configurable.
>
> In general, stock ath10k firmware does not have full support for setting
> arbitrary bitrates options.
Yes, i know that option but havent tried that. My intention was to limit to MCS7
so in order to verify that commands i tried to change nss.


From mcgrof at kernel.org  Fri Jul 22 15:05:26 2016
From: mcgrof at kernel.org (Luis R. Rodriguez)
Date: Sat, 23 Jul 2016 00:05:26 +0200
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <a264e995-fc46-7fcd-69f9-80992385b6b1@broadcom.com>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
 <20160721070938.GA2658@redhat.com>
 <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>
 <20160721080541.GB2658@redhat.com> <5790A28F.8030102@redhat.com>
 <20160721115122.GA31869@redhat.com>
 <a264e995-fc46-7fcd-69f9-80992385b6b1@broadcom.com>
Message-ID: <20160722220526.GL5537@wotan.suse.de>

On Fri, Jul 22, 2016 at 10:38:24AM +0200, Arend Van Spriel wrote:
> + Luis
> 
> On 21-7-2016 13:51, Stanislaw Gruszka wrote:
> > (cc: firmware and brcmfmac maintainers)
> > 
> > On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
> >>
> >>
> >> On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
> >>> On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
> >>>> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
> >>>>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
> >>>>>> Firmware files are versioned to prevent older
> >>>>>> driver instances to load unsupported firmware
> >>>>>> blobs. This is reflected with a fallback logic
> >>>>>> which attempts to load several firmware files.
> >>>>>>
> >>>>>> This however produced a lot of unnecessary
> >>>>>> warnings sometimes confusing users and leading
> >>>>>> them to rename firmware files making things even
> >>>>>> more confusing.
> >>>>>
> >>>>> This happens on kernels configured with
> >>>>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
> >>>>> but also 60 seconds delay before loading next firmware version.
> >>>>> For some reason RHEL kernel needs above config option, so this
> >>>>> patch is very welcome from my perspective.
> >>>>>
> >>>>
> >>>> Sorry for my ignorance but how does the firmware loading work if not
> >>>> with udev's help?
> >>>
> >>> I'm not sure exactly, but I think kernel VFS layer is capable to copy
> >>> file data directly from mounted filesystem without user space helper.
> >>
> >> Here's the situation: request_firmware() waits 60 seconds for udev to do its
> >> loading magic via a "usermode helper".  This delay is there to allow, for
> >> example, userspace to unpack or download a new firmware image or verify the
> >> firmware image *in userspace* before providing it to the driver to apply to the HW.
> >>
> >> Why 60 seconds?  It is arbitrary and there is no way for udev & the kernel to
> >> handshake on completion.
> >>
> >>>
> >>>> As you can imagine, iwlwifi is suffering from the
> >>>> same problem and I would be interested in applying the same change,
> >>>> but I'd love to understand a bit more :)
> >>>
> >>> Yes, iwlwifi (and some other drivers) suffer from this. However this
> >>> happen when the newest firmware version is not installed on the system
> >>> and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
> >>> it's not common.
> >>
> >> request_firmware_direct() was introduced at my request because (as you've
> >> noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
> >> periods of time when starting.  The bug that this introduced was a 60 second
> >> delay per logical cpu when starting a system.  On a 64 cpu system that meant the
> >> boot would complete in a little over one hour.
> >>
> >>>
> >>> I started to see this currently, because that option was enabled on 
> >>> RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
> >>> happened because of that, i.e. thermal device was not functional
> >>> because f/w wasn't loaded due to big delay.
> >>>
> >>> I'm not sure if replacing to request_firmware_direct() is a good
> >>> fix though. For example I can see this problem also on brcmfmac, which
> >>> use request_firmware_nowait(). I think I would rather prefer special
> >>> helper for firmware drivers that needs user helper and have
> >>> request_firmware() be direct as default.
> >>>
> >>
> >> The difference between request_firmware_direct() and request_firmware() is that
> >> the _direct() version does not wait the 60 seconds for udev interaction.  The
> >> only userspace check performed is to see if the file is there, and if the file
> >> does exist it is provided to the driver to be applied to the hardware.
> >>
> >> So the real question to ask here is whether or not the ath10k, brcmfmac, and
> >> iwlwifi require udev to do anything beyond checking for the existence and
> >> loading the firmware image.  If they don't, then it is better to use
> >> request_firmware_direct().
> > 
> > They don't need that, like 99% of the drivers I think, hence changing the
> > default seems to be more reasonable. However changing 3 drivers would work
> > for me as well, and that change do not introduce risk of broking drivers
> > that require udev fw download.
> > 
> > iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
> > use request_firmware_nowait(), so it first need to be converted to
> > ordinary request_firmware(), but this should be doable and I can do
> > that.
> 
> I am going bonkers here. This is the Nth time a discussion pops up on
> firmware API usage. I stopped counting N :-( So the first issue was that
> the INIT was taking to long as we were requesting firmware during probe
> which was executed in the INIT context. So we added a worker and
> register the driver from there. There was probably a reason for
> switching to _no_wait() as well, but I do not recall the details. The
> things is I don't know if I need user-space or not. I just need firmware
> to get the device up and running. We have changed our driver a couple of
> times now to accommodate something that in my opinion should have been
> abstracted behind the firmware API in the first place and now here is
> another proposal to change the drivers. Come on!

Its a big mess, but a lot of it has to do with the fact that none of the
issues have been well documented. Its also not clear what distros, driver
developers or users should do. I've tried helping with by providing such
documentation and also providing grammar rules to avoid further issues [0],
hopefully this series will be merged soon.

[0] https://marc.info/?l=linux-kernel&m=146611775314567

Using grammar rules the hunt with coccinelle as of today's linux-next
reveals there are only 2 explicit users of the usermode helper, and
I've vetted for these as well in the above patch series.

Now, other than this users will experience the usermode helper if the
distribution messed up and build their kernel with the fallback
usermode helper. If this was done on some old kernel the only way
to fix that is to fix that kernel build or change drivers to avoid
the usermode helper explicitly, unfortunately some API calls cannot
avoid it .... I've documented all this in the above series.

> > However I wonder if changing that will not broke the case when
> > driver is build-in in the kernel and f/w is not yet available when
> > driver start to initialize.

Indeed, tons of races are in theory possible here ;) technically since we use a
common API to read files directly now, a race might also be possible for other
users of the API on init as well. I have some grammar rules to test for this in
development, that is to vet that not only the firmware API is checked and we
avoid on init but also other callers that use the same read API.

> > Or maybe nowadays this is not the case
> > any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w 
> > images are build-in in the kernel or copied to initramfs?

The firmware API is a mess and I've been trying to correct that
with a more flexible API.

> That is a nice idea, but I have not seen any change in that area. Could
> have missed it.

Extensions to the fw API are IMHO best done through a newer flexible
API, feel free to refer to this development tree if you'd like to
contribute:

https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160616-sysdata-v2

  Luis


From mcgrof at kernel.org  Fri Jul 22 15:15:23 2016
From: mcgrof at kernel.org (Luis R. Rodriguez)
Date: Sat, 23 Jul 2016 00:15:23 +0200
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <20160722102559.GA2662@redhat.com>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
 <20160721070938.GA2658@redhat.com>
 <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>
 <20160721080541.GB2658@redhat.com> <5790A28F.8030102@redhat.com>
 <20160721115122.GA31869@redhat.com>
 <a264e995-fc46-7fcd-69f9-80992385b6b1@broadcom.com>
 <20160722102559.GA2662@redhat.com>
Message-ID: <20160722221523.GM5537@wotan.suse.de>

On Fri, Jul 22, 2016 at 12:26:00PM +0200, Stanislaw Gruszka wrote:
> On Fri, Jul 22, 2016 at 10:38:24AM +0200, Arend Van Spriel wrote:
> > + Luis
> > 
> > On 21-7-2016 13:51, Stanislaw Gruszka wrote:
> > > (cc: firmware and brcmfmac maintainers)
> > > 
> > > On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
> > >>
> > >>
> > >> On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
> > >>> On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
> > >>>> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
> > >>>>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
> > >>>>>> Firmware files are versioned to prevent older
> > >>>>>> driver instances to load unsupported firmware
> > >>>>>> blobs. This is reflected with a fallback logic
> > >>>>>> which attempts to load several firmware files.
> > >>>>>>
> > >>>>>> This however produced a lot of unnecessary
> > >>>>>> warnings sometimes confusing users and leading
> > >>>>>> them to rename firmware files making things even
> > >>>>>> more confusing.
> > >>>>>
> > >>>>> This happens on kernels configured with
> > >>>>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
> > >>>>> but also 60 seconds delay before loading next firmware version.
> > >>>>> For some reason RHEL kernel needs above config option, so this
> > >>>>> patch is very welcome from my perspective.
> > >>>>>
> > >>>>
> > >>>> Sorry for my ignorance but how does the firmware loading work if not
> > >>>> with udev's help?
> > >>>
> > >>> I'm not sure exactly, but I think kernel VFS layer is capable to copy
> > >>> file data directly from mounted filesystem without user space helper.
> > >>
> > >> Here's the situation: request_firmware() waits 60 seconds for udev to do its
> > >> loading magic via a "usermode helper".  This delay is there to allow, for
> > >> example, userspace to unpack or download a new firmware image or verify the
> > >> firmware image *in userspace* before providing it to the driver to apply to the HW.
> > >>
> > >> Why 60 seconds?  It is arbitrary and there is no way for udev & the kernel to
> > >> handshake on completion.
> > >>
> > >>>
> > >>>> As you can imagine, iwlwifi is suffering from the
> > >>>> same problem and I would be interested in applying the same change,
> > >>>> but I'd love to understand a bit more :)
> > >>>
> > >>> Yes, iwlwifi (and some other drivers) suffer from this. However this
> > >>> happen when the newest firmware version is not installed on the system
> > >>> and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
> > >>> it's not common.
> > >>
> > >> request_firmware_direct() was introduced at my request because (as you've
> > >> noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
> > >> periods of time when starting.  The bug that this introduced was a 60 second
> > >> delay per logical cpu when starting a system.  On a 64 cpu system that meant the
> > >> boot would complete in a little over one hour.
> > >>
> > >>>
> > >>> I started to see this currently, because that option was enabled on 
> > >>> RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
> > >>> happened because of that, i.e. thermal device was not functional
> > >>> because f/w wasn't loaded due to big delay.
> > >>>
> > >>> I'm not sure if replacing to request_firmware_direct() is a good
> > >>> fix though. For example I can see this problem also on brcmfmac, which
> > >>> use request_firmware_nowait(). I think I would rather prefer special
> > >>> helper for firmware drivers that needs user helper and have
> > >>> request_firmware() be direct as default.
> > >>>
> > >>
> > >> The difference between request_firmware_direct() and request_firmware() is that
> > >> the _direct() version does not wait the 60 seconds for udev interaction.  The
> > >> only userspace check performed is to see if the file is there, and if the file
> > >> does exist it is provided to the driver to be applied to the hardware.
> > >>
> > >> So the real question to ask here is whether or not the ath10k, brcmfmac, and
> > >> iwlwifi require udev to do anything beyond checking for the existence and
> > >> loading the firmware image.  If they don't, then it is better to use
> > >> request_firmware_direct().
> > > 
> > > They don't need that, like 99% of the drivers I think, hence changing the
> > > default seems to be more reasonable. However changing 3 drivers would work
> > > for me as well, and that change do not introduce risk of broking drivers
> > > that require udev fw download.
> > > 
> > > iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
> > > use request_firmware_nowait(), so it first need to be converted to
> > > ordinary request_firmware(), but this should be doable and I can do
> > > that.
> > 
> > I am going bonkers here. This is the Nth time a discussion pops up on
> > firmware API usage. I stopped counting N :-( So the first issue was that
> > the INIT was taking to long as we were requesting firmware during probe
> > which was executed in the INIT context. So we added a worker and
> > register the driver from there. There was probably a reason for
> > switching to _no_wait() as well, but I do not recall the details. The
> > things is I don't know if I need user-space or not. I just need firmware
> > to get the device up and running. We have changed our driver a couple of
> > times now to accommodate something that in my opinion should have been
> > abstracted behind the firmware API in the first place and now here is
> > another proposal to change the drivers. Come on!
> 
> I understand you dislike that :-) Just to clarify the issue here:
> 
> Some drivers (including brcmfmac) request new firmware images, which are
> not yet available (i.e. development F/W versions) and then fall-back
> to older firmware version and works perfectly fine.

The right way to address this of course is to extend the FW API
so that a batch of firmware files can be hunted for and one can
easily annotate as a driver developer which are optional and which are
not. The API then will do everything for you.

I was considering this as a future extension to the firmware API
through the new extensible firmware API, the sysdata API. I'd prefer
to add that as a secondary step, but if someone wants to add support
for it now feel free to send me some patches against my tree.

> However with CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y configured, in case
> of missing F/W image, request firmware involve user space helper and
> waits 60s (loading_timeout value from drivers/base/firmware_class.c),
> what delays creating network interface and confuse users.

Correct, this has been a holy mess. One way to fix this on userspace
is to upgrade systemd with an exception to the udev kmod helper,
and avoid the timeout completely for kmod helper which loads drivers.

CONFIG_FW_LOADER_USER_HELPER_FALLBACK should be avoided.

> For brcmfmac this looks like this:
> 
> [   15.160923] brcmfmac 0000:03:00.0: Direct firmware load for brcm/brcmfmac4356-pcie.txt failed with error -2
> [   15.170759] brcmfmac 0000:03:00.0: Falling back to user helper
> <snip>
> [   75.709397] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 22 2015 06:16:41 version 7.35.180.119 (r594535) FWID 01-1a5c4016
> [   75.736941] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code (0x30 0x30)
> 
> Without CONFIG_FW_LOADER_USER_HELPER_FALLBACK first firmware request
> silently fail and then instantly next F/W image is loaded.

Yup.

> Another option to solve to problem would be stop requesting not
> available publicly firmware. However, I assume some drivers would
> like to preserve that option.

No, this seems counter productive given that the firmware is expected
to land eventually.

> > > However I wonder if changing that will not broke the case when
> > > driver is build-in in the kernel and f/w is not yet available when
> > > driver start to initialize. Or maybe nowadays this is not the case
> > > any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w 
> > > images are build-in in the kernel or copied to initramfs?
> > 
> > That is a nice idea, but I have not seen any change in that area. Could
> > have missed it.
> 
> I believe this is how the things are already done, IOW switching to
> request_firmware_direct() in the driver should be no harm.

We don't stuff firmware as built-in if the driver used MODULE_FIRMWARE()
and the driver is built-in. What commit did that?

The right thing to do is distros should avoid
CONFIG_FW_LOADER_USER_HELPER_FALLBACK and if they are stuck with it, a
systemd work around is possible. Upstream systemd already increased
the timeout to 180 seconds. Upstream also added a udevd --event-timeout
command line option, look into that. Other distros (OpenSUSE) avoids
the kmod timeout ;)

The timeout thing was simply a mistake, specially for kmod and it wasn't
well thought out. I've listed more serious implications for it here:

http://www.do-not-panic.com/2015/12/linux-asynchronous-probe.html

  Luis


From mcgrof at kernel.org  Fri Jul 22 15:19:29 2016
From: mcgrof at kernel.org (Luis R. Rodriguez)
Date: Sat, 23 Jul 2016 00:19:29 +0200
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <579216D8.2010401@redhat.com>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
 <20160721070938.GA2658@redhat.com>
 <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>
 <20160721080541.GB2658@redhat.com> <5790A28F.8030102@redhat.com>
 <20160721115122.GA31869@redhat.com>
 <a264e995-fc46-7fcd-69f9-80992385b6b1@broadcom.com>
 <20160722102559.GA2662@redhat.com>
 <84a2cfbe-3d58-a5ec-e028-166dce4c9304@broadcom.com>
 <579216D8.2010401@redhat.com>
Message-ID: <20160722221929.GN5537@wotan.suse.de>

On Fri, Jul 22, 2016 at 08:51:36AM -0400, Prarit Bhargava wrote:
> On 07/22/2016 08:21 AM, Arend Van Spriel wrote:
> >> Another option to solve to problem would be stop requesting not
> >> available publicly firmware. However, I assume some drivers would
> >> like to preserve that option.
> > 
> > Actually, this is not the case with brcmfmac. We do need a firmware
> > file, ie. brcm/brcmfmac4356-pcie.bin, and also request for a nvram file,
> > ie. brcm/brcmfmac4356-pcie.txt. The latter is optional and the device
> > works fine without it.
> > 
> > What is still unclear to me is when request_firmware_direct() would fail
> > and in what circumstances the udev helper is a valid callback. Can you
> > explain such a scenario. Another question I have is what the reasons are
> > behind the 60 seconds timeout.
> 
> request_firmware_direct() will fail when the specified FW file is not present.
> This is different from request_firmware() which implements a usermode helper to
> potentially download firmware, or unpack a firmware image.
> 
> Re: 60 second timeout ... The 60 second timeout with request_firmware() is
> completely arbitrary.  There is no way for udev to signal back to the kernel
> that userspace helper has not completed its actions, so the kernel has a 60 dead
> man timer-ish delay.

Lets call it what it was: the 60 second timeout thing was simply a mistake.
Its no longer 60 seconds anyway, and in fact its accepted a dreaded issue.
What *we* should be doing is thinking about proper long term architecture now.
Async probe was one solution to some issues, a new flexible firmware API
that avoids the usermode helper 100% is another.

Distros stuck with the fallback option should review their strategies,
either disabling the fallback option, upgrade systemd, or use alternative
solutions (opensuse has a good one).

> >>>> However I wonder if changing that will not broke the case when
> >>>> driver is build-in in the kernel and f/w is not yet available when
> >>>> driver start to initialize. Or maybe nowadays this is not the case
> >>>> any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w 
> >>>> images are build-in in the kernel or copied to initramfs?
> >>>
> >>> That is a nice idea, but I have not seen any change in that area. Could
> >>> have missed it.
> >>
> >> I believe this is how the things are already done, IOW switching to
> >> request_firmware_direct() in the driver should be no harm.
> > 
> > Ok. What are the consequences when:
> > - driver is built-in.
> > - driver+firmware present on initramfs.
> > - driver on initramfs, firmware only present on rootfs.
> > - driver+firmware only on rootfs.
> > 
> > I assume the third one would be considered a configuration issue.
> 
> I think your question here can be answered by reading drivers/base/Kconfig:88,
> and reading about those 4 config options.

No, this documentation is terrible, I've posted some patches to help with this
mess.

> I could paraphrase it butI think the
> Kconfig notes are better than I could explain it.  Note that this is how things
> currently work with request_firmware_nowait().  IIRC request_firmware_nowait()
> is just an asynchronous version of request_firmware().

... its a mess.

  Luis


From greearb at candelatech.com  Fri Jul 22 15:43:21 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 22 Jul 2016 15:43:21 -0700
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
Message-ID: <5792A189.5050807@candelatech.com>

On 06/13/2016 11:17 PM, Rajkumar Manoharan wrote:
> commit b057886524be ("ath10k: do not use coherent memory for allocated
> device memory chunks") replaced coherent memory allocation for memory
> chunks to fix low memory platforms. Unfortunately this is causing system
> freeze on x86 platform while bringing up qca99x0 device. The system
> hangs while DMA mapping bigger memory chunks (689816/865444 bytes). Fix
> this by limiting maximum memory chunk size to 256 KiB per request.
>
> Cc: Felix Fietkau <nbd at nbd.name>
> Fixes: b057886524be ("ath10k: do not use coherent memory for allocated device memory chunks")
> Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
> ---
>   drivers/net/wireless/ath/ath10k/wmi.c | 6 ++++++
>   drivers/net/wireless/ath/ath10k/wmi.h | 1 +
>   2 files changed, 7 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> index 6279ab4a760e..7c15f65fe5ed 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -4411,6 +4411,12 @@ static int ath10k_wmi_alloc_chunk(struct ath10k *ar, u32 req_id,
>   		if (!pool_size)
>   			return -EINVAL;
>
> +		if (pool_size > WMI_MAX_MEM_CHUNK_SIZE) {
> +			num_units = WMI_MAX_MEM_CHUNK_SIZE /
> +					round_up(unit_len, 4);
> +			pool_size = num_units * round_up(unit_len, 4);
> +		}

I started testing my 9980 x86-64 system with VT/d enabled today.
With this patch in my tree, it crashes on bootup (with my firmware).
Works fine without this patch.

I don't see the exact place it is crashing in the firmware, though I could
probably narrow it down with some effort.  It is in the early startup code,
at least, which makes debugging more difficult.

This patch works fine with a slightly newer firmware compiled for 9984.  That
same firmware compiled for 9980 crashes, but I am not certain it is the same issue
as the older 9980.  It appears similar, at least.

Looks to me like there are lots of variances in how firmware and chip revisions
deal with this particular code, so we are going to have to test on lots of chips
and platforms to know if a 'fix' is really a fix or not.

Thanks,
Ben


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



From s.gottschall at dd-wrt.com  Sat Jul 23 02:11:59 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Sat, 23 Jul 2016 11:11:59 +0200
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <5792A189.5050807@candelatech.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <5792A189.5050807@candelatech.com>
Message-ID: <6495e664-5da8-a11b-0bd5-15dc24c51edf@dd-wrt.com>

from my point of view this patch is just shit. it trunkates the maximum 
allocated memory to a certain value.
so firmware requests 800 kb memory but just gets 256kb. so out of bound 
memory access is guaranteed at all.


Am 23.07.2016 um 00:43 schrieb Ben Greear:
> On 06/13/2016 11:17 PM, Rajkumar Manoharan wrote:
>> commit b057886524be ("ath10k: do not use coherent memory for allocated
>> device memory chunks") replaced coherent memory allocation for memory
>> chunks to fix low memory platforms. Unfortunately this is causing system
>> freeze on x86 platform while bringing up qca99x0 device. The system
>> hangs while DMA mapping bigger memory chunks (689816/865444 bytes). Fix
>> this by limiting maximum memory chunk size to 256 KiB per request.
>>
>> Cc: Felix Fietkau <nbd at nbd.name>
>> Fixes: b057886524be ("ath10k: do not use coherent memory for 
>> allocated device memory chunks")
>> Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
>> ---
>>   drivers/net/wireless/ath/ath10k/wmi.c | 6 ++++++
>>   drivers/net/wireless/ath/ath10k/wmi.h | 1 +
>>   2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
>> b/drivers/net/wireless/ath/ath10k/wmi.c
>> index 6279ab4a760e..7c15f65fe5ed 100644
>> --- a/drivers/net/wireless/ath/ath10k/wmi.c
>> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
>> @@ -4411,6 +4411,12 @@ static int ath10k_wmi_alloc_chunk(struct 
>> ath10k *ar, u32 req_id,
>>           if (!pool_size)
>>               return -EINVAL;
>>
>> +        if (pool_size > WMI_MAX_MEM_CHUNK_SIZE) {
>> +            num_units = WMI_MAX_MEM_CHUNK_SIZE /
>> +                    round_up(unit_len, 4);
>> +            pool_size = num_units * round_up(unit_len, 4);
>> +        }
>
> I started testing my 9980 x86-64 system with VT/d enabled today.
> With this patch in my tree, it crashes on bootup (with my firmware).
> Works fine without this patch.
>
> I don't see the exact place it is crashing in the firmware, though I 
> could
> probably narrow it down with some effort.  It is in the early startup 
> code,
> at least, which makes debugging more difficult.
>
> This patch works fine with a slightly newer firmware compiled for 
> 9984.  That
> same firmware compiled for 9980 crashes, but I am not certain it is 
> the same issue
> as the older 9980.  It appears similar, at least.
>
> Looks to me like there are lots of variances in how firmware and chip 
> revisions
> deal with this particular code, so we are going to have to test on 
> lots of chips
> and platforms to know if a 'fix' is really a fix or not.
>
> Thanks,
> Ben
>
>


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From rmanohar at qti.qualcomm.com  Sat Jul 23 02:45:12 2016
From: rmanohar at qti.qualcomm.com (Manoharan, Rajkumar)
Date: Sat, 23 Jul 2016 09:45:12 +0000
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <6495e664-5da8-a11b-0bd5-15dc24c51edf@dd-wrt.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <5792A189.5050807@candelatech.com>,
 <6495e664-5da8-a11b-0bd5-15dc24c51edf@dd-wrt.com>
Message-ID: <1469267112032.61173@qti.qualcomm.com>

> from my point of view this patch is just shit. it trunkates the maximum
> allocated memory to a certain value.
> so firmware requests 800 kb memory but just gets 256kb. so out of bound
> memory access is guaranteed at all.
> 
Even with current logic, If the memory chunk allocation fails for bigger size, then it tries
to allocate smaller chunks. So anyway it is guaranteed for oob access. no?

        while (!vaddr && num_units) {
                pool_size = num_units * round_up(unit_len, 4);
                if (!pool_size)
                        return -EINVAL;

                vaddr = kzalloc(pool_size, GFP_KERNEL | __GFP_NOWARN);
                if (!vaddr)
                        num_units /= 2;
        }

Actually the commit "ath10k: do not use coherent memory for allocated device memory chunks"
is causing system hang on non VT/d x86 platform. Better to revert the commit until it is properly
root caused

-Rajkumar    

Am 23.07.2016 um 00:43 schrieb Ben Greear:
> On 06/13/2016 11:17 PM, Rajkumar Manoharan wrote:
>> commit b057886524be ("ath10k: do not use coherent memory for allocated
>> device memory chunks") replaced coherent memory allocation for memory
>> chunks to fix low memory platforms. Unfortunately this is causing system
>> freeze on x86 platform while bringing up qca99x0 device. The system
>> hangs while DMA mapping bigger memory chunks (689816/865444 bytes). Fix
>> this by limiting maximum memory chunk size to 256 KiB per request.
>>
>> Cc: Felix Fietkau <nbd at nbd.name>
>> Fixes: b057886524be ("ath10k: do not use coherent memory for
>> allocated device memory chunks")
>> Signed-off-by: Rajkumar Manoharan <rmanohar at qti.qualcomm.com>
>> ---
>>   drivers/net/wireless/ath/ath10k/wmi.c | 6 ++++++
>>   drivers/net/wireless/ath/ath10k/wmi.h | 1 +
>>   2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
>> b/drivers/net/wireless/ath/ath10k/wmi.c
>> index 6279ab4a760e..7c15f65fe5ed 100644
>> --- a/drivers/net/wireless/ath/ath10k/wmi.c
>> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
>> @@ -4411,6 +4411,12 @@ static int ath10k_wmi_alloc_chunk(struct
>> ath10k *ar, u32 req_id,
>>           if (!pool_size)
>>               return -EINVAL;
>>
>> +        if (pool_size > WMI_MAX_MEM_CHUNK_SIZE) {
>> +            num_units = WMI_MAX_MEM_CHUNK_SIZE /
>> +                    round_up(unit_len, 4);
>> +            pool_size = num_units * round_up(unit_len, 4);
>> +        }
>
> I started testing my 9980 x86-64 system with VT/d enabled today.
> With this patch in my tree, it crashes on bootup (with my firmware).
> Works fine without this patch.
>
> I don't see the exact place it is crashing in the firmware, though I
> could
> probably narrow it down with some effort.  It is in the early startup
> code,
> at least, which makes debugging more difficult.
>
> This patch works fine with a slightly newer firmware compiled for
> 9984.  That
> same firmware compiled for 9980 crashes, but I am not certain it is
> the same issue
> as the older 9980.  It appears similar, at least.
>
> Looks to me like there are lots of variances in how firmware and chip
> revisions
> deal with this particular code, so we are going to have to test on
> lots of chips
> and platforms to know if a 'fix' is really a fix or not.
>
> Thanks,
> Ben
>
>


--
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From greearb at candelatech.com  Sat Jul 23 14:55:37 2016
From: greearb at candelatech.com (Ben Greear)
Date: Sat, 23 Jul 2016 14:55:37 -0700
Subject: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
In-Reply-To: <6495e664-5da8-a11b-0bd5-15dc24c51edf@dd-wrt.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <5792A189.5050807@candelatech.com>
 <6495e664-5da8-a11b-0bd5-15dc24c51edf@dd-wrt.com>
Message-ID: <5793E7D9.60707@candelatech.com>



On 07/23/2016 02:11 AM, Sebastian Gottschall wrote:
> from my point of view this patch is just shit. it trunkates the maximum allocated memory to a certain value.
> so firmware requests 800 kb memory but just gets 256kb. so out of bound memory access is guaranteed at all.

At least some of the firmware logic attempts to deal with this segmentation.  9984 firmware had bugs in one area that I fixed,
but probably there are other bugs and that is why it fails for 9980 firmware.

Even if I fix my firmware, that doesn't help everyone else with stock firmware.

At best, maybe enable this type of logic for only exact firmware with proper feature
flag showing that it is known to work with it.

Thanks,
Ben

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


From egrumbach at gmail.com  Mon Jul 25 00:51:47 2016
From: egrumbach at gmail.com (Emmanuel Grumbach)
Date: Mon, 25 Jul 2016 10:51:47 +0300
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <20160722221929.GN5537@wotan.suse.de>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
 <20160721070938.GA2658@redhat.com>
 <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>
 <20160721080541.GB2658@redhat.com> <5790A28F.8030102@redhat.com>
 <20160721115122.GA31869@redhat.com>
 <a264e995-fc46-7fcd-69f9-80992385b6b1@broadcom.com>
 <20160722102559.GA2662@redhat.com>
 <84a2cfbe-3d58-a5ec-e028-166dce4c9304@broadcom.com>
 <579216D8.2010401@redhat.com> <20160722221929.GN5537@wotan.suse.de>
Message-ID: <CANUX_P2dosQr=B-Sd2+fcgWnrLjdT_ee5j0tt=8A_ns_YJ3Wew@mail.gmail.com>

On Sat, Jul 23, 2016 at 1:19 AM, Luis R. Rodriguez <mcgrof at kernel.org> wrote:
> On Fri, Jul 22, 2016 at 08:51:36AM -0400, Prarit Bhargava wrote:
>> On 07/22/2016 08:21 AM, Arend Van Spriel wrote:
>> >> Another option to solve to problem would be stop requesting not
>> >> available publicly firmware. However, I assume some drivers would
>> >> like to preserve that option.
>> >
>> > Actually, this is not the case with brcmfmac. We do need a firmware
>> > file, ie. brcm/brcmfmac4356-pcie.bin, and also request for a nvram file,
>> > ie. brcm/brcmfmac4356-pcie.txt. The latter is optional and the device
>> > works fine without it.
>> >
>> > What is still unclear to me is when request_firmware_direct() would fail
>> > and in what circumstances the udev helper is a valid callback. Can you
>> > explain such a scenario. Another question I have is what the reasons are
>> > behind the 60 seconds timeout.
>>
>> request_firmware_direct() will fail when the specified FW file is not present.
>> This is different from request_firmware() which implements a usermode helper to
>> potentially download firmware, or unpack a firmware image.
>>
>> Re: 60 second timeout ... The 60 second timeout with request_firmware() is
>> completely arbitrary.  There is no way for udev to signal back to the kernel
>> that userspace helper has not completed its actions, so the kernel has a 60 dead
>> man timer-ish delay.
>
> Lets call it what it was: the 60 second timeout thing was simply a mistake.
> Its no longer 60 seconds anyway, and in fact its accepted a dreaded issue.
> What *we* should be doing is thinking about proper long term architecture now.
> Async probe was one solution to some issues, a new flexible firmware API
> that avoids the usermode helper 100% is another.
>
> Distros stuck with the fallback option should review their strategies,
> either disabling the fallback option, upgrade systemd, or use alternative
> solutions (opensuse has a good one).
>
>> >>>> However I wonder if changing that will not broke the case when
>> >>>> driver is build-in in the kernel and f/w is not yet available when
>> >>>> driver start to initialize. Or maybe nowadays this is not the case
>> >>>> any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w
>> >>>> images are build-in in the kernel or copied to initramfs?
>> >>>
>> >>> That is a nice idea, but I have not seen any change in that area. Could
>> >>> have missed it.
>> >>
>> >> I believe this is how the things are already done, IOW switching to
>> >> request_firmware_direct() in the driver should be no harm.
>> >
>> > Ok. What are the consequences when:
>> > - driver is built-in.
>> > - driver+firmware present on initramfs.
>> > - driver on initramfs, firmware only present on rootfs.
>> > - driver+firmware only on rootfs.
>> >
>> > I assume the third one would be considered a configuration issue.
>>
>> I think your question here can be answered by reading drivers/base/Kconfig:88,
>> and reading about those 4 config options.
>
> No, this documentation is terrible, I've posted some patches to help with this
> mess.
>
>> I could paraphrase it butI think the
>> Kconfig notes are better than I could explain it.  Note that this is how things
>> currently work with request_firmware_nowait().  IIRC request_firmware_nowait()
>> is just an asynchronous version of request_firmware().
>
> ... its a mess.
>

Awesome. I leave the code as is and ignore any RHEL bugs that are
related to that. If someone wants to improve all this, I'd be thankful
if he could do the work in the subsystem as Arend suggested.


From michal.kazior at tieto.com  Mon Jul 25 03:25:02 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 25 Jul 2016 12:25:02 +0200
Subject: ath10k fail to load firmware
In-Reply-To: <A3D794F1192BBF449DF2EC3D7EE263F44A5402F40A@SHAX7MCDC101.APAC.DELL.COM>
References: <20160719070932.GA2751@redhat.com>
 <CA+BoTQn98UFuGT0NntdE1HgG9UmmwzS=JsGkLmeGoMHSFGyDRg@mail.gmail.com>
 <20160719072754.GB2751@redhat.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F0C8@SHAX7MCDC101.APAC.DELL.COM>
 <CA+BoTQn4T+4zMrJEbLBfu92w=mVqWBZZkZaYaW__V2_-VLkCyQ@mail.gmail.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F107@SHAX7MCDC101.APAC.DELL.COM>
 <CA+BoTQk7QKaO2yxMq5JEhrBhn4WtpmWTcOxfiXcvYxrFvaxdgw@mail.gmail.com>
 <20160719092727.GD2751@redhat.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F23C@SHAX7MCDC101.APAC.DELL.COM>
 <CA+BoTQk_R9sv4-wXGLOt-JzP+3PqSHeyMEweGEXAv84HjJPp3Q@mail.gmail.com>
 <A3D794F1192BBF449DF2EC3D7EE263F44A5402F40A@SHAX7MCDC101.APAC.DELL.COM>
Message-ID: <CA+BoTQ=VR7PbYdidJAZQBD2ufXq_wQfesONCJSrEr11Yg78+sw@mail.gmail.com>

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

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


Micha?


From s.gottschall at dd-wrt.com  Mon Jul 25 07:37:29 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Mon, 25 Jul 2016 16:37:29 +0200
Subject: 9984 issues
In-Reply-To: <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
Message-ID: <73ce025f-c583-a747-ee9a-91bbfba56ff4@dd-wrt.com>

Hello

finally i received 9984 devices to follow up with my work on vht160.
but the big issue is. the 9984 works in ap mode with current firmware. 
but in sta mode it crashes after seconds, no matter which operation mode 
is used.
ben's ct firmware crashes in ap and sta mode, so i prefer to run using 
the offical variant. can someone help here?

Sebastian


From greearb at candelatech.com  Mon Jul 25 07:43:56 2016
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 25 Jul 2016 07:43:56 -0700
Subject: 9984 issues
In-Reply-To: <73ce025f-c583-a747-ee9a-91bbfba56ff4@dd-wrt.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <e05dcb58-1cb1-a33a-31bb-b8ba1edf1363@dd-wrt.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
 <73ce025f-c583-a747-ee9a-91bbfba56ff4@dd-wrt.com>
Message-ID: <579625AC.107@candelatech.com>

On 07/25/2016 07:37 AM, Sebastian Gottschall wrote:
> Hello
>
> finally i received 9984 devices to follow up with my work on vht160.
> but the big issue is. the 9984 works in ap mode with current firmware. but in sta mode it crashes after seconds, no matter which operation mode is used.
> ben's ct firmware crashes in ap and sta mode, so i prefer to run using the offical variant. can someone help here?

Does it crash if you connect to an AP with 9980 or 9880?  I am curious if it is only with
9984 AP that crashes.  I have only one 9984 radio right now, but STA mode was working for me against
9980 AP.

I am just getting started on this, so hopefully it will get more stable soon...

And for the QCA firmware, might be worth posting a stack dump from the firmware,
maybe someone there can decode it.  Unfortunately, I could not get a useful decode
from the one you sent me of my firmware...

Thanks,
Ben

>
> Sebastian
>


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



From s.gottschall at dd-wrt.com  Mon Jul 25 08:09:46 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Mon, 25 Jul 2016 17:09:46 +0200
Subject: 9984 issues
In-Reply-To: <579625AC.107@candelatech.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
 <73ce025f-c583-a747-ee9a-91bbfba56ff4@dd-wrt.com>
 <579625AC.107@candelatech.com>
Message-ID: <6234373a-8ad9-1aec-032e-6e07b1510ef4@dd-wrt.com>

Am 25.07.2016 um 16:43 schrieb Ben Greear:
> On 07/25/2016 07:37 AM, Sebastian Gottschall wrote:
>> Hello
>>
>> finally i received 9984 devices to follow up with my work on vht160.
>> but the big issue is. the 9984 works in ap mode with current 
>> firmware. but in sta mode it crashes after seconds, no matter which 
>> operation mode is used.
>> ben's ct firmware crashes in ap and sta mode, so i prefer to run 
>> using the offical variant. can someone help here?
>
> Does it crash if you connect to an AP with 9980 or 9880?  I am curious 
> if it is only with
> 9984 AP that crashes.  I have only one 9984 radio right now, but STA 
> mode was working for me against
> 9980 AP.
>
nope
ct firmware 9984 wdsap -> wdssta 9980 -> ap crash, sta ok
qca firmware 9984 wdsap -> wdssta 9980 -> ap no crash, sta ok
ct firmware 9984 wdsap -> wdssta or sta 9984 -> sta crash , ap crash
qca firmware 9984 wdsap -> wdssta or sta 9984 -> sta crash, ap ok (i 
tested both sta and wdssta)

> I am just getting started on this, so hopefully it will get more 
> stable soon...
>
> And for the QCA firmware, might be worth posting a stack dump from the 
> firmware,
> maybe someone there can decode it.  Unfortunately, I could not get a 
> useful decode
> from the one you sent me of my firmware...
i just sended you yours. seem to be more usefull since you can decode it 
with your tools
>
> Thanks,
> Ben
>
>>
>> Sebastian
>>
>
>


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From adrian at freebsd.org  Mon Jul 25 09:03:24 2016
From: adrian at freebsd.org (Adrian Chadd)
Date: Mon, 25 Jul 2016 09:03:24 -0700
Subject: 9984 issues
In-Reply-To: <6234373a-8ad9-1aec-032e-6e07b1510ef4@dd-wrt.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <fa3eab06-28f0-e5d4-2e92-770134b49dfa@dd-wrt.com>
 <1467218124941.40575@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
 <73ce025f-c583-a747-ee9a-91bbfba56ff4@dd-wrt.com>
 <579625AC.107@candelatech.com>
 <6234373a-8ad9-1aec-032e-6e07b1510ef4@dd-wrt.com>
Message-ID: <CAJ-Vmomr7DSCEA0-i3p=tc=Kh0xCQ-gK20_c7L_=WSTQ4PLRVw@mail.gmail.com>

heh, adding "wdsap" and "wdssta" is a pretty big piece of information,
versus STA/AP.

just saying!



-a


On 25 July 2016 at 08:09, Sebastian Gottschall <s.gottschall at dd-wrt.com> wrote:
> Am 25.07.2016 um 16:43 schrieb Ben Greear:
>>
>> On 07/25/2016 07:37 AM, Sebastian Gottschall wrote:
>>>
>>> Hello
>>>
>>> finally i received 9984 devices to follow up with my work on vht160.
>>> but the big issue is. the 9984 works in ap mode with current firmware.
>>> but in sta mode it crashes after seconds, no matter which operation mode is
>>> used.
>>> ben's ct firmware crashes in ap and sta mode, so i prefer to run using
>>> the offical variant. can someone help here?
>>
>>
>> Does it crash if you connect to an AP with 9980 or 9880?  I am curious if
>> it is only with
>> 9984 AP that crashes.  I have only one 9984 radio right now, but STA mode
>> was working for me against
>> 9980 AP.
>>
> nope
> ct firmware 9984 wdsap -> wdssta 9980 -> ap crash, sta ok
> qca firmware 9984 wdsap -> wdssta 9980 -> ap no crash, sta ok
> ct firmware 9984 wdsap -> wdssta or sta 9984 -> sta crash , ap crash
> qca firmware 9984 wdsap -> wdssta or sta 9984 -> sta crash, ap ok (i tested
> both sta and wdssta)
>
>> I am just getting started on this, so hopefully it will get more stable
>> soon...
>>
>> And for the QCA firmware, might be worth posting a stack dump from the
>> firmware,
>> maybe someone there can decode it.  Unfortunately, I could not get a
>> useful decode
>> from the one you sent me of my firmware...
>
> i just sended you yours. seem to be more usefull since you can decode it
> with your tools
>>
>>
>> Thanks,
>> Ben
>>
>>>
>>> Sebastian
>>>
>>
>>
>
>
> --
> Mit freundlichen Gr?ssen / Regards
>
> Sebastian Gottschall / CTO
>
> NewMedia-NET GmbH - DD-WRT
> Firmensitz:  Berliner Ring 101, 64625 Bensheim
> Registergericht: Amtsgericht Darmstadt, HRB 25473
> Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
> http://www.dd-wrt.com
> email: s.gottschall at dd-wrt.com
> Tel.: +496251-582650 / Fax: +496251-5826565
>
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From s.gottschall at dd-wrt.com  Mon Jul 25 09:31:28 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Mon, 25 Jul 2016 18:31:28 +0200
Subject: 9984 issues
In-Reply-To: <CAJ-Vmomr7DSCEA0-i3p=tc=Kh0xCQ-gK20_c7L_=WSTQ4PLRVw@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
 <73ce025f-c583-a747-ee9a-91bbfba56ff4@dd-wrt.com>
 <579625AC.107@candelatech.com>
 <6234373a-8ad9-1aec-032e-6e07b1510ef4@dd-wrt.com>
 <CAJ-Vmomr7DSCEA0-i3p=tc=Kh0xCQ-gK20_c7L_=WSTQ4PLRVw@mail.gmail.com>
Message-ID: <d5410503-fd51-5076-8236-c296346f5d7f@dd-wrt.com>

Am 25.07.2016 um 18:03 schrieb Adrian Chadd:
> heh, adding "wdsap" and "wdssta" is a pretty big piece of information,
> versus STA/AP.
>
> just saying!
doesnt matter. wdsap/wdssta is just 4addr support. but ap->sta crashes too
>
>
>
> -a
>
>
> On 25 July 2016 at 08:09, Sebastian Gottschall <s.gottschall at dd-wrt.com> wrote:
>> Am 25.07.2016 um 16:43 schrieb Ben Greear:
>>> On 07/25/2016 07:37 AM, Sebastian Gottschall wrote:
>>>> Hello
>>>>
>>>> finally i received 9984 devices to follow up with my work on vht160.
>>>> but the big issue is. the 9984 works in ap mode with current firmware.
>>>> but in sta mode it crashes after seconds, no matter which operation mode is
>>>> used.
>>>> ben's ct firmware crashes in ap and sta mode, so i prefer to run using
>>>> the offical variant. can someone help here?
>>>
>>> Does it crash if you connect to an AP with 9980 or 9880?  I am curious if
>>> it is only with
>>> 9984 AP that crashes.  I have only one 9984 radio right now, but STA mode
>>> was working for me against
>>> 9980 AP.
>>>
>> nope
>> ct firmware 9984 wdsap -> wdssta 9980 -> ap crash, sta ok
>> qca firmware 9984 wdsap -> wdssta 9980 -> ap no crash, sta ok
>> ct firmware 9984 wdsap -> wdssta or sta 9984 -> sta crash , ap crash
>> qca firmware 9984 wdsap -> wdssta or sta 9984 -> sta crash, ap ok (i tested
>> both sta and wdssta)
>>
>>> I am just getting started on this, so hopefully it will get more stable
>>> soon...
>>>
>>> And for the QCA firmware, might be worth posting a stack dump from the
>>> firmware,
>>> maybe someone there can decode it.  Unfortunately, I could not get a
>>> useful decode
>>> from the one you sent me of my firmware...
>> i just sended you yours. seem to be more usefull since you can decode it
>> with your tools
>>>
>>> Thanks,
>>> Ben
>>>
>>>> Sebastian
>>>>
>>>
>>
>> --
>> Mit freundlichen Gr?ssen / Regards
>>
>> Sebastian Gottschall / CTO
>>
>> NewMedia-NET GmbH - DD-WRT
>> Firmensitz:  Berliner Ring 101, 64625 Bensheim
>> Registergericht: Amtsgericht Darmstadt, HRB 25473
>> Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
>> http://www.dd-wrt.com
>> email: s.gottschall at dd-wrt.com
>> Tel.: +496251-582650 / Fax: +496251-5826565
>>
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From adrian at freebsd.org  Mon Jul 25 10:22:03 2016
From: adrian at freebsd.org (Adrian Chadd)
Date: Mon, 25 Jul 2016 10:22:03 -0700
Subject: 9984 issues
In-Reply-To: <d5410503-fd51-5076-8236-c296346f5d7f@dd-wrt.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
 <73ce025f-c583-a747-ee9a-91bbfba56ff4@dd-wrt.com>
 <579625AC.107@candelatech.com>
 <6234373a-8ad9-1aec-032e-6e07b1510ef4@dd-wrt.com>
 <CAJ-Vmomr7DSCEA0-i3p=tc=Kh0xCQ-gK20_c7L_=WSTQ4PLRVw@mail.gmail.com>
 <d5410503-fd51-5076-8236-c296346f5d7f@dd-wrt.com>
Message-ID: <CAJ-VmokA_yNM-n+CsJgy+hVEAKCv8Kbn2EKvrKrUmabXs8=xCw@mail.gmail.com>

Hi,

Yeah, but WDS/4-addr support likely does something different
internally to the firmware.
(I finally hve source to look, fwiw...)


-a


From s.gottschall at dd-wrt.com  Mon Jul 25 18:11:02 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Tue, 26 Jul 2016 03:11:02 +0200
Subject: 9984 issues
In-Reply-To: <CAJ-VmokA_yNM-n+CsJgy+hVEAKCv8Kbn2EKvrKrUmabXs8=xCw@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
 <73ce025f-c583-a747-ee9a-91bbfba56ff4@dd-wrt.com>
 <579625AC.107@candelatech.com>
 <6234373a-8ad9-1aec-032e-6e07b1510ef4@dd-wrt.com>
 <CAJ-Vmomr7DSCEA0-i3p=tc=Kh0xCQ-gK20_c7L_=WSTQ4PLRVw@mail.gmail.com>
 <d5410503-fd51-5076-8236-c296346f5d7f@dd-wrt.com>
 <CAJ-VmokA_yNM-n+CsJgy+hVEAKCv8Kbn2EKvrKrUmabXs8=xCw@mail.gmail.com>
Message-ID: <033c694a-b93e-d5fd-9930-8b69281d8b3d@dd-wrt.com>

Am 25.07.2016 um 19:22 schrieb Adrian Chadd:
> Hi,
>
> Yeah, but WDS/4-addr support likely does something different
> internally to the firmware.
> (I finally hve source to look, fwiw...
ignore it. it does crash in any sta operation mode. STA without WDS too

>
>
> -a
>


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From sdhrtht at outlook.com  Mon Jul 25 18:43:10 2016
From: sdhrtht at outlook.com (sdhrtht)
Date: Tue, 26 Jul 2016 01:43:10 +0000 (UTC)
Subject: Fail to Capture QOS data packets in Monitoring mode -
 =?utf-8?b?UUNBOTg4eOKAj+KAjw==?=
Message-ID: <loom.20160726T034139-557@post.gmane.org>

ath10k monitor failing to capture data packets with WMM enabled on AP.

AP Status: (when no QOS data Packets. MGMT and CTRL Packets are able to 
captured)
1) 0x03 (3) - Secondary channel is below Primary
2) 1 - any Channel width in secondary channel width
3) 1 - Use of RIFS permitted
4) 0x02 - Only HT STAs in the BSS, however there exists at least on 20Mhz 
STA
5) 0 - all Associated HT STAs are greenfield capable

Tested with latest CT and non-CT firmware's.



From rajjoshi at comp.nus.edu.sg  Mon Jul 25 19:07:45 2016
From: rajjoshi at comp.nus.edu.sg (Raj Joshi)
Date: Tue, 26 Jul 2016 10:07:45 +0800
Subject: =?UTF-8?Q?Re=3A_Fail_to_Capture_QOS_data_packets_in_Monitoring_m?=
 =?UTF-8?Q?ode_=2D_QCA988x=E2=80=8F=E2=80=8F?=
In-Reply-To: <loom.20160726T034139-557@post.gmane.org>
References: <loom.20160726T034139-557@post.gmane.org>
Message-ID: <CA+uUJGudfwyqTjzwK2WVbMrd1czVPT4pM1J50ageGtRtBe644A@mail.gmail.com>

Hi,

The following may not necessarily be your case. But since you
mentioned MGMT and CTRL packets are captured and not QoS data packets,
I observed a similar behavior when my configuration was as below:
* Sender: Operating 80Mhz dynamic channel width (secondary channel
either above or below primary channel, doesn't matter)
* Sniffer: Operating on 80MHz width. However, the sniffer's primary
channel doesn't overlap with the sender's primary channel; basically
they have different primary channels.

It is necessary that the primary channels of the sender and the
sniffer match. Otherwise, the sniffer is able to only see the non-HT
duplicate frames sent by the sender. This is because those frames are
sent on all the four 20MHz channels, one of which is your sniffer's
primary channel.

I am not sure if the greenfield configuration could be a culprit here.
But you might want to check the above first :)

Cheers,
Raj Joshi


On Tue, Jul 26, 2016 at 9:43 AM, sdhrtht <sdhrtht at outlook.com> wrote:
> ath10k monitor failing to capture data packets with WMM enabled on AP.
>
> AP Status: (when no QOS data Packets. MGMT and CTRL Packets are able to
> captured)
> 1) 0x03 (3) - Secondary channel is below Primary
> 2) 1 - any Channel width in secondary channel width
> 3) 1 - Use of RIFS permitted
> 4) 0x02 - Only HT STAs in the BSS, however there exists at least on 20Mhz
> STA
> 5) 0 - all Associated HT STAs are greenfield capable
>
> Tested with latest CT and non-CT firmware's.
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From greearb at candelatech.com  Mon Jul 25 19:26:05 2016
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 25 Jul 2016 19:26:05 -0700
Subject: 9984 issues
In-Reply-To: <033c694a-b93e-d5fd-9930-8b69281d8b3d@dd-wrt.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
 <73ce025f-c583-a747-ee9a-91bbfba56ff4@dd-wrt.com>
 <579625AC.107@candelatech.com>
 <6234373a-8ad9-1aec-032e-6e07b1510ef4@dd-wrt.com>
 <CAJ-Vmomr7DSCEA0-i3p=tc=Kh0xCQ-gK20_c7L_=WSTQ4PLRVw@mail.gmail.com>
 <d5410503-fd51-5076-8236-c296346f5d7f@dd-wrt.com>
 <CAJ-VmokA_yNM-n+CsJgy+hVEAKCv8Kbn2EKvrKrUmabXs8=xCw@mail.gmail.com>
 <033c694a-b93e-d5fd-9930-8b69281d8b3d@dd-wrt.com>
Message-ID: <5796CA3D.7010506@candelatech.com>



On 07/25/2016 06:11 PM, Sebastian Gottschall wrote:
> Am 25.07.2016 um 19:22 schrieb Adrian Chadd:
>> Hi,
>>
>> Yeah, but WDS/4-addr support likely does something different
>> internally to the firmware.
>> (I finally hve source to look, fwiw...
> ignore it. it does crash in any sta operation mode. STA without WDS too

Just my firmware, or QCA firmware too?

Thanks,
Ben


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


From s.gottschall at dd-wrt.com  Mon Jul 25 19:40:11 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Tue, 26 Jul 2016 04:40:11 +0200
Subject: 9984 issues
In-Reply-To: <5796CA3D.7010506@candelatech.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
 <73ce025f-c583-a747-ee9a-91bbfba56ff4@dd-wrt.com>
 <579625AC.107@candelatech.com>
 <6234373a-8ad9-1aec-032e-6e07b1510ef4@dd-wrt.com>
 <CAJ-Vmomr7DSCEA0-i3p=tc=Kh0xCQ-gK20_c7L_=WSTQ4PLRVw@mail.gmail.com>
 <d5410503-fd51-5076-8236-c296346f5d7f@dd-wrt.com>
 <CAJ-VmokA_yNM-n+CsJgy+hVEAKCv8Kbn2EKvrKrUmabXs8=xCw@mail.gmail.com>
 <033c694a-b93e-d5fd-9930-8b69281d8b3d@dd-wrt.com>
 <5796CA3D.7010506@candelatech.com>
Message-ID: <a73e7629-323e-95ae-c38d-3fd0564a6d8c@dd-wrt.com>

Am 26.07.2016 um 04:26 schrieb Ben Greear:
>
>
> On 07/25/2016 06:11 PM, Sebastian Gottschall wrote:
>> Am 25.07.2016 um 19:22 schrieb Adrian Chadd:
>>> Hi,
>>>
>>> Yeah, but WDS/4-addr support likely does something different
>>> internally to the firmware.
>>> (I finally hve source to look, fwiw...
>> ignore it. it does crash in any sta operation mode. STA without WDS too
>
> Just my firmware, or QCA firmware too?
yours is crashing in ap and sta mode. qca is only crashing in sta mode.
see my previous list which shows all test scenarios. i wrote this already


----->
ct firmware 9984 wdsap -> wdssta 9980 -> ap crash, sta ok
qca firmware 9984 wdsap -> wdssta 9980 -> ap no crash, sta ok
ct firmware 9984 wdsap -> wdssta or sta 9984 -> sta crash , ap crash
qca firmware 9984 wdsap -> wdssta or sta 9984 -> sta crash, ap ok (i 
tested both sta and wdssta)
>
> Thanks,
> Ben
>
>


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From sdhrtht at outlook.com  Mon Jul 25 20:06:15 2016
From: sdhrtht at outlook.com (sudheer thota)
Date: Tue, 26 Jul 2016 08:36:15 +0530
Subject: Not able to capture qos data packets - QCA988x
In-Reply-To: <BAY176-W27264163A549F6C69777EFB60D0@phx.gbl>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>,
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>,
 <1468941948774.87860@qti.qualcomm.com>,
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>,
 <578E5AFA.4000908@candelatech.com>,
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>,
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>,
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>,
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>,
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>,
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>,
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>,
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>,
 <73ce025f-c583-a747-ee9a-91bbfba56ff4@dd-wrt.com>,
 <579625AC.107@candelatech.com>,
 <6234373a-8ad9-1aec-032e-6e07b1510ef4@dd-wrt.com>,
 <CAJ-Vmomr7DSCEA0-i3p=tc=Kh0xCQ-gK20_c7L_=WSTQ4PLRVw@mail.gmail.com>,
 <d5410503-fd51-5076-82
 ,36-c296346f5d7f@dd-wrt.com>,<BAY176-W27264163A549F6C69777EFB60D0@phx.gbl>
Message-ID: <BAY176-W46EDDEDEC0C0573E68A47DB90E0@phx.gbl>

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

 		 	   		  

From sdhrtht at outlook.com  Mon Jul 25 20:12:21 2016
From: sdhrtht at outlook.com (sudheer thota)
Date: Tue, 26 Jul 2016 08:42:21 +0530
Subject: =?windows-1256?Q?RE:_Fail_t?= =?windows-1256?Q?o_Capture_?=
 =?windows-1256?Q?QOS_data_p?= =?windows-1256?Q?ackets_in_?=
 =?windows-1256?Q?Monitoring?= =?windows-1256?Q?_mode_-_QC?=
 =?windows-1256?Q?A988x=FE=FE?=
In-Reply-To: <CA+uUJGudfwyqTjzwK2WVbMrd1czVPT4pM1J50ageGtRtBe644A@mail.gmail.com>
References: <loom.20160726T034139-557@post.gmane.org>,
 <CA+uUJGudfwyqTjzwK2WVbMrd1czVPT4pM1J50ageGtRtBe644A@mail.gmail.com>
Message-ID: <BAY176-W477486EE1F43BB0A6F3969B90E0@phx.gbl>

Went through same path and verified with COMMVIEW on primary and secondary channels.?

on the other hand, surprisingly Qos packets appears when there another devices associates with ?AP and disappears when it disconnects. only greenfield mode is disabled during the transition when second STA association happens. ?

----------------------------------------
> From: rajjoshi at comp.nus.edu.sg
> Date: Tue, 26 Jul 2016 10:07:45 +0800
> Subject: Re: Fail to Capture QOS data packets in Monitoring mode - QCA988x??
> To: sdhrtht at outlook.com
> CC: ath10k at lists.infradead.org
>
> Hi,
>
> The following may not necessarily be your case. But since you
> mentioned MGMT and CTRL packets are captured and not QoS data packets,
> I observed a similar behavior when my configuration was as below:
> * Sender: Operating 80Mhz dynamic channel width (secondary channel
> either above or below primary channel, doesn't matter)
> * Sniffer: Operating on 80MHz width. However, the sniffer's primary
> channel doesn't overlap with the sender's primary channel; basically
> they have different primary channels.
>
> It is necessary that the primary channels of the sender and the
> sniffer match. Otherwise, the sniffer is able to only see the non-HT
> duplicate frames sent by the sender. This is because those frames are
> sent on all the four 20MHz channels, one of which is your sniffer's
> primary channel.
>
> I am not sure if the greenfield configuration could be a culprit here.
> But you might want to check the above first :)
>
> Cheers,
> Raj Joshi
>
>
> On Tue, Jul 26, 2016 at 9:43 AM, sdhrtht <sdhrtht at outlook.com> wrote:
>> ath10k monitor failing to capture data packets with WMM enabled on AP.
>>
>> AP Status: (when no QOS data Packets. MGMT and CTRL Packets are able to
>> captured)
>> 1) 0x03 (3) - Secondary channel is below Primary
>> 2) 1 - any Channel width in secondary channel width
>> 3) 1 - Use of RIFS permitted
>> 4) 0x02 - Only HT STAs in the BSS, however there exists at least on 20Mhz
>> STA
>> 5) 0 - all Associated HT STAs are greenfield capable
>>
>> Tested with latest CT and non-CT firmware's.
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
 		 	   		  

From michal.kazior at tieto.com  Mon Jul 25 23:21:41 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 26 Jul 2016 08:21:41 +0200
Subject: Not able to capture qos data packets - QCA988x
In-Reply-To: <BAY176-W46EDDEDEC0C0573E68A47DB90E0@phx.gbl>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>
 <1468941948774.87860@qti.qualcomm.com>
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>
 <578E5AFA.4000908@candelatech.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
 <73ce025f-c583-a747-ee9a-91bbfba56ff4@dd-wrt.com>
 <579625AC.107@candelatech.com>
 <6234373a-8ad9-1aec-032e-6e07b1510ef4@dd-wrt.com>
 <CAJ-Vmomr7DSCEA0-i3p=tc=Kh0xCQ-gK20_c7L_=WSTQ4PLRVw@mail.gmail.com>
 <BAY176-W27264163A549F6C69777EFB60D0@phx.gbl>
 <BAY176-W46EDDEDEC0C0573E68A47DB90E0@phx.gbl>
Message-ID: <CA+BoTQktJXJ+_oODypMfo7fhuA4+RSo1A5DoOYvWGBN=5HB9eQ@mail.gmail.com>

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

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

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


Micha?


From s.gottschall at dd-wrt.com  Tue Jul 26 02:31:41 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Tue, 26 Jul 2016 11:31:41 +0200
Subject: 9984 issues solution
In-Reply-To: <5796CA3D.7010506@candelatech.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
 <73ce025f-c583-a747-ee9a-91bbfba56ff4@dd-wrt.com>
 <579625AC.107@candelatech.com>
 <6234373a-8ad9-1aec-032e-6e07b1510ef4@dd-wrt.com>
 <CAJ-Vmomr7DSCEA0-i3p=tc=Kh0xCQ-gK20_c7L_=WSTQ4PLRVw@mail.gmail.com>
 <d5410503-fd51-5076-8236-c296346f5d7f@dd-wrt.com>
 <CAJ-VmokA_yNM-n+CsJgy+hVEAKCv8Kbn2EKvrKrUmabXs8=xCw@mail.gmail.com>
 <033c694a-b93e-d5fd-9930-8b69281d8b3d@dd-wrt.com>
 <5796CA3D.7010506@candelatech.com>
Message-ID: <fdb58430-e1a0-48e5-feb0-618d7bb77179@dd-wrt.com>

i found the reason and the solution. i disabled all beamforming vht 
caps. this will prevent the firmware of beeing crashing.
so it seems, beamforming is responsible for it
could the firmware be fixed?

Sebastian



Am 26.07.2016 um 04:26 schrieb Ben Greear:
>
>
> On 07/25/2016 06:11 PM, Sebastian Gottschall wrote:
>> Am 25.07.2016 um 19:22 schrieb Adrian Chadd:
>>> Hi,
>>>
>>> Yeah, but WDS/4-addr support likely does something different
>>> internally to the firmware.
>>> (I finally hve source to look, fwiw...
>> ignore it. it does crash in any sta operation mode. STA without WDS too
>
> Just my firmware, or QCA firmware too?
>
> Thanks,
> Ben
>
>


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From michal.kazior at tieto.com  Tue Jul 26 03:27:40 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 26 Jul 2016 12:27:40 +0200
Subject: 9984 issues solution
In-Reply-To: <fdb58430-e1a0-48e5-feb0-618d7bb77179@dd-wrt.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>
 <73ce025f-c583-a747-ee9a-91bbfba56ff4@dd-wrt.com>
 <579625AC.107@candelatech.com>
 <6234373a-8ad9-1aec-032e-6e07b1510ef4@dd-wrt.com>
 <CAJ-Vmomr7DSCEA0-i3p=tc=Kh0xCQ-gK20_c7L_=WSTQ4PLRVw@mail.gmail.com>
 <d5410503-fd51-5076-8236-c296346f5d7f@dd-wrt.com>
 <CAJ-VmokA_yNM-n+CsJgy+hVEAKCv8Kbn2EKvrKrUmabXs8=xCw@mail.gmail.com>
 <033c694a-b93e-d5fd-9930-8b69281d8b3d@dd-wrt.com>
 <5796CA3D.7010506@candelatech.com>
 <fdb58430-e1a0-48e5-feb0-618d7bb77179@dd-wrt.com>
Message-ID: <CA+BoTQks2S+LM6izSxQ9mdCgt3DdMYY=o=+wwA7z4A0+vaN+kQ@mail.gmail.com>

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

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

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


Micha?


From sdhrtht at outlook.com  Tue Jul 26 04:53:29 2016
From: sdhrtht at outlook.com (sudheer thota)
Date: Tue, 26 Jul 2016 17:23:29 +0530
Subject: Not able to capture qos data packets - QCA988x
In-Reply-To: <CA+BoTQktJXJ+_oODypMfo7fhuA4+RSo1A5DoOYvWGBN=5HB9eQ@mail.gmail.com>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>,
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>,
 <1468941948774.87860@qti.qualcomm.com>,
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>,
 <578E5AFA.4000908@candelatech.com>,
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>,
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>,
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>,
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>,
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>,
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>,
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>,
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>,
 <73ce025f-c583-a747-ee9a-91bbfba56ff4@dd-wrt.com>,
 <579625AC.107@candelatech.com>,
 <6234373a-8ad9-1aec-032e-6e07b1510ef4@dd-wrt.com>,
 <CAJ-Vmomr7DSCEA0-i3p=tc=Kh0xCQ-gK20_c7L_=WSTQ4PLRVw@mail.gmail.com>,
 <BAY176-W27264163A549F
 6C69777EFB60D0@phx.gbl>, <BAY176-W46EDDEDEC0C0573E68A47DB90E0@phx.gbl>,
 <CA+BoTQktJXJ+_oODypMfo7fhuA4+RSo1A5DoOYvWGBN=5HB9eQ@mail.gmail.com>
Message-ID: <BAY176-W43827D0BC3AF9D12C5E82DB90E0@phx.gbl>

ath10k is a standalone sniffer configured to monitor data transfer rates between AP and STA. its not the AP.

details of the configuration:
AP: Netgear WNDR3400V3 : WMM enabled, Ch 153, upto 300mbps.
STA1: Roku Streaming Stick: only 20MHz Capable - LGI (verified from data-rates and MCS index)

Monitor: Ath10k

Seems to be combination of RIFS (enabled), Operating mode (0x02) and Greenfield Capable, causing the issues to miss QOS data packet.

Confirmed from connecting different devices(STA2 - Samsung Tablet) which turns into??RIFS (enabled), Operating mode (0x03) and Greenfield not Capable.


----------------------------------------
> From: michal.kazior at tieto.com
> Date: Tue, 26 Jul 2016 08:21:41 +0200
> Subject: Re: Not able to capture qos data packets - QCA988x
> To: sdhrtht at outlook.com
> CC: ath10k at lists.infradead.org
>
> On 26 July 2016 at 05:06, sudheer thota <sdhrtht at outlook.com> wrote:
>> wireless interface(ath10k) monitor failing to capture data packets when
>> WMM enabled on AP.
>>
>> AP Status reflects in following state: (when no QOS data Packets. MGMT and CTRL Packets are able to captured)
>> 1) 0x03 (3) - Secondary channel is below Primary
>> 2) 1 - any Channel width in secondary channel width
>> 3) 1 - Use of RIFS permitted
>> 4) 0x02 - Only HT STAs in the BSS, however there exists at least on 20Mhz STA
>> 5) 0 - all Associated HT STAs are greenfield capable
>
> You didn't really explain your topology. Are you using ath10k to sniff
> only or to run AP *and* sniff at the same time?
>
> FWIW It's kind of a problem to sniff your own transmission with QoS
> because of NWifi vs 802.11 headers problem so regular packet
> dissection won't recognize them properly.
>
>
> Micha?
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
 		 	   		  

From arnagara at qti.qualcomm.com  Tue Jul 26 09:45:52 2016
From: arnagara at qti.qualcomm.com (Ashok Raj Nagarajan)
Date: Tue, 26 Jul 2016 22:15:52 +0530
Subject: [PATCH] ath10k: fix get rx_status from htt context
Message-ID: <1469551552-845-1-git-send-email-arnagara@qti.qualcomm.com>

On handling amsdu on rx path, get the rx_status from htt context. Without this
fix, we are seeing warnings when running DBDC traffic like this.

WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:4105 ieee80211_rx_napi+0x88/0x7d8 [mac80211]()

[ 1715.878248] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.18.21 #1
[ 1715.878273] [<c001d3f4>] (unwind_backtrace) from [<c001a4b0>] (show_stack+0x10/0x14)
[ 1715.878293] [<c001a4b0>] (show_stack) from [<c01bee64>] (dump_stack+0x70/0xbc)
[ 1715.878315] [<c01bee64>] (dump_stack) from [<c002a61c>] (warn_slowpath_common+0x64/0x88)
[ 1715.878339] [<c002a61c>] (warn_slowpath_common) from [<c002a6d0>] (warn_slowpath_null+0x18/0x20)
[ 1715.878395] [<c002a6d0>] (warn_slowpath_null) from [<bf4caa98>] (ieee80211_rx_napi+0x88/0x7d8 [mac80211])
[ 1715.878474] [<bf4caa98>] (ieee80211_rx_napi [mac80211]) from [<bf568658>] (ath10k_htt_t2h_msg_handler+0xb48/0xbfc [ath10k_core])
[ 1715.878535] [<bf568658>] (ath10k_htt_t2h_msg_handler [ath10k_core]) from [<bf568708>] (ath10k_htt_t2h_msg_handler+0xbf8/0xbfc [ath10k_core])
[ 1715.878597] [<bf568708>] (ath10k_htt_t2h_msg_handler [ath10k_core]) from [<bf569160>] (ath10k_htt_txrx_compl_task+0xa54/0x1170 [ath10k_core])
[ 1715.878639] [<bf569160>] (ath10k_htt_txrx_compl_task [ath10k_core]) from [<c002db14>] (tasklet_action+0xb4/0x130)
[ 1715.878659] [<c002db14>] (tasklet_action) from [<c002d110>] (__do_softirq+0xe0/0x210)
[ 1715.878678] [<c002d110>] (__do_softirq) from [<c002d4b4>] (irq_exit+0x84/0xe0)
[ 1715.878700] [<c002d4b4>] (irq_exit) from [<c005a544>] (__handle_domain_irq+0x98/0xd0)
[ 1715.878722] [<c005a544>] (__handle_domain_irq) from [<c00085f4>] (gic_handle_irq+0x38/0x5c)
[ 1715.878741] [<c00085f4>] (gic_handle_irq) from [<c0009680>] (__irq_svc+0x40/0x74)
[ 1715.878753] Exception stack(0xc05f9f50 to 0xc05f9f98)
[ 1715.878767] 9f40: ffffffed 00000000 00399e1e c000a220
[ 1715.878786] 9f60: 00000000 c05f6780 c05f8000 00000000 c05f5db8 ffffffed c05f8000 c04d1980
[ 1715.878802] 9f80: 00000000 c05f9f98 c0018110 c0018114 60000013 ffffffff
[ 1715.878822] [<c0009680>] (__irq_svc) from [<c0018114>] (arch_cpu_idle+0x2c/0x50)
[ 1715.878844] [<c0018114>] (arch_cpu_idle) from [<c00530d4>] (cpu_startup_entry+0x108/0x234)
[ 1715.878866] [<c00530d4>] (cpu_startup_entry) from [<c05c7be0>] (start_kernel+0x33c/0x3b8)
[ 1715.878879] ---[ end trace 6d5e1cc0fef8ed6a ]---
[ 1715.878899] ------------[ cut here ]------------

Fixes: 18235664e7f9 ("ath10k: cleanup amsdu processing for rx indication")
Signed-off-by: Ashok Raj Nagarajan <arnagara at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 78db5d6..24c8d65 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1525,7 +1525,7 @@ static void ath10k_htt_rx_h_filter(struct ath10k *ar,
 static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
 {
 	struct ath10k *ar = htt->ar;
-	static struct ieee80211_rx_status rx_status;
+	struct ieee80211_rx_status *rx_status = &htt->rx_status;
 	struct sk_buff_head amsdu;
 	int ret;
 
@@ -1549,11 +1549,11 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
 		return ret;
 	}
 
-	ath10k_htt_rx_h_ppdu(ar, &amsdu, &rx_status, 0xffff);
+	ath10k_htt_rx_h_ppdu(ar, &amsdu, rx_status, 0xffff);
 	ath10k_htt_rx_h_unchain(ar, &amsdu, ret > 0);
-	ath10k_htt_rx_h_filter(ar, &amsdu, &rx_status);
-	ath10k_htt_rx_h_mpdu(ar, &amsdu, &rx_status);
-	ath10k_htt_rx_h_deliver(ar, &amsdu, &rx_status);
+	ath10k_htt_rx_h_filter(ar, &amsdu, rx_status);
+	ath10k_htt_rx_h_mpdu(ar, &amsdu, rx_status);
+	ath10k_htt_rx_h_deliver(ar, &amsdu, rx_status);
 
 	return 0;
 }
-- 
1.9.1



From pvutov at solectek.com  Tue Jul 26 19:06:50 2016
From: pvutov at solectek.com (Petar Vutov)
Date: Tue, 26 Jul 2016 19:06:50 -0700
Subject: Coverage class on ath10k
In-Reply-To: <mailman.34731.1463383905.1639.ath10k@lists.infradead.org>
References: <mailman.34731.1463383905.1639.ath10k@lists.infradead.org>
Message-ID: <5798173A.50001@solectek.com>

Hi All,

Does anyone know how I can modify coverage class for ath10k?

It looks like that command  'iw phy0 set distance <meters>' doesn't get 
to the firmware on QCA98XX due to missing function set_coverage_class.

Is there any other way to manipulate ack timeout and slot time on the 
firmware?

Thanks,

Petar Vutov
Director of Software Engineering
Solectek Corp.
8969 Kenamar Drive, Suite 113
San Diego, CA 92121
1-858-450-1220 Ext 3008
www.solectek.com




From sdhrtht at outlook.com  Tue Jul 26 23:51:56 2016
From: sdhrtht at outlook.com (sudheer thota)
Date: Wed, 27 Jul 2016 12:21:56 +0530
Subject: RIFS packets missing on ath10k monitor
In-Reply-To: <BAY176-W426C633D2FC24792734487B90F0@phx.gbl>
References: <20160614061728.570-1-rmanohar@qti.qualcomm.com>,
 <CA+BoTQkepLz55Vdr7OuMnPQPLKq_+vjZi=m2Y9rHLRgBZPsWOw@mail.gmail.com>,
 <1468941948774.87860@qti.qualcomm.com>,
 <CAJ-Vmon1duBNcWhjaNdANYFfd3hwQUYYHrmx7LRZvT-Ec2x1Cg@mail.gmail.com>,
 <578E5AFA.4000908@candelatech.com>,
 <CA+BoTQ=QMPUtY64ELCToZLcSrCPQdG=2Eg4FrsULeeDg9sFPYA@mail.gmail.com>,
 <CAJ-Vmok95tiLzmnfiBnnOLQK9hXW2DfjPPVGy9yqucq32PBwJw@mail.gmail.com>,
 <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>,
 <CAJ-Vmo=d=PgUu_AYT1C82AJcnUxKUo_VYMn_b1QF8M_T+5KpkA@mail.gmail.com>,
 <CA+BoTQnN1EVGBu0J5Y7-z2=uqsG8rXS0Lvs7VAoeawv9MGuFyQ@mail.gmail.com>,
 <b1cdb5c3-6ddb-8a69-d0f7-79d8e6ba23d0@dd-wrt.com>,
 <CA+BoTQmrk_U8oVXxk-5hBz60=R-xR4H=2_x2pj9BVDYXPOoCGg@mail.gmail.com>,
 <6487f1d3-339e-a6dd-d866-b11b37b4ddff@dd-wrt.com>,
 <73ce025f-c583-a747-ee9a-91bbfba56ff4@dd-wrt.com>,
 <579625AC.107@candelatech.com>,
 <6234373a-8ad9-1aec-032e-6e07b1510ef4@dd-wrt.com>,
 <CAJ-Vmomr7DSCEA0-i3p=tc=Kh0xCQ-gK20_c7L_=WSTQ4PLRVw@mail.gmail.com>,
 <BAY176-W27264163A549F
 , , 6C69777EFB60D0@phx.gbl>, <BAY176-W46EDDEDEC0C0573E68A47DB90E0@phx.gbl>,
 <CA+BoTQktJXJ+_oODypMfo7fhuA4+RSo1A5DoOYvWGBN=5HB9eQ@mail.gmail.com>,
 <BAY176-W43827D0BC3AF9D12C5E82DB90E0@phx.gbl>,
 <BAY176-W426C633D2FC24792734487B90F0@phx.gbl>
Message-ID: <BAY176-W4727918833A034C84E740DB90F0@phx.gbl>

Came across a scenario where ath10k monitor fails to capture QOS data?packets (N900 router and Roku).?

observed these packets are with "RIFS?permitted" flag set along with "Greenfield mode enabled".?

as the RIFS?is obsolete in AC specification, Is it possible for ath10k driver to?capture N packets with RIFS? or?

is it possible to enable this mode?through command line on ath10k driver to capture these packets.? 		 	   		  

From benjamin at sipsolutions.net  Wed Jul 27 01:33:44 2016
From: benjamin at sipsolutions.net (Benjamin Berg)
Date: Wed, 27 Jul 2016 10:33:44 +0200
Subject: [PATCH] ath10k: Allow setting coverage class
Message-ID: <1469608424-11370-1-git-send-email-benjamin@sipsolutions.net>

Unfortunately ath10k does not generally allow modifying the coverage class
with the stock firmware and Qualcomm has so far refused to implement this
feature so that it can be properly supported in ath10k. If we however know
the registers that need to be modified for proper operation with a higher
coverage class, then we can do these modifications from the driver.

This patch implements this hack for first generation cards which are based
on a core that is similar to ath9k. The registers are modified in place and
need to be re-written every time the firmware sets them. To achieve this
the register status is verified after any event from the firmware.

The coverage class may not be modified temporarily right after the card
re-initializes the registers. This is for example the case during scanning.

A warning will be generated if the hack is not supported on the card or
unexpected values are hit. There is no error reporting for userspace
applications though (this is a limitation in the mac80211 driver
interface).

Thanks to Sebastian Gottschall <s.gottschall at dd-wrt.com> for initially
working on a userspace support for this. This patch wouldn't have been
possible without this documentation.

Signed-off-by: Benjamin Berg <benjamin at sipsolutions.net>
Signed-off-by: Simon Wunderlich <sw at simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer at fit.fraunhofer.de>
---
 drivers/net/wireless/ath/ath10k/core.h    |  10 ++
 drivers/net/wireless/ath/ath10k/hw.c      |   9 ++
 drivers/net/wireless/ath/ath10k/hw.h      |  28 +++++-
 drivers/net/wireless/ath/ath10k/mac.c     |  10 ++
 drivers/net/wireless/ath/ath10k/wmi-ops.h |  17 ++++
 drivers/net/wireless/ath/ath10k/wmi.c     | 151 ++++++++++++++++++++++++++++++
 6 files changed, 224 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 9374bcd..781219b 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -935,6 +935,16 @@ struct ath10k {
 	struct ath10k_thermal thermal;
 	struct ath10k_wow wow;
 
+	/* protected by data_lock */
+	struct {
+		s16 coverage_class;
+
+		u32 reg_slottime_conf;
+		u32 reg_slottime_orig;
+		u32 reg_ack_cts_timeout_conf;
+		u32 reg_ack_cts_timeout_orig;
+	} fw_coverage;
+
 	/* must be last */
 	u8 drv_priv[0] __aligned(sizeof(void *));
 };
diff --git a/drivers/net/wireless/ath/ath10k/hw.c b/drivers/net/wireless/ath/ath10k/hw.c
index f903d46..82249be 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -22,6 +22,7 @@ const struct ath10k_hw_regs qca988x_regs = {
 	.rtc_soc_base_address		= 0x00004000,
 	.rtc_wmac_base_address		= 0x00005000,
 	.soc_core_base_address		= 0x00009000,
+	.wlan_mac_base_address		= 0x00020000,
 	.ce_wrapper_base_address	= 0x00057000,
 	.ce0_base_address		= 0x00057400,
 	.ce1_base_address		= 0x00057800,
@@ -48,6 +49,7 @@ const struct ath10k_hw_regs qca6174_regs = {
 	.rtc_soc_base_address			= 0x00000800,
 	.rtc_wmac_base_address			= 0x00001000,
 	.soc_core_base_address			= 0x0003a000,
+	.wlan_mac_base_address			= 0x00020000,
 	.ce_wrapper_base_address		= 0x00034000,
 	.ce0_base_address			= 0x00034400,
 	.ce1_base_address			= 0x00034800,
@@ -74,6 +76,7 @@ const struct ath10k_hw_regs qca99x0_regs = {
 	.rtc_soc_base_address			= 0x00080000,
 	.rtc_wmac_base_address			= 0x00000000,
 	.soc_core_base_address			= 0x00082000,
+	.wlan_mac_base_address			= 0x00030000,
 	.ce_wrapper_base_address		= 0x0004d000,
 	.ce0_base_address			= 0x0004a000,
 	.ce1_base_address			= 0x0004a400,
@@ -109,6 +112,7 @@ const struct ath10k_hw_regs qca99x0_regs = {
 const struct ath10k_hw_regs qca4019_regs = {
 	.rtc_soc_base_address                   = 0x00080000,
 	.soc_core_base_address                  = 0x00082000,
+	.wlan_mac_base_address                  = 0x00030000,
 	.ce_wrapper_base_address                = 0x0004d000,
 	.ce0_base_address                       = 0x0004a000,
 	.ce1_base_address                       = 0x0004a400,
@@ -139,6 +143,7 @@ const struct ath10k_hw_regs qca4019_regs = {
 };
 
 const struct ath10k_hw_values qca988x_values = {
+	.mac_core_rev			= ATH10K_HW_MAC_CORE_ATH9K,
 	.rtc_state_val_on		= 3,
 	.ce_count			= 8,
 	.msi_assign_ce_max		= 7,
@@ -148,6 +153,7 @@ const struct ath10k_hw_values qca988x_values = {
 };
 
 const struct ath10k_hw_values qca6174_values = {
+	.mac_core_rev			= ATH10K_HW_MAC_CORE_ATH9K,
 	.rtc_state_val_on		= 3,
 	.ce_count			= 8,
 	.msi_assign_ce_max		= 7,
@@ -157,6 +163,7 @@ const struct ath10k_hw_values qca6174_values = {
 };
 
 const struct ath10k_hw_values qca99x0_values = {
+	.mac_core_rev			= ATH10K_HW_MAC_CORE_WAVE2,
 	.rtc_state_val_on		= 5,
 	.ce_count			= 12,
 	.msi_assign_ce_max		= 12,
@@ -166,6 +173,7 @@ const struct ath10k_hw_values qca99x0_values = {
 };
 
 const struct ath10k_hw_values qca9888_values = {
+	.mac_core_rev			= ATH10K_HW_MAC_CORE_WAVE2,
 	.rtc_state_val_on		= 3,
 	.ce_count			= 12,
 	.msi_assign_ce_max		= 12,
@@ -175,6 +183,7 @@ const struct ath10k_hw_values qca9888_values = {
 };
 
 const struct ath10k_hw_values qca4019_values = {
+	.mac_core_rev                   = ATH10K_HW_MAC_CORE_WAVE2,
 	.ce_count                       = 12,
 	.num_target_ce_config_wlan      = 10,
 	.ce_desc_meta_data_mask         = 0xFFF0,
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index e014cd7..4151326 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -230,6 +230,7 @@ struct ath10k_hw_regs {
 	u32 rtc_soc_base_address;
 	u32 rtc_wmac_base_address;
 	u32 soc_core_base_address;
+	u32 wlan_mac_base_address;
 	u32 ce_wrapper_base_address;
 	u32 ce0_base_address;
 	u32 ce1_base_address;
@@ -257,6 +258,12 @@ extern const struct ath10k_hw_regs qca6174_regs;
 extern const struct ath10k_hw_regs qca99x0_regs;
 extern const struct ath10k_hw_regs qca4019_regs;
 
+enum ath10k_hw_mac_core_rev {
+	ATH10K_HW_MAC_CORE_UNKNOWN = 0,
+	ATH10K_HW_MAC_CORE_ATH9K,
+	ATH10K_HW_MAC_CORE_WAVE2,
+};
+
 struct ath10k_hw_values {
 	u32 rtc_state_val_on;
 	u8 ce_count;
@@ -264,6 +271,7 @@ struct ath10k_hw_values {
 	u8 num_target_ce_config_wlan;
 	u16 ce_desc_meta_data_mask;
 	u8 ce_desc_meta_data_lsb;
+	enum ath10k_hw_mac_core_rev mac_core_rev;
 };
 
 extern const struct ath10k_hw_values qca988x_values;
@@ -545,7 +553,7 @@ enum ath10k_hw_cc_wraparound_type {
 #define WLAN_SI_BASE_ADDRESS			0x00010000
 #define WLAN_GPIO_BASE_ADDRESS			0x00014000
 #define WLAN_ANALOG_INTF_BASE_ADDRESS		0x0001c000
-#define WLAN_MAC_BASE_ADDRESS			0x00020000
+#define WLAN_MAC_BASE_ADDRESS			ar->regs->wlan_mac_base_address
 #define EFUSE_BASE_ADDRESS			0x00030000
 #define FPGA_REG_BASE_ADDRESS			0x00039000
 #define WLAN_UART2_BASE_ADDRESS			0x00054c00
@@ -745,4 +753,22 @@ enum ath10k_hw_cc_wraparound_type {
 
 #define RTC_STATE_V_GET(x) (((x) & RTC_STATE_V_MASK) >> RTC_STATE_V_LSB)
 
+/* Register definitions for ath10k cards that include a MAC which is based
+ * on ATH9k. This ath9k based MAC still has the same or at least similar
+ * registers.
+ * These registers are usually managed by the ath10k firmware. However by
+ * overriding them it is possible to support a few additional features; in this
+ * case setting the coverage class.
+ */
+#define ATH9K_MAC_TIME_OUT		0x8014
+#define ATH9K_MAC_TIME_OUT_MAX		0x00003FFF
+#define ATH9K_MAC_TIME_OUT_ACK		0x00003FFF
+#define ATH9K_MAC_TIME_OUT_ACK_S	0
+#define ATH9K_MAC_TIME_OUT_CTS		0x3FFF0000
+#define ATH9K_MAC_TIME_OUT_CTS_S	16
+
+#define ATH9K_MAC_IFS_SLOT		0x1070
+#define ATH9K_MAC_IFS_SLOT_M		0x0000FFFF
+#define ATH9K_MAC_IFS_SLOT_RESV0	0xFFFF0000
+
 #endif /* _HW_H_ */
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 55c823f..a9b587e 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5372,6 +5372,15 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw,
 	mutex_unlock(&ar->conf_mutex);
 }
 
+static void ath10k_set_coverage_class(struct ieee80211_hw *hw,
+				      s16 value)
+{
+	struct ath10k *ar = hw->priv;
+
+	if (ath10k_wmi_pdev_set_coverage_class(ar, value) == -EOPNOTSUPP)
+		ath10k_warn(ar, "Modification of coverage class is not supported!\n");
+}
+
 static int ath10k_hw_scan(struct ieee80211_hw *hw,
 			  struct ieee80211_vif *vif,
 			  struct ieee80211_scan_request *hw_req)
@@ -7397,6 +7406,7 @@ static const struct ieee80211_ops ath10k_ops = {
 	.remove_interface		= ath10k_remove_interface,
 	.configure_filter		= ath10k_configure_filter,
 	.bss_info_changed		= ath10k_bss_info_changed,
+	.set_coverage_class		= ath10k_set_coverage_class,
 	.hw_scan			= ath10k_hw_scan,
 	.cancel_hw_scan			= ath10k_cancel_hw_scan,
 	.set_key			= ath10k_set_key,
diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index 64ebd30..3ebc57e 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -52,6 +52,8 @@ struct wmi_ops {
 	int (*pull_wow_event)(struct ath10k *ar, struct sk_buff *skb,
 			      struct wmi_wow_ev_arg *arg);
 	enum wmi_txbf_conf (*get_txbf_conf_scheme)(struct ath10k *ar);
+	void (*set_pdev_coverage_class)(struct ath10k *ar,
+					s16 value);
 
 	struct sk_buff *(*gen_pdev_suspend)(struct ath10k *ar, u32 suspend_opt);
 	struct sk_buff *(*gen_pdev_resume)(struct ath10k *ar);
@@ -1012,6 +1014,21 @@ ath10k_wmi_pdev_get_temperature(struct ath10k *ar)
 }
 
 static inline int
+ath10k_wmi_pdev_set_coverage_class(struct ath10k *ar,
+				   s16 value)
+{
+	if (!ar->wmi.ops->set_pdev_coverage_class)
+		return -EOPNOTSUPP;
+
+	if (value < 0)
+		value = 0;
+
+	ar->wmi.ops->set_pdev_coverage_class(ar, value);
+
+	return 0;
+}
+
+static inline int
 ath10k_wmi_addba_clear_resp(struct ath10k *ar, u32 vdev_id, const u8 *mac)
 {
 	struct sk_buff *skb;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 169cd2e7..7f30e70 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -28,6 +28,7 @@
 #include "wmi-ops.h"
 #include "p2p.h"
 #include "hw.h"
+#include "hif.h"
 
 /* MAIN WMI cmd track */
 static struct wmi_cmd_map wmi_cmd_map = {
@@ -3096,6 +3097,121 @@ ath10k_wmi_op_pull_peer_kick_ev(struct ath10k *ar, struct sk_buff *skb,
 	return 0;
 }
 
+static void
+ath10k_ath9k_set_pdev_coverage_class(struct ath10k *ar, s16 value)
+{
+	u32 slottime_reg;
+	u32 slottime;
+	u32 timeout_reg;
+	u32 timeout;
+	u32 counters_freq_mhz = ar->hw_params.channel_counters_freq_hz / 1000;
+
+	/* The firmware does not support setting the coverage class. Instead
+	 * this function monitors and modifies the corresponding MAC registers.
+	 */
+
+	spin_lock_bh(&ar->data_lock);
+
+	/* Retrieve the current values of the two registers that need to be
+	 * adjusted.
+	 */
+	slottime_reg = ath10k_hif_read32(ar, WLAN_MAC_BASE_ADDRESS +
+					     ATH9K_MAC_IFS_SLOT);
+	timeout_reg = ath10k_hif_read32(ar, WLAN_MAC_BASE_ADDRESS +
+					    ATH9K_MAC_TIME_OUT);
+
+	if (value < 0)
+		value = ar->fw_coverage.coverage_class;
+
+	/* Break out if the coverage class and registers have the expected
+	 * value.
+	 */
+	if (value == ar->fw_coverage.coverage_class &&
+	    slottime_reg == ar->fw_coverage.reg_slottime_conf &&
+	    timeout_reg == ar->fw_coverage.reg_ack_cts_timeout_conf)
+		goto unlock;
+
+	/* Store new initial register values from the firmware. */
+	if (slottime_reg != ar->fw_coverage.reg_slottime_conf)
+		ar->fw_coverage.reg_slottime_orig = slottime_reg;
+	if (timeout_reg != ar->fw_coverage.reg_ack_cts_timeout_conf)
+		ar->fw_coverage.reg_ack_cts_timeout_orig = timeout_reg;
+
+	/* Calculat new value based on the (original) firmware calculation. */
+	slottime_reg = ar->fw_coverage.reg_slottime_orig;
+	timeout_reg = ar->fw_coverage.reg_ack_cts_timeout_orig;
+
+	/* Do some sanity checks on the slottime register. */
+	if (unlikely(slottime_reg % counters_freq_mhz)) {
+		ath10k_warn(ar,
+			    "Not adjusting coverage class timeouts, expected an integer microsecond slot time in HW register\n");
+
+		goto store_regs;
+	}
+
+	slottime = (slottime_reg & ATH9K_MAC_IFS_SLOT_M) / counters_freq_mhz;
+	if (unlikely(slottime != 9 && slottime != 20)) {
+		ath10k_warn(ar,
+			    "Not adjusting coverage class timeouts, expected a slot time of 9 or 20us in HW register. It is %uus.\n",
+			    slottime);
+
+		goto store_regs;
+	}
+
+	/* Recalculate the register values by adding the additional propagation
+	 * delay (3us per coverage class).
+	 */
+
+	slottime = (slottime_reg & ATH9K_MAC_IFS_SLOT_M);
+	slottime += value * 3 * counters_freq_mhz;
+	slottime = min_t(u32, slottime, ATH9K_MAC_IFS_SLOT_M);
+	slottime_reg = (slottime_reg & ~ATH9K_MAC_IFS_SLOT_M) | slottime;
+
+	/* Update ack timeout (lower halfword). */
+	timeout = (timeout_reg & ATH9K_MAC_TIME_OUT_ACK);
+	timeout = timeout >> ATH9K_MAC_TIME_OUT_ACK_S;
+	timeout += 3 * value * counters_freq_mhz;
+	timeout = min_t(u32, timeout, ATH9K_MAC_TIME_OUT_MAX);
+	timeout = (timeout << ATH9K_MAC_TIME_OUT_ACK_S)
+	timeout = timeout & ATH9K_MAC_TIME_OUT_ACK;
+	timeout_reg = (timeout_reg & ~ATH9K_MAC_TIME_OUT_ACK) | timeout;
+
+	/* Update cts timeout (upper halfword). */
+	timeout = (timeout_reg & ATH9K_MAC_TIME_OUT_CTS)
+	timeout = timeout >> ATH9K_MAC_TIME_OUT_CTS_S;
+	timeout += 3 * value * counters_freq_mhz;
+	timeout = min_t(u32, timeout, ATH9K_MAC_TIME_OUT_MAX);
+	timeout = (timeout << ATH9K_MAC_TIME_OUT_CTS_S)
+	timeout = timeout & ATH9K_MAC_TIME_OUT_CTS;
+	timeout_reg = (timeout_reg & ~ATH9K_MAC_TIME_OUT_CTS) | timeout;
+
+	ath10k_hif_write32(ar, WLAN_MAC_BASE_ADDRESS + 0x1070, slottime_reg);
+	ath10k_hif_write32(ar, WLAN_MAC_BASE_ADDRESS + 0x8014, timeout_reg);
+
+store_regs:
+	/* After an error we will not retry setting the coverage class. */
+	ar->fw_coverage.coverage_class = value;
+	ar->fw_coverage.reg_slottime_conf = slottime_reg;
+	ar->fw_coverage.reg_ack_cts_timeout_conf = timeout_reg;
+
+unlock:
+	spin_unlock_bh(&ar->data_lock);
+}
+
+static void
+ath10k_wmi_op_set_pdev_coverage_class(struct ath10k *ar, s16 value)
+{
+	switch (ar->hw_values->mac_core_rev) {
+	case ATH10K_HW_MAC_CORE_ATH9K:
+		ath10k_ath9k_set_pdev_coverage_class(ar, value);
+		break;
+	default:
+		if (value != -1)
+			ath10k_warn(ar, "Setting the coverage class is not supported for this chipset.");
+		break;
+	}
+}
+
 void ath10k_wmi_event_peer_sta_kickout(struct ath10k *ar, struct sk_buff *skb)
 {
 	struct wmi_peer_kick_ev_arg arg = {};
@@ -4992,6 +5108,12 @@ static void ath10k_wmi_op_rx(struct ath10k *ar, struct sk_buff *skb)
 		break;
 	}
 
+	/* Check and possibly reset the coverage class configuration override.
+	 * There are many conditions (in particular internal card resets) that
+	 * can cause the registers to be re-initialized.
+	 */
+	ath10k_wmi_op_set_pdev_coverage_class(ar, -1);
+
 out:
 	dev_kfree_skb(skb);
 }
@@ -5116,6 +5238,12 @@ static void ath10k_wmi_10_1_op_rx(struct ath10k *ar, struct sk_buff *skb)
 		break;
 	}
 
+	/* Check and possibly reset the coverage class configuration override.
+	 * There are many conditions (in particular internal card resets) that
+	 * can cause the registers to be re-initialized.
+	 */
+	ath10k_wmi_op_set_pdev_coverage_class(ar, -1);
+
 out:
 	dev_kfree_skb(skb);
 }
@@ -5240,6 +5368,12 @@ static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, struct sk_buff *skb)
 		break;
 	}
 
+	/* Check and possibly reset the coverage class configuration override.
+	 * There are many conditions (in particular internal card resets) that
+	 * can cause the registers to be re-initialized.
+	 */
+	ath10k_wmi_op_set_pdev_coverage_class(ar, -1);
+
 out:
 	dev_kfree_skb(skb);
 }
@@ -5323,6 +5457,12 @@ static void ath10k_wmi_10_4_op_rx(struct ath10k *ar, struct sk_buff *skb)
 		break;
 	}
 
+	/* Check and possibly reset the coverage class configuration override.
+	 * There are many conditions (in particular internal card resets) that
+	 * can cause the registers to be re-initialized.
+	 */
+	ath10k_wmi_op_set_pdev_coverage_class(ar, -1);
+
 out:
 	dev_kfree_skb(skb);
 }
@@ -6017,6 +6157,7 @@ void ath10k_wmi_start_scan_init(struct ath10k *ar,
 		| WMI_SCAN_EVENT_COMPLETED
 		| WMI_SCAN_EVENT_BSS_CHANNEL
 		| WMI_SCAN_EVENT_FOREIGN_CHANNEL
+		| WMI_SCAN_EVENT_FOREIGN_CHANNEL_EXIT
 		| WMI_SCAN_EVENT_DEQUEUED;
 	arg->scan_ctrl_flags |= WMI_SCAN_CHAN_STAT_EVENT;
 	arg->n_bssids = 1;
@@ -7666,6 +7807,8 @@ static const struct wmi_ops wmi_ops = {
 	.pull_fw_stats = ath10k_wmi_main_op_pull_fw_stats,
 	.pull_roam_ev = ath10k_wmi_op_pull_roam_ev,
 
+	.set_pdev_coverage_class = ath10k_wmi_op_set_pdev_coverage_class,
+
 	.gen_pdev_suspend = ath10k_wmi_op_gen_pdev_suspend,
 	.gen_pdev_resume = ath10k_wmi_op_gen_pdev_resume,
 	.gen_pdev_set_rd = ath10k_wmi_op_gen_pdev_set_rd,
@@ -7739,6 +7882,8 @@ static const struct wmi_ops wmi_10_1_ops = {
 	.pull_rdy = ath10k_wmi_op_pull_rdy_ev,
 	.pull_roam_ev = ath10k_wmi_op_pull_roam_ev,
 
+	.set_pdev_coverage_class = ath10k_wmi_op_set_pdev_coverage_class,
+
 	.gen_pdev_suspend = ath10k_wmi_op_gen_pdev_suspend,
 	.gen_pdev_resume = ath10k_wmi_op_gen_pdev_resume,
 	.gen_pdev_set_param = ath10k_wmi_op_gen_pdev_set_param,
@@ -7808,6 +7953,8 @@ static const struct wmi_ops wmi_10_2_ops = {
 	.pull_rdy = ath10k_wmi_op_pull_rdy_ev,
 	.pull_roam_ev = ath10k_wmi_op_pull_roam_ev,
 
+	.set_pdev_coverage_class = ath10k_wmi_op_set_pdev_coverage_class,
+
 	.gen_pdev_suspend = ath10k_wmi_op_gen_pdev_suspend,
 	.gen_pdev_resume = ath10k_wmi_op_gen_pdev_resume,
 	.gen_pdev_set_param = ath10k_wmi_op_gen_pdev_set_param,
@@ -7874,6 +8021,8 @@ static const struct wmi_ops wmi_10_2_4_ops = {
 	.pull_rdy = ath10k_wmi_op_pull_rdy_ev,
 	.pull_roam_ev = ath10k_wmi_op_pull_roam_ev,
 
+	.set_pdev_coverage_class = ath10k_wmi_op_set_pdev_coverage_class,
+
 	.gen_pdev_suspend = ath10k_wmi_op_gen_pdev_suspend,
 	.gen_pdev_resume = ath10k_wmi_op_gen_pdev_resume,
 	.gen_pdev_set_param = ath10k_wmi_op_gen_pdev_set_param,
@@ -7938,6 +8087,8 @@ static const struct wmi_ops wmi_10_4_ops = {
 	.pull_roam_ev = ath10k_wmi_op_pull_roam_ev,
 	.get_txbf_conf_scheme = ath10k_wmi_10_4_txbf_conf_scheme,
 
+	.set_pdev_coverage_class = ath10k_wmi_op_set_pdev_coverage_class,
+
 	.gen_pdev_suspend = ath10k_wmi_op_gen_pdev_suspend,
 	.gen_pdev_resume = ath10k_wmi_op_gen_pdev_resume,
 	.gen_pdev_set_rd = ath10k_wmi_10x_op_gen_pdev_set_rd,
-- 
2.8.1



From michal.kazior at tieto.com  Wed Jul 27 02:15:11 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 27 Jul 2016 11:15:11 +0200
Subject: [PATCH] ath10k: Allow setting coverage class
In-Reply-To: <1469608424-11370-1-git-send-email-benjamin@sipsolutions.net>
References: <1469608424-11370-1-git-send-email-benjamin@sipsolutions.net>
Message-ID: <CA+BoTQmLdfLaANVBqoSW8WQwZSSNz0WrJNvA0fji4i9XOd1D9w@mail.gmail.com>

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

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


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

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


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

WAVE1 would be more appropriate.


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

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

Moreover FW refers to these register as PCU_ACK_CTS_TIMEOUT and
PCU_GBL_IFS_SLOT.


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

Wrong function prefix/name. Should be: ath10k_mac_op_set_coverage_class


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

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


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

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


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

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

ath10k_wmi_ is appropriate for stuff in wmi.c


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

Wrong message style.


> +
> +               goto store_regs;
> +       }
> +
> +       slottime = (slottime_reg & ATH9K_MAC_IFS_SLOT_M) / counters_freq_mhz;
> +       if (unlikely(slottime != 9 && slottime != 20)) {
> +               ath10k_warn(ar,
> +                           "Not adjusting coverage class timeouts, expected a slot time of 9 or 20us in HW register. It is %uus.\n",
> +                           slottime);

Wrong message style.


[...]
> +       timeout_reg = (timeout_reg & ~ATH9K_MAC_TIME_OUT_ACK) | timeout;
> +
> +       /* Update cts timeout (upper halfword). */
> +       timeout = (timeout_reg & ATH9K_MAC_TIME_OUT_CTS)
> +       timeout = timeout >> ATH9K_MAC_TIME_OUT_CTS_S;
> +       timeout += 3 * value * counters_freq_mhz;
> +       timeout = min_t(u32, timeout, ATH9K_MAC_TIME_OUT_MAX);
> +       timeout = (timeout << ATH9K_MAC_TIME_OUT_CTS_S)
> +       timeout = timeout & ATH9K_MAC_TIME_OUT_CTS;
> +       timeout_reg = (timeout_reg & ~ATH9K_MAC_TIME_OUT_CTS) | timeout;

I would really love to see Jakub's hw register helper macros get
merged and used here..


> +
> +       ath10k_hif_write32(ar, WLAN_MAC_BASE_ADDRESS + 0x1070, slottime_reg);
> +       ath10k_hif_write32(ar, WLAN_MAC_BASE_ADDRESS + 0x8014, timeout_reg);

So you're defining register offsets and then you're using literal
values to address them?..


[...]
> +static void
> +ath10k_wmi_op_set_pdev_coverage_class(struct ath10k *ar, s16 value)
> +{
> +       switch (ar->hw_values->mac_core_rev) {
> +       case ATH10K_HW_MAC_CORE_ATH9K:
> +               ath10k_ath9k_set_pdev_coverage_class(ar, value);
> +               break;
> +       default:
> +               if (value != -1)
> +                       ath10k_warn(ar, "Setting the coverage class is not supported for this chipset.");
> +               break;
> +       }
> +}

This is wrong in general. You aren't using WMI to submit coverage
class configuration so it doesn't belong here (wmi.c and wmi-ops).
You're poking HW registers directly actually.

The logic should be placed in mac.c and hw.c and abstracted away
through hw_ops which are defined/populated per-hw in pci.c. Vasanth
recently worked on something similar for rx descriptor handling
(ar->hw_rx_desc_ops). I think it should be generalized to hw_ops and
you should add the coverage-class stuff on top of that.


Micha?


From lkp at intel.com  Wed Jul 27 03:28:08 2016
From: lkp at intel.com (kbuild test robot)
Date: Wed, 27 Jul 2016 18:28:08 +0800
Subject: [PATCH] ath10k: Allow setting coverage class
In-Reply-To: <1469608424-11370-1-git-send-email-benjamin@sipsolutions.net>
Message-ID: <201607271844.4Ha6HzJ2%fengguang.wu@intel.com>

Hi,

[auto build test ERROR on ath6kl/ath-next]
[also build test ERROR on next-20160727]
[cannot apply to v4.7]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Benjamin-Berg/ath10k-Allow-setting-coverage-class/20160727-163809
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   drivers/net/wireless/ath/ath10k/wmi.c: In function 'ath10k_ath9k_set_pdev_coverage_class':
>> drivers/net/wireless/ath/ath10k/wmi.c:3176:2: error: expected ';' before 'timeout'
     timeout = timeout & ATH9K_MAC_TIME_OUT_ACK;
     ^
   drivers/net/wireless/ath/ath10k/wmi.c:3181:2: error: expected ';' before 'timeout'
     timeout = timeout >> ATH9K_MAC_TIME_OUT_CTS_S;
     ^
   drivers/net/wireless/ath/ath10k/wmi.c:3185:2: error: expected ';' before 'timeout'
     timeout = timeout & ATH9K_MAC_TIME_OUT_CTS;
     ^

vim +3176 drivers/net/wireless/ath/ath10k/wmi.c

  3170		/* Update ack timeout (lower halfword). */
  3171		timeout = (timeout_reg & ATH9K_MAC_TIME_OUT_ACK);
  3172		timeout = timeout >> ATH9K_MAC_TIME_OUT_ACK_S;
  3173		timeout += 3 * value * counters_freq_mhz;
  3174		timeout = min_t(u32, timeout, ATH9K_MAC_TIME_OUT_MAX);
  3175		timeout = (timeout << ATH9K_MAC_TIME_OUT_ACK_S)
> 3176		timeout = timeout & ATH9K_MAC_TIME_OUT_ACK;
  3177		timeout_reg = (timeout_reg & ~ATH9K_MAC_TIME_OUT_ACK) | timeout;
  3178	
  3179		/* Update cts timeout (upper halfword). */

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 46490 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160727/1e55d165/attachment-0001.obj>

From vthiagar at qti.qualcomm.com  Wed Jul 27 05:36:42 2016
From: vthiagar at qti.qualcomm.com (Vasanthakumar Thiagarajan)
Date: Wed, 27 Jul 2016 18:06:42 +0530
Subject: [PATCH 0/4] ath10k: Padding related clean ups in rx
Message-ID: <1469623006-13178-1-git-send-email-vthiagar@qti.qualcomm.com>

This patch set adds abstraction for rx_hw_desc processing so that
we can make use of newer desc fields notifying padding information
which is done on rx payload. "ath10k: Properly remove padding from
the start of rx payload" fixes padding related bug in ethernet decap
mode for QCA99X0, QCA9984 qnd QCA4019 but even fixing this bug will
not make ethernet decap mode work, there needs to be some more fix
wich would follow this patch series.

Vasanthakumar Thiagarajan (4):
  ath10k: Move ath10k_hw_params definition to hw.h
  ath10k: Add provision for Rx descriptor abstraction
  ath10k: Properly remove padding from the start of rx payload
  ath10k: Remove 4-addr padding related hw_param configuration

 drivers/net/wireless/ath/ath10k/core.c   | 21 ++++++----
 drivers/net/wireless/ath/ath10k/core.h   | 48 +--------------------
 drivers/net/wireless/ath/ath10k/htt_rx.c | 36 +++++++++-------
 drivers/net/wireless/ath/ath10k/hw.c     | 13 ++++++
 drivers/net/wireless/ath/ath10k/hw.h     | 71 +++++++++++++++++++++++++++++---
 5 files changed, 114 insertions(+), 75 deletions(-)

-- 
1.9.1



From vthiagar at qti.qualcomm.com  Wed Jul 27 05:36:44 2016
From: vthiagar at qti.qualcomm.com (Vasanthakumar Thiagarajan)
Date: Wed, 27 Jul 2016 18:06:44 +0530
Subject: [PATCH 2/4] ath10k: Add provision for Rx descriptor abstraction
In-Reply-To: <1469623006-13178-1-git-send-email-vthiagar@qti.qualcomm.com>
References: <1469623006-13178-1-git-send-email-vthiagar@qti.qualcomm.com>
Message-ID: <1469623006-13178-3-git-send-email-vthiagar@qti.qualcomm.com>

There are slight differences in Rx hw descriptor information
among different chips. So far driver does not use those new
information for any functionalities, but there is one important
information which is available from QCA99X0 onwards to indicate
the number of bytes that hw padded at the begining of the rx
payload and this information is needed to undecap the rx
packet. Add an abstraction for Rx desc to make use of the
new desc information available. The callback that this patch
defines to retrieve the padding bytes will be used in follow-up
patch.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 12 ++++++++++++
 drivers/net/wireless/ath/ath10k/hw.c   | 13 +++++++++++++
 drivers/net/wireless/ath/ath10k/hw.h   | 12 ++++++++++++
 3 files changed, 37 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index e889829..9c5e93b 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -68,6 +68,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_size = QCA988X_BOARD_DATA_SZ,
 			.board_ext_size = QCA988X_BOARD_EXT_DATA_SZ,
 		},
+		.hw_rx_desc_ops = &qca988x_rx_desc_ops,
 	},
 	{
 		.id = QCA9887_HW_1_0_VERSION,
@@ -87,6 +88,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_size = QCA9887_BOARD_DATA_SZ,
 			.board_ext_size = QCA9887_BOARD_EXT_DATA_SZ,
 		},
+		.hw_rx_desc_ops = &qca988x_rx_desc_ops,
 	},
 	{
 		.id = QCA6174_HW_2_1_VERSION,
@@ -104,6 +106,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_size = QCA6174_BOARD_DATA_SZ,
 			.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
 		},
+		.hw_rx_desc_ops = &qca988x_rx_desc_ops,
 	},
 	{
 		.id = QCA6174_HW_2_1_VERSION,
@@ -122,6 +125,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_size = QCA6174_BOARD_DATA_SZ,
 			.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
 		},
+		.hw_rx_desc_ops = &qca988x_rx_desc_ops,
 	},
 	{
 		.id = QCA6174_HW_3_0_VERSION,
@@ -140,6 +144,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_size = QCA6174_BOARD_DATA_SZ,
 			.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
 		},
+		.hw_rx_desc_ops = &qca988x_rx_desc_ops,
 	},
 	{
 		.id = QCA6174_HW_3_2_VERSION,
@@ -159,6 +164,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_size = QCA6174_BOARD_DATA_SZ,
 			.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
 		},
+		.hw_rx_desc_ops = &qca988x_rx_desc_ops,
 	},
 	{
 		.id = QCA99X0_HW_2_0_DEV_VERSION,
@@ -182,6 +188,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_size = QCA99X0_BOARD_DATA_SZ,
 			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
 		},
+		.hw_rx_desc_ops = &qca99x0_rx_desc_ops,
 	},
 	{
 		.id = QCA9984_HW_1_0_DEV_VERSION,
@@ -205,6 +212,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_size = QCA99X0_BOARD_DATA_SZ,
 			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
 		},
+		.hw_rx_desc_ops = &qca99x0_rx_desc_ops,
 	},
 	{
 		.id = QCA9888_HW_2_0_DEV_VERSION,
@@ -227,6 +235,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_size = QCA99X0_BOARD_DATA_SZ,
 			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
 		},
+		.hw_rx_desc_ops = &qca99x0_rx_desc_ops,
 	},
 	{
 		.id = QCA9377_HW_1_0_DEV_VERSION,
@@ -244,6 +253,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_size = QCA9377_BOARD_DATA_SZ,
 			.board_ext_size = QCA9377_BOARD_EXT_DATA_SZ,
 		},
+		.hw_rx_desc_ops = &qca988x_rx_desc_ops,
 	},
 	{
 		.id = QCA9377_HW_1_1_DEV_VERSION,
@@ -261,6 +271,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_size = QCA9377_BOARD_DATA_SZ,
 			.board_ext_size = QCA9377_BOARD_EXT_DATA_SZ,
 		},
+		.hw_rx_desc_ops = &qca988x_rx_desc_ops,
 	},
 	{
 		.id = QCA4019_HW_1_0_DEV_VERSION,
@@ -285,6 +296,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_size = QCA4019_BOARD_DATA_SZ,
 			.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
 		},
+		.hw_rx_desc_ops = &qca99x0_rx_desc_ops,
 	},
 };
 
diff --git a/drivers/net/wireless/ath/ath10k/hw.c b/drivers/net/wireless/ath/ath10k/hw.c
index f903d46..6149aa9 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -219,3 +219,16 @@ void ath10k_hw_fill_survey_time(struct ath10k *ar, struct survey_info *survey,
 	survey->time = CCNT_TO_MSEC(ar, cc);
 	survey->time_busy = CCNT_TO_MSEC(ar, rcc);
 }
+
+const struct ath10k_hw_rx_desc_ops qca988x_rx_desc_ops = {
+};
+
+static int ath10k_qca99x0_rx_desc_get_l3_pad_bytes(struct htt_rx_desc *rxd)
+{
+	return MS(__le32_to_cpu(rxd->msdu_end.qca99x0.info1),
+		  RX_MSDU_END_INFO1_L3_HDR_PAD);
+}
+
+const struct ath10k_hw_rx_desc_ops qca99x0_rx_desc_ops = {
+	.rx_desc_get_l3_pad_bytes = ath10k_qca99x0_rx_desc_get_l3_pad_bytes,
+};
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 1315557..a281544 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -409,8 +409,20 @@ struct ath10k_hw_params {
 		size_t board_size;
 		size_t board_ext_size;
 	} fw;
+
+	const struct ath10k_hw_rx_desc_ops *hw_rx_desc_ops;
 };
 
+struct htt_rx_desc;
+
+/* Defines needed for Rx descriptor abstraction */
+struct ath10k_hw_rx_desc_ops {
+	int (*rx_desc_get_l3_pad_bytes)(struct htt_rx_desc *rxd);
+};
+
+extern const struct ath10k_hw_rx_desc_ops qca988x_rx_desc_ops;
+extern const struct ath10k_hw_rx_desc_ops qca99x0_rx_desc_ops;
+
 /* Target specific defines for MAIN firmware */
 #define TARGET_NUM_VDEVS			8
 #define TARGET_NUM_PEER_AST			2
-- 
1.9.1



From vthiagar at qti.qualcomm.com  Wed Jul 27 05:36:43 2016
From: vthiagar at qti.qualcomm.com (Vasanthakumar Thiagarajan)
Date: Wed, 27 Jul 2016 18:06:43 +0530
Subject: [PATCH 1/4] ath10k: Move ath10k_hw_params definition to hw.h
In-Reply-To: <1469623006-13178-1-git-send-email-vthiagar@qti.qualcomm.com>
References: <1469623006-13178-1-git-send-email-vthiagar@qti.qualcomm.com>
Message-ID: <1469623006-13178-2-git-send-email-vthiagar@qti.qualcomm.com>

This is to prepare for rx descriptor abstraction where we'll
be dereferencing ath10k_hw_params member in hw.h. Moreover
hw.h looks more suitable to house ath10k_hw_params definition
than core.h

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.h | 48 +---------------------------------
 drivers/net/wireless/ath/ath10k/hw.h   | 48 ++++++++++++++++++++++++++++++++++
 2 files changed, 49 insertions(+), 47 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 30ae5bf..5ace413 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -715,53 +715,7 @@ struct ath10k {
 	struct ath10k_htc htc;
 	struct ath10k_htt htt;
 
-	struct ath10k_hw_params {
-		u32 id;
-		u16 dev_id;
-		const char *name;
-		u32 patch_load_addr;
-		int uart_pin;
-		u32 otp_exe_param;
-
-		/* Type of hw cycle counter wraparound logic, for more info
-		 * refer enum ath10k_hw_cc_wraparound_type.
-		 */
-		enum ath10k_hw_cc_wraparound_type cc_wraparound_type;
-
-		/* Some of chip expects fragment descriptor to be continuous
-		 * memory for any TX operation. Set continuous_frag_desc flag
-		 * for the hardware which have such requirement.
-		 */
-		bool continuous_frag_desc;
-
-		/* CCK hardware rate table mapping for the newer chipsets
-		 * like QCA99X0, QCA4019 got revised. The CCK h/w rate values
-		 * are in a proper order with respect to the rate/preamble
-		 */
-		bool cck_rate_map_rev2;
-
-		u32 channel_counters_freq_hz;
-
-		/* Mgmt tx descriptors threshold for limiting probe response
-		 * frames.
-		 */
-		u32 max_probe_resp_desc_thres;
-
-		/* The padding bytes's location is different on various chips */
-		enum ath10k_hw_4addr_pad hw_4addr_pad;
-
-		u32 tx_chain_mask;
-		u32 rx_chain_mask;
-		u32 max_spatial_stream;
-		u32 cal_data_len;
-
-		struct ath10k_hw_params_fw {
-			const char *dir;
-			const char *board;
-			size_t board_size;
-			size_t board_ext_size;
-		} fw;
-	} hw_params;
+	struct ath10k_hw_params hw_params;
 
 	/* contains the firmware images used with ATH10K_FIRMWARE_MODE_NORMAL */
 	struct ath10k_fw_components normal_mode_fw;
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index e014cd7..1315557 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -363,6 +363,54 @@ enum ath10k_hw_cc_wraparound_type {
 	ATH10K_HW_CC_WRAP_SHIFTED_EACH = 2,
 };
 
+struct ath10k_hw_params {
+	u32 id;
+	u16 dev_id;
+	const char *name;
+	u32 patch_load_addr;
+	int uart_pin;
+	u32 otp_exe_param;
+
+	/* Type of hw cycle counter wraparound logic, for more info
+	 * refer enum ath10k_hw_cc_wraparound_type.
+	 */
+	enum ath10k_hw_cc_wraparound_type cc_wraparound_type;
+
+	/* Some of chip expects fragment descriptor to be continuous
+	 * memory for any TX operation. Set continuous_frag_desc flag
+	 * for the hardware which have such requirement.
+	 */
+	bool continuous_frag_desc;
+
+	/* CCK hardware rate table mapping for the newer chipsets
+	 * like QCA99X0, QCA4019 got revised. The CCK h/w rate values
+	 * are in a proper order with respect to the rate/preamble
+	 */
+	bool cck_rate_map_rev2;
+
+	u32 channel_counters_freq_hz;
+
+	/* Mgmt tx descriptors threshold for limiting probe response
+	 * frames.
+	 */
+	u32 max_probe_resp_desc_thres;
+
+	/* The padding bytes's location is different on various chips */
+	enum ath10k_hw_4addr_pad hw_4addr_pad;
+
+	u32 tx_chain_mask;
+	u32 rx_chain_mask;
+	u32 max_spatial_stream;
+	u32 cal_data_len;
+
+	struct ath10k_hw_params_fw {
+		const char *dir;
+		const char *board;
+		size_t board_size;
+		size_t board_ext_size;
+	} fw;
+};
+
 /* Target specific defines for MAIN firmware */
 #define TARGET_NUM_VDEVS			8
 #define TARGET_NUM_PEER_AST			2
-- 
1.9.1



From vthiagar at qti.qualcomm.com  Wed Jul 27 05:36:45 2016
From: vthiagar at qti.qualcomm.com (Vasanthakumar Thiagarajan)
Date: Wed, 27 Jul 2016 18:06:45 +0530
Subject: [PATCH 3/4] ath10k: Properly remove padding from the start of rx
 payload
In-Reply-To: <1469623006-13178-1-git-send-email-vthiagar@qti.qualcomm.com>
References: <1469623006-13178-1-git-send-email-vthiagar@qti.qualcomm.com>
Message-ID: <1469623006-13178-4-git-send-email-vthiagar@qti.qualcomm.com>

In QCA99X0 (QCA99X0, QCA9984, QCA9888 and QCA4019) family chips,
hw adds padding at the begining of the rx payload to make L3
header 4-byte aligned. In the chips doing this type of padding,
the number of bytes padded will be indicated through msdu_end:info1.
Define a hw_rx_desc_ops wrapper to retrieve the number of padded
bytes and use this while doing undecap. This should fix padding
related issues with ethernt decap format with QCA99X0, QCA9984,
QCA9888 and QCA4019 hw.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 36 +++++++++++++++++++-------------
 drivers/net/wireless/ath/ath10k/hw.h     |  9 ++++++++
 2 files changed, 31 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 78db5d6..36c4809 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1056,9 +1056,11 @@ static void ath10k_htt_rx_h_undecap_nwifi(struct ath10k *ar,
 					  const u8 first_hdr[64])
 {
 	struct ieee80211_hdr *hdr;
+	struct htt_rx_desc *rxd;
 	size_t hdr_len;
 	u8 da[ETH_ALEN];
 	u8 sa[ETH_ALEN];
+	int l3_pad_bytes;
 
 	/* Delivered decapped frame:
 	 * [nwifi 802.11 header] <-- replaced with 802.11 hdr
@@ -1072,19 +1074,12 @@ static void ath10k_htt_rx_h_undecap_nwifi(struct ath10k *ar,
 	 */
 
 	/* pull decapped header and copy SA & DA */
-	if ((ar->hw_params.hw_4addr_pad == ATH10K_HW_4ADDR_PAD_BEFORE) &&
-	    ieee80211_has_a4(((struct ieee80211_hdr *)first_hdr)->frame_control)) {
-		/* The QCA99X0 4 address mode pad 2 bytes at the
-		 * beginning of MSDU
-		 */
-		hdr = (struct ieee80211_hdr *)(msdu->data + 2);
-		/* The skb length need be extended 2 as the 2 bytes at the tail
-		 * be excluded due to the padding
-		 */
-		skb_put(msdu, 2);
-	} else {
-		hdr = (struct ieee80211_hdr *)(msdu->data);
-	}
+	rxd = (void *)msdu->data - sizeof(*rxd);
+
+	l3_pad_bytes = ath10k_rx_desc_get_l3_pad_bytes(&ar->hw_params, rxd);
+	skb_put(msdu, l3_pad_bytes);
+
+	hdr = (struct ieee80211_hdr *)(msdu->data + l3_pad_bytes);
 
 	hdr_len = ath10k_htt_rx_nwifi_hdrlen(ar, hdr);
 	ether_addr_copy(da, ieee80211_get_DA(hdr));
@@ -1151,6 +1146,8 @@ static void ath10k_htt_rx_h_undecap_eth(struct ath10k *ar,
 	void *rfc1042;
 	u8 da[ETH_ALEN];
 	u8 sa[ETH_ALEN];
+	int l3_pad_bytes;
+	struct htt_rx_desc *rxd;
 
 	/* Delivered decapped frame:
 	 * [eth header] <-- replaced with 802.11 hdr & rfc1042/llc
@@ -1161,6 +1158,11 @@ static void ath10k_htt_rx_h_undecap_eth(struct ath10k *ar,
 	if (WARN_ON_ONCE(!rfc1042))
 		return;
 
+	rxd = (void *)msdu->data - sizeof(*rxd);
+	l3_pad_bytes = ath10k_rx_desc_get_l3_pad_bytes(&ar->hw_params, rxd);
+	skb_put(msdu, l3_pad_bytes);
+	skb_pull(msdu, l3_pad_bytes);
+
 	/* pull decapped header and copy SA & DA */
 	eth = (struct ethhdr *)msdu->data;
 	ether_addr_copy(da, eth->h_dest);
@@ -1191,6 +1193,8 @@ static void ath10k_htt_rx_h_undecap_snap(struct ath10k *ar,
 {
 	struct ieee80211_hdr *hdr;
 	size_t hdr_len;
+	int l3_pad_bytes;
+	struct htt_rx_desc *rxd;
 
 	/* Delivered decapped frame:
 	 * [amsdu header] <-- replaced with 802.11 hdr
@@ -1198,7 +1202,11 @@ static void ath10k_htt_rx_h_undecap_snap(struct ath10k *ar,
 	 * [payload]
 	 */
 
-	skb_pull(msdu, sizeof(struct amsdu_subframe_hdr));
+	rxd = (void *)msdu->data - sizeof(*rxd);
+	l3_pad_bytes = ath10k_rx_desc_get_l3_pad_bytes(&ar->hw_params, rxd);
+
+	skb_put(msdu, l3_pad_bytes);
+	skb_pull(msdu, sizeof(struct amsdu_subframe_hdr) + l3_pad_bytes);
 
 	hdr = (struct ieee80211_hdr *)first_hdr;
 	hdr_len = ieee80211_hdrlen(hdr->frame_control);
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index a281544..cdd2ce4 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -423,6 +423,15 @@ struct ath10k_hw_rx_desc_ops {
 extern const struct ath10k_hw_rx_desc_ops qca988x_rx_desc_ops;
 extern const struct ath10k_hw_rx_desc_ops qca99x0_rx_desc_ops;
 
+static inline int
+ath10k_rx_desc_get_l3_pad_bytes(struct ath10k_hw_params *hw,
+				struct htt_rx_desc *rxd)
+{
+	if (hw->hw_rx_desc_ops->rx_desc_get_l3_pad_bytes)
+		return hw->hw_rx_desc_ops->rx_desc_get_l3_pad_bytes(rxd);
+	return 0;
+}
+
 /* Target specific defines for MAIN firmware */
 #define TARGET_NUM_VDEVS			8
 #define TARGET_NUM_PEER_AST			2
-- 
1.9.1



From vthiagar at qti.qualcomm.com  Wed Jul 27 05:36:46 2016
From: vthiagar at qti.qualcomm.com (Vasanthakumar Thiagarajan)
Date: Wed, 27 Jul 2016 18:06:46 +0530
Subject: [PATCH 4/4] ath10k: Remove 4-addr padding related hw_param
 configuration
In-Reply-To: <1469623006-13178-1-git-send-email-vthiagar@qti.qualcomm.com>
References: <1469623006-13178-1-git-send-email-vthiagar@qti.qualcomm.com>
Message-ID: <1469623006-13178-5-git-send-email-vthiagar@qti.qualcomm.com>

hw_4addr_pad was added to handle different types of padding
in 4-address rx frame. But this padding is not very specific
to 4-address, it can happen even with three address + ethernet
decap mode. Since the  padding information can be obtained
through Rx desc for QCA99X0 and newer chips, this hw_param
is not needed any more.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 9 ---------
 drivers/net/wireless/ath/ath10k/hw.h   | 8 --------
 2 files changed, 17 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 9c5e93b..74d0ace 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -60,7 +60,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.otp_exe_param = 0,
 		.channel_counters_freq_hz = 88000,
 		.max_probe_resp_desc_thres = 0,
-		.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_AFTER,
 		.cal_data_len = 2116,
 		.fw = {
 			.dir = QCA988X_HW_2_0_FW_DIR,
@@ -80,7 +79,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.otp_exe_param = 0,
 		.channel_counters_freq_hz = 88000,
 		.max_probe_resp_desc_thres = 0,
-		.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_AFTER,
 		.cal_data_len = 2116,
 		.fw = {
 			.dir = QCA9887_HW_1_0_FW_DIR,
@@ -117,7 +115,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.otp_exe_param = 0,
 		.channel_counters_freq_hz = 88000,
 		.max_probe_resp_desc_thres = 0,
-		.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_AFTER,
 		.cal_data_len = 8124,
 		.fw = {
 			.dir = QCA6174_HW_2_1_FW_DIR,
@@ -136,7 +133,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.otp_exe_param = 0,
 		.channel_counters_freq_hz = 88000,
 		.max_probe_resp_desc_thres = 0,
-		.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_AFTER,
 		.cal_data_len = 8124,
 		.fw = {
 			.dir = QCA6174_HW_3_0_FW_DIR,
@@ -155,7 +151,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.otp_exe_param = 0,
 		.channel_counters_freq_hz = 88000,
 		.max_probe_resp_desc_thres = 0,
-		.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_AFTER,
 		.cal_data_len = 8124,
 		.fw = {
 			/* uses same binaries as hw3.0 */
@@ -177,7 +172,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.cck_rate_map_rev2 = true,
 		.channel_counters_freq_hz = 150000,
 		.max_probe_resp_desc_thres = 24,
-		.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
 		.tx_chain_mask = 0xf,
 		.rx_chain_mask = 0xf,
 		.max_spatial_stream = 4,
@@ -201,7 +195,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.cck_rate_map_rev2 = true,
 		.channel_counters_freq_hz = 150000,
 		.max_probe_resp_desc_thres = 24,
-		.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
 		.tx_chain_mask = 0xf,
 		.rx_chain_mask = 0xf,
 		.max_spatial_stream = 4,
@@ -224,7 +217,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.continuous_frag_desc = true,
 		.channel_counters_freq_hz = 150000,
 		.max_probe_resp_desc_thres = 24,
-		.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
 		.tx_chain_mask = 3,
 		.rx_chain_mask = 3,
 		.max_spatial_stream = 2,
@@ -285,7 +277,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.cck_rate_map_rev2 = true,
 		.channel_counters_freq_hz = 125000,
 		.max_probe_resp_desc_thres = 24,
-		.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
 		.tx_chain_mask = 0x3,
 		.rx_chain_mask = 0x3,
 		.max_spatial_stream = 2,
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index cdd2ce4..1620e76 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -338,11 +338,6 @@ enum ath10k_hw_rate_rev2_cck {
 	ATH10K_HW_RATE_REV2_CCK_SP_11M,
 };
 
-enum ath10k_hw_4addr_pad {
-	ATH10K_HW_4ADDR_PAD_AFTER,
-	ATH10K_HW_4ADDR_PAD_BEFORE,
-};
-
 enum ath10k_hw_cc_wraparound_type {
 	ATH10K_HW_CC_WRAP_DISABLED = 0,
 
@@ -395,9 +390,6 @@ struct ath10k_hw_params {
 	 */
 	u32 max_probe_resp_desc_thres;
 
-	/* The padding bytes's location is different on various chips */
-	enum ath10k_hw_4addr_pad hw_4addr_pad;
-
 	u32 tx_chain_mask;
 	u32 rx_chain_mask;
 	u32 max_spatial_stream;
-- 
1.9.1



From vthiagar at qti.qualcomm.com  Wed Jul 27 05:38:05 2016
From: vthiagar at qti.qualcomm.com (Vasanthakumar Thiagarajan)
Date: Wed, 27 Jul 2016 18:08:05 +0530
Subject: [PATCH] ath10k: Fix rfc1042 header retrieval in QCA4019 with eth
 decap mode
Message-ID: <1469623085-13942-1-git-send-email-vthiagar@qti.qualcomm.com>

Chipset from QCA99X0 onwards (QCA99X0, QCA9984, QCA4019 & future)
rx_hdr_status is not padded to align in 4-byte boundary. Define a
new hw_params field to handle different alignment behaviour between
different hw. This patch fixes improper retrieval of rfc1042 header
with QCA4019. This patch along with "ath10k: Properly remove padding
from the start of rx payload" will fix traffic failure in ethernet
decap mode for QCA4019.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c   | 12 ++++++++++++
 drivers/net/wireless/ath/ath10k/htt_rx.c |  5 +++--
 drivers/net/wireless/ath/ath10k/hw.h     |  3 +++
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 74d0ace..ea6a8f4 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -68,6 +68,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_ext_size = QCA988X_BOARD_EXT_DATA_SZ,
 		},
 		.hw_rx_desc_ops = &qca988x_rx_desc_ops,
+		.decap_align_bytes = 4,
 	},
 	{
 		.id = QCA9887_HW_1_0_VERSION,
@@ -87,6 +88,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_ext_size = QCA9887_BOARD_EXT_DATA_SZ,
 		},
 		.hw_rx_desc_ops = &qca988x_rx_desc_ops,
+		.decap_align_bytes = 4,
 	},
 	{
 		.id = QCA6174_HW_2_1_VERSION,
@@ -105,6 +107,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
 		},
 		.hw_rx_desc_ops = &qca988x_rx_desc_ops,
+		.decap_align_bytes = 4,
 	},
 	{
 		.id = QCA6174_HW_2_1_VERSION,
@@ -123,6 +126,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
 		},
 		.hw_rx_desc_ops = &qca988x_rx_desc_ops,
+		.decap_align_bytes = 4,
 	},
 	{
 		.id = QCA6174_HW_3_0_VERSION,
@@ -141,6 +145,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
 		},
 		.hw_rx_desc_ops = &qca988x_rx_desc_ops,
+		.decap_align_bytes = 4,
 	},
 	{
 		.id = QCA6174_HW_3_2_VERSION,
@@ -160,6 +165,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
 		},
 		.hw_rx_desc_ops = &qca988x_rx_desc_ops,
+		.decap_align_bytes = 4,
 	},
 	{
 		.id = QCA99X0_HW_2_0_DEV_VERSION,
@@ -183,6 +189,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
 		},
 		.hw_rx_desc_ops = &qca99x0_rx_desc_ops,
+		.decap_align_bytes = 1,
 	},
 	{
 		.id = QCA9984_HW_1_0_DEV_VERSION,
@@ -206,6 +213,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
 		},
 		.hw_rx_desc_ops = &qca99x0_rx_desc_ops,
+		.decap_align_bytes = 1,
 	},
 	{
 		.id = QCA9888_HW_2_0_DEV_VERSION,
@@ -228,6 +236,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
 		},
 		.hw_rx_desc_ops = &qca99x0_rx_desc_ops,
+		.decap_align_bytes = 1,
 	},
 	{
 		.id = QCA9377_HW_1_0_DEV_VERSION,
@@ -246,6 +255,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_ext_size = QCA9377_BOARD_EXT_DATA_SZ,
 		},
 		.hw_rx_desc_ops = &qca988x_rx_desc_ops,
+		.decap_align_bytes = 4,
 	},
 	{
 		.id = QCA9377_HW_1_1_DEV_VERSION,
@@ -264,6 +274,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_ext_size = QCA9377_BOARD_EXT_DATA_SZ,
 		},
 		.hw_rx_desc_ops = &qca988x_rx_desc_ops,
+		.decap_align_bytes = 4,
 	},
 	{
 		.id = QCA4019_HW_1_0_DEV_VERSION,
@@ -288,6 +299,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 			.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
 		},
 		.hw_rx_desc_ops = &qca99x0_rx_desc_ops,
+		.decap_align_bytes = 1,
 	},
 };
 
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 36c4809..97d5b07 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1108,6 +1108,7 @@ static void *ath10k_htt_rx_h_find_rfc1042(struct ath10k *ar,
 	size_t hdr_len, crypto_len;
 	void *rfc1042;
 	bool is_first, is_last, is_amsdu;
+	int bytes_aligned = ar->hw_params.decap_align_bytes;
 
 	rxd = (void *)msdu->data - sizeof(*rxd);
 	hdr = (void *)rxd->rx_hdr_status;
@@ -1124,8 +1125,8 @@ static void *ath10k_htt_rx_h_find_rfc1042(struct ath10k *ar,
 		hdr_len = ieee80211_hdrlen(hdr->frame_control);
 		crypto_len = ath10k_htt_rx_crypto_param_len(ar, enctype);
 
-		rfc1042 += round_up(hdr_len, 4) +
-			   round_up(crypto_len, 4);
+		rfc1042 += round_up(hdr_len, bytes_aligned) +
+			   round_up(crypto_len, bytes_aligned);
 	}
 
 	if (is_amsdu)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 1620e76..1961e67 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -403,6 +403,9 @@ struct ath10k_hw_params {
 	} fw;
 
 	const struct ath10k_hw_rx_desc_ops *hw_rx_desc_ops;
+
+	/* Number of bytes used for alignment in rx_hdr_status of rx desc. */
+	int decap_align_bytes;
 };
 
 struct htt_rx_desc;
-- 
1.9.1



From michal.kazior at tieto.com  Wed Jul 27 05:43:09 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 27 Jul 2016 14:43:09 +0200
Subject: [PATCH 2/4] ath10k: Add provision for Rx descriptor abstraction
In-Reply-To: <1469623006-13178-3-git-send-email-vthiagar@qti.qualcomm.com>
References: <1469623006-13178-1-git-send-email-vthiagar@qti.qualcomm.com>
 <1469623006-13178-3-git-send-email-vthiagar@qti.qualcomm.com>
Message-ID: <CA+BoTQ=kUP-Qtw1EWKKfM_aGtJS_4oQdz4tqD5tiJkF_k3-vOA@mail.gmail.com>

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

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

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


Micha?


From vthiagar at qti.qualcomm.com  Wed Jul 27 05:59:47 2016
From: vthiagar at qti.qualcomm.com (Thiagarajan, Vasanthakumar)
Date: Wed, 27 Jul 2016 12:59:47 +0000
Subject: [PATCH 2/4] ath10k: Add provision for Rx descriptor abstraction
In-Reply-To: <CA+BoTQ=kUP-Qtw1EWKKfM_aGtJS_4oQdz4tqD5tiJkF_k3-vOA@mail.gmail.com>
References: <1469623006-13178-1-git-send-email-vthiagar@qti.qualcomm.com>
 <1469623006-13178-3-git-send-email-vthiagar@qti.qualcomm.com>
 <CA+BoTQ=kUP-Qtw1EWKKfM_aGtJS_4oQdz4tqD5tiJkF_k3-vOA@mail.gmail.com>
Message-ID: <5798B042.4070604@qti.qualcomm.com>

On Wednesday 27 July 2016 06:13 PM, Michal Kazior wrote:
> On 27 July 2016 at 14:36, Vasanthakumar Thiagarajan
> <vthiagar at qti.qualcomm.com> wrote:
>> There are slight differences in Rx hw descriptor information
>> among different chips. So far driver does not use those new
>> information for any functionalities, but there is one important
>> information which is available from QCA99X0 onwards to indicate
>> the number of bytes that hw padded at the begining of the rx
>> payload and this information is needed to undecap the rx
>> packet. Add an abstraction for Rx desc to make use of the
>> new desc information available. The callback that this patch
>> defines to retrieve the padding bytes will be used in follow-up
>> patch.
>>
>> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar at qti.qualcomm.com>
>> ---
>>   drivers/net/wireless/ath/ath10k/core.c | 12 ++++++++++++
>>   drivers/net/wireless/ath/ath10k/hw.c   | 13 +++++++++++++
>>   drivers/net/wireless/ath/ath10k/hw.h   | 12 ++++++++++++
>>   3 files changed, 37 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
>> index e889829..9c5e93b 100644
>> --- a/drivers/net/wireless/ath/ath10k/core.c
>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>> @@ -68,6 +68,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
>>                          .board_size = QCA988X_BOARD_DATA_SZ,
>>                          .board_ext_size = QCA988X_BOARD_EXT_DATA_SZ,
>>                  },
>> +               .hw_rx_desc_ops = &qca988x_rx_desc_ops,
> [...]
>> +struct ath10k_hw_rx_desc_ops {
>> +       int (*rx_desc_get_l3_pad_bytes)(struct htt_rx_desc *rxd);
>> +};
>
> Benjamin is trying to implement coverage class by poking hw registers
> over firmware's head [1]. I'm thinking the hw_rx_desc_ops could be
> generalized to hw_ops so it can be used for doing hw-specific hacks as
> well. What do you think?

Sure. Instead of reworking this patch set, can this be done in a separate patch?.

Vasanth

From michal.kazior at tieto.com  Wed Jul 27 06:12:04 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 27 Jul 2016 15:12:04 +0200
Subject: [PATCH 2/4] ath10k: Add provision for Rx descriptor abstraction
In-Reply-To: <5798B042.4070604@qti.qualcomm.com>
References: <1469623006-13178-1-git-send-email-vthiagar@qti.qualcomm.com>
 <1469623006-13178-3-git-send-email-vthiagar@qti.qualcomm.com>
 <CA+BoTQ=kUP-Qtw1EWKKfM_aGtJS_4oQdz4tqD5tiJkF_k3-vOA@mail.gmail.com>
 <5798B042.4070604@qti.qualcomm.com>
Message-ID: <CA+BoTQnc5x1+YoW=n3e+iXg13HwZaP_BOS_mJWzOWBY+9s=dAw@mail.gmail.com>

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

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


Micha?


From rajjoshi at comp.nus.edu.sg  Wed Jul 27 06:23:48 2016
From: rajjoshi at comp.nus.edu.sg (Raj Joshi)
Date: Wed, 27 Jul 2016 20:23:48 +0700
Subject: Completely disabling RTS/CTS
In-Reply-To: <57919126.7000601@candelatech.com>
References: <CA+uUJGu6qSmxupEkaqPmLBQf53wQtjyXidFCf+4X9vMxL4WmoA@mail.gmail.com>
 <CABPxzY+KHVGAUKjU2kWdKiEPZFV3=sOnWe-qBMDOPffw_vJ0+g@mail.gmail.com>
 <5790FBF0.2060800@candelatech.com>
 <CA+uUJGv4qD=-su8792tWEHCJQg5soXfQ6trzb5mwxteXDD_ZRA@mail.gmail.com>
 <57919126.7000601@candelatech.com>
Message-ID: <CA+uUJGsf3MeGtdM=DmDOsFgmQNRpi8gbttFPw1ctJCxX0EsrwQ@mail.gmail.com>

Hi Ben,

Thanks for the info. I investigated further to find that the two
firmware params ENABLE_RTSCTS and RTS_THRESHOLD are not respected by
the firmware rate control. I completely ensured that these params are
always set such that RTS/CTS can never happen. Yet I can see RTS/CTS
exchanges. Further I found from the sniffed traces that these RTS/CTS
exchanges happen whenever there are A-MPDU re-transmissions i.e. the
whole A-MPDU is lost. I suppose with such an incident the firmware
rate control infers collisions and thus activates RTS/CTS for the next
A-MPDU.

Thus a crude workaround would be to bring down the A-MPDU
re-transmissions. With lower bitrates (NSS-1, MCS-0), obviously I can
see less RTS/CTS exchanges than with the higher ones. However, it
doesn't help my purpose. I also played around aggregation. The default
aggregation setting is to have AMSDUs of maximum size 3 within an
A-MPDU. Unlike I imagined earlier, there is no significant change in
the number of A-MPDU re-transmissions when I disable AMSDU completely
(of course for the same link quality).

I really wished that the firmware rate control totally respected the
ENABLE_RTSCTS param. Nevertheless are there any better suggestions to
lower the A-MPDU re-transmissions. It would be a great help to know.

Thanks,
Raj Joshi

On Fri, Jul 22, 2016 at 10:21 AM, Ben Greear <greearb at candelatech.com> wrote:
>
>
> On 07/21/2016 07:54 PM, Raj Joshi wrote:
>>
>> I am operating VHT (802.11ac) in AP-client configuration and thus
>> aggregation is inevitable (as per the standard) as well as desirable
>> (I suppose). I am receiving all A-MSDUs and not A-MPDUs. Now since
>> losses are expensive to recover in case of A-MSDUs than A-MPDUs, is
>> that the reason that there are intermittent RTS/CTS frames by rate
>> control?
>>
>> If the culprit is firmware rate-control, I can try setting the bitrate
>> mask and check again. Also how can I force the use of A-MPDUs rather
>> than A-MSDUs? If this is outside the purview of firmware rate control,
>> then I can try this one as well.
>
>
> AMPDU and AMSDU should work fine in STA and AP mode.  If you are using IBSS,
> then firmware must disable AMSDU since there seems to be some hardware bug
> with
> IBSS and AMSDU.
>
> I don't think you can affect RTS/CTS from the host.  I think it would
> require
> a firmware code change to disable RTS/CTS rate-code entries.
>
> I think there is a way to set the AMSDU size, and you could make it small
> enough to effectively disable AMSDU.
>
> Thanks,
> Ben
>
>
>>
>> Thanks,
>> Raj Joshi
>>
>>
>> On Fri, Jul 22, 2016 at 12:44 AM, Ben Greear <greearb at candelatech.com>
>> wrote:
>>>
>>> On 07/21/2016 07:29 AM, Krishna Chaitanya wrote:
>>>>
>>>>
>>>> On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <rajjoshi at comp.nus.edu.sg>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I am trying to "completely" disable RTS/CTS.
>>>>>
>>>>> * Case 1: Using iw/iwconfig when I set the sender's RTS threshold to a
>>>>> very high value (RTS thr=10000 B), I expect that no RTS should be
>>>>> sent. However, it seems that this threshold is not being honored and I
>>>>> can sniff large number of RTS/CTS frames. I verified that no A-MSDU is
>>>>> exceeding 10000 B.
>>>>> * Case 2: Interestingly, when I set the sender's RTS threshold to off
>>>>> (RTS thr:off), compared to case #1 much less number of RTS/CTS frames
>>>>> are seen and throughput is seen to improve. But I can still see
>>>>> RTS/CTS frames being sent.
>>>>> * Since the channel is clear and much isolated, and there is just one
>>>>> AP and one STA, there is negligible chance of other factors playing
>>>>> any role.
>>>>> * There is one change though that I have disabled dynamic bandwidth
>>>>> i.e. ar->wmi.pdev_param->dynamic_bw set zero in mac.c. I believe this
>>>>> is likely not an issue as similar RTS/CTS behavior is seen even with
>>>>> dynamic_bw set to 1 (there are no heterogeneous channel widths in the
>>>>> network in any case).
>>>>> * Another thing I noticed is that the RTS/CTS protection mode if set,
>>>>> it is set to CTS-to-self, rather than "RTS/CTS" i.e.
>>>>> ar->wmi.vdev_param->protection_mode in mac.c is either set to 1 or 0
>>>>> (depending upon use_cts_prot), but not 2. This probably seems not
>>>>> helpful in hidden node scenarios as the CTS frame is unicasted instead
>>>>> broadcasting.
>>>>>
>>>>> I would appreciate any pointers on completely disabling RTS/CTS as
>>>>> well as the ability to choose between complete RTS/CTS versus
>>>>> CTS-to-self whenever RTS/CTS is enabled.
>>>>
>>>>
>>>> Which mode is this? For aggregated frames (AMPDU) RTS Threshold is
>>>> not checked, so it can still be enabled
>>>
>>>
>>>
>>> Probably would require firmware changes to fully disable RTS/CTS
>>> from what I recall when I was reading the rate-ctrl code...
>>>
>>> Thanks,
>>> Ben
>>>
>>>>
>>>> _______________________________________________
>>>> ath10k mailing list
>>>> ath10k at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>
>>>
>>>
>>> --
>>> Ben Greear <greearb at candelatech.com>
>>> Candela Technologies Inc  http://www.candelatech.com
>>>
>>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
Raj Joshi


On Fri, Jul 22, 2016 at 11:21 AM, Ben Greear <greearb at candelatech.com> wrote:
>
>
> On 07/21/2016 07:54 PM, Raj Joshi wrote:
>>
>> I am operating VHT (802.11ac) in AP-client configuration and thus
>> aggregation is inevitable (as per the standard) as well as desirable
>> (I suppose). I am receiving all A-MSDUs and not A-MPDUs. Now since
>> losses are expensive to recover in case of A-MSDUs than A-MPDUs, is
>> that the reason that there are intermittent RTS/CTS frames by rate
>> control?
>>
>> If the culprit is firmware rate-control, I can try setting the bitrate
>> mask and check again. Also how can I force the use of A-MPDUs rather
>> than A-MSDUs? If this is outside the purview of firmware rate control,
>> then I can try this one as well.
>
>
> AMPDU and AMSDU should work fine in STA and AP mode.  If you are using IBSS,
> then firmware must disable AMSDU since there seems to be some hardware bug
> with
> IBSS and AMSDU.
>
> I don't think you can affect RTS/CTS from the host.  I think it would
> require
> a firmware code change to disable RTS/CTS rate-code entries.
>
> I think there is a way to set the AMSDU size, and you could make it small
> enough to effectively disable AMSDU.
>
> Thanks,
> Ben
>
>
>>
>> Thanks,
>> Raj Joshi
>>
>>
>> On Fri, Jul 22, 2016 at 12:44 AM, Ben Greear <greearb at candelatech.com>
>> wrote:
>>>
>>> On 07/21/2016 07:29 AM, Krishna Chaitanya wrote:
>>>>
>>>>
>>>> On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <rajjoshi at comp.nus.edu.sg>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I am trying to "completely" disable RTS/CTS.
>>>>>
>>>>> * Case 1: Using iw/iwconfig when I set the sender's RTS threshold to a
>>>>> very high value (RTS thr=10000 B), I expect that no RTS should be
>>>>> sent. However, it seems that this threshold is not being honored and I
>>>>> can sniff large number of RTS/CTS frames. I verified that no A-MSDU is
>>>>> exceeding 10000 B.
>>>>> * Case 2: Interestingly, when I set the sender's RTS threshold to off
>>>>> (RTS thr:off), compared to case #1 much less number of RTS/CTS frames
>>>>> are seen and throughput is seen to improve. But I can still see
>>>>> RTS/CTS frames being sent.
>>>>> * Since the channel is clear and much isolated, and there is just one
>>>>> AP and one STA, there is negligible chance of other factors playing
>>>>> any role.
>>>>> * There is one change though that I have disabled dynamic bandwidth
>>>>> i.e. ar->wmi.pdev_param->dynamic_bw set zero in mac.c. I believe this
>>>>> is likely not an issue as similar RTS/CTS behavior is seen even with
>>>>> dynamic_bw set to 1 (there are no heterogeneous channel widths in the
>>>>> network in any case).
>>>>> * Another thing I noticed is that the RTS/CTS protection mode if set,
>>>>> it is set to CTS-to-self, rather than "RTS/CTS" i.e.
>>>>> ar->wmi.vdev_param->protection_mode in mac.c is either set to 1 or 0
>>>>> (depending upon use_cts_prot), but not 2. This probably seems not
>>>>> helpful in hidden node scenarios as the CTS frame is unicasted instead
>>>>> broadcasting.
>>>>>
>>>>> I would appreciate any pointers on completely disabling RTS/CTS as
>>>>> well as the ability to choose between complete RTS/CTS versus
>>>>> CTS-to-self whenever RTS/CTS is enabled.
>>>>
>>>>
>>>> Which mode is this? For aggregated frames (AMPDU) RTS Threshold is
>>>> not checked, so it can still be enabled
>>>
>>>
>>>
>>> Probably would require firmware changes to fully disable RTS/CTS
>>> from what I recall when I was reading the rate-ctrl code...
>>>
>>> Thanks,
>>> Ben
>>>
>>>>
>>>> _______________________________________________
>>>> ath10k mailing list
>>>> ath10k at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>
>>>
>>>
>>> --
>>> Ben Greear <greearb at candelatech.com>
>>> Candela Technologies Inc  http://www.candelatech.com
>>>
>>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
Raj Joshi


On Fri, Jul 22, 2016 at 10:21 AM, Ben Greear <greearb at candelatech.com> wrote:
>
>
> On 07/21/2016 07:54 PM, Raj Joshi wrote:
>>
>> I am operating VHT (802.11ac) in AP-client configuration and thus
>> aggregation is inevitable (as per the standard) as well as desirable
>> (I suppose). I am receiving all A-MSDUs and not A-MPDUs. Now since
>> losses are expensive to recover in case of A-MSDUs than A-MPDUs, is
>> that the reason that there are intermittent RTS/CTS frames by rate
>> control?
>>
>> If the culprit is firmware rate-control, I can try setting the bitrate
>> mask and check again. Also how can I force the use of A-MPDUs rather
>> than A-MSDUs? If this is outside the purview of firmware rate control,
>> then I can try this one as well.
>
>
> AMPDU and AMSDU should work fine in STA and AP mode.  If you are using IBSS,
> then firmware must disable AMSDU since there seems to be some hardware bug
> with
> IBSS and AMSDU.
>
> I don't think you can affect RTS/CTS from the host.  I think it would
> require
> a firmware code change to disable RTS/CTS rate-code entries.
>
> I think there is a way to set the AMSDU size, and you could make it small
> enough to effectively disable AMSDU.
>
> Thanks,
> Ben
>
>
>>
>> Thanks,
>> Raj Joshi
>>
>>
>> On Fri, Jul 22, 2016 at 12:44 AM, Ben Greear <greearb at candelatech.com>
>> wrote:
>>>
>>> On 07/21/2016 07:29 AM, Krishna Chaitanya wrote:
>>>>
>>>>
>>>> On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <rajjoshi at comp.nus.edu.sg>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I am trying to "completely" disable RTS/CTS.
>>>>>
>>>>> * Case 1: Using iw/iwconfig when I set the sender's RTS threshold to a
>>>>> very high value (RTS thr=10000 B), I expect that no RTS should be
>>>>> sent. However, it seems that this threshold is not being honored and I
>>>>> can sniff large number of RTS/CTS frames. I verified that no A-MSDU is
>>>>> exceeding 10000 B.
>>>>> * Case 2: Interestingly, when I set the sender's RTS threshold to off
>>>>> (RTS thr:off), compared to case #1 much less number of RTS/CTS frames
>>>>> are seen and throughput is seen to improve. But I can still see
>>>>> RTS/CTS frames being sent.
>>>>> * Since the channel is clear and much isolated, and there is just one
>>>>> AP and one STA, there is negligible chance of other factors playing
>>>>> any role.
>>>>> * There is one change though that I have disabled dynamic bandwidth
>>>>> i.e. ar->wmi.pdev_param->dynamic_bw set zero in mac.c. I believe this
>>>>> is likely not an issue as similar RTS/CTS behavior is seen even with
>>>>> dynamic_bw set to 1 (there are no heterogeneous channel widths in the
>>>>> network in any case).
>>>>> * Another thing I noticed is that the RTS/CTS protection mode if set,
>>>>> it is set to CTS-to-self, rather than "RTS/CTS" i.e.
>>>>> ar->wmi.vdev_param->protection_mode in mac.c is either set to 1 or 0
>>>>> (depending upon use_cts_prot), but not 2. This probably seems not
>>>>> helpful in hidden node scenarios as the CTS frame is unicasted instead
>>>>> broadcasting.
>>>>>
>>>>> I would appreciate any pointers on completely disabling RTS/CTS as
>>>>> well as the ability to choose between complete RTS/CTS versus
>>>>> CTS-to-self whenever RTS/CTS is enabled.
>>>>
>>>>
>>>> Which mode is this? For aggregated frames (AMPDU) RTS Threshold is
>>>> not checked, so it can still be enabled
>>>
>>>
>>>
>>> Probably would require firmware changes to fully disable RTS/CTS
>>> from what I recall when I was reading the rate-ctrl code...
>>>
>>> Thanks,
>>> Ben
>>>
>>>>
>>>> _______________________________________________
>>>> ath10k mailing list
>>>> ath10k at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>
>>>
>>>
>>> --
>>> Ben Greear <greearb at candelatech.com>
>>> Candela Technologies Inc  http://www.candelatech.com
>>>
>>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com


From mohammed at qti.qualcomm.com  Wed Jul 27 08:04:56 2016
From: mohammed at qti.qualcomm.com (Mohammed Shafi Shajakhan)
Date: Wed, 27 Jul 2016 20:34:56 +0530
Subject: [PATCH] ath10k: Remove driver log suggesting QCA9887 support is
 experimental
Message-ID: <1469631896-9852-1-git-send-email-mohammed@qca.qualcomm.com>

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

Support for QCA9887 is no longer experimental and if there are any issues
we need to address them

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

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index f06dd39..f3d943c 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3144,7 +3144,6 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
 		pci_hard_reset = ath10k_pci_qca988x_chip_reset;
 		break;
 	case QCA9887_1_0_DEVICE_ID:
-		dev_warn(&pdev->dev, "QCA9887 support is still experimental, there are likely bugs. You have been warned.\n");
 		hw_rev = ATH10K_HW_QCA9887;
 		pci_ps = false;
 		pci_soft_reset = ath10k_pci_warm_reset;
-- 
1.9.1



From greearb at candelatech.com  Wed Jul 27 10:26:27 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 27 Jul 2016 10:26:27 -0700
Subject: [PATCH] ath10k: Allow setting coverage class
In-Reply-To: <1469608424-11370-1-git-send-email-benjamin@sipsolutions.net>
References: <1469608424-11370-1-git-send-email-benjamin@sipsolutions.net>
Message-ID: <5798EEC3.5040008@candelatech.com>

On 07/27/2016 01:33 AM, Benjamin Berg wrote:
> Unfortunately ath10k does not generally allow modifying the coverage class
> with the stock firmware and Qualcomm has so far refused to implement this
> feature so that it can be properly supported in ath10k. If we however know
> the registers that need to be modified for proper operation with a higher
> coverage class, then we can do these modifications from the driver.
>
> This patch implements this hack for first generation cards which are based
> on a core that is similar to ath9k. The registers are modified in place and
> need to be re-written every time the firmware sets them. To achieve this
> the register status is verified after any event from the firmware.
>
> The coverage class may not be modified temporarily right after the card
> re-initializes the registers. This is for example the case during scanning.
>
> A warning will be generated if the hack is not supported on the card or
> unexpected values are hit. There is no error reporting for userspace
> applications though (this is a limitation in the mac80211 driver
> interface).
>
> Thanks to Sebastian Gottschall <s.gottschall at dd-wrt.com> for initially
> working on a userspace support for this. This patch wouldn't have been
> possible without this documentation.

I would be concerned about the various resets firmware does to work around
hardware hangs as well.  I don't think any events are generated for these, unless
you count the dbglog messages?

Thanks,
Ben

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



From greearb at candelatech.com  Wed Jul 27 10:41:57 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 27 Jul 2016 10:41:57 -0700
Subject: Coverage class on ath10k
In-Reply-To: <5798173A.50001@solectek.com>
References: <mailman.34731.1463383905.1639.ath10k@lists.infradead.org>
 <5798173A.50001@solectek.com>
Message-ID: <5798F265.2010106@candelatech.com>

On 07/26/2016 07:06 PM, Petar Vutov wrote:
> Hi All,
>
> Does anyone know how I can modify coverage class for ath10k?
>
> It looks like that command  'iw phy0 set distance <meters>' doesn't get to the firmware on QCA98XX due to missing function set_coverage_class.
>
> Is there any other way to manipulate ack timeout and slot time on the firmware?

It requires some small tweaks to the firmware, or something like the huge hack
that was just posted to the ath10k mailing list.

Thanks,
Ben

>
> Thanks,
>
> Petar Vutov
> Director of Software Engineering
> Solectek Corp.
> 8969 Kenamar Drive, Suite 113
> San Diego, CA 92121
> 1-858-450-1220 Ext 3008
> www.solectek.com
>
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>


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



From gaurang at vt.edu  Wed Jul 27 15:42:19 2016
From: gaurang at vt.edu (Gaurang Ramesh Naik)
Date: Wed, 27 Jul 2016 18:42:19 -0400
Subject: Use Channel Switch Announcement (CSA) without DFS
Message-ID: <CAFc9h7vkdFcns6zaeO0mAVPGAqcY62t5D2gNY5d6GkW=pwjVTA@mail.gmail.com>

Hi All,

Is it possible to use CSA when the AP operates on channel that do not
require DFS? Can I trigget CSA from the AP in some way?

Thanks,
GN.


From michal.kazior at tieto.com  Wed Jul 27 22:02:30 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 28 Jul 2016 07:02:30 +0200
Subject: Use Channel Switch Announcement (CSA) without DFS
In-Reply-To: <CAFc9h7vkdFcns6zaeO0mAVPGAqcY62t5D2gNY5d6GkW=pwjVTA@mail.gmail.com>
References: <CAFc9h7vkdFcns6zaeO0mAVPGAqcY62t5D2gNY5d6GkW=pwjVTA@mail.gmail.com>
Message-ID: <CA+BoTQkw29PvZXqvX5oe2-cyvNURMY3G-SKsv6FqxD7BN2yyHw@mail.gmail.com>

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

You can ask hostapd via hostapd_cli to:

 chan_switch 5 5180

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


Micha?


From gaurang at vt.edu  Wed Jul 27 22:06:54 2016
From: gaurang at vt.edu (Gaurang Ramesh Naik)
Date: Thu, 28 Jul 2016 01:06:54 -0400
Subject: Use Channel Switch Announcement (CSA) without DFS
In-Reply-To: <CA+BoTQkw29PvZXqvX5oe2-cyvNURMY3G-SKsv6FqxD7BN2yyHw@mail.gmail.com>
References: <CAFc9h7vkdFcns6zaeO0mAVPGAqcY62t5D2gNY5d6GkW=pwjVTA@mail.gmail.com>
 <CA+BoTQkw29PvZXqvX5oe2-cyvNURMY3G-SKsv6FqxD7BN2yyHw@mail.gmail.com>
Message-ID: <CAFc9h7vxPkTuU2rpxCP_oN825V7cJNTVSK2JxhDbDRNKsv9Wpg@mail.gmail.com>

Thank you so much! Exactly what I was looking for.

On Thu, Jul 28, 2016 at 1:02 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 28 July 2016 at 00:42, Gaurang Ramesh Naik <gaurang at vt.edu> wrote:
>> Hi All,
>>
>> Is it possible to use CSA when the AP operates on channel that do not
>> require DFS? Can I trigget CSA from the AP in some way?
>
> You can ask hostapd via hostapd_cli to:
>
>  chan_switch 5 5180
>
> This will start CSA with CS count=5 to frequency 5180. If you type
> chan_switch without argument I believe you should get help/usage on
> the command.
>
>
> Micha?


From kvalo at qca.qualcomm.com  Thu Jul 28 03:52:56 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 28 Jul 2016 12:52:56 +0200
Subject: ath10k: fix get rx_status from htt context
In-Reply-To: <1469551552-845-1-git-send-email-arnagara@qti.qualcomm.com>
Message-ID: <23fc0be38ebd49c8a320182cf2d9d7e0@euamsexm01a.eu.qualcomm.com>

Ashok Raj Nagarajan <arnagara at qti.qualcomm.com> wrote:
> On handling amsdu on rx path, get the rx_status from htt context. Without this
> fix, we are seeing warnings when running DBDC traffic like this.
> 
> WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:4105 ieee80211_rx_napi+0x88/0x7d8 [mac80211]()
> 
> [ 1715.878248] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.18.21 #1
> [ 1715.878273] [<c001d3f4>] (unwind_backtrace) from [<c001a4b0>] (show_stack+0x10/0x14)
> [ 1715.878293] [<c001a4b0>] (show_stack) from [<c01bee64>] (dump_stack+0x70/0xbc)
> [ 1715.878315] [<c01bee64>] (dump_stack) from [<c002a61c>] (warn_slowpath_common+0x64/0x88)
> [ 1715.878339] [<c002a61c>] (warn_slowpath_common) from [<c002a6d0>] (warn_slowpath_null+0x18/0x20)
> [ 1715.878395] [<c002a6d0>] (warn_slowpath_null) from [<bf4caa98>] (ieee80211_rx_napi+0x88/0x7d8 [mac80211])
> [ 1715.878474] [<bf4caa98>] (ieee80211_rx_napi [mac80211]) from [<bf568658>] (ath10k_htt_t2h_msg_handler+0xb48/0xbfc [ath10k_core])
> [ 1715.878535] [<bf568658>] (ath10k_htt_t2h_msg_handler [ath10k_core]) from [<bf568708>] (ath10k_htt_t2h_msg_handler+0xbf8/0xbfc [ath10k_core])
> [ 1715.878597] [<bf568708>] (ath10k_htt_t2h_msg_handler [ath10k_core]) from [<bf569160>] (ath10k_htt_txrx_compl_task+0xa54/0x1170 [ath10k_core])
> [ 1715.878639] [<bf569160>] (ath10k_htt_txrx_compl_task [ath10k_core]) from [<c002db14>] (tasklet_action+0xb4/0x130)
> [ 1715.878659] [<c002db14>] (tasklet_action) from [<c002d110>] (__do_softirq+0xe0/0x210)
> [ 1715.878678] [<c002d110>] (__do_softirq) from [<c002d4b4>] (irq_exit+0x84/0xe0)
> [ 1715.878700] [<c002d4b4>] (irq_exit) from [<c005a544>] (__handle_domain_irq+0x98/0xd0)
> [ 1715.878722] [<c005a544>] (__handle_domain_irq) from [<c00085f4>] (gic_handle_irq+0x38/0x5c)
> [ 1715.878741] [<c00085f4>] (gic_handle_irq) from [<c0009680>] (__irq_svc+0x40/0x74)
> [ 1715.878753] Exception stack(0xc05f9f50 to 0xc05f9f98)
> [ 1715.878767] 9f40: ffffffed 00000000 00399e1e c000a220
> [ 1715.878786] 9f60: 00000000 c05f6780 c05f8000 00000000 c05f5db8 ffffffed c05f8000 c04d1980
> [ 1715.878802] 9f80: 00000000 c05f9f98 c0018110 c0018114 60000013 ffffffff
> [ 1715.878822] [<c0009680>] (__irq_svc) from [<c0018114>] (arch_cpu_idle+0x2c/0x50)
> [ 1715.878844] [<c0018114>] (arch_cpu_idle) from [<c00530d4>] (cpu_startup_entry+0x108/0x234)
> [ 1715.878866] [<c00530d4>] (cpu_startup_entry) from [<c05c7be0>] (start_kernel+0x33c/0x3b8)
> [ 1715.878879] ---[ end trace 6d5e1cc0fef8ed6a ]---
> [ 1715.878899] ------------[ cut here ]------------
> 
> Fixes: 18235664e7f9 ("ath10k: cleanup amsdu processing for rx indication")
> Signed-off-by: Ashok Raj Nagarajan <arnagara at qti.qualcomm.com>

I'm planning to push this to 4.8 if no objections.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9248457/



From kvalo at qca.qualcomm.com  Thu Jul 28 03:53:48 2016
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 28 Jul 2016 12:53:48 +0200
Subject: ath10k: Remove driver log suggesting QCA9887 support is
 experimental
In-Reply-To: <1469631896-9852-1-git-send-email-mohammed@qca.qualcomm.com>
Message-ID: <d5f3b2d785f8445399c15158db26c79c@euamsexm01a.eu.qualcomm.com>

Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>
> 
> Support for QCA9887 is no longer experimental and if there are any issues
> we need to address them
> 
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed at qti.qualcomm.com>

I'm planning to push this to 4.8 if no objections.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9249941/



From arend.vanspriel at broadcom.com  Thu Jul 28 12:23:35 2016
From: arend.vanspriel at broadcom.com (Arend van Spriel)
Date: Thu, 28 Jul 2016 21:23:35 +0200
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <20160722220526.GL5537@wotan.suse.de>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
 <20160721070938.GA2658@redhat.com>
 <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>
 <20160721080541.GB2658@redhat.com> <5790A28F.8030102@redhat.com>
 <20160721115122.GA31869@redhat.com>
 <a264e995-fc46-7fcd-69f9-80992385b6b1@broadcom.com>
 <20160722220526.GL5537@wotan.suse.de>
Message-ID: <c3bbb2f3-f551-41bf-ba29-c75f78b5b9ed@broadcom.com>



On 23-07-16 00:05, Luis R. Rodriguez wrote:
> On Fri, Jul 22, 2016 at 10:38:24AM +0200, Arend Van Spriel wrote:
>> + Luis
>>
>> On 21-7-2016 13:51, Stanislaw Gruszka wrote:
>>> (cc: firmware and brcmfmac maintainers)
>>>
>>> On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
>>>>
>>>>
>>>> On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
>>>>> On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
>>>>>> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
>>>>>>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
>>>>>>>> Firmware files are versioned to prevent older
>>>>>>>> driver instances to load unsupported firmware
>>>>>>>> blobs. This is reflected with a fallback logic
>>>>>>>> which attempts to load several firmware files.
>>>>>>>>
>>>>>>>> This however produced a lot of unnecessary
>>>>>>>> warnings sometimes confusing users and leading
>>>>>>>> them to rename firmware files making things even
>>>>>>>> more confusing.
>>>>>>>
>>>>>>> This happens on kernels configured with
>>>>>>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
>>>>>>> but also 60 seconds delay before loading next firmware version.
>>>>>>> For some reason RHEL kernel needs above config option, so this
>>>>>>> patch is very welcome from my perspective.
>>>>>>>
>>>>>>
>>>>>> Sorry for my ignorance but how does the firmware loading work if not
>>>>>> with udev's help?
>>>>>
>>>>> I'm not sure exactly, but I think kernel VFS layer is capable to copy
>>>>> file data directly from mounted filesystem without user space helper.
>>>>
>>>> Here's the situation: request_firmware() waits 60 seconds for udev to do its
>>>> loading magic via a "usermode helper".  This delay is there to allow, for
>>>> example, userspace to unpack or download a new firmware image or verify the
>>>> firmware image *in userspace* before providing it to the driver to apply to the HW.
>>>>
>>>> Why 60 seconds?  It is arbitrary and there is no way for udev & the kernel to
>>>> handshake on completion.
>>>>
>>>>>
>>>>>> As you can imagine, iwlwifi is suffering from the
>>>>>> same problem and I would be interested in applying the same change,
>>>>>> but I'd love to understand a bit more :)
>>>>>
>>>>> Yes, iwlwifi (and some other drivers) suffer from this. However this
>>>>> happen when the newest firmware version is not installed on the system
>>>>> and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
>>>>> it's not common.
>>>>
>>>> request_firmware_direct() was introduced at my request because (as you've
>>>> noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
>>>> periods of time when starting.  The bug that this introduced was a 60 second
>>>> delay per logical cpu when starting a system.  On a 64 cpu system that meant the
>>>> boot would complete in a little over one hour.
>>>>
>>>>>
>>>>> I started to see this currently, because that option was enabled on 
>>>>> RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
>>>>> happened because of that, i.e. thermal device was not functional
>>>>> because f/w wasn't loaded due to big delay.
>>>>>
>>>>> I'm not sure if replacing to request_firmware_direct() is a good
>>>>> fix though. For example I can see this problem also on brcmfmac, which
>>>>> use request_firmware_nowait(). I think I would rather prefer special
>>>>> helper for firmware drivers that needs user helper and have
>>>>> request_firmware() be direct as default.
>>>>>
>>>>
>>>> The difference between request_firmware_direct() and request_firmware() is that
>>>> the _direct() version does not wait the 60 seconds for udev interaction.  The
>>>> only userspace check performed is to see if the file is there, and if the file
>>>> does exist it is provided to the driver to be applied to the hardware.
>>>>
>>>> So the real question to ask here is whether or not the ath10k, brcmfmac, and
>>>> iwlwifi require udev to do anything beyond checking for the existence and
>>>> loading the firmware image.  If they don't, then it is better to use
>>>> request_firmware_direct().
>>>
>>> They don't need that, like 99% of the drivers I think, hence changing the
>>> default seems to be more reasonable. However changing 3 drivers would work
>>> for me as well, and that change do not introduce risk of broking drivers
>>> that require udev fw download.
>>>
>>> iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
>>> use request_firmware_nowait(), so it first need to be converted to
>>> ordinary request_firmware(), but this should be doable and I can do
>>> that.
>>
>> I am going bonkers here. This is the Nth time a discussion pops up on
>> firmware API usage. I stopped counting N :-( So the first issue was that
>> the INIT was taking to long as we were requesting firmware during probe
>> which was executed in the INIT context. So we added a worker and
>> register the driver from there. There was probably a reason for
>> switching to _no_wait() as well, but I do not recall the details. The
>> things is I don't know if I need user-space or not. I just need firmware
>> to get the device up and running. We have changed our driver a couple of
>> times now to accommodate something that in my opinion should have been
>> abstracted behind the firmware API in the first place and now here is
>> another proposal to change the drivers. Come on!
> 
> Its a big mess, but a lot of it has to do with the fact that none of the
> issues have been well documented. Its also not clear what distros, driver
> developers or users should do. I've tried helping with by providing such
> documentation and also providing grammar rules to avoid further issues [0],
> hopefully this series will be merged soon.
> 
> [0] https://marc.info/?l=linux-kernel&m=146611775314567
> 
> Using grammar rules the hunt with coccinelle as of today's linux-next
> reveals there are only 2 explicit users of the usermode helper, and
> I've vetted for these as well in the above patch series.
> 
> Now, other than this users will experience the usermode helper if the
> distribution messed up and build their kernel with the fallback
> usermode helper. If this was done on some old kernel the only way
> to fix that is to fix that kernel build or change drivers to avoid
> the usermode helper explicitly, unfortunately some API calls cannot
> avoid it .... I've documented all this in the above series.
> 
>>> However I wonder if changing that will not broke the case when
>>> driver is build-in in the kernel and f/w is not yet available when
>>> driver start to initialize.
> 
> Indeed, tons of races are in theory possible here ;) technically since we use a
> common API to read files directly now, a race might also be possible for other
> users of the API on init as well. I have some grammar rules to test for this in
> development, that is to vet that not only the firmware API is checked and we
> avoid on init but also other callers that use the same read API.
> 
>>> Or maybe nowadays this is not the case
>>> any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w 
>>> images are build-in in the kernel or copied to initramfs?
> 
> The firmware API is a mess and I've been trying to correct that
> with a more flexible API.
> 
>> That is a nice idea, but I have not seen any change in that area. Could
>> have missed it.
> 
> Extensions to the fw API are IMHO best done through a newer flexible
> API, feel free to refer to this development tree if you'd like to
> contribute:
> 
> https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160616-sysdata-v2

So I had a look and noticed commit c8df68e83392 ("firmware: annotate
thou shalt not request fw on init or probe"). Now this conflicts with
our wireless driver. The original suggestion a long, long time ago was
to use IFF_UP as trigger to go and request firmware. However, for that
we would need to register a netdevice during probe, and consequently we
should also have a wiphy instance registered. However, that has all kind
of feature flags for which we need firmware running on the device to
query what is supported and what not. I can make a fair bet that
brcmfmac is not the only driver with such a requirement. So how can we
crack that nut.

Regards,
Arend


From arend.vanspriel at broadcom.com  Thu Jul 28 12:23:48 2016
From: arend.vanspriel at broadcom.com (Arend van Spriel)
Date: Thu, 28 Jul 2016 21:23:48 +0200
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <20160722221523.GM5537@wotan.suse.de>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
 <20160721070938.GA2658@redhat.com>
 <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>
 <20160721080541.GB2658@redhat.com> <5790A28F.8030102@redhat.com>
 <20160721115122.GA31869@redhat.com>
 <a264e995-fc46-7fcd-69f9-80992385b6b1@broadcom.com>
 <20160722102559.GA2662@redhat.com> <20160722221523.GM5537@wotan.suse.de>
Message-ID: <313899f0-5980-867c-eef1-afe2a984f85e@broadcom.com>



On 23-07-16 00:15, Luis R. Rodriguez wrote:
> On Fri, Jul 22, 2016 at 12:26:00PM +0200, Stanislaw Gruszka wrote:
>> On Fri, Jul 22, 2016 at 10:38:24AM +0200, Arend Van Spriel wrote:
>>> + Luis
>>>
>>> On 21-7-2016 13:51, Stanislaw Gruszka wrote:
>>>> (cc: firmware and brcmfmac maintainers)
>>>>
>>>> On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
>>>>>
>>>>>
>>>>> On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
>>>>>> On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
>>>>>>> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
>>>>>>>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
>>>>>>>>> Firmware files are versioned to prevent older
>>>>>>>>> driver instances to load unsupported firmware
>>>>>>>>> blobs. This is reflected with a fallback logic
>>>>>>>>> which attempts to load several firmware files.
>>>>>>>>>
>>>>>>>>> This however produced a lot of unnecessary
>>>>>>>>> warnings sometimes confusing users and leading
>>>>>>>>> them to rename firmware files making things even
>>>>>>>>> more confusing.
>>>>>>>>
>>>>>>>> This happens on kernels configured with
>>>>>>>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
>>>>>>>> but also 60 seconds delay before loading next firmware version.
>>>>>>>> For some reason RHEL kernel needs above config option, so this
>>>>>>>> patch is very welcome from my perspective.
>>>>>>>>
>>>>>>>
>>>>>>> Sorry for my ignorance but how does the firmware loading work if not
>>>>>>> with udev's help?
>>>>>>
>>>>>> I'm not sure exactly, but I think kernel VFS layer is capable to copy
>>>>>> file data directly from mounted filesystem without user space helper.
>>>>>
>>>>> Here's the situation: request_firmware() waits 60 seconds for udev to do its
>>>>> loading magic via a "usermode helper".  This delay is there to allow, for
>>>>> example, userspace to unpack or download a new firmware image or verify the
>>>>> firmware image *in userspace* before providing it to the driver to apply to the HW.
>>>>>
>>>>> Why 60 seconds?  It is arbitrary and there is no way for udev & the kernel to
>>>>> handshake on completion.
>>>>>
>>>>>>
>>>>>>> As you can imagine, iwlwifi is suffering from the
>>>>>>> same problem and I would be interested in applying the same change,
>>>>>>> but I'd love to understand a bit more :)
>>>>>>
>>>>>> Yes, iwlwifi (and some other drivers) suffer from this. However this
>>>>>> happen when the newest firmware version is not installed on the system
>>>>>> and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
>>>>>> it's not common.
>>>>>
>>>>> request_firmware_direct() was introduced at my request because (as you've
>>>>> noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
>>>>> periods of time when starting.  The bug that this introduced was a 60 second
>>>>> delay per logical cpu when starting a system.  On a 64 cpu system that meant the
>>>>> boot would complete in a little over one hour.
>>>>>
>>>>>>
>>>>>> I started to see this currently, because that option was enabled on 
>>>>>> RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
>>>>>> happened because of that, i.e. thermal device was not functional
>>>>>> because f/w wasn't loaded due to big delay.
>>>>>>
>>>>>> I'm not sure if replacing to request_firmware_direct() is a good
>>>>>> fix though. For example I can see this problem also on brcmfmac, which
>>>>>> use request_firmware_nowait(). I think I would rather prefer special
>>>>>> helper for firmware drivers that needs user helper and have
>>>>>> request_firmware() be direct as default.
>>>>>>
>>>>>
>>>>> The difference between request_firmware_direct() and request_firmware() is that
>>>>> the _direct() version does not wait the 60 seconds for udev interaction.  The
>>>>> only userspace check performed is to see if the file is there, and if the file
>>>>> does exist it is provided to the driver to be applied to the hardware.
>>>>>
>>>>> So the real question to ask here is whether or not the ath10k, brcmfmac, and
>>>>> iwlwifi require udev to do anything beyond checking for the existence and
>>>>> loading the firmware image.  If they don't, then it is better to use
>>>>> request_firmware_direct().
>>>>
>>>> They don't need that, like 99% of the drivers I think, hence changing the
>>>> default seems to be more reasonable. However changing 3 drivers would work
>>>> for me as well, and that change do not introduce risk of broking drivers
>>>> that require udev fw download.
>>>>
>>>> iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
>>>> use request_firmware_nowait(), so it first need to be converted to
>>>> ordinary request_firmware(), but this should be doable and I can do
>>>> that.
>>>
>>> I am going bonkers here. This is the Nth time a discussion pops up on
>>> firmware API usage. I stopped counting N :-( So the first issue was that
>>> the INIT was taking to long as we were requesting firmware during probe
>>> which was executed in the INIT context. So we added a worker and
>>> register the driver from there. There was probably a reason for
>>> switching to _no_wait() as well, but I do not recall the details. The
>>> things is I don't know if I need user-space or not. I just need firmware
>>> to get the device up and running. We have changed our driver a couple of
>>> times now to accommodate something that in my opinion should have been
>>> abstracted behind the firmware API in the first place and now here is
>>> another proposal to change the drivers. Come on!
>>
>> I understand you dislike that :-) Just to clarify the issue here:
>>
>> Some drivers (including brcmfmac) request new firmware images, which are
>> not yet available (i.e. development F/W versions) and then fall-back
>> to older firmware version and works perfectly fine.
> 
> The right way to address this of course is to extend the FW API
> so that a batch of firmware files can be hunted for and one can
> easily annotate as a driver developer which are optional and which are
> not. The API then will do everything for you.

That is more or less how I abstracted it in brcmfmac. Our batch only
consists of max two files with binary executable image and rf
calibration data, which may or may not be optional. So we do not have
firmware fallback sequence.

For iwlwifi and ath10k I guess the use-case is that the batch is an
ordered list from newest supported firmware to oldest supported firmware.

> I was considering this as a future extension to the firmware API
> through the new extensible firmware API, the sysdata API. I'd prefer
> to add that as a secondary step, but if someone wants to add support
> for it now feel free to send me some patches against my tree.
> 
>> However with CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y configured, in case
>> of missing F/W image, request firmware involve user space helper and
>> waits 60s (loading_timeout value from drivers/base/firmware_class.c),
>> what delays creating network interface and confuse users.
> 
> Correct, this has been a holy mess. One way to fix this on userspace
> is to upgrade systemd with an exception to the udev kmod helper,
> and avoid the timeout completely for kmod helper which loads drivers.
> 
> CONFIG_FW_LOADER_USER_HELPER_FALLBACK should be avoided.
> 
>> For brcmfmac this looks like this:
>>
>> [   15.160923] brcmfmac 0000:03:00.0: Direct firmware load for brcm/brcmfmac4356-pcie.txt failed with error -2
>> [   15.170759] brcmfmac 0000:03:00.0: Falling back to user helper
>> <snip>
>> [   75.709397] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 22 2015 06:16:41 version 7.35.180.119 (r594535) FWID 01-1a5c4016
>> [   75.736941] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code (0x30 0x30)
>>
>> Without CONFIG_FW_LOADER_USER_HELPER_FALLBACK first firmware request
>> silently fail and then instantly next F/W image is loaded.
> 
> Yup.
> 
>> Another option to solve to problem would be stop requesting not
>> available publicly firmware. However, I assume some drivers would
>> like to preserve that option.
> 
> No, this seems counter productive given that the firmware is expected
> to land eventually.
> 
>>>> However I wonder if changing that will not broke the case when
>>>> driver is build-in in the kernel and f/w is not yet available when
>>>> driver start to initialize. Or maybe nowadays this is not the case
>>>> any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w 
>>>> images are build-in in the kernel or copied to initramfs?
>>>
>>> That is a nice idea, but I have not seen any change in that area. Could
>>> have missed it.
>>
>> I believe this is how the things are already done, IOW switching to
>> request_firmware_direct() in the driver should be no harm.
> 
> We don't stuff firmware as built-in if the driver used MODULE_FIRMWARE()
> and the driver is built-in. What commit did that?
> 
> The right thing to do is distros should avoid
> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and if they are stuck with it, a
> systemd work around is possible. Upstream systemd already increased
> the timeout to 180 seconds. Upstream also added a udevd --event-timeout
> command line option, look into that. Other distros (OpenSUSE) avoids
> the kmod timeout ;)
> 
> The timeout thing was simply a mistake, specially for kmod and it wasn't
> well thought out. I've listed more serious implications for it here:
> 
> http://www.do-not-panic.com/2015/12/linux-asynchronous-probe.html

Thanks. Will read that.

Regards,
Arend


From mcgrof at kernel.org  Thu Jul 28 16:28:21 2016
From: mcgrof at kernel.org (Luis R. Rodriguez)
Date: Fri, 29 Jul 2016 01:28:21 +0200
Subject: [RFC] ath10k: silence firmware file probing warnings
In-Reply-To: <c3bbb2f3-f551-41bf-ba29-c75f78b5b9ed@broadcom.com>
References: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
 <20160721070938.GA2658@redhat.com>
 <CANUX_P3ADxi+RHkH=d8Ypcqy9WVKSu4JYH7K3HtTNCuWg3wCeQ@mail.gmail.com>
 <20160721080541.GB2658@redhat.com> <5790A28F.8030102@redhat.com>
 <20160721115122.GA31869@redhat.com>
 <a264e995-fc46-7fcd-69f9-80992385b6b1@broadcom.com>
 <20160722220526.GL5537@wotan.suse.de>
 <c3bbb2f3-f551-41bf-ba29-c75f78b5b9ed@broadcom.com>
Message-ID: <20160728232821.GB3296@wotan.suse.de>

On Thu, Jul 28, 2016 at 09:23:35PM +0200, Arend van Spriel wrote:
> On 23-07-16 00:05, Luis R. Rodriguez wrote:
> > The firmware API is a mess and I've been trying to correct that
> > with a more flexible API.

<-- snip -->

> > Extensions to the fw API are IMHO best done through a newer flexible
> > API, feel free to refer to this development tree if you'd like to
> > contribute:
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160616-sysdata-v2
> 
> So I had a look and noticed commit c8df68e83392 ("firmware: annotate
> thou shalt not request fw on init or probe"). Now this conflicts with
> our wireless driver. The original suggestion a long, long time ago was
> to use IFF_UP as trigger to go and request firmware. However, for that
> we would need to register a netdevice during probe, and consequently we
> should also have a wiphy instance registered. However, that has all kind
> of feature flags for which we need firmware running on the device to
> query what is supported and what not. I can make a fair bet that
> brcmfmac is not the only driver with such a requirement. So how can we
> crack that nut.

Glad you asked.

Despite my latest set of updates on documentation for the firmware_class [0] (not
yet merged), and it being based on the latest discussed and agreed upon we
really have nothing well ironed out for what you describe, so let's try
to figure that out now.

To be clear, folks had originally said using the firmware API on *init* was
dumb, and some of this came up because of the infamous systemd udev timeout.
For completeness, I've documented some of the history of this issue
in great detail [1], mostly because I had to deal with a bug at SUSE about
this, and find a proper solution. Avoiding re-iterating *exactly why* the
timeout for kmod was ill-founded, and assuming you all now buy that,
the summary of facts of the *why* it turns out to be a bad idea to use the
firmware API on init *or* probe:

  a) by default the driver model actually calls both init and probe serially and
     synchronously
  b) we have no deterministic way of being certain we have whatever filesystem
     the driver needed as ready, the firmware may live in initramfs, or may only
     be available later on the real filesystem, and even after that the system
     may be designed to pivot_root.

In terms of solutions, lets discuss, here are a few options I can think of:

  1) Because of b) if you know you are going to use the firmware API you should
     just stuff firmware that is needed on init or probe as built-in
     (CONFIG_EXTRA_FIRMWARE) or stuff it into initramfs. This approach is generally
     accepted, however there is no systematic approach to ensure this is done. Now
     that we have coccinelle grammar to find these drivers it should be relatively
     easy to identify them and require the firmware as part of the distribution's
     initramfs or peg them as part of CONFIG_EXTRA_FIRMWARE if a distro prefers that.

     The only issue with this approach is its left up to the distribution to resolve.

  2) If the driver *knows* that probe may take a while it can request the driver core
     to probe the driver asynchronously, it can do so by using:

static struct pci_driver foo_pci_driver = {
      ...
      .driver.probe_type = PROBE_PREFER_ASYNCHRONOUS,
};

    This would not really resolve the deterministic issues listed in b) and for
    this reason this is not really a firmware-API-on-probe solution -- its an
    annotation to help avoid delays boot due to knowing probe may take a while.

  3) Userspace that loads modules can / should pass the async probe generic
     module parameter "async_probe" (for instance 'modprobe ath10k async_probe')
     when loading all modules. This should already be relatively
     safe when using on modules. This is what systemd long ago assumed was
     being done anyway. Again, also this is not really a firmware-API-on-probe solution,
     it can however be used by systemd for instance to help avoid delays on
     boot due to module lengthy probe calls

As it stands we have no resolution for the deterministic existential issues of
the firmware but in practice 1-3 should help. 2-3 should probably be done
regardless. I've been meaning to send patches for 3) but haven't had time.

As far as the deterministic existential firmware issue... Since we're just
reading files from the filesystem now (there are exceptions to this, but my
goal is to corner-case this code with the sysdata API), if we really wanted
something rock solid for these drivers I suppose we could consider implementing
an event driven probe if a driver requests for async probe. For instance, if
async probe was requested and the driver has MODULE_FIRMWARE(firmware_name)
we could add a notifier to probe the driver once the firmware is accessible.

For all intents and purposes though -- although I know the real issue here
the deterministic way of knowing when firmware is available, in practice
annotating your driver with PROBE_PREFER_ASYNCHRONOUS should solve most
races. This would not be a resolution, but rather an annotation to the fact
your driver probe does take a while -- and should make most folks happy until
we have a proper deterministic firmware solution, I think.

I welcome other ideas.

[0] https://lkml.kernel.org/r/1466117661-22075-1-git-send-email-mcgrof at kernel.org
[1] http://www.do-not-panic.com/2015/12/linux-asynchronous-probe.html

  Luis


From Perry_Yuan at Dell.com  Fri Jul 29 00:45:12 2016
From: Perry_Yuan at Dell.com (Perry_Yuan at Dell.com)
Date: Fri, 29 Jul 2016 15:45:12 +0800
Subject: ath10k fail to load firmware
In-Reply-To: <20160719072754.GB2751@redhat.com>
References: <20160719070932.GA2751@redhat.com>
 <CA+BoTQn98UFuGT0NntdE1HgG9UmmwzS=JsGkLmeGoMHSFGyDRg@mail.gmail.com>
 <20160719072754.GB2751@redhat.com>
Message-ID: <A3D794F1192BBF449DF2EC3D7EE263F44A544E3A5C@SHAX7MCDC101.APAC.DELL.COM>

Dell - No Restrictions - Confidential

HI Stanislaw:
Now we have got the available firmware for DW1820 wireless card ,but we  found  one new problem .
I built   upstream  4.6.4  and 4.7  kernel  code  and install the kernel images , the wireless driver can work , which means I  can get  IP address and  ping  external network successfully .

But it cannot  work with  RHEL 7.3 test kernel   kernel-3.10.0-473.el7.x86_64.rpm . This kernel will  occur panic  frequently .
Even  system can get IP address from AP . but it cannot ping external  network .
So I would think the backport driver have some issue .
I have found some differences  with upstream 4.7 kernel code  where you  do backport   . I will  provide the kernel panic log later .



keep up the good work
Perry  Yuan
Dell | Client Software Group | Platform Sftwr Senior Engineer
office +86 21 22030689, mobile +86 18521512823
perry_yuan at dell.com
Please consider the environment before printing this email.

-----Original Message-----
From: Stanislaw Gruszka [mailto:sgruszka at redhat.com]
Sent: Tuesday, July 19, 2016 3:28 PM
To: Michal Kazior <michal.kazior at tieto.com>
Cc: Kalle Valo <kvalo at qca.qualcomm.com>; ath10k at lists.infradead.org; Yuan, Perry <Perry_Yuan at Dell.com>
Subject: Re: ath10k fail to load firmware

On Tue, Jul 19, 2016 at 09:18:01AM +0200, Michal Kazior wrote:
> On 19 July 2016 at 09:09, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
> > Perry from Dell has ath10k device, which do not work with current
> > linux-firmware. It's on RHEL kernel, however wirelss stack and
> > drivers are from 4.7-rc1 (I did not update to 4.7 final yet, since I
> > do not see ath10k fix, which could possibly help here). Partial
> > dmesg is in the attachment.
>
> hw.3 qca6174 chips tend to require very specific board data for proper
> calibration.
>
>   [ 3838.601884] ath10k_pci 0000: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 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 ed5f849a
>
> Your board-2.bin doesn't contain the matching board data and the
> driver then falls back to the older board API1 which is pretty much
> doomed to fail on qca6174 hw.3.
>
> @Kalle: Perhaps ath10k needs to fail early with an adequate message
> for qca6174 hw.3 if board API2 lookup fails (e.g. hw_params flag
> because this seems to be quite closely coupled with hardware itself).
>
> @Stanislaw: You either need to grab a more recent board-2.bin
> (https://github.com/kvalo/ath10k-firmware/tree/master/QCA6174/hw3.0),

@Perry, could you replace board-2.bin from above link on /lib/firmware/ath10k/QCA6174/hw3.0/ and check if that work ?

> 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 think we can wait till firmware will be updated upstream, however Dell would like to know if what we provide in new RHEL7 release will work on their hardware.

Thanks
Stanislaw


From Perry_Yuan at Dell.com  Fri Jul 29 02:07:46 2016
From: Perry_Yuan at Dell.com (Perry_Yuan at Dell.com)
Date: Fri, 29 Jul 2016 17:07:46 +0800
Subject: ath10k fail to load firmware
References: <20160719070932.GA2751@redhat.com>
 <CA+BoTQn98UFuGT0NntdE1HgG9UmmwzS=JsGkLmeGoMHSFGyDRg@mail.gmail.com>
 <20160719072754.GB2751@redhat.com> 
Message-ID: <A3D794F1192BBF449DF2EC3D7EE263F44A544E3AB0@SHAX7MCDC101.APAC.DELL.COM>

Hi Stanislaw:

We got the right firmware but the kernel kernel-3.10.0-473.el7.x86_64.rpm is still not working at all .
In order to fix the issue for DW1820 .  I am afraid  that you have to merge the below patches for RHEL7.3 kernel. I have verified those patches . DW1820 card driver is working well  on  -473  kernel  now .

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e50525bef593c3dd0564df676c567d77f7c20322

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8d0a0710ea0d22881fdb40eb79d346a98cc64ae6

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fee48cf8374569a3888fd8c8536283e6067f0cfb

Thanks .

keep up the good work
Perry? Yuan
Dell | Client Software Group | Platform Sftwr Senior Engineer
office +86 21 22030689, mobile +86 18521512823
perry_yuan at dell.com
Please consider the environment before printing this email.


-----Original Message-----
From: Yuan, Perry 
Sent: Friday, July 29, 2016 3:45 PM
To: 'Stanislaw Gruszka' <sgruszka at redhat.com>; Michal Kazior <michal.kazior at tieto.com>
Cc: Kalle Valo <kvalo at qca.qualcomm.com>; ath10k at lists.infradead.org; Shen, Yijun <Yijun_Shen at Dell.com>; David D Wang (David_D_Wang at dell.com) <David_D_Wang at dell.com>; Karl Hastings <karl at redhat.com>
Subject: RE: ath10k fail to load firmware

Dell - No Restrictions - Confidential 

HI Stanislaw:
Now we have got the available firmware for DW1820 wireless card ,but we  found  one new problem .
I built   upstream  4.6.4  and 4.7  kernel  code  and install the kernel images , the wireless driver can work , which means I  can get  IP address and  ping  external network successfully .

But it cannot  work with  RHEL 7.3 test kernel   kernel-3.10.0-473.el7.x86_64.rpm . This kernel will  occur panic  frequently .
Even  system can get IP address from AP . but it cannot ping external  network . 
So I would think the backport driver have some issue . 
I have found some differences  with upstream 4.7 kernel code  where you  do backport   . I will  provide the kernel panic log later .



keep up the good work
Perry? Yuan
Dell | Client Software Group | Platform Sftwr Senior Engineer office +86 21 22030689, mobile +86 18521512823 perry_yuan at dell.com Please consider the environment before printing this email.

-----Original Message-----
From: Stanislaw Gruszka [mailto:sgruszka at redhat.com]
Sent: Tuesday, July 19, 2016 3:28 PM
To: Michal Kazior <michal.kazior at tieto.com>
Cc: Kalle Valo <kvalo at qca.qualcomm.com>; ath10k at lists.infradead.org; Yuan, Perry <Perry_Yuan at Dell.com>
Subject: Re: ath10k fail to load firmware

On Tue, Jul 19, 2016 at 09:18:01AM +0200, Michal Kazior wrote:
> On 19 July 2016 at 09:09, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
> > Perry from Dell has ath10k device, which do not work with current 
> > linux-firmware. It's on RHEL kernel, however wirelss stack and 
> > drivers are from 4.7-rc1 (I did not update to 4.7 final yet, since I 
> > do not see ath10k fix, which could possibly help here). Partial 
> > dmesg is in the attachment.
> 
> hw.3 qca6174 chips tend to require very specific board data for proper 
> calibration.
> 
>   [ 3838.601884] ath10k_pci 0000: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 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 ed5f849a
> 
> Your board-2.bin doesn't contain the matching board data and the 
> driver then falls back to the older board API1 which is pretty much 
> doomed to fail on qca6174 hw.3.
> 
> @Kalle: Perhaps ath10k needs to fail early with an adequate message 
> for qca6174 hw.3 if board API2 lookup fails (e.g. hw_params flag 
> because this seems to be quite closely coupled with hardware itself).
> 
> @Stanislaw: You either need to grab a more recent board-2.bin 
> (https://github.com/kvalo/ath10k-firmware/tree/master/QCA6174/hw3.0),

@Perry, could you replace board-2.bin from above link on /lib/firmware/ath10k/QCA6174/hw3.0/ and check if that work ?

> 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 think we can wait till firmware will be updated upstream, however Dell would like to know if what we provide in new RHEL7 release will work on their hardware.

Thanks
Stanislaw


From benjamin at sipsolutions.net  Fri Jul 29 07:52:27 2016
From: benjamin at sipsolutions.net (Benjamin Berg)
Date: Fri, 29 Jul 2016 16:52:27 +0200
Subject: [PATCH] ath10k: Allow setting coverage class
In-Reply-To: <5798EEC3.5040008@candelatech.com>
 (sfid-20160727_192629_507046_B6A4A1EA)
References: <1469608424-11370-1-git-send-email-benjamin@sipsolutions.net>
 <5798EEC3.5040008@candelatech.com> (sfid-20160727_192629_507046_B6A4A1EA)
Message-ID: <1469803947.7306.139.camel@sipsolutions.net>

On Mi, 2016-07-27 at 10:26 -0700, Ben Greear wrote:
> On 07/27/2016 01:33 AM, Benjamin Berg wrote:
> > 
> > Unfortunately ath10k does not generally allow modifying the coverage class
> > with the stock firmware and Qualcomm has so far refused to implement this
> > feature so that it can be properly supported in ath10k. If we however know
> > the registers that need to be modified for proper operation with a higher
> > coverage class, then we can do these modifications from the driver.
> > 
> > This patch implements this hack for first generation cards which are based
> > on a core that is similar to ath9k. The registers are modified in place and
> > need to be re-written every time the firmware sets them. To achieve this
> > the register status is verified after any event from the firmware.
> > 
> > The coverage class may not be modified temporarily right after the card
> > re-initializes the registers. This is for example the case during scanning.
> > 
> > A warning will be generated if the hack is not supported on the card or
> > unexpected values are hit. There is no error reporting for userspace
> > applications though (this is a limitation in the mac80211 driver
> > interface).
> > 
> > > > Thanks to Sebastian Gottschall <s.gottschall at dd-wrt.com> for initially
> > working on a userspace support for this. This patch wouldn't have been
> > possible without this documentation.
> 
> I would be concerned about the various resets firmware does to work around
> hardware hangs as well.??I don't think any events are generated for these, unless
> you count the dbglog messages?

Yeah, I am aware of the fact that the firmware may do internal resets
from time to time. The interesting question (and one for which I do not
know the answer) is whether we get a wmi or other event under all
conditions where the register may be rewritten due to a reset.

The current code will re-set the register value after any wmi event
including debug messages. If this is not enough, then the only solution
might be to periodically poll the register values instead of relying on
a received event.

Benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20160729/974ad2c9/attachment.sig>

From greearb at candelatech.com  Fri Jul 29 08:09:40 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 29 Jul 2016 08:09:40 -0700
Subject: [PATCH] ath10k: Allow setting coverage class
In-Reply-To: <1469803947.7306.139.camel@sipsolutions.net>
References: <1469608424-11370-1-git-send-email-benjamin@sipsolutions.net>
 <5798EEC3.5040008@candelatech.com>
 <1469803947.7306.139.camel@sipsolutions.net>
Message-ID: <579B71B4.7080206@candelatech.com>

On 07/29/2016 07:52 AM, Benjamin Berg wrote:
> On Mi, 2016-07-27 at 10:26 -0700, Ben Greear wrote:
>> On 07/27/2016 01:33 AM, Benjamin Berg wrote:
>>>
>>> Unfortunately ath10k does not generally allow modifying the coverage class
>>> with the stock firmware and Qualcomm has so far refused to implement this
>>> feature so that it can be properly supported in ath10k. If we however know
>>> the registers that need to be modified for proper operation with a higher
>>> coverage class, then we can do these modifications from the driver.
>>>
>>> This patch implements this hack for first generation cards which are based
>>> on a core that is similar to ath9k. The registers are modified in place and
>>> need to be re-written every time the firmware sets them. To achieve this
>>> the register status is verified after any event from the firmware.
>>>
>>> The coverage class may not be modified temporarily right after the card
>>> re-initializes the registers. This is for example the case during scanning.
>>>
>>> A warning will be generated if the hack is not supported on the card or
>>> unexpected values are hit. There is no error reporting for userspace
>>> applications though (this is a limitation in the mac80211 driver
>>> interface).
>>>
>>>>> Thanks to Sebastian Gottschall <s.gottschall at dd-wrt.com> for initially
>>> working on a userspace support for this. This patch wouldn't have been
>>> possible without this documentation.
>>
>> I would be concerned about the various resets firmware does to work around
>> hardware hangs as well.  I don't think any events are generated for these, unless
>> you count the dbglog messages?
>
> Yeah, I am aware of the fact that the firmware may do internal resets
> from time to time. The interesting question (and one for which I do not
> know the answer) is whether we get a wmi or other event under all
> conditions where the register may be rewritten due to a reset.
>
> The current code will re-set the register value after any wmi event
> including debug messages. If this is not enough, then the only solution
> might be to periodically poll the register values instead of relying on
> a received event.

You will get a dbglog event at least most of the time, so maybe that
will be good enough.

Someone with src code and that cared could audit the code I guess, but then
that person could also just implement the feature properly in the firmware
to begin with...

Thanks,
Ben

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



From s.gottschall at dd-wrt.com  Fri Jul 29 09:44:09 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Fri, 29 Jul 2016 18:44:09 +0200
Subject: 9984 (and maybe others) rekeying issue
Message-ID: <5f28dce8-9212-5c58-4e8c-664c6379a222@dd-wrt.com>

i have simple configuration on a 9984 with wds ap

my laptop is connected (broadcom 802.11n chipset)

and 2 wds stations are connected (one is qca9984 and the other is 9880)

both stations but not my laptop disconnects every 60 minutes which seems 
to be related to wpa rekeying

(all interfaces are running wpa 2 personal)

any hint?


Sebastian

-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From s.gottschall at dd-wrt.com  Fri Jul 29 09:46:22 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Fri, 29 Jul 2016 18:46:22 +0200
Subject: 9984 noise calibration issue
Message-ID: <1b84b188-6abc-12d0-80f1-7f98f741c948@dd-wrt.com>

on 9984 the cyclic noise calibration doesnt seem to work unlike on 9880

on 9880 the channel noise floor changes cyclic depending on the environment

on 9984 the noise floor keeps static, only a channel change like 
triggered by a scan will update the noise floor to its new value.

and hint?


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From s.gottschall at dd-wrt.com  Fri Jul 29 09:38:26 2016
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Fri, 29 Jul 2016 18:38:26 +0200
Subject: [PATCH] ath10k: Allow setting coverage class
In-Reply-To: <579B71B4.7080206@candelatech.com>
References: <1469608424-11370-1-git-send-email-benjamin@sipsolutions.net>
 <5798EEC3.5040008@candelatech.com>
 <1469803947.7306.139.camel@sipsolutions.net>
 <579B71B4.7080206@candelatech.com>
Message-ID: <6ab675fa-4ba8-6272-9ffe-2f08c46daff1@dd-wrt.com>

if these sourcecodes would be just up to date with the binaries provided 
by qca. but qca doesnt seem to care that much about it.
this is mainly also the reason why there are soo many long term 
stability issues with no resolution


Am 29.07.2016 um 17:09 schrieb Ben Greear:
> On 07/29/2016 07:52 AM, Benjamin Berg wrote:
>> On Mi, 2016-07-27 at 10:26 -0700, Ben Greear wrote:
>>> On 07/27/2016 01:33 AM, Benjamin Berg wrote:
>>>>
>>>> Unfortunately ath10k does not generally allow modifying the 
>>>> coverage class
>>>> with the stock firmware and Qualcomm has so far refused to 
>>>> implement this
>>>> feature so that it can be properly supported in ath10k. If we 
>>>> however know
>>>> the registers that need to be modified for proper operation with a 
>>>> higher
>>>> coverage class, then we can do these modifications from the driver.
>>>>
>>>> This patch implements this hack for first generation cards which 
>>>> are based
>>>> on a core that is similar to ath9k. The registers are modified in 
>>>> place and
>>>> need to be re-written every time the firmware sets them. To achieve 
>>>> this
>>>> the register status is verified after any event from the firmware.
>>>>
>>>> The coverage class may not be modified temporarily right after the 
>>>> card
>>>> re-initializes the registers. This is for example the case during 
>>>> scanning.
>>>>
>>>> A warning will be generated if the hack is not supported on the 
>>>> card or
>>>> unexpected values are hit. There is no error reporting for userspace
>>>> applications though (this is a limitation in the mac80211 driver
>>>> interface).
>>>>
>>>>>> Thanks to Sebastian Gottschall <s.gottschall at dd-wrt.com> for 
>>>>>> initially
>>>> working on a userspace support for this. This patch wouldn't have been
>>>> possible without this documentation.
>>>
>>> I would be concerned about the various resets firmware does to work 
>>> around
>>> hardware hangs as well.  I don't think any events are generated for 
>>> these, unless
>>> you count the dbglog messages?
>>
>> Yeah, I am aware of the fact that the firmware may do internal resets
>> from time to time. The interesting question (and one for which I do not
>> know the answer) is whether we get a wmi or other event under all
>> conditions where the register may be rewritten due to a reset.
>>
>> The current code will re-set the register value after any wmi event
>> including debug messages. If this is not enough, then the only solution
>> might be to periodically poll the register values instead of relying on
>> a received event.
>
> You will get a dbglog event at least most of the time, so maybe that
> will be good enough.
>
> Someone with src code and that cared could audit the code I guess, but 
> then
> that person could also just implement the feature properly in the 
> firmware
> to begin with...
>
> Thanks,
> Ben
>


-- 
Mit freundlichen Gr?ssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Gesch?ftsf?hrer: Peter Steinh?user, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



From rajjoshi at comp.nus.edu.sg  Sat Jul 30 01:26:44 2016
From: rajjoshi at comp.nus.edu.sg (Raj Joshi)
Date: Sat, 30 Jul 2016 15:26:44 +0700
Subject: Broadcasting packets using ath10k
Message-ID: <CA+uUJGsgkx8MDr=7DjtBS++YcwCqdAfMjJ9f-RcDAaQ=SOi=ZQ@mail.gmail.com>

Hi all,

For some research experiments, I need to broadcast packets (at
different fixed rates using the bitrates mask). Think of it as a
standalone rudimentary 802.11ac wireless traffic generator.

Simply using iperf for a broadcast address is not allowed (in managed
mode at least) and so I have tried the multicast option. The multicast
option has the following issues:
1) The STA or the AP cannot be standalone: if STA is to be a
multicaster it needs to be associated with an AP and if the AP is to
be a multicaster it needs at least one STA to be associated with it.
2) Traffic direction: When the STA sends a packet to a multicast
address, the packet is first unicasted to the AP at the rate set by
the bitrates mask. The AP then acknowledges it with a blockACK and
further retransmits (multicasts) it with a basic rate (802.11a 6
Mbps). So there is no pure traffic generation. I even tried setting
TTL (number of hops) to zero, but no avail.
3) Cannot fix the rates: On the other hand, when the AP multicasts,
the traffic pattern is as expected - simple outgoing packets with no
blockACKs or other redirection. However, the AP doesn't honor the
bitrates masks and multicast traffic is sent using the basic rate. For
other traffic such as a regular UDP/TCP flow, the AP does honor the
bitrates mask.

Anyone has better ideas on putting together a rudimentary 802.11ac
traffic generator? It would be great to know :)

Thanks,
Raj Joshi


From leroi.lists at gmail.com  Sun Jul 31 16:35:36 2016
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Mon, 1 Aug 2016 02:35:36 +0300
Subject: [PATCH] ath10k: disable wake_tx_queue for older devices
In-Reply-To: <87zipt1kco.fsf@kamboji.qca.qualcomm.com>
References: <1463489221-24989-1-git-send-email-michal.kazior@tieto.com>
 <1467201146-6844-1-git-send-email-michal.kazior@tieto.com>
 <87zipt1kco.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CACiydb+yNc-UKVRFR-UxTq-YFBDpEDsa1qWNBGCHpe=_zv8o7g@mail.gmail.com>

On 7 July 2016 at 19:30, Valo, Kalle <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> Ideally wake_tx_queue should be used regardless as
>> it is a requirement for reducing bufferbloat and
>> implementing airtime fairness in the future.
>>
>> However some setups (typically low-end platforms
>> hosting QCA988X) suffer performance regressions
>> with the current wake_tx_queue implementation.
>> Therefore disable it unless it is really
>> beneficial with current codebase (which is when
>> firmware supports smart pull-push tx scheduling).
>>
>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>
> I think it's too late to send this to 4.7 anymore (and this due to my
> vacation). So I'm planning to queue this to 4.8, but if the feedback is
> positive we can always send this to a 4.7 stable release.
>

Sorry guys, drowned.
So, yes, applying this patch does the job. That is gets me to the
results similar to
https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041448.html

Going to try latest code on same system...

Regards,
Roman


